+Specifies:
+
+ Maximum size of the buffer for content filtering.
+
+Type of value:
+
+ Size in Kbytes
+
+Default value:
+
+ 4096
+
+Effect if unset:
+
+ Use a 4MB (4096 KB) limit.
+
+Notes:
+
+ For content filtering, i.e. the +filter and +deanimate-gif actions, it is
+ necessary that Privoxy buffers the entire document body. This can be
+ potentially dangerous, since a server could just keep sending data
+ indefinitely and wait for your RAM to exhaust -- with nasty consequences.
+ Hence this option.
+
+ When a document buffer size reaches the buffer-limit, it is flushed to the
+ client unfiltered and no further attempt to filter the rest of the document
+ is made. Remember that there may be multiple threads running, which might
+ require up to buffer-limit Kbytes each, unless you have enabled
+ "single-threaded" above.
+
+-------------------------------------------------------------------------------
+
+7.5. Forwarding
+
+This feature allows routing of HTTP requests through a chain of multiple
+proxies. It can be used to better protect privacy and confidentiality when
+accessing specific domains by routing requests to those domains through an
+anonymous public proxy. Or to use a caching proxy to speed up browsing. Or
+chaining to a parent proxy may be necessary because the machine that Privoxy
+runs on has no direct Internet access.
+
+Also specified here are SOCKS proxies. Privoxy supports the SOCKS 4 and SOCKS
+4A protocols.
+
+-------------------------------------------------------------------------------
+
+7.5.1. forward
+
+Specifies:
+
+ To which parent HTTP proxy specific requests should be routed.
+
+Type of value:
+
+ target_pattern http_parent[:port]
+
+ where target_pattern is a URL pattern that specifies to which requests
+ (i.e. URLs) this forward rule shall apply. Use / to denote "all URLs".
+ http_parent[:port] is the DNS name or IP address of the parent HTTP proxy
+ through which the requests should be forwarded, optionally followed by its
+ listening port (default: 8080). Use a single dot (.) to denote "no
+ forwarding".
+
+Default value:
+
+ Unset
+
+Effect if unset:
+
+ Don't use parent HTTP proxies.
+
+Notes:
+
+ If http_parent is ".", then requests are not forwarded to another HTTP
+ proxy but are made directly to the web servers.
+
+ Multiple lines are OK, they are checked in sequence, and the last match
+ wins.
+
+Examples:
+
+ Everything goes to an example anonymizing proxy, except SSL on port 443
+ (which it doesn't handle):
+
+ forward / anon-proxy.example.org:8080
+ forward :443 .
+
+ Everything goes to our example ISP's caching proxy, except for requests to
+ that ISP's sites:
+
+ forward / caching-proxy.example-isp.net:8000
+ forward .example-isp.net .
+
+-------------------------------------------------------------------------------
+
+7.5.2. forward-socks4 and forward-socks4a
+
+Specifies:
+
+ Through which SOCKS proxy (and to which parent HTTP proxy) specific
+ requests should be routed.
+
+Type of value:
+
+ target_pattern socks_proxy[:port] http_parent[:port]
+
+ where target_pattern is a URL pattern that specifies to which requests
+ (i.e. URLs) this forward rule shall apply. Use / to denote "all URLs".
+ http_parent and socks_proxy are IP addresses in dotted decimal notation or
+ valid DNS names (http_parent may be "." to denote "no HTTP forwarding"),
+ and the optional port parameters are TCP ports, i.e. integer values from 1
+ to 64535
+
+Default value:
+
+ Unset
+
+Effect if unset:
+
+ Don't use SOCKS proxies.
+
+Notes:
+
+ Multiple lines are OK, they are checked in sequence, and the last match
+ wins.
+
+ The difference between forward-socks4 and forward-socks4a is that in the
+ SOCKS 4A protocol, the DNS resolution of the target hostname happens on the
+ SOCKS server, while in SOCKS 4 it happens locally.
+
+ If http_parent is ".", then requests are not forwarded to another HTTP
+ proxy but are made (HTTP-wise) directly to the web servers, albeit through
+ a SOCKS proxy.
+
+Examples:
+
+ From the company example.com, direct connections are made to all "internal"
+ domains, but everything outbound goes through their ISP's proxy by way of
+ example.com's corporate SOCKS 4A gateway to the Internet.
+
+ forward-socks4a / socks-gw.example.com:1080 www-cache.example-isp.net:8080
+ forward .example.com .
+
+ A rule that uses a SOCKS 4 gateway for all destinations but no HTTP parent
+ looks like this:
+
+ forward-socks4 / socks-gw.example.com:1080 .
+
+ To chain Privoxy and Tor, both running on the same system, you should use
+ the rule:
+
+ forward-socks4 / 127.0.0.1:9050 .
+
+ The public Tor network can't be used to reach your local network, therefore
+ it's a good idea to make some exceptions:
+
+ forward 192.168.*.*/ .
+ forward 10.*.*.*/ .
+ forward 127.*.*.*/ .
+
+ Unencrypted connections to systems in these address ranges will be as (un)
+ secure as the local network is, but the alternative is that you can't reach
+ the network at all.
+
+ If you also want to be able to reach servers in your local network by using
+ their names, you will need additional exceptions that look like this:
+
+ forward localhost/ .
+
+-------------------------------------------------------------------------------
+
+7.5.3. Advanced Forwarding Examples
+
+If you have links to multiple ISPs that provide various special content only to
+their subscribers, you can configure multiple Privoxies which have connections
+to the respective ISPs to act as forwarders to each other, so that your users
+can see the internal content of all ISPs.
+
+Assume that host-a has a PPP connection to isp-a.net. And host-b has a PPP
+connection to isp-b.net. Both run Privoxy. Their forwarding configuration can
+look like this:
+
+host-a:
+
+ forward / .
+ forward .isp-b.net host-b:8118
+
+host-b:
+
+ forward / .
+ forward .isp-a.net host-a:8118
+
+Now, your users can set their browser's proxy to use either host-a or host-b
+and be able to browse the internal content of both isp-a and isp-b.
+
+If you intend to chain Privoxy and squid locally, then chain as browser ->
+squid -> privoxy is the recommended way.
+
+Assuming that Privoxy and squid run on the same box, your squid configuration
+could then look like this:
+
+ # Define Privoxy as parent proxy (without ICP)
+ cache_peer 127.0.0.1 parent 8118 7 no-query
+
+ # Define ACL for protocol FTP
+ acl ftp proto FTP
+
+ # Do not forward FTP requests to Privoxy
+ always_direct allow ftp
+
+ # Forward all the rest to Privoxy
+ never_direct allow all
+
+You would then need to change your browser's proxy settings to squid's address
+and port. Squid normally uses port 3128. If unsure consult http_port in
+squid.conf.
+
+You could just as well decide to only forward requests for Windows executables
+through a virus-scanning parent proxy, say, on antivir.example.com, port 8010:
+
+ forward / .
+ forward /.*\.(exe|com|dll|zip)$ antivir.example.com:8010
+
+-------------------------------------------------------------------------------
+
+7.5.4. forwarded-connect-retries
+
+Specifies:
+
+ How often Privoxy retries if a forwarded connection request fails.
+
+Type of value:
+
+ Number of retries.
+
+Default value:
+
+ 0
+
+Effect if unset:
+
+ Forwarded connections are treated like direct connections and no retry
+ attempts are made.
+
+Notes:
+
+ forwarded-connect-retries is mainly interesting for socks4a connections,
+ where Privoxy can't detect why the connections failed. The connection might
+ have failed because of a DNS timeout in which case a retry makes sense, but
+ it might also have failed because the server doesn't exist or isn't
+ reachable. In this case the retry will just delay the appearance of
+ Privoxy's error message.
+
+ Only use this option, if you are getting many forwarding related error
+ messages, that go away when you try again manually. Start with a small
+ value and check Privoxy's logfile from time to time, to see how many
+ retries are usually needed.
+
+Examples:
+
+ forwarded-connect-retries 1
+
+-------------------------------------------------------------------------------
+
+7.6. Windows GUI Options
+
+Privoxy has a number of options specific to the Windows GUI interface:
+
+If "activity-animation" is set to 1, the Privoxy icon will animate when
+"Privoxy" is active. To turn off, set to 0.
+
+ activity-animation 1
+
+
+If "log-messages" is set to 1, Privoxy will log messages to the console window:
+
+ log-messages 1
+
+
+If "log-buffer-size" is set to 1, the size of the log buffer, i.e. the amount
+of memory used for the log messages displayed in the console window, will be
+limited to "log-max-lines" (see below).
+
+Warning: Setting this to 0 will result in the buffer to grow infinitely and eat
+up all your memory!
+
+ log-buffer-size 1
+
+
+log-max-lines is the maximum number of lines held in the log buffer. See above.
+
+ log-max-lines 200
+
+
+If "log-highlight-messages" is set to 1, Privoxy will highlight portions of the
+log messages with a bold-faced font:
+
+ log-highlight-messages 1
+
+
+The font used in the console window:
+
+ log-font-name Comic Sans MS
+
+
+Font size used in the console window:
+
+ log-font-size 8
+
+
+"show-on-task-bar" controls whether or not Privoxy will appear as a button on
+the Task bar when minimized:
+
+ show-on-task-bar 0
+
+
+If "close-button-minimizes" is set to 1, the Windows close button will minimize
+Privoxy instead of closing the program (close with the exit option on the File
+menu).
+
+ close-button-minimizes 1
+
+
+The "hide-console" option is specific to the MS-Win console version of Privoxy.
+If this option is used, Privoxy will disconnect from and hide the command
+console.
+
+ #hide-console
+
+
+-------------------------------------------------------------------------------
+
+8. Actions Files
+
+The actions files are used to define what actions Privoxy takes for which URLs,
+and thus determines 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 a number of such actions, with a wide range of
+functionality. Each action does something a little different. These actions
+give us a veritable arsenal of tools with which to exert our control,
+preferences and independence. Actions can be combined so that their effects are
+aggregated when applied against a given set of URLs.
+
+There are three action files included with Privoxy with differing purposes:
+
+ * 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 as-is for most users. This is the file that the
+ developers are keeping updated, and making available to users. The user's
+ preferences as set in standard.action, e.g. either Cautious (the default),
+ Medium, or Advanced (see below).
+
+ * 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.
+
+ * standard.action - is used by the web based editor at http://
+ config.privoxy.org/edit-actions-list?f=default, to set various pre-defined
+ sets of rules for the default actions section in default.action.
+
+ Edit Set to Cautious Set to Medium Set to Advanced
+
+ These have increasing levels of aggressiveness and have no influence on
+ your browsing unless you select them explicitly in the editor. A default
+ installation should be pre-set to Cautious (versions prior to 3.0.5 were
+ set to Medium). New users should try this for a while before adjusting the
+ settings to more aggressive levels.
+
+ The Edit button allows you to turn each action on/off individually for
+ fine-tuning. The Cautious button changes the actions list to low/safe
+ settings which will activate a minimal set of Privoxy's features, and
+ subsequently there will be less of a chance for accidental problems. The
+ Medium button sets the list to a medium level of ad blocking and a low
+ level set of privacy features. The Advanced button sets the list to a high
+ level of ad blocking and medium level of privacy. See the chart below. The
+ latter three buttons over-ride any changes via with the Edit button. More
+ fine-tuning can be done in the lower sections of this internal page.
+
+ It is not recommend to edit the standard.action file itself.
+
+ The default profiles, and their associated actions, as pre-defined in
+ standard.action are:
+
+ Table 1. Default Configurations
+
+ +-------------------------------------------------------------------------+
+ |Feature |Cautious |Medium |Advanced |
+ |------------------+-----------------+------------------+-----------------|
+ |Ad-blocking |medium |high |high |
+ |Aggressiveness | | | |
+ |------------------+-----------------+------------------+-----------------|
+ |Ad-filtering by |no |yes |yes |
+ |size | | | |
+ |------------------+-----------------+------------------+-----------------|
+ |Ad-filtering by |no |no |yes |
+ |link | | | |
+ |------------------+-----------------+------------------+-----------------|
+ |Pop-up killing |blocks only |blocks only |all |
+ |------------------+-----------------+------------------+-----------------|
+ |Privacy Features |low |medium |medium/high |
+ |------------------+-----------------+------------------+-----------------|
+ |Cookie handling |none |session-only |kill |
+ |------------------+-----------------+------------------+-----------------|
+ |Referer forging |no |yes |yes |
+ |------------------+-----------------+------------------+-----------------|
+ |GIF de-animation |no |yes |yes |
+ |------------------+-----------------+------------------+-----------------|
+ |Fast redirects |no |no |yes |
+ |------------------+-----------------+------------------+-----------------|
+ |HTML taming |no |yes |yes |
+ |------------------+-----------------+------------------+-----------------|
+ |JavaScript taming |no |yes |yes |
+ |------------------+-----------------+------------------+-----------------|
+ |Web-bug killing |no |yes |yes |
+ |------------------+-----------------+------------------+-----------------|
+ |Image tag |no |no |yes |
+ |reordering | | | |
+ +-------------------------------------------------------------------------+
+
+The list of actions files to be used are defined in the main configuration
+file, and are processed in the order they are defined (e.g. default.action is
+typically process before user.action). The content of these can all be viewed
+and edited from http://config.privoxy.org/show-status. The over-riding
+principle when applying actions, is that the last action that matches a given
+URL, wins. The broadest, most general rules go first (defined in
+default.action), followed by any exceptions (typically also in default.action),
+which are then followed lastly by any local preferences (typically in
+user.action). Generally, user.action has the last word.
+
+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.
+
+-------------------------------------------------------------------------------
+
+8.1. Finding the Right Mix
+
+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. And, things can always change, requiring refinements in the
+configuration. 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 crunch all cookies per default, you'll have to make exceptions from
+that rule for sites that you regularly use and that require cookies for
+actually useful purposes, 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
+:).
+
+-------------------------------------------------------------------------------
+
+8.2. How to Edit
+
+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". Warning: the "Advanced" setting is
+more aggressive, and will be more likely to cause problems for some sites.
+Experienced users only!
+
+If you prefer plain text editing to GUIs, you can of course also directly edit
+the the actions files with your favorite text editor. Look at default.action
+which is richly commented with many good examples.
+
+-------------------------------------------------------------------------------
+
+8.3. How Actions are Applied to URLs
+
+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 a regular section with a heading
+line of { +handle-as-image }, then later another one with just { +block },
+resulting in both actions to apply. And there may well be cases where you will
+want to combine actions together. Such a section then might look like:
+
+ { +handle-as-image +block }
+ # Block these as if they were images. Send no block page.
+ banners.example.com
+ media.example.com/.*banners
+ .example.com/images/ads/
+
+You can trace this process for any given URL by visiting http://
+config.privoxy.org/show-url-info.
+
+Examples and more detail on this is provided in the Appendix, Troubleshooting:
+Anatomy of an Action section.
+
+-------------------------------------------------------------------------------
+
+8.4. Patterns
+
+As mentioned, Privoxy uses "patterns" to determine what actions might apply to
+which sites and pages your browser attempts to access. These "patterns" use
+wild card type pattern matching to achieve a high degree of flexibility. This
+allows one expression to be expanded and potentially match against many similar
+patterns.
+
+Generally, a Privoxy pattern has the form <domain>/<path>, where both the
+<domain> and <path> are optional. (This is why the special / pattern matches
+all URLs). Note that the protocol portion of the URL pattern (e.g. http://)
+should not be included in the pattern. This is assumed already!
+
+The pattern matching syntax is different for the domain and path parts of the
+URL. The domain part uses a simple globbing type matching technique, while the
+path part uses a more flexible "Regular Expressions (PCRE)" based syntax.
+
+www.example.com/
+
+ is a domain-only pattern and will match any request to www.example.com,
+ regardless of which document on that server is requested. So ALL pages in
+ this domain would be covered by the scope of this action. Note that a
+ simple example.com is different and would NOT match.
+
+www.example.com
+
+ means exactly the same. For domain-only patterns, the trailing / may be
+ omitted.
+
+www.example.com/index.html
+
+ matches only the single document /index.html on www.example.com.
+
+/index.html
+
+ matches the document /index.html, regardless of the domain, i.e. on any web
+ server anywhere.
+
+index.html
+
+ matches nothing, since it would be interpreted as a domain name and there
+ is no top-level domain called .html. So its a mistake.
+
+-------------------------------------------------------------------------------
+
+8.4.1. The Domain Pattern
+
+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:
+
+.example.com
+
+ matches any domain that ENDS in .example.com
+
+www.
+
+ matches any domain that STARTS with www.
+
+.example.
+
+ matches any domain that CONTAINS .example.. And, by the way, also included
+ would be any files or documents that exist within that domain since no path
+ limitations are specified. (Correctly speaking: It matches any FQDN that
+ contains example as a domain.) This might be www.example.com,
+ news.example.de, or www.example.net/cgi/testing.pl for instance. All these
+ cases are matched.
+
+Additionally, there are wild-cards that you can use in the domain names
+themselves. These work similarly to shell globbing type wild-cards: "*"
+represents zero or more arbitrary characters (this is equivalent to the
+"Regular Expression" based syntax of ".*"), "?" represents any single character
+(this is equivalent to the regular expression syntax of a simple "."), and you
+can define "character classes" in square brackets which is similar to the same
+regular expression technique. All of this can be freely mixed:
+
+ad*.example.com
+
+ matches "adserver.example.com", "ads.example.com", etc but not
+ "sfads.example.com"
+
+*ad*.example.com
+
+ matches all of the above, and then some.
+
+.?pix.com
+
+ matches www.ipix.com, pictures.epix.com, a.b.c.d.e.upix.com etc.
+
+www[1-9a-ez].example.c*
+
+ matches www1.example.com, www4.example.cc, wwwd.example.cy,
+ wwwz.example.com etc., but not wwww.example.com.
+
+While flexibile, this is not the sophistication of full regular expression
+based syntax.
+
+-------------------------------------------------------------------------------
+
+8.4.2. The Path Pattern
+
+Privoxy uses Perl compatible (PCRE) "Regular Expression" based syntax (through
+the PCRE library) for matching the path portion (after the slash), and is thus
+more flexible.
+
+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://
+perldoc.perl.org/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.
+
+.example.com/.*
+
+ Is equivalent to just ".example.com", since any documents within that
+ domain are matched with or without the ".*" regular expression. This is
+ redundant
+
+.example.com/.*/index.html
+
+ Will match any page in the domain of "example.com" that is named
+ "index.html", and that is part of some path. For example, it matches
+ "www.example.com/testing/index.html" but NOT "www.example.com/index.html"
+ because the regular expression called for at least two "/'s", thus the path
+ requirement. It also would match "www.example.com/testing/index_html",
+ because of the special meta-character ".".
+
+.example.com/(.*/)?index\.html
+
+ This regular expression is conditional so it will match any page named
+ "index.html" regardless of path which in this case can have one or more "/
+ 's". And this one must contain exactly ".html" (but does not have to end
+ with that!).
+
+.example.com/(.*/)(ads|banners?|junk)
+
+ This regular expression will match any path of "example.com" that contains
+ any of the words "ads", "banner", "banners" (because of the "?") or "junk".
+ The path does not have to end in these words, just contain them.
+
+.example.com/(.*/)(ads|banners?|junk)/.*\.(jpe?g|gif|png)$
+
+ This is very much the same as above, except now it must end in either
+ ".jpg", ".jpeg", ".gif" or ".png". So this one is limited to common image
+ formats.
+
+There are many, many good examples to be found in default.action, and more
+tutorials below in Appendix on regular expressions.
+
+-------------------------------------------------------------------------------
+
+8.5. Actions
+
+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.
+
+Actions fall into three categories:
+
+ * 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 such as user.action). 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! Last match wins.
+
+The list of valid Privoxy actions are:
+
+-------------------------------------------------------------------------------
+
+8.5.1. add-header
+
+Typical use:
+
+ Confuse log analysis, custom applications
+
+Effect:
+
+ Sends a user defined HTTP header to the web server.
+
+Type:
+
+ Multi-value.
+
+Parameter:
+
+ Any string value is possible. Validity of the defined HTTP headers is not
+ checked. It is recommended that you use the "X-" prefix for custom headers.
+
+Notes:
+
+ 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.
+
+Example usage:
+
+ +add-header{X-User-Tracking: sucks}
+
+-------------------------------------------------------------------------------
+
+8.5.2. block
+
+Typical use:
+
+ Block ads or other unwanted content
+
+Effect:
+
+ Requests for URLs to which this action applies are blocked, i.e. the
+ requests are trapped by Privoxy and the requested URL is never retrieved,
+ but is answered locally with a substitute page or image, as determined by
+ the handle-as-image, set-image-blocker, and handle-as-empty-document
+ actions.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ Privoxy sends a special "BLOCKED" page for requests to blocked pages. This
+ page contains links to find out why the request was blocked, and a
+ click-through to the blocked content (the latter only if compiled with the
+ force feature enabled). The "BLOCKED" page adapts to the available screen
+ space -- it displays full-blown if space allows, or miniaturized and
+ text-only if loaded into a small frame or window. If you are using Privoxy
+ right now, you can take a look at the "BLOCKED" page.
+
+ A very important exception occurs if both block and handle-as-image, apply
+ to the same request: it will then be replaced by an image. If
+ set-image-blocker (see below) also applies, the type of image will be
+ determined by its parameter, if not, the standard checkerboard pattern is
+ sent.
+
+ It is important to understand this process, in order to understand how
+ Privoxy deals with ads and other unwanted content. Blocking is a core
+ feature, and one upon which various other features depend.
+
+ The filter action can perform a very similar task, by "blocking" banner
+ images and other content through rewriting the relevant URLs in the
+ document's HTML source, so they don't get requested in the first place.
+ Note that this is a totally different technique, and it's easy to confuse
+ the two.
+
+Example usage (section):
+
+ {+block}
+ # Block and replace with "blocked" page
+ .nasty-stuff.example.com
+
+ {+block +handle-as-image}
+ # Block and replace with image
+ .ad.doubleclick.net
+ .ads.r.us/banners/
+
+ {+block +handle-as-empty-document}
+ # Block and then ignore
+ adserver.exampleclick.net/.*\.js$
+
+-------------------------------------------------------------------------------
+
+8.5.3. content-type-overwrite
+
+Typical use:
+
+ Stop useless download menus from popping up, or change the browser's
+ rendering mode
+
+Effect:
+
+ Replaces the "Content-Type:" HTTP server header.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ Any string.
+
+Notes:
+
+ The "Content-Type:" HTTP server header is used by the browser to decide
+ what to do with the document. The value of this header can cause the
+ browser to open a download menu instead of displaying the document by
+ itself, even if the document's format is supported by the browser.
+
+ The declared content type can also affect which rendering mode the browser
+ chooses. If XHTML is delivered as "text/html", many browsers treat it as
+ yet another broken HTML document. If it is send as "application/xml",
+ browsers with XHTML support will only display it, if the syntax is correct.
+
+ If you see a web site that proudly uses XHTML buttons, but sets
+ "Content-Type: text/html", you can use Privoxy to overwrite it with
+ "application/xml" and validate the web master's claim inside your
+ XHTML-supporting browser. If the syntax is incorrect, the browser will
+ complain loudly.
+
+ You can also go the opposite direction: if your browser prints error
+ messages instead of rendering a document falsely declared as XHTML, you can
+ overwrite the content type with "text/html" and have it rendered as broken
+ HTML document.
+
+ By default content-type-overwrite only replaces "Content-Type:" headers
+ that look like some kind of text. If you want to overwrite it
+ unconditionally, you have to combine it with force-text-mode. This
+ limitation exists for a reason, think twice before circumventing it.
+
+ Most of the time it's easier to enable filter-server-headers and replace
+ this action with a custom regular expression. It allows you to activate it
+ for every document of a certain site and it will still only replace the
+ content types you aimed at.
+
+ Of course you can apply content-type-overwrite to a whole site and then
+ make URL based exceptions, but it's a lot more work to get the same
+ precision.
+
+Example usage (sections):
+
+ # Check if www.example.net/ really uses valid XHTML
+ {+content-type-overwrite {application/xml}}
+ www.example.net/
+
+ # but leave the content type unmodified if the URL looks like a style sheet
+ {-content-type-overwrite}
+ www.example.net/*.\.css$
+ www.example.net/*.style
+
+-------------------------------------------------------------------------------
+
+8.5.4. crunch-client-header
+
+Typical use:
+
+ Remove a client header Privoxy has no dedicated action for.
+
+Effect:
+
+ Deletes every header sent by the client that contains the string the user
+ supplied as parameter.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ Any string.
+
+Notes:
+
+ This action allows you to block client headers for which no dedicated
+ Privoxy action exists. Privoxy will remove every client header that
+ contains the string you supplied as parameter.
+
+ Regular expressions are not supported and you can't use this action to
+ block different headers in the same request, unless they contain the same
+ string.
+
+ crunch-client-header is only meant for quick tests. If you have to block
+ several different headers, or only want to modify parts of them, you should
+ enable filter-client-headers and create your own filter.
+
+ +-----------------------------------------------------------------+
+ | Warning |
+ |-----------------------------------------------------------------|
+ |Don't block any header without understanding the consequences. |
+ +-----------------------------------------------------------------+
+Example usage (section):
+
+ # Block the non-existent "Privacy-Violation:" client header
+ {+crunch-client-header {Privacy-Violation:}}
+ /
+
+
+-------------------------------------------------------------------------------
+
+8.5.5. crunch-if-none-match
+
+Typical use:
+
+ Prevent yet another way to track the user's steps between sessions.
+
+Effect:
+
+ Deletes the "If-None-Match:" HTTP client header.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ Removing the "If-None-Match:" HTTP client header is useful for filter
+ testing, where you want to force a real reload instead of getting status
+ code "304" which would cause the browser to use a cached copy of the page.
+
+ It is also useful to make sure the header isn't used as a cookie
+ replacement.
+
+ Blocking the "If-None-Match:" header shouldn't cause any caching problems,
+ as long as the "If-Modified-Since:" header isn't blocked as well.
+
+ It is recommended to use this action together with hide-if-modified-since
+ and overwrite-last-modified.
+
+Example usage (section):
+
+ # Let the browser revalidate cached documents without being tracked across sessions
+ {+hide-if-modified-since {-60} \
+ +overwrite-last-modified {randomize} \
+ +crunch-if-none-match}
+ /
+
+-------------------------------------------------------------------------------
+
+8.5.6. crunch-incoming-cookies
+
+Typical use:
+
+ Prevent the web server from setting any cookies on your system
+
+Effect:
+
+ Deletes any "Set-Cookie:" HTTP headers from server replies.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ This action is only concerned with incoming cookies. For outgoing cookies,
+ use crunch-outgoing-cookies. Use both to disable cookies completely.
+
+ It makes no sense at all to use this action in conjunction with the
+ session-cookies-only action, since it would prevent the session cookies
+ from being set. See also filter-content-cookies.
+
+Example usage:
+
+ +crunch-incoming-cookies
+
+-------------------------------------------------------------------------------
+
+8.5.7. crunch-server-header
+
+Typical use:
+
+ Remove a server header Privoxy has no dedicated action for.
+
+Effect:
+
+ Deletes every header sent by the server that contains the string the user
+ supplied as parameter.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ Any string.
+
+Notes:
+
+ This action allows you to block server headers for which no dedicated
+ Privoxy action exists. Privoxy will remove every server header that
+ contains the string you supplied as parameter.
+
+ Regular expressions are not supported and you can't use this action to
+ block different headers in the same request, unless they contain the same
+ string.
+
+ crunch-server-header is only meant for quick tests. If you have to block
+ several different headers, or only want to modify parts of them, you should
+ enable filter-server-headers and create your own filter.
+
+ +-----------------------------------------------------------------+
+ | Warning |
+ |-----------------------------------------------------------------|
+ |Don't block any header without understanding the consequences. |
+ +-----------------------------------------------------------------+
+Example usage (section):
+
+ # Crunch server headers that try to prevent caching
+ {+crunch-server-header {no-cache}}
+ /
+
+-------------------------------------------------------------------------------
+
+8.5.8. crunch-outgoing-cookies
+
+Typical use:
+
+ Prevent the web server from reading any cookies from your system
+
+Effect:
+
+ Deletes any "Cookie:" HTTP headers from client requests.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ This action is only concerned with outgoing cookies. For incoming cookies,
+ use crunch-incoming-cookies. Use both to disable cookies completely.
+
+ It makes no sense at all to use this action in conjunction with the
+ session-cookies-only action, since it would prevent the session cookies
+ from being read.
+
+Example usage:
+
+ +crunch-outgoing-cookies
+
+-------------------------------------------------------------------------------
+
+8.5.9. deanimate-gifs
+
+Typical use:
+
+ Stop those annoying, distracting animated GIF images.
+
+Effect:
+
+ De-animate GIF animations, i.e. reduce them to their first or last image.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ "last" or "first"
+
+Notes:
+
+ 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).
+
+ You can safely use this action with patterns that will also match non-GIF
+ objects, because no attempt will be made at anything that doesn't look like
+ a GIF.
+
+Example usage:
+
+ +deanimate-gifs{last}
+
+-------------------------------------------------------------------------------
+
+8.5.10. downgrade-http-version
+
+Typical use:
+
+ Work around (very rare) problems with HTTP/1.1
+
+Effect:
+
+ Downgrades HTTP/1.1 client requests and server replies to HTTP/1.0.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ This is a left-over from the time when Privoxy didn't support important
+ HTTP/1.1 features well. It is left here for the unlikely case that you
+ experience HTTP/1.1 related problems with some server out there. Not all
+ (optional) HTTP/1.1 features are supported yet, so there is a chance you
+ might need this action.
+
+Example usage (section):
+
+ {+downgrade-http-version}
+ problem-host.example.com
+
+-------------------------------------------------------------------------------
+
+8.5.11. fast-redirects
+
+Typical use:
+
+ Fool some click-tracking scripts and speed up indirect links.
+
+Effect:
+
+ Detects redirection URLs and redirects the browser without contacting the
+ redirection server first.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ + "simple-check" to just search for the string "http://" to detect
+ redirection URLs.
+
+ + "check-decoded-url" to decode URLs (if necessary) before searching for
+ redirection URLs.
+
+Notes:
+
+ Many sites, like yahoo.com, don't just link to other sites. Instead, they
+ will link to some script on their own servers, giving the destination as a
+ parameter, which will then redirect you to the final target. URLs resulting
+ from this scheme typically look like: "http://www.example.org/
+ click-tracker.cgi?target=http%3a//www.example.net/".
+
+ 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
+ asks the server for one redirect after the other. Plus, it feeds the
+ advertisers.
+
+ This feature is currently not very smart and is scheduled for improvement.
+ If it is enabled by default, you will have to create some exceptions to
+ this action. It can lead to failures in several ways:
+
+ Not every URLs with other URLs as parameters is evil. Some sites offer a
+ real service that requires this information to work. For example a
+ validation service needs to know, which document to validate.
+ fast-redirects assumes that every URL parameter that looks like another URL
+ is a redirection target, and will always redirect to the last one. Most of
+ the time the assumption is correct, but if it isn't, the user gets
+ redirected anyway.
+
+ Another failure occurs if the URL contains other parameters after the URL
+ parameter. The URL: "http://www.example.org/?redirect=http%3a//
+ www.example.net/&foo=bar". contains the redirection URL "http://
+ www.example.net/", followed by another parameter. fast-redirects doesn't
+ know that and will cause a redirect to "http://www.example.net/&foo=bar".
+ Depending on the target server configuration, the parameter will be
+ silently ignored or lead to a "page not found" error. It is possible to fix
+ these redirected requests with filter-client-headers but it requires a
+ little effort.
+
+ To detect a redirection URL, fast-redirects only looks for the string
+ "http://", either in plain text (invalid but often used) or encoded as
+ "http%3a//". Some sites use their own URL encoding scheme, encrypt the
+ address of the target server or replace it with a database id. In theses
+ cases fast-redirects is fooled and the request reaches the redirection
+ server where it probably gets logged.
+
+Example usage:
+
+ { +fast-redirects{simple-check} }
+ .example.com
+
+ { +fast-redirects{check-decoded-url} }
+ another.example.com/testing
+
+-------------------------------------------------------------------------------
+
+8.5.12. filter
+
+Typical use:
+
+ Get rid of HTML and JavaScript annoyances, banner advertisements (by size),
+ do fun text replacements, etc.
+
+Effect:
+
+ All files of text-based type, most notably HTML and JavaScript, to which
+ this action applies, are filtered on-the-fly through the specified regular
+ expression based substitutions. (Note: as of version 3.0.3 plain text
+ documents are exempted from filtering, because web servers often use the
+ text/plain MIME type for all files whose type they don't know.) By default,
+ filtering works only on the raw document content itself (that which can be
+ seen with View Source), not the headers.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ The name of a filter, as defined in the filter file. Filters can be defined
+ in one or more files as defined by the filterfile option in the config file
+ . default.filter is the collection of filters supplied by the developers.
+ Locally defined filters should go in their own file, such as user.filter.
+
+ When used in its negative form, and without parameters, all filtering is
+ completely disabled.
+
+Notes:
+
+ For your convenience, there are a number of pre-defined filters available
+ in the distribution filter file that you can use. See the examples below
+ for a list.
+
+ 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.
+
+ "Rolling your own" filters requires a knowledge of "Regular Expressions"
+ and "HTML". This is very powerful feature, and potentially very intrusive.
+ Use with caution.
+
+ The amount of data that can be filtered is limited to the buffer-limit
+ option in the main config file. The default is 4096 KB (4 Megs). Once this
+ limit is exceeded, the buffered data, and all pending data, is passed
+ through unfiltered.
+
+ Inappropriate MIME types, such as zipped files, are not filtered at all.
+ (Again, only text-based types except plain text). Encrypted SSL data (from
+ HTTPS servers) cannot be filtered either, since this would violate the
+ integrity of the secure transaction. In some situations it might be
+ necessary to protect certain text, like source code, from filtering by
+ defining appropriate -filter exceptions.
+
+ At this time, Privoxy cannot uncompress compressed documents. If you want
+ filtering to work on all documents, even those that would normally be sent
+ compressed, use the prevent-compression action in conjunction with filter.
+
+ Filtering can achieve some of the same effects as the block action, i.e. it
+ can be used to block ads and banners. But the mechanism works quite
+ differently. One effective use, is to block ad banners based on their size
+ (see below), since many of these seem to be somewhat standardized.
+
+ Feedback with suggestions for new or improved filters is particularly
+ welcome!
+
+ The below list has only the names and a one-line description of each
+ predefined filter. There are more verbose explanations of what these
+ filters do in the filter file chapter.
+
+Example usage (with filters from the distribution default.filter file). See the
+ Predefined Filters section for more explanation on each:
+
+ +filter{js-annoyances} # Get rid of particularly annoying JavaScript abuse
+
+ +filter{js-events} # Kill all JS event bindings (Radically destructive! Only for extra nasty sites)
+
+ +filter{html-annoyances} # Get rid of particularly annoying HTML abuse
+
+ +filter{content-cookies} # Kill cookies that come in the HTML or JS content
+
+ +filter{refresh-tags} # Kill automatic refresh tags (for dial-on-demand setups)
+
+ +filter{unsolicited-popups} # Disable only unsolicited pop-up windows
+
+ +filter{all-popups} # Kill all popups in JavaScript and HTML
+
+ +filter{img-reorder} # Reorder attributes in <img> tags to make the banners-by-* filters more effective
+
+ +filter{banners-by-size} # Kill banners by size
+
+ +filter{banners-by-link} # Kill banners by their links to known clicktrackers
+
+ +filter{webbugs} # Squish WebBugs (1x1 invisible GIFs used for user tracking)
+
+ +filter{tiny-textforms} # Extend those tiny textareas up to 40x80 and kill the hard wrap
+
+ +filter{jumping-windows} # Prevent windows from resizing and moving themselves
+
+ +filter{frameset-borders} # Give frames a border and make them resizeable
+
+ +filter{demoronizer} # Fix MS's non-standard use of standard charsets
+
+ +filter{shockwave-flash} # Kill embedded Shockwave Flash objects
+
+ +filter{quicktime-kioskmode} # Make Quicktime movies savable
+
+ +filter{fun} # Text replacements for subversive browsing fun!
+
+ +filter{crude-parental} # Crude parental filtering (demo only)
+
+ +filter{ie-exploits} # Disable some known Internet Explorer bug exploits
+
+-------------------------------------------------------------------------------
+
+8.5.13. filter-client-headers
+
+Typical use:
+
+ To apply filtering to the client's (browser's) headers
+
+Effect:
+
+ By default, Privoxy's filters only apply to the document content itself.
+ This will extend those filters to include the client's headers as well.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ Regular expressions can be used to filter headers as well. Check your
+ filters closely before activating this action, as it can easily lead to
+ broken requests.
+
+ These filters are applied to each header on its own, not to them all at
+ once. This makes it easier to diagnose problems, but on the downside you
+ can't write filters that only change header x if header y's value is z.
+
+ The filters are used after the other header actions have finished and can
+ use their output as input.
+
+ Whenever possible one should specify ^, $, the whole header name and the
+ colon, to make sure the filter doesn't cause havoc to other headers or the
+ page itself. For example if you want to transform Galeon User-Agents to
+ Firefox User-Agents you shouldn't use:
+
+ s@Galeon/\d\.\d\.\d @@
+
+ but:
+
+ s@^(User-Agent:.*) Galeon/\d\.\d\.\d (Firefox/\d\.\d\.\d\.\d)$@$1 $2@
+
+Example usage (section):
+
+ {+filter-client-headers +filter{test_filter}}
+ problem-host.example.com
+
+
+-------------------------------------------------------------------------------
+
+8.5.14. filter-server-headers
+
+Typical use:
+
+ To apply filtering to the server's headers
+
+Effect:
+
+ By default, Privoxy's filters only apply to the document content itself.
+ This will extend those filters to include the server's headers as well.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ Similar to filter-client-headers, but works on the server instead. To
+ filter both server and client, use both.
+
+ As with filter-client-headers, check your filters before activating this
+ action, as it can easily lead to broken requests.
+
+ These filters are applied to each header on its own, not to them all at
+ once. This makes it easier to diagnose problems, but on the downside you
+ can't write filters that only change header x if header y's value is z.
+
+ The filters are used after the other header actions have finished and can
+ use their output as input.
+
+ Remember too, whenever possible one should specify ^, $, the whole header
+ name and the colon, to make sure the filter doesn't cause havoc to other
+ headers or the page itself. See above for example.
+
+Example usage (section):
+
+ {+filter-server-headers +filter{test_filter}}
+ problem-host.example.com
+
+
+-------------------------------------------------------------------------------
+
+8.5.15. force-text-mode
+
+Typical use:
+
+ Force Privoxy to treat a document as if it was in some kind of text format.
+
+Effect:
+
+ Declares a document as text, even if the "Content-Type:" isn't detected as
+ such.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ As explained above, Privoxy tries to only filter files that are in some
+ kind of text format. The same restrictions apply to content-type-overwrite.
+ force-text-mode declares a document as text, without looking at the
+ "Content-Type:" first.
+
+ +-----------------------------------------------------------------+
+ | Warning |
+ |-----------------------------------------------------------------|
+ |Think twice before activating this action. Filtering binary data |
+ |with regular expressions can cause file damage. |
+ +-----------------------------------------------------------------+
+Example usage:
+
+ +force-text-mode
+
+
+-------------------------------------------------------------------------------
+
+8.5.16. handle-as-empty-document
+
+Typical use:
+
+ Mark URLs that should be replaced by empty documents if they get blocked
+
+Effect:
+
+ This action alone doesn't do anything noticeable. It just marks URLs. If
+ the block action also applies, the presence or absence of this mark decides
+ whether an HTML "blocked" page, or an empty document will be sent to the
+ client as a substitute for the blocked content. The empty document isn't
+ literally empty, but actually contains a single space.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ Some browsers complain about syntax errors if JavaScript documents are
+ blocked with Privoxy's default HTML page; this option can be used to
+ silence them.
+
+ The content type for the empty document can be specified with
+ content-type-overwrite{}, but usually this isn't necessary.
+
+Example usage:
+
+ # Block all documents on example.org that end with ".js",
+ # but send an empty document instead of the usual HTML message.
+ {+block +handle-as-empty-document}
+ example.org/.*\.js$
+
+
+-------------------------------------------------------------------------------
+
+8.5.17. handle-as-image
+
+Typical use:
+
+ Mark URLs as belonging to images (so they'll be replaced by images if they
+ do get blocked, rather than HTML pages)
+
+Effect:
+
+ This action alone doesn't do anything noticeable. It just marks URLs as
+ images. If the block action also applies, the presence or absence of this
+ mark decides whether an HTML "blocked" page, or a replacement image (as
+ determined by the set-image-blocker action) will be sent to the client as a
+ substitute for the blocked content.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ The below generic example section is actually part of default.action. It
+ marks all URLs with well-known image file name extensions as images and
+ should be left intact.
+
+ Users will probably only want to use the handle-as-image action in
+ conjunction with block, to block sources of banners, whose URLs don't
+ reflect the file type, like in the second example section.
+
+ Note that you cannot treat HTML pages as images in most cases. For
+ instance, (in-line) ad frames require an HTML page to be sent, or they
+ won't display properly. Forcing handle-as-image in this situation will not
+ replace the ad frame with an image, but lead to error messages.
+
+Example usage (sections):
+
+ # Generic image extensions:
+ #
+ {+handle-as-image}
+ /.*\.(gif|jpg|jpeg|png|bmp|ico)$
+
+ # These don't look like images, but they're banners and should be
+ # blocked as images:
+ #
+ {+block +handle-as-image}
+ some.nasty-banner-server.com/junk.cgi?output=trash
+
+ # Banner source! Who cares if they also have non-image content?
+ ad.doubleclick.net
+
+-------------------------------------------------------------------------------
+
+8.5.18. hide-accept-language
+
+Typical use:
+
+ Pretend to use different language settings.
+
+Effect:
+
+ Deletes or replaces the "Accept-Language:" HTTP header in client requests.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ Keyword: "block", or any user defined value.
+
+Notes:
+
+ Faking the browser's language settings can be useful to make a foreign
+ User-Agent set with hide-user-agent more believable.
+
+ However some sites with content in different languages check the
+ "Accept-Language:" to decide which one to take by default. Sometimes it
+ isn't possible to later switch to another language without changing the
+ "Accept-Language:" header first.
+
+ Therefore it's a good idea to either only change the "Accept-Language:"
+ header to languages you understand, or to languages that aren't wide
+ spread.
+
+ Before setting the "Accept-Language:" header to a rare language, you should
+ consider that it helps to make your requests unique and thus easier to
+ trace. If you don't plan to change this header frequently, you should stick
+ to a common language.
+
+Example usage (section):
+
+ # Pretend to use Canadian language settings.
+ {+hide-accept-language{en-ca} \
+ +hide-user-agent{Mozilla/5.0 (X11; U; OpenBSD i386; en-CA; rv:1.8.0.4) Gecko/20060628 Firefox/1.5.0.4} \
+ }
+ /
+
+-------------------------------------------------------------------------------
+
+8.5.19. hide-content-disposition
+
+Typical use:
+
+ Prevent download menus for content you prefer to view inside the browser.
+
+Effect:
+
+ Deletes or replaces the "Content-Disposition:" HTTP header set by some
+ servers.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ Keyword: "block", or any user defined value.
+
+Notes:
+
+ Some servers set the "Content-Disposition:" HTTP header for documents they
+ assume you want to save locally before viewing them. The
+ "Content-Disposition:" header contains the file name the browser is
+ supposed to use by default.
+
+ In most browsers that understand this header, it makes it impossible to
+ just view the document, without downloading it first, even if it's just a
+ simple text file or an image.
+
+ Removing the "Content-Disposition:" header helps to prevent this annoyance,
+ but some browsers additionally check the "Content-Type:" header, before
+ they decide if they can display a document without saving it first. In
+ these cases, you have to change this header as well, before the browser
+ stops displaying download menus.
+
+ It is also possible to change the server's file name suggestion to another
+ one, but in most cases it isn't worth the time to set it up.
+
+Example usage:
+
+ # Disarm the download link in Sourceforge's patch tracker
+ {-filter\
+ +content-type-overwrite {text/plain}\
+ +hide-content-disposition {block} }
+ .sourceforge.net/tracker/download.php
+
+-------------------------------------------------------------------------------
+
+8.5.20. hide-if-modified-since
+
+Typical use:
+
+ Prevent yet another way to track the user's steps between sessions.
+
+Effect:
+
+ Deletes the "If-Modified-Since:" HTTP client header or modifies its value.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ Keyword: "block", or a user defined value that specifies a range of hours.
+
+Notes:
+
+ Removing this header is useful for filter testing, where you want to force
+ a real reload instead of getting status code "304", which would cause the
+ browser to use a cached copy of the page.
+
+ Instead of removing the header, hide-if-modified-since can also add or
+ subtract a random amount of time to/from the header's value. You specify a
+ range of minutes where the random factor should be chosen from and Privoxy
+ does the rest. A negative value means subtracting, a positive value adding.
+
+ Randomizing the value of the "If-Modified-Since:" makes sure it isn't used
+ as a cookie replacement, but you will run into caching problems if the
+ random range is too high.
+
+ It is a good idea to only use a small negative value and let
+ overwrite-last-modified handle the greater changes.
+
+ It is also recommended to use this action together with
+ crunch-if-none-match.
+
+Example usage (section):
+
+ # Let the browser revalidate without being tracked across sessions
+ {+hide-if-modified-since {-60}\
+ +overwrite-last-modified {randomize}\
+ +crunch-if-none-match}
+ /
+
+-------------------------------------------------------------------------------
+
+8.5.21. hide-forwarded-for-headers
+
+Typical use:
+
+ Improve privacy by hiding the true source of the request
+
+Effect:
+
+ Deletes any existing "X-Forwarded-for:" HTTP header from client requests,
+ and prevents adding a new one.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ It is fairly safe to leave this on.
+
+ This action is scheduled for improvement: It should be able to generate
+ forged "X-Forwarded-for:" headers using random IP addresses from a
+ specified network, to make successive requests from the same client look
+ like requests from a pool of different users sharing the same proxy.
+
+Example usage:
+
+ +hide-forwarded-for-headers
+
+-------------------------------------------------------------------------------
+
+8.5.22. hide-from-header
+
+Typical use:
+
+ Keep your (old and ill) browser from telling web servers your email address
+
+Effect:
+
+ Deletes any existing "From:" HTTP header, or replaces it with the specified
+ string.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ Keyword: "block", or any user defined value.
+
+Notes:
+
+ 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 be sent to the web
+ server. If you do, it is a matter of fairness not to use any address that
+ is actually used by a real person.
+
+ This action is rarely needed, as modern web browsers don't send "From:"
+ headers anymore.
+
+Example usage:
+
+ +hide-from-header{block}
+
+ or
+
+ +hide-from-header{spam-me-senseless@sittingduck.example.com}
+
+-------------------------------------------------------------------------------
+
+8.5.23. hide-referrer
+
+Typical use:
+
+ Conceal which link you followed to get to a particular site
+
+Effect:
+
+ Deletes the "Referer:" (sic) HTTP header from the client request, or
+ replaces it with a forged one.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ + "conditional-block" to delete the header completely if the host has
+ changed.
+
+ + "block" to delete the header unconditionally.
+
+ + "forge" to pretend to be coming from the homepage of the server we are
+ talking to.
+
+ + Any other string to set a user defined referrer.
+
+Notes:
+
+ conditional-block is the only parameter, that isn't easily detected in the
+ server's log file. If it blocks the referrer, the request will look like
+ the visitor used a bookmark or typed in the address directly.
+
+ Leaving the referrer unmodified for requests on the same host allows the
+ server owner to see the visitor's "click path", but in most cases she could
+ also get that information by comparing other parts of the log file: for
+ example the User-Agent if it isn't a very common one, or the user's IP
+ address if it doesn't change between different requests.
+
+ Always blocking the referrer, or using a custom one, can lead to failures
+ on servers that check the referrer before they answer any requests, in an
+ attempt to prevent their valuable content from being embedded or linked to
+ elsewhere.
+
+ Both conditional-block and forge will work with referrer checks, as long as
+ content and valid referring page are on the same host. Most of the time
+ that's the case.
+
+ hide-referer is an alternate spelling of hide-referrer and the two can be
+ can be freely substituted with each other. ("referrer" is the correct
+ English spelling, however the HTTP specification has a bug - it requires it
+ to be spelled as "referer".)
+
+Example usage:
+
+ +hide-referrer{forge}
+
+ or
+
+ +hide-referrer{http://www.yahoo.com/}
+
+-------------------------------------------------------------------------------
+
+8.5.24. hide-user-agent
+
+Typical use:
+
+ Conceal your type of browser and client operating system
+
+Effect:
+
+ Replaces the value of the "User-Agent:" HTTP header in client requests with
+ the specified value.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ Any user-defined string.
+
+Notes:
+
+ +-----------------------------------------------------------------+
+ | Warning |
+ |-----------------------------------------------------------------|
+ |This can lead to problems on web sites that depend on looking at |
+ |this header in order to customize their content for different |
+ |browsers (which, by the way, is NOT the right thing to do: good |
+ |web sites work browser-independently). |
+ +-----------------------------------------------------------------+
+
+ Using this action in multi-user setups or wherever different types of
+ browsers will access the same Privoxy is not recommended. In single-user,
+ single-browser setups, you might use it to delete your OS version
+ information from the headers, because it is an invitation to exploit known
+ bugs for your OS. It is also occasionally useful to forge this in order to
+ access sites that won't let you in otherwise (though there may be a good
+ reason in some cases). Example of this: some MSN sites will not let Mozilla
+ enter, yet forging to a Netscape 6.1 user-agent works just fine. (Must be
+ just a silly MS goof, I'm sure :-).
+
+ This action is scheduled for improvement.
+
+Example usage:
+
+ +hide-user-agent{Netscape 6.1 (X11; I; Linux 2.4.18 i686)}
+
+-------------------------------------------------------------------------------
+
+8.5.25. inspect-jpegs
+
+Typical use:
+
+ To protect against the MS buffer over-run in JPEG processing
+
+Effect:
+
+ Protect against a known exploit
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ See Microsoft Security Bulletin MS04-028. JPEG images are one of the most
+ common image types found across the Internet. The exploit as described can
+ allow execution of code on the target system, giving an attacker access to
+ the system in question by merely planting an altered JPEG image, which
+ would have no obvious indications of what lurks inside. This action
+ prevents unwanted intrusion.
+
+Example usage:
+
+ +inspect-jpegs
+
+-------------------------------------------------------------------------------
+
+8.5.26. kill-popups
+
+Typical use:
+
+ Eliminate those annoying pop-up windows (deprecated)
+
+Effect:
+
+ While loading the document, replace JavaScript code that opens pop-up
+ windows with (syntactically neutral) dummy code on the fly.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ This action is basically a built-in, hardwired special-purpose filter
+ action, but there are important differences: For kill-popups, the document
+ need not be buffered, so it can be incrementally rendered while
+ downloading. But kill-popups doesn't catch as many pop-ups as filter
+ {all-popups} does and is not as smart as filter{unsolicited-popups} is.
+
+ Think of it as a fast and efficient replacement for a filter that you can
+ use if you don't want any filtering at all. Note that it doesn't make sense
+ to combine it with any filter action, since as soon as one filter applies,
+ the whole document needs to be buffered anyway, which destroys the
+ advantage of the kill-popups action over its filter equivalent.
+
+ Killing all pop-ups unconditionally is problematic. Many shops and banks
+ rely on pop-ups to display forms, shopping carts etc, and the filter
+ {unsolicited-popups} does a fairly good job of catching only the unwanted
+ ones.
+
+ If the only kind of pop-ups that you want to kill are exit consoles (those
+ really nasty windows that appear when you close an other one), you might
+ want to use filter{js-annoyances} instead.
+
+Example usage:
+
+ +kill-popups
+
+-------------------------------------------------------------------------------
+
+8.5.27. limit-connect
+
+Typical use:
+
+ Prevent abuse of Privoxy as a TCP proxy relay or disable SSL for untrusted
+ sites
+
+Effect:
+
+ Specifies to which ports HTTP CONNECT requests are allowable.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ A comma-separated list of ports or port ranges (the latter using dashes,
+ with the minimum defaulting to 0 and the maximum to 65K).
+
+Notes:
+
+ By default, i.e. if no limit-connect action applies, Privoxy only allows
+ HTTP CONNECT requests to port 443 (the standard, secure HTTPS port). Use
+ limit-connect if more fine-grained control is desired for some or all
+ destinations.
+
+ 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 server. This can be a big
+ security hole, since CONNECT-enabled proxies can be abused as TCP relays
+ very easily.
+
+ Privoxy relays HTTPS traffic without seeing the decoded content. Websites
+ can leverage this limitation to circumvent Privoxy's filters. By specifying
+ an invalid port range you can disable HTTPS entirely. If you plan to
+ disable SSL by default, consider enabling
+ treat-forbidden-connects-like-blocks as well, to be able to quickly create
+ exceptions.
+
+Example usages:
+
+ +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-} # Ports less than 3, 7, 20 to 100 and above 500 are OK.
+ +limit-connect{-} # All ports are OK
+ +limit-connect{,} # No HTTPS/SSL traffic is allowed
+
+-------------------------------------------------------------------------------
+
+8.5.28. prevent-compression
+
+Typical use:
+
+ Ensure that servers send the content uncompressed, so it can be passed
+ through filters.
+
+Effect:
+
+ Removes the Accept-Encoding header which can be used to ask for compressed
+ transfer.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ More and more websites send their content compressed by default, which is
+ generally a good idea and saves bandwidth. But for the filter,
+ deanimate-gifs and kill-popups actions to work, Privoxy needs access to the
+ uncompressed data. Unfortunately, Privoxy can't yet(!) uncompress, filter,
+ and re-compress the content on the fly. So if you want to ensure that all
+ websites, including those that normally compress, can be filtered, you need
+ to use this action.
+
+ This will slow down transfers from those websites, though. If you use any
+ of the above-mentioned actions, you will typically want to use
+ prevent-compression in conjunction with them.
+
+ Note that some (rare) ill-configured sites don't handle requests for
+ uncompressed documents correctly (they send an empty document body). If you
+ use prevent-compression per default, you'll have to add exceptions for
+ those sites. See the example for how to do that.
+
+Example usage (sections):
+
+ # Set default:
+ #
+ {+prevent-compression}
+ / # Match all sites
+
+ # Make exceptions for ill sites:
+ #
+ {-prevent-compression}
+ www.debianhelp.org
+ www.pclinuxonline.com
+
+-------------------------------------------------------------------------------
+
+8.5.29. overwrite-last-modified
+
+Typical use:
+
+ Prevent yet another way to track the user's steps between sessions.
+
+Effect:
+
+ Deletes the "Last-Modified:" HTTP server header or modifies its value.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ One of the keywords: "block", "reset-to-request-time" and "randomize"
+
+Notes:
+
+ Removing the "Last-Modified:" header is useful for filter testing, where
+ you want to force a real reload instead of getting status code "304", which
+ would cause the browser to reuse the old version of the page.
+
+ The "randomize" option overwrites the value of the "Last-Modified:" header
+ with a randomly chosen time between the original value and the current
+ time. In theory the server could send each document with a different
+ "Last-Modified:" header to track visits without using cookies. "Randomize"
+ makes it impossible and the browser can still revalidate cached documents.
+
+ "reset-to-request-time" overwrites the value of the "Last-Modified:" header
+ with the current time. You could use this option together with
+ hided-if-modified-since to further customize your random range.
+
+ The preferred parameter here is "randomize". It is safe to use, as long as
+ the time settings are more or less correct. If the server sets the
+ "Last-Modified:" header to the time of the request, the random range
+ becomes zero and the value stays the same. Therefore you should later
+ randomize it a second time with hided-if-modified-since, just to be sure.
+
+ It is also recommended to use this action together with
+ crunch-if-none-match.
+
+Example usage:
+
+ # Let the browser revalidate without being tracked across sessions
+ {+hide-if-modified-since {-60}\
+ +overwrite-last-modified {randomize}\
+ +crunch-if-none-match}
+ /
+
+-------------------------------------------------------------------------------
+
+8.5.30. redirect
+
+Typical use:
+
+ Redirect requests to other sites.
+
+Effect:
+
+ Convinces the browser that the requested document has been moved to another
+ location and the browser should get it from there.
+
+Type:
+
+ Parameterized
+
+Parameter:
+
+ Any URL.
+
+Notes:
+
+ This action is useful to replace whole documents with ones of your
+ choosing. This can be used to enforce safe surfing, or just as a simple
+ convenience.
+
+ You can do the same by combining the actions block, handle-as-image and
+ set-image-blocker{URL}. It doesn't sound right for non-image documents, and
+ that's why this action was created.
+
+ This action will be ignored if you use it together with block.
+
+Example usages:
+
+ # Replace example.com's style sheet with another one
+ { +redirect{http://localhost/css-replacements/example.com.css} }
+ example.com/stylesheet.css
+
+ # Create a short, easy to remember nickname for a favorite site
+ { +redirect{http://www.privoxy.org/user-manual/actions-file.html} }
+ a
+
+-------------------------------------------------------------------------------
+
+8.5.31. send-vanilla-wafer
+
+Typical use:
+
+ Feed log analysis scripts with useless data.
+
+Effect:
+
+ Sends a cookie with each request stating that you do not accept any
+ copyright on cookies sent to you, and asking the site operator not to track
+ you.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ The vanilla wafer is a (relatively) unique header and could conceivably be
+ used to track you.
+
+ This action is rarely used and not enabled in the default configuration.
+
+Example usage:
+
+ +send-vanilla-wafer
+
+-------------------------------------------------------------------------------
+
+8.5.32. send-wafer
+
+Typical use:
+
+ Send custom cookies or feed log analysis scripts with even more useless
+ data.
+
+Effect:
+
+ Sends a custom, user-defined cookie with each request.
+
+Type:
+
+ Multi-value.
+
+Parameter:
+
+ A string of the form "name=value".
+
+Notes:
+
+ Being multi-valued, multiple instances of this action can apply to the same
+ request, resulting in multiple cookies being sent.
+
+ This action is rarely used and not enabled in the default configuration.
+
+Example usage (section):
+
+ {+send-wafer{UsingPrivoxy=true}}
+ my-internal-testing-server.void
+
+-------------------------------------------------------------------------------
+
+8.5.33. session-cookies-only
+
+Typical use:
+
+ Allow only temporary "session" cookies (for the current browser session
+ only).
+
+Effect:
+
+ Deletes the "expires" field from "Set-Cookie:" server headers. Most
+ browsers will not store such cookies permanently and forget them in between
+ sessions.
+
+Type:
+
+ Boolean.
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ This is less strict than crunch-incoming-cookies / crunch-outgoing-cookies
+ and allows you to browse websites that insist or rely on setting cookies,
+ without compromising your privacy too badly.
+
+ Most browsers will not permanently store cookies that have been processed
+ by session-cookies-only and will forget about them between sessions. 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.
+
+ It makes no sense at all to use session-cookies-only together with
+ crunch-incoming-cookies or crunch-outgoing-cookies. If you do, cookies will
+ be plainly killed.
+
+ Note that it is up to the browser how it handles such cookies without an
+ "expires" field. If you use an exotic browser, you might want to try it out
+ to be sure.
+
+ This setting also has no effect on cookies that may have been stored
+ previously by the browser before starting Privoxy. These would have to be
+ removed manually.
+
+ Privoxy also uses the content-cookies filter to block some types of
+ cookies. Content cookies are not effected by session-cookies-only.
+
+Example usage:
+
+ +session-cookies-only
+
+-------------------------------------------------------------------------------
+
+8.5.34. set-image-blocker
+
+Typical use:
+
+ Choose the replacement for blocked images
+
+Effect:
+
+ This action alone doesn't do anything noticeable. If both block and
+ handle-as-image also apply, i.e. if the request is to be blocked as an
+ image, then the parameter of this action decides what will be sent as a
+ replacement.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ + "pattern" to send a built-in checkerboard pattern image. The image is
+ visually decent, scales very well, and makes it obvious where banners
+ were busted.
+
+ + "blank" to send a built-in transparent image. This makes banners
+ disappear completely, but makes it hard to detect where Privoxy has
+ blocked images on a given page and complicates troubleshooting if
+ Privoxy has blocked innocent images, like navigation icons.
+
+ + "target-url" to send a redirect to target-url. You can redirect to any
+ image anywhere, even in your local filesystem via "file:///" URL. (But
+ note that not all browsers support redirecting to a local file system).
+
+ A good application of redirects is to use special Privoxy-built-in
+ URLs, which send the built-in images, as target-url. This has the same
+ visual effect as specifying "blank" or "pattern" in the first place,
+ but enables your browser to cache the replacement image, instead of
+ requesting it over and over again.
+
+Notes:
+
+ The URLs for the built-in images are "http://config.privoxy.org/
+ send-banner?type=type", where type is either "blank" or "pattern".
+
+ There is a third (advanced) type, called "auto". It is NOT to be used in
+ set-image-blocker, but meant for use from filters. Auto will select the
+ type of image that would have applied to the referring page, had it been an
+ image.
+
+Example usage:
+
+ Built-in pattern:
+
+ +set-image-blocker{pattern}
+
+ Redirect to the BSD devil: