Based on your feedback and the continuing development, updated actions files will be made available on the files section of our project page.
If you wish to receive an email notification whenever we release updates of Privoxy or the actions file, subscribe to our announce mailing list, ijbswa-announce@lists.sourceforge.net.
The syntax, number, and purpose of configuration files has substantially changed from Junkbuster and earlier versions of Privoxy. The old files, like blocklist will not work at all. If you are upgrading from a 2.0.x version, you will need to port your configuration data to the new format. Note that even the pattern syntax has changed! Even configuration files from the 2.9.x versions will need to be adapted, as configuration syntax has been very much in flow in the 2.9.x series.
Actions files are where various actions that Privoxy might take while processing a certain request, are configured. Typically, you would define a set of default actions that apply to all URLs, then add exceptions to these defaults where needed.
Actions can be defined on a URL pattern basis, i.e. for single URLs, whole web sites, groups or parts thereof etc. Actions can also be grouped together and then applied to requests matching one or more patterns. There are many possible actions that might apply to any given site. As an example, if you are blocking cookies as one of your default actions, but need to accept cookies from a given site, you would need to define an exception for this site in one of your actions files, preferably in user.action
For a comprehensive discussion of the actions concept, please refer to the actions file chapter in the user manual. It includes a list of all actions and an actions file tutorial to get you started.
Actions files are just text files in a special syntax and can be edited with a text editor. The probably easiest way is to access Privoxy's user interface with your web browser at http://config.privoxy.org/ (Shortcut: http://p.p/) and then select "View & change the current configuration" from the menu.
As of Privoxy v2.9.15, three actions files are being included, to be used for different purposes: These are default.action, the "main" actions file which is actively maintained by the Privoxy developers, user.action, where users are encouraged to make their private customizations, and standard.action, which is for internal Privoxy use only. Please see the actions chapter in the user manual for a more detailed explanation.
Earlier versions included three different versions of the default.action file. The new scheme allows for greater flexibility of local configuration, and for browser based selection of pre-defined "aggressiveness" levels.
The default configuration shouldn't impact the usability of any of these services. It will, however, make all cookies temporary, so that your browser will forget your login credentials in between browser sessions. If you would like not to have to log in manually each time you access those websites, simply turn off all cookie handling for them in the user.action file. An example for yahoo might look like:
# Allow all cookies for Yahoo login:
#
{ -crunch-incoming-cookies -crunch-outgoing-cookies -session-cookies-only }
.login.yahoo.com |
Configuring Privoxy is not entirely trivial. To help you get started, we provide you with three different default action "packages" in the web based actions file editor at http://config.privoxy.org/show-status. The following table shows you, which of the most important features are enabled in each configuration:
Table 1. Default Configurations
| Feature | Cautious | Intermadiate | Advanced |
|---|---|---|---|
| Ad-blocking by URL | yes | yes | yes |
| Ad-filtering by size | yes | yes | yes |
| GIF de-animation | no | yes | yes |
| Referer forging | no | yes | yes |
| Cookie handling | none | session-only | kill |
| Pop-up killing | no | yes | yes |
| Fast redirects | no | no | yes |
| HTML taming | yes | yes | yes |
| JavaScript taming | yes | yes | yes |
| Web-bug killing | yes | yes | yes |
| Fun text replacements | no | no | yes |
| Image tag reordering | no | no | yes |
| Ad-filtering by link | no | no | yes |
Where the defaults are likely to break some sites, exceptions for known popular "problem" sites are included, but in general, the more aggressive your default settings are, the more exceptions you will have to make later. See the user manual for a more deatiled discussion.
It may seem strange that regular users can edit the config files with their browsers, although the whole /etc/privoxy hierarchy belongs to the user "privoxy", with only 644 permissions.
When you use the browser-based editor, Privoxy itself is writing to the config files. Because Privoxy is running as the user "privoxy", it can update the config files.
If you run Privoxy for multiple untrusted users (e.g. in a LAN), you will probably want to turn the web-based editor and remote toggle features off by setting "enable-edit-actions 0" and "enable-remote-toggle 0" in the main configuration file.
Note that in the default configuration, only local users (i.e. those on "localhost") can connect to Privoxy, so this is not (normally) a security problem.
The default.filter file is where filters are defined, which can be used to modify or remove, web page content on the fly. Filters apply to anything in the page source, including HTML tags, and JavaScript. Regular expressions are used to accomplish this. There are a number of pre-defined filters to deal with common annoyances. The filters are only defined here, to invoke them, you need to use the filter action in one of the actions files. Filtering is automatically disabled for inappropriate MIME types.
If you are familiar with regular expressions, and HTML, you can look at the provided default.filter with a text editor and define your own filters. This is potentially a very powerful feature, but requires some expertise in both regular expressions and HTML/HTTP.
Presently, there is no GUI editor option for this part of the configuration, but you can disable/enable the various pre-defined filters of the included default.filter file with the web-based actions file editor.
By default, Privoxy only responds to requests from 127.0.0.1 (localhost). To have it act as a server for a network, this needs to be changed in the main configuration file. Look for the listen-address option, which may be commented out with a "#" symbol. Make sure it is uncommented, and assign it the address of the LAN gateway interface, and port number to use. Assuming your LAN address is 192.168.1.1 and you wish to run Privoxy on port 8118, this line schould look like:
listen-address 192.168.1.1:8118 |
Save the file, and restart Privoxy. Configure all browsers on the network then to use this address and port number.
If you run Privoxy on a LAN with untrusted users, we recommend that you double-check the access control and security options!
The replacement for blocked images can be controlled with the set-image-blocker action. You have the choice of a checkerboard pattern, a transparent 1x1 GIF image (aka "blank"), or a redirect to a custom image of your choice. Note that this choice only has effect for images which are blocked as images, i.e. whose URLs match both a handle-as-image and block action.
If you want to see nothing, then change the set-image-blocker action to "blank". This can be done by editing the default.action file, or trough the web-based actions file editor.
Remember that telling which image is an ad and which isn't, is mostly guesswork. While we hope that the standard configuration is rather smart, it can and will make errors. The checkerboard image is visually decent, but it shows you that and where images were blocked, which can be very helpful in case some navigation aid or otherwise innocent image was erraneously blocked. Some people might also enjoy seeing how many banners they don't have to see..
This happens when the banners are not embedded in the HTML code of the page itself, but in separate HTML (sub)documents that are loaded into (i)frames or (i)layers, and these external HTML documents are blocked. Being non-images they get replaced by a substitute HTML page rather than a substitute image, which wouldn't work out technically, since the browser expects and accepts only HTML when it has requested an HTML document.
The substitute page adapts to the available space and shows itself as a miniature two-liner if loaded into small frames, or full-blown with a large red "BLOCKED" banner if space allows.
If you prefer the banners to be blocked by images, you must see to it that the HTML documents in which they are embedded are not blocked. Clicking the "See why" link offered in the substitute page will show you which rule blocked the page. After changing the rule and un-blocking the HTML documents, the browser will try to load the actual banner images and the usual image blocking will (hopefully!) kick in.
Yes, it can run as a system service using srvany.exe. The only catch is that this will effectively disable the Privoxy icon (and its menu!) in the taskbar. You can have one or the other, but not both at this time :(
There is a pending feature request for this functionality. See the discussion at http://sourceforge.net/tracker/?func=detail&atid=361118&aid=485617&group_id=11118, for details, and a sample configuration.
This can be done and is often useful to combine the benefits of Privoxy with those of a caching proxy. See the forwarding chapter in the user manual which describes how to do this.
No, Privoxy currently does not have this ability, though it is planned for a future release. Transparent proxies require special handling of the request headers beyond what Privoxy is now capable of.
Chaining Privoxy behind another proxy that has this ability should work though. See the forwarding chapter in the user manual. As a transparent proxy to be used for chaining we recommend Transproxy (http://www.transproxy.nlc.net.au/).