The actions files are used to define what actions Privoxy takes for which URLs, and thus determine how ad images, cookies and various other aspects of HTTP content and transactions are handled, and on which sites (or even parts thereof). There are three such files included with Privoxy (as of version 2.9.15), with differing purposes:
standard.action - is used by the web based editor, to set various pre-defined sets of rules for the default actions section in default.action. These have increasing levels of aggressiveness and have no influence on your browsing unless you select them explicitly in the editor. It is not recommend to edit this file.
default.action - is the primary action file that sets the initial values for all actions. It is intended to provide a base level of functionality for Privoxy's array of features. So it is a set of broad rules that should work reasonably well for users everywhere. This is the file that the developers are keeping updated, and making available to users.
user.action - is intended to be for local site preferences and exceptions. As an example, if your ISP or your bank has specific requirements, and need special handling, this kind of thing should go here. This file will not be upgraded.
The list of actions files to be used are defined in the main configuration file, and are processed in the order they are defined. The content of these can all be viewed and edited from http://config.privoxy.org/show-status.
An actions file typically has multiple sections. If you want to use "aliases" in an actions file, you have to place the (optional) alias section at the top of that file. Then comes the default set of rules which will apply universally to all sites and pages (be very careful with using such a universal set in user.action or any other actions file after default.action, because it will override the result from consulting any previous file). And then below that, exceptions to the defined universal policies. You can regard user.action as an appendix to default.action, with the advantage that is a separate file, which makes preserving your personal settings across Privoxy upgrades easier.
Actions can be used to block anything you want, including ads, banners, or just some obnoxious URL that you would rather not see. Cookies can be accepted or rejected, or accepted only during the current browser session (i.e. not written to disk), content can be modified, JavaScripts tamed, user-tracking fooled, and much more. See below for a complete list of actions.
Note that some actions, like cookie suppression or script disabling, may render some sites unusable that rely on these techniques to work properly. Finding the right mix of actions is not always easy and certainly a matter of personal taste. In general, it can be said that the more "aggressive" your default settings (in the top section of the actions file) are, the more exceptions for "trusted" sites you will have to make later. If, for example, you want to kill popup windows per default, you'll have to make exceptions from that rule for sites that you regularly use and that require popups for actually useful content, like maybe your bank, favorite shop, or newspaper.
We have tried to provide you with reasonable rules to start from in the distribution actions files. But there is no general rule of thumb on these things. There just are too many variables, and sites are constantly changing. Sooner or later you will want to change the rules (and read this chapter again :).
The easiest way to edit the actions files is with a browser by using our browser-based editor, which can be reached from http://config.privoxy.org/show-status. The editor allows both fine-grained control over every single feature on a per-URL basis, and easy choosing from wholesale sets of defaults like "Cautious", "Medium" or "Advanced".
If you prefer plain text editing to GUIs, you can of course also directly edit the the actions files. Look at default.action which is richly commented.
Actions files are divided into sections. There are special sections, like the "alias" sections which will be discussed later. For now let's concentrate on regular sections: They have a heading line (often split up to multiple lines for readability) which consist of a list of actions, separated by whitespace and enclosed in curly braces. Below that, there is a list of URL patterns, each on a separate line.
To determine which actions apply to a request, the URL of the request is compared to all patterns in each action file file. Every time it matches, the list of applicable actions for the URL is incrementally updated, using the heading of the section in which the pattern is located. If multiple matches for the same URL set the same action differently, the last match wins. If not, the effects are aggregated (e.g. a URL might match both the "+handle-as-image" and "+block" actions).
You can trace this process for any given URL by visiting http://config.privoxy.org/show-url-info.
More detail on this is provided in the Appendix, Anatomy of an Action.
Generally, a pattern has the form <domain>/<path>, where both the <domain> and <path> are optional. (This is why the pattern / matches all URLs).
is a domain-only pattern and will match any request to www.example.com, regardless of which document on that server is requested.
means exactly the same. For domain-only patterns, the trailing / may be omitted.
matches only the single document /index.html on www.example.com.
matches the document /index.html, regardless of the domain, i.e. on any web server.
matches nothing, since it would be interpreted as a domain name and there is no top-level domain called .html.
The matching of the domain part offers some flexible options: if the domain starts or ends with a dot, it becomes unanchored at that end. For example:
matches any domain that ENDS in .example.com
matches any domain that STARTS with www.
matches any domain that CONTAINS .example. (Correctly speaking: It matches any FQDN that contains example as a domain.)
Additionally, there are wild-cards that you can use in the domain names themselves. They work pretty similar to shell wild-cards: "*" stands for zero or more arbitrary characters, "?" stands for any single character, you can define character classes in square brackets and all of that can be freely mixed:
matches "adserver.example.com", "ads.example.com", etc but not "sfads.example.com"
matches all of the above, and then some.
matches www.ipix.com, pictures.epix.com, a.b.c.d.e.upix.com etc.
matches www1.example.com, www4.example.cc, wwwd.example.cy, wwwz.example.com etc., but not wwww.example.com.
Privoxy uses Perl compatible regular expressions (through the PCRE library) for matching the path.
There is an Appendix with a brief quick-start into regular expressions, and full (very technical) documentation on PCRE regex syntax is available on-line at http://www.pcre.org/man.txt. You might also find the Perl man page on regular expressions (man perlre) useful, which is available on-line at http://www.perldoc.com/perl5.6/pod/perlre.html.
Note that the path pattern is automatically left-anchored at the "/", i.e. it matches as if it would start with a "^" (regular expression speak for the beginning of a line).
Please also note that matching in the path is case INSENSITIVE by default, but you can switch to case sensitive at any point in the pattern by using the "(?-i)" switch: www.example.com/(?-i)PaTtErN.* will match only documents whose path starts with PaTtErN in exactly this capitalization.
All actions are disabled by default, until they are explicitly enabled somewhere in an actions file. Actions are turned on if preceded with a "+", and turned off if preceded with a "-". So a +action means "do that action", e.g. +block means "please block URLs that match the following patterns", and -block means "don't block URLs that match the following patterns, even if +block previously applied."
Again, actions are invoked by placing them on a line, enclosed in curly braces and separated by whitespace, like in {+some-action -some-other-action{some-parameter}}, followed by a list of URL patterns, one per line, to which they apply. Together, the actions line and the following pattern lines make up a section of the actions file.
There are three classes of actions:
Boolean, i.e the action can only be "enabled" or "disabled". Syntax:
+name # enable action name -name # disable action name |
Example: +block
Parameterized, where some value is required in order to enable this type of action. Syntax:
+name{param} # enable action and set parameter to param,
# overwriting parameter from previous match if necessary
-name # disable action. The parameter can be omitted |
Note that if the URL matches multiple positive forms of a parameterized action, the last match wins, i.e. the params from earlier matches are simply ignored.
Example: +hide-user-agent{ Mozilla 1.0 }
Multi-value. These look exactly like parameterized actions, but they behave differently: If the action applies multiple times to the same URL, but with different parameters, all the parameters from all matches are remembered. This is used for actions that can be executed for the same request repeatedly, like adding multiple headers, or filtering through multiple filters. Syntax:
+name{param} # enable action and add param to the list of parameters
-name{param} # remove the parameter param from the list of parameters
# If it was the last one left, disable the action.
-name # disable this action completely and remove all parameters from the list |
Examples: +add-header{X-Fun-Header: Some text} and +filter{html-annoyances}
If nothing is specified in any actions file, no "actions" are taken. So in this case Privoxy would just be a normal, non-blocking, non-anonymizing proxy. You must specifically enable the privacy and blocking features you need (although the provided default actions files will give a good starting point).
Later defined actions always over-ride earlier ones. So exceptions to any rules you make, should come in the latter part of the file (or in a file that is processed later when using multiple actions files). For multi-valued actions, the actions are applied in the order they are specified. Actions files are processed in the order they are defined in config (the default installation has three actions files). It also quite possible for any given URL pattern to match more than one pattern and thus more than one set of actions!
The list of valid Privoxy actions are:
Multi-value.
Send a user defined HTTP header to the web server. Can be used to confuse log analysis.
Any value is possible. Validity of the defined HTTP headers is not checked. It is recommended that you use the "X-" prefix for custom headers.
{+add-header{X-User-Tracking: sucks}}
.example.com
This action may be specified multiple times, in order to define multiple headers. This is rarely needed for the typical user. If you don't know what "HTTP headers" are, you definitely don't need to worry about this one.
Boolean.
Requests for URLs to which this action applies are blocked, i.e. the requests are not forwarded to the remote server, but answered locally with a substitute page or image, as determined by the handle-as-image and set-image-blocker actions. It is typically used to block ads or other obnoxious content.
N/A
{+block}
.banners.example.com
.ads.r.us
If a URL matches one of the blocked patterns, Privoxy will intercept the URL and display its special "BLOCKED" page instead. If there is sufficient space, a large red banner will appear with a friendly message about why the page was blocked, and a way to go there anyway. If there is insufficient space a smaller "BLOCKED" page will appear without the red banner. Click here to view the default blocked HTML page (Privoxy must be running for this to work as intended!).
A very important exception is if the URL matches both "+block" and "+handle-as-image", then it will be handled by "+set-image-blocker" (see below). It is important to understand this process, in order to understand how Privoxy is able to deal with ads and other objectionable content.
The "+filter" action can also perform some of the same functionality as "+block", but by virtue of very different programming techniques, and is most often used for different reasons.
Parameterized.
To stop those annoying, distracting animated GIF images.
"last" or "first"
{+deanimate-gifs{last}}
.example.com
De-animate all animated GIF images, i.e. reduce them to their last frame. This will also shrink the images considerably (in bytes, not pixels!). If the option "first" is given, the first frame of the animation is used as the replacement. If "last" is given, the last frame of the animation is used instead, which probably makes more sense for most banner animations, but also has the risk of not showing the entire last frame (if it is only a delta to an earlier frame).
Boolean.
"+downgrade-http-version" will downgrade HTTP/1.1 client requests to HTTP/1.0 and downgrade the responses as well.
N/A
{+downgrade-http-version}
.example.com
Use this action for servers that use HTTP/1.1 protocol features that Privoxy doesn't handle well yet. HTTP/1.1 is only partially implemented. Default is not to downgrade requests. This is an infrequently needed action, and is used to help with rare problem sites only.
Boolean.
The "+fast-redirects" action enables interception of "redirect" requests from one server to another, which are used to track users.Privoxy can cut off all but the last valid URL in a redirect request and send a local redirect back to your browser without contacting the intermediate site(s).
N/A
{+fast-redirects}
.example.com
Many sites, like yahoo.com, don't just link to other sites. Instead, they will link to some script on their own server, giving the destination as a parameter, which will then redirect you to the final target. URLs resulting from this scheme typically look like: http://some.place/some_script?http://some.where-else.
Sometimes, there are even multiple consecutive redirects encoded in the URL. These redirections via scripts make your web browsing more traceable, since the server from which you follow such a link can see where you go to. Apart from that, valuable bandwidth and time is wasted, while your browser ask the server for one redirect after the other. Plus, it feeds the advertisers.
This is a normally "on" feature, and often requires exceptions for sites that are sensitive to defeating this mechanism.
Parameterized.
Apply page filtering as defined by named sections of the default.filter file to the specified site(s). "Filtering" can be any modification of the raw page content, including re-writing or deletion of content.
"+filter" must include the name of one of the section identifiers from default.filter (or whatever filterfile is specified in config).
| +filter{html-annoyances}: Get rid of particularly annoying HTML abuse. |
| +filter{js-annoyances}: Get rid of particularly annoying JavaScript abuse |
| +filter{content-cookies}: Kill cookies that come in the HTML or JS content |
| +filter{popups}: Kill all popups in JS and HTML |
| +filter{frameset-borders}: Give frames a border and make them resizable |
| +filter{webbugs}: Squish WebBugs (1x1 invisible GIFs used for user tracking) |
| +filter{refresh-tags}: Kill automatic refresh tags (for dial-on-demand setups) |
| +filter{fun}: Text replacements for subversive browsing fun! |
| +filter{nimda}: Remove Nimda (virus) code. |
| +filter{banners-by-size}: Kill banners by size (very efficient!) |
| +filter{shockwave-flash}: Kill embedded Shockwave Flash objects |
| +filter{crude-parental}: Kill all web pages that contain the words "sex" or "warez" |
This is potentially a very powerful feature! And requires a knowledge of regular expressions if you want to "roll your own". Filtering operates on a line by line basis throughout the entire page.
Filtering requires buffering the page content, which may appear to slow down page rendering since nothing is displayed until all content has passed the filters. (It does not really take longer, but seems that way since the page is not incrementally displayed.) This effect will be more noticeable on slower connections.
Filtering can achieve some of the effects as the "+block" action, i.e. it can be used to block ads and banners. In the overall scheme of things, filtering is one of the first things "Privoxy" does with a web page. So other most other actions are applied to the already "filtered" page.
Boolean.
Block any existing X-Forwarded-for HTTP header, and do not add a new one.
N/A
{+hide-forwarded-for-headers}
.example.com
It is fairly safe to leave this on. It does not seem to break many sites.
Parameterized.
To block the browser from sending your email address in a "From:" header.
Keyword: "block", or any user defined value.
{+hide-from-header{block}}
.example.com
The keyword "block" will completely remove the header (not to be confused with the "+block" action). Alternately, you can specify any value you prefer to send to the web server.
Parameterized.
Don't send the "Referer:" (sic) HTTP header to the web site. Or, alternately send a forged header instead.
Prevent the header from being sent with the keyword, "block". Or, "forge" a URL to one from the same server as the request. Or, set to user defined value of your choice.
{+hide-referer{forge}}
.example.com
"forge" is the preferred option here, since some servers will not send images back otherwise.
"+hide-referrer" is an alternate spelling of "+hide-referer". It has the exact same parameters, and can be freely mixed with, "+hide-referer". ("referrer" is the correct English spelling, however the HTTP specification has a bug - it requires it to be spelled as "referer".)
Parameterized.
To change the "User-Agent:" header so web servers can't tell your browser type. Who's business is it anyway?
Any user defined string.
{+hide-user-agent{Netscape 6.1 (X11; I; Linux 2.4.18 i686)}}
.msn.com
Warning! This breaks many web sites that depend on this in order to determine how the target browser will respond to various requests. Use with caution.
Boolean.
To define what Privoxy should treat automatically as an image, and is an important ingredient of how ads are handled.
N/A
{+handle-as-image}
/.*\.(gif|jpg|jpeg|png|bmp|ico)
This only has meaning if the URL (or pattern) also is "+block"ed, in which case a user definable image can be sent rather than a HTML page. This is integral to the whole concept of ad blocking: the URL must match both a "+block" rule, and "+handle-as-image". (See "+set-image-blocker" below for control over what will actually be displayed by the browser.)
There is little reason to change the default definition for this action.
Parameterized.
Decide what to do with URLs that end up tagged with both "+block" and "+handle-as-image", e.g an advertisement.
There are four available options: "-set-image-blocker" will send a HTML "blocked" page, usually resulting in a "broken image" icon. "+set-image-blocker{blank}" will send a 1x1 transparent GIF image. "+set-image-blocker{pattern}" will send a checkerboard type pattern (the default). And finally, "+set-image-blocker{http://xyz.com}" will send a HTTP temporary redirect to the specified image. This has the advantage of the icon being being cached by the browser, which will speed up the display.
{+set-image-blocker{blank}}
.example.com
If you want invisible ads, they need to meet criteria as matching both images and blocked actions. And then, "image-blocker" should be set to "blank" for invisibility. Note you cannot treat HTML pages as images in most cases. For instance, frames require an HTML page to display. So a frame that is an ad, typically cannot be treated as an image. Forcing an "image" in this situation just will not work reliably.
Parameterized.
By default, Privoxy only allows HTTP CONNECT requests to port 443 (the standard, secure HTTPS port). Use "+limit-connect" to disable this altogether, or to allow more ports.
Any valid port number, or port number range.
+limit-connect{443} # This is the default and need not be specified.
+limit-connect{80,443} # Ports 80 and 443 are OK.
+limit-connect{-3, 7, 20-100, 500-} # Port less than 3, 7, 20 to 100 and above 500 are OK.
The CONNECT methods exists in HTTP to allow access to secure websites (https:// URLs) through proxies. It works very simply: the proxy connects to the server on the specified port, and then short-circuits its connections to the client and to the remote proxy. This can be a big security hole, since CONNECT-enabled proxies can be abused as TCP relays very easily.
If you want to allow CONNECT for more ports than this, or want to forbid CONNECT altogether, you can specify a comma separated list of ports and port ranges (the latter using dashes, with the minimum defaulting to 0 and max to 65K).
If you don't know what any of this means, there probably is no reason to change this one.
Boolean.
Prevent the specified websites from compressing HTTP data.
N/A
{+prevent-compression}
.example.com
Some websites do this, which can be a problem for Privoxy, since "+filter", "+kill-popups" and "+gif-deanimate" will not work on compressed data. This will slow down connections to those websites, though. Default typically is to turn "prevent-compression" on.
Boolean.
Allow cookies for the current browser session only.
N/A
{-session-cookies-only}
.example.com
If websites set cookies, "+session-cookies-only" will make sure they are erased when you exit and restart your web browser. This makes profiling cookies useless, but won't break sites which require cookies so that you can log in for transactions. This is generally turned on for all sites, and is the recommended setting.
"+prevent-*-cookies" actions should be turned off as well (see below), for "+session-cookies-only" to work. Or, else no cookies will get through at all. For, "persistent" cookies that survive across browser sessions, see below as well.
Boolean.
Explicitly prevent the web server from reading any cookies on your system.
N/A
{+prevent-reading-cookies}
.example.com
Often used in conjunction with "+prevent-setting-cookies" to disable cookies completely. Note that "+session-cookies-only" requires these to both be disabled (or else it never gets any cookies to cache).
For "persistent" cookies to work (i.e. they survive across browser sessions and reboots), all three cookie settings should be "off" for the specified sites.
Boolean.
Explicitly block the web server from storing cookies on your system.
N/A
{+prevent-setting-cookies}
.example.com
Often used in conjunction with "+prevent-reading-cookies" to disable cookies completely (see above).
Boolean.
Stop those annoying JavaScript pop-up windows!
N/A
{+kill-popups}
.example.com
"+kill-popups" uses a built in filter to disable pop-ups that use the window.open() function, etc. This is one of the first actions processed by Privoxy as it contacts the remote web server. This action is not always 100% reliable, and is supplemented by "+filter{popups}".
Boolean.
Sends a cookie for every site stating that you do not accept any copyright on cookies sent to you, and asking them not to track you.
N/A
{+send-vanilla-wafer}
.example.com
This action only applies if you are using a jarfile for saving cookies. Of course, this is a (relatively) unique header and could conceivably be used to track you.
Multi-value.
This allows you to send an arbitrary, user definable cookie.
User specified cookie name and corresponding value.
{+send-wafer{name=value}}
.example.com
This can be specified multiple times in order to add as many cookies as you like.
Note that many of these actions have the potential to cause a page to misbehave, possibly even not to display at all. There are many ways a site designer may choose to design his site, and what HTTP header content, and other criteria, he may depend on. There is no way to have hard and fast rules for all sites. See the Appendix for a brief example on troubleshooting actions.
Remember that the meaning of any of the above references is reversed by preceding the action with a "-", in place of the "+". Also, that some actions are turned on in the default section of the actions file, and require little to no additional configuration. These are just "on".
But, other actions that are turned on in the default section do typically require exceptions to be listed in the latter sections of one of our actions file. For instance, by default no URLs are "blocked" (i.e. in the default definitions of default.action). We need exceptions to this in order to enable ad blocking in the lower sections. But we need to be very selective about what we do block. Thus, the default is "off" for blocking.
Below is a liberally commented sample default.action file to demonstrate how all the pieces come together. And to show how exceptions to the default policies can be handled. This is followed by a brief user.action with similar examples.
# Sample default.action file <developers@privoxy.org>
# Settings -- Don't change! For internal Privoxy use ONLY.
{{settings}}
for-privoxy-version=3.0
##########################################################################
# Aliases must be defined *before* they are used. These are
# easier to remember, and can combine several actions into one. Once
# defined they can be used just like any built-in action -- but within
# this file only! Aliases do not require a + or - sign.
##########################################################################
# Some useful aliases.
# Alias to turn off cookie handling, ie allow all cookies unmolested.
-prevent-cookies = -prevent-setting-cookies -prevent-reading-cookies \
-session-cookies-only
# Alias to both block and treat as if an image for ad blocking
# purposes.
+imageblock = +block +handle-as-image
# Fragile sites should have the minimum changes:
fragile = -block -deanimate-gifs -fast-redirects -filter -hide-referer \
-prevent-cookies -kill-popups
# Shops should be allowed to set persistent cookies
shop = -filter -prevent-cookies -session-cookies-only
##########################################################################
# Begin default action settings. Anything in this section will match
# all URLs -- UNLESS we have exceptions that also match, defined below this
# section. We will show all potential actions here whether they are on
# or off. We could omit any disabled action if we wanted, since all
# actions are 'off' by default anyway. Shown for completeness only.
# Actions are enabled if preceded by a '+', otherwise they are disabled
# (unless an alias has been defined without this).
##########################################################################
{ \
-add-header \
-block \
-deanimate-gifs \
-downgrade-http-version \
+fast-redirects \
+filter{html-annoyances} \
+filter{js-annoyances} \
-filter{content-cookies} \
-filter{popups} \
+filter{webbugs} \
-filter{refresh-tags} \
-filter{fun} \
+filter{nimda} \
+filter{banners-by-size} \
-filter{shockwave-flash} \
-filter{crude-prental} \
+hide-forwarded-for-headers \
+hide-from-header{block} \
-hide-referrer \
-hide-user-agent \
-handle-as-image \
+set-image-blocker{pattern} \
-limit-connect \
+prevent-compression \
-session-cookies-only \
-prevent-reading-cookies \
-prevent-setting-cookies \
-kill-popups \
-send-vanilla-wafer \
-send-wafer \
}
/ # forward slash will match *all* potential URL patterns.
##########################################################################
# Default behavior is now set. Now we will define some exceptions to our
# default action policies.
##########################################################################
# These sites are very complex and require very minimal interference.
# We'll disable most actions with our 'fragile' alias:
{ fragile }
.office.microsoft.com # surprise, surprise!
.windowsupdate.microsoft.com
# Shopping sites - not as fragile but require some special
# handling. We still want to block ads, and we will allow
# persistant cookies via the 'shop' alias:
{ shop }
.quietpc.com
.worldpay.com # for quietpc.com
.jungle.com
.scan.co.uk
# These sites require pop-ups too :( We'll combine our 'shop'
# alias with two other actions into one rule to allow all popups.
{ shop -kill-popups -filter{popups} }
.dabs.com
.overclockers.co.uk
# The 'Fast-redirects' action breaks some sites. Disable this action
# for these known sensitive sites:
{ -fast-redirects }
login.yahoo.com
edit.europe.yahoo.com
.google.com
.altavista.com/.*(like|url|link):http
.altavista.com/trans.*urltext=http
.nytimes.com
# Define which file types will be treated as images. Important
# for ad blocking.
{ +handle-as-image }
/.*\.(gif|jpe?g|png|bmp|ico)
# Now lets list some domains that are known ad generators. And
# our alias that we use here will block these as well as force
# them to be treated as images. This combination of actions is
# important for ad blocking. What the browser will show instead is
# determined by the setting of "+set-image-blocker"
{ +imageblock }
ar.atwola.com
.ad.doubleclick.net
.a.yimg.com/(?:(?!/i/).)*$
.a[0-9].yimg.com/(?:(?!/i/).)*$
bs*.gsanet.com
bs*.einets.com
.qkimg.net
ad.*.doubleclick.net
# These will just simply be blocked. They will generate the BLOCKED
# banner page, if matched. Heavy use of wildcards and regular
# expressions in this example. Enable block action:
{ +block }
ad*.
.*ads.
banner?.
count*.
/.*count(er)?\.(pl|cgi|exe|dll|asp|php[34]?)
/(?:.*/)?(publicite|werbung|rekla(ma|me|am)|annonse|maino(kset|nta|s)?)/
.hitbox.com
# The above block section will probably inadvertantly catch some
# sites we DO NOT want blocked via the wildcards and regular expressions.
# Now let's set exceptions to the exceptions so the good guys get better
# treatment. Disable block action:
{ -block }
advogato.org
adsl.
ad[ud]*.
advice.
# Let's just trust all .edu top level domains.
.edu
www.ugu.com/sui/ugu/adv
# We'll need to access to path names containing 'download'
.*downloads.
/downloads/
# 'adv' is for globalintersec and means advanced, not advertisement
www.globalintersec.com/adv
# Don't filter *anything* from our friends at sourceforge.
# Notice we don't have to name the individual filter
# identifiers -- we just turn them all off in one fell swoop.
# Disable all filters for this one site:
{ -filter }
.sourceforge.net
So far we are painting with a broad brush by setting general policies. The above would be a reasonable starting point for many situations. Now, we want to be more specific and have customized rules that are more suitable to our personal habits and preferences. These would be for narrowly defined situations like your ISP or your bank, and should be placed in user.action, which is parsed after all other actions files and should not be clobbered by upgrades. So any settings here, will have the last word and over-ride any previously defined actions.
Now a few examples of some things that one might do with a user.action file.
# Sample user.action file.
# Any aliases you want to use need to be re-defined here.
# Alias to turn off cookie handling, ie allow all cookies unmolested.
-prevent-cookies = -prevent-setting-cookies -prevent-reading-cookies \
-session-cookies-only
# Fragile sites should have the minimum changes:
fragile = -block -deanimate-gifs -fast-redirects -filter -hide-referer \
-prevent-cookies -kill-popups
# Allow persistent cookies for a few regular sites that we
# trust via our above alias. These will be saved from one browser session
# to the next. We are explicity turning off any and all cookie handling,
# even though the prevent-*-cookie settings were disabled in our above
# default.action anyway. So cookies from these domains will come through
# unmolested.
{ -prevent-cookies }
.sun.com
.yahoo.com
.msdn.microsoft.com
.redhat.com
# My ISP uses obnoxious self promoting images on many pages.
# Nuke them :) Note that "+handle-as-image" need not be specified,
# since all URLs ending in .gif will be tagged as images by the
# general rules in default.action anyway.
{ +block }
www.my-isp-example.com/logo[0-9].gif
# Say the site where you do your homebanking needs to open
# popup windows, but you have chosen to kill popups by
# default. This will allow it for your-example-bank.com:
#
{ -filter{popups} -kill-popups }
.my-example-bank.com
# This site is delicate, and requires kid-glove
# treatment.
{ fragile }
.forbes.com
Custom "actions", known to Privoxy as "aliases", can be defined by combining other "actions". These can in turn be invoked just like the built-in "actions". Currently, an alias can contain any character except space, tab, "=", "{" or "}". But please use only "a"- "z", "0"-"9", "+", and "-". Alias names are not case sensitive, and must be defined before other actions in the actions file! And there can only be one set of "aliases" defined per file. Each actions file may have its own aliases, but they are only visible within that file. Aliases do not requir a "+" or "-" sign in front, since they are merely expanded.
Now let's define a few aliases:
# Useful custom aliases we can use later. These must come first!
{{alias}}
+prevent-cookies = +prevent-setting-cookies +prevent-reading-cookies
-prevent-cookies = -prevent-setting-cookies -prevent-reading-cookies
fragile = -block -prevent-cookies -filter -fast-redirects -hide-referer -kill-popups
shop = -prevent-cookies -filter -fast-redirects
+imageblock = +block +handle-as-image
# Aliases defined from other aliases, for people who don't like to type
# too much: ;-)
c0 = +prevent-cookies
c1 = -prevent-cookies
#... etc. Customize to your heart's content.
Some examples using our "shop" and "fragile" aliases from above. These would appear in the lower sections of an actions file as exceptions to the default actions (as defined in the upper section):
# These sites are very complex and require
# minimal interference.
{fragile}
.office.microsoft.com
.windowsupdate.microsoft.com
.nytimes.com
# Shopping sites - but we still want to block ads.
{shop}
.quietpc.com
.worldpay.com # for quietpc.com
.scan.co.uk
# These shops require pop-ups also
{shop -kill-popups}
.dabs.com
.overclockers.co.uk
The "shop" and "fragile" aliases are often used for "problem" sites that require most actions to be disabled in order to function properly.