+ 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.
+ Filters should be used with caution, and where an equivalent "action" is
+ not available.
+
+ 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.
+
+ Compressed content can't be filtered either, unless Privoxy is compiled
+ with zlib support (requires at least Privoxy 3.0.7), in which case Privoxy
+ will decompress the content before filtering it.
+
+ If you use a Privoxy version without zlib support, but want filtering to
+ work on as much documents as possible, even those that would normally be
+ sent compressed, you must use the prevent-compression action in conjunction
+ with filter.
+
+ Content 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. Useful if your browser lacks this ability.
+
+
+ +filter{all-popups} # Kill all popups in JavaScript and HTML. Useful if your browser lacks this ability.
+
+
+ +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 a known Internet Explorer bug exploits
+
+
+ +filter{site-specifics} # Custom filters for specific site related problems
+
+
+ +filter{google} # Removes text ads and other Google specific improvements
+
+
+ +filter{yahoo} # Removes text ads and other Yahoo specific improvements
+
+
+ +filter{msn} # Removes text ads and other MSN specific improvements
+
+
+ +filter{blogspot} # Cleans up Blogspot blogs
+
+
+ +filter{no-ping} # Removes non-standard ping attributes from anchor and area tags
+
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+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. forward-override
+
+Typical use:
+
+ Change the forwarding settings based on User-Agent or request origin
+
+Effect:
+
+ Overrules the forward directives in the configuration file.
+
+Type:
+
+ Multi-value.
+
+Parameter:
+
+ □ "forward ." to use a direct connection without any additional proxies.
+
+ □ "forward 127.0.0.1:8123" to use the HTTP proxy listening at 127.0.0.1
+ port 8123.
+
+ □ "forward-socks4a 127.0.0.1:9050 ." to use the socks4a proxy listening
+ at 127.0.0.1 port 9050. Replace "forward-socks4a" with "forward-socks4"
+ to use a socks4 connection (with local DNS resolution) instead.
+
+ □ "forward-socks4a 127.0.0.1:9050 proxy.example.org:8000" to use the
+ socks4a proxy listening at 127.0.0.1 port 9050 to reach the HTTP proxy
+ listening at proxy.example.org port 8000. Replace "forward-socks4a"
+ with "forward-socks4" to use a socks4 connection (with local DNS
+ resolution) instead.
+
+Notes:
+
+ This action takes parameters similar to the forward directives in the
+ configuration file, but without the URL pattern. It can be used as
+ replacement, but normally it's only used in cases where matching based on
+ the request URL isn't sufficient.
+
+ ┌─────────────────────────────────────────────────────────────────┐
+ │ Warning │
+ ├─────────────────────────────────────────────────────────────────┤
+ │Please read the description for the forward directives before │
+ │using this action. Forwarding to the wrong people will reduce │
+ │your privacy and increase the chances of man-in-the-middle │
+ │attacks. │
+ │ │
+ │If the ports are missing or invalid, default values will be used.│
+ │This might change in the future and you shouldn't rely on it. │
+ │Otherwise incorrect syntax causes Privoxy to exit. │
+ │ │
+ │Use the show-url-info CGI page to verify that your forward │
+ │settings do what you thought the do. │
+ └─────────────────────────────────────────────────────────────────┘
+Example usage:
+
+ # Always use direct connections for requests previously tagged as
+ # "User-Agent: fetch libfetch/2.0" and make sure
+ # resuming downloads continues to work.
+ # This way you can continue to use Tor for your normal browsing,
+ # without overloading the Tor network with your FreeBSD ports updates
+ # or downloads of bigger files like ISOs.
+ {+forward-override{forward .} \
+ -hide-if-modified-since \
+ -overwrite-last-modified \
+ }
+ TAG:^User-Agent: fetch libfetch/2\.0$
+
+
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.5.17. 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. And of course this action can also be used to eliminate the
+ Privoxy BLOCKED message in frames.
+
+ 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.18. 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.19. 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.20. 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.
+
+ This action will probably be removed in the future, use server-header
+ filters instead.
+
+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.21. 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.22. hide-forwarded-for-headers
+
+Typical use:
+
+ Improve privacy by not embedding the source of the request in the HTTP
+ headers.
+
+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 safe to leave this on.
+
+Example usage:
+
+ +hide-forwarded-for-headers
+
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.5.23. 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.24. 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.25. 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 :-).
+
+ More information on known user-agent strings can be found at http://
+ www.user-agents.org/ and http://en.wikipedia.org/wiki/User_agent.
+
+Example usage:
+
+ +hide-user-agent{Netscape 6.1 (X11; I; Linux 2.4.18 i686)}
+
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.5.26. 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 this exploit.
+
+ Note that the described exploit is only one of many, using this action does
+ not mean that you no longer have to patch the client.
+
+Example usage:
+
+ +inspect-jpegs
+
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.5.27. 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 better 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.
+
+ This action is most appropriate for browsers that don't have any controls
+ for unwanted pop-ups. Not recommended for general usage.
+
+Example usage:
+
+ +kill-popups
+
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.5.28. 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.29. 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 the filter, deanimate-gifs
+ and kill-popups actions need access to the uncompressed data.
+
+ When compiled with zlib support (available since Privoxy 3.0.7), content
+ that should be filtered is decompressed on-the-fly and you don't have to
+ worry about this action. If you are using an older Privoxy version, or one
+ that hasn't been compiled with zlib support, this action can be used to
+ convince the server to send the content uncompressed.
+
+ Most text-based instances compress very well, the size is seldom decreased
+ by less than 50%, for markup-heavy instances like news feeds saving more
+ than 90% of the original size isn't unusual.
+
+ Not using compression will therefore slow down the transfer, and you should
+ only enable this action if you really need it. As of Privoxy 3.0.7 it's
+ disabled in all predefined action settings.
+
+ Note that some (rare) ill-configured sites don't handle requests for
+ uncompressed documents correctly. Broken PHP applications tend to send an
+ empty document body, some IIS versions only send the beginning of the
+ content. If you enable prevent-compression per default, you might want to
+ add exceptions for those sites. See the example for how to do that.
+
+Example usage (sections):
+
+ # Selectively turn off compression, and enable a filter
+ #
+ { +filter{tiny-textforms} +prevent-compression }
+ # Match only these sites
+ .google.
+ sourceforge.net
+ sf.net
+
+ # Or instead, we could set a universal default:
+ #
+ { +prevent-compression }
+ / # Match all sites
+
+ # Then maybe make exceptions for broken sites:
+ #
+ { -prevent-compression }
+ .compusa.com/
+
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.5.30. 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.31. 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:
+
+ An absolute URL or a single pcrs command.
+
+Notes:
+
+ Requests to which this action applies are answered with a HTTP redirect to
+ URLs of your choosing. The new URL is either provided as parameter, or
+ derived by applying a single pcrs command to the original URL.
+
+ This action will be ignored if you use it together with block. It can be
+ combined with fast-redirects{check-decoded-url} to redirect to a decoded
+ version of a rewritten URL.
+
+ Use this action carefully, make sure not to create redirection loops and be
+ aware that using your own redirects might make it possible to fingerprint
+ your requests.
+
+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
+ # (relies on the browser accept and forward invalid URLs to Privoxy)
+ { +redirect{http://www.privoxy.org/user-manual/actions-file.html} }
+ a
+
+ # Always use the expanded view for Undeadly.org articles
+ # (Note the $ at the end of the URL pattern to make sure
+ # the request for the rewritten URL isn't redirected as well)
+ {+redirect{s@$@&mode=expanded@}}
+ undeadly.org/cgi\?action=article&sid=\d*$
+
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.5.32. 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.33. 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.34. server-header-filter
+
+Typical use:
+
+ Rewrite or remove single server headers.
+
+Effect:
+
+ All server headers to which this action applies are filtered on-the-fly
+ through the specified regular expression based substitutions.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ The name of a server-header filter, as defined in one of the filter files.
+
+Notes:
+
+ Server-header filters are applied to each header on its own, not to 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. You
+ can do that by using tags though.
+
+ Server-header filters are executed after the other header actions have
+ finished and use their output as input.
+
+ Please refer to the filter file chapter to learn which server-header
+ filters are available by default, and how to create your own.
+
+Example usage (section):
+
+ {+server-header-filter{html-to-xml}}
+ example.org/xml-instance-that-is-delivered-as-html
+
+ {+server-header-filter{xml-to-html}}
+ example.org/instance-that-is-delivered-as-xml-but-is-not
+
+
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.5.35. server-header-tagger
+
+Typical use:
+
+ Enable or disable filters based on the Content-Type header.
+
+Effect:
+
+ Server headers to which this action applies are filtered on-the-fly through
+ the specified regular expression based substitutions, the result is used as
+ tag.
+
+Type:
+
+ Parameterized.
+
+Parameter:
+
+ The name of a server-header tagger, as defined in one of the filter files.
+
+Notes:
+
+ Server-header taggers are applied to each header on its own, and as the
+ header isn't modified, each tagger "sees" the original.
+
+ Server-header taggers are executed before all other header actions that
+ modify server headers. Their tags can be used to control all of the other
+ server-header actions, the content filters and the crunch actions (redirect
+ and block).
+
+ Obviously crunching based on tags created by server-header taggers doesn't
+ prevent the request from showing up in the server's log file.
+
+Example usage (section):
+
+ # Tag every request with the content type declared by the server
+ {+server-header-tagger{content-type}}
+ /
+
+
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.5.36. 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.37. 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 daemon:
+
+ +set-image-blocker{http://www.freebsd.org/gifs/dae_up3.gif}
+
+
+ Redirect to the built-in pattern for better caching:
+
+ +set-image-blocker{http://config.privoxy.org/send-banner?type=pattern}
+
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.5.38. treat-forbidden-connects-like-blocks
+
+Typical use:
+
+ Block forbidden connects with an easy to find error message.
+
+Effect:
+
+ If this action is enabled, Privoxy no longer makes a difference between
+ forbidden connects and ordinary blocks.
+
+Type:
+
+ Boolean
+
+Parameter:
+
+ N/A
+
+Notes:
+
+ By default Privoxy answers forbidden "Connect" requests with a short error
+ message inside the headers. If the browser doesn't display headers (most
+ don't), you just see an empty page.
+
+ With this action enabled, Privoxy displays the message that is used for
+ ordinary blocks instead. If you decide to make an exception for the page in
+ question, you can do so by following the "See why" link.
+
+ For "Connect" requests the clients tell Privoxy which host they are
+ interested in, but not which document they plan to get later. As a result,
+ the "Go there anyway" wouldn't work and is therefore suppressed.
+
+Example usage:
+
+ +treat-forbidden-connects-like-blocks
+
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.5.39. Summary
+
+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.
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.6. Aliases
+
+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 name can contain any character except space, tab, "=", "{"
+and "}", but we strongly recommend that you only use "a" to "z", "0" to "9",
+"+", and "-". Alias names are not case sensitive, and are not required to start
+with a "+" or "-" sign, since they are merely textually expanded.
+
+Aliases can be used throughout the actions file, but they must be defined in a
+special section at the top of the file! And there can only be one such section
+per actions file. Each actions file may have its own alias section, and the
+aliases defined in it are only visible within that file.
+
+There are two main reasons to use aliases: One is to save typing for frequently
+used combinations of actions, the other one is a gain in flexibility: If you
+decide once how you want to handle shops by defining an alias called "shop",
+you can later change your policy on shops in one place, and your changes will
+take effect everywhere in the actions file where the "shop" alias is used.
+Calling aliases by their purpose also makes your actions files more readable.
+
+Currently, there is one big drawback to using aliases, though: Privoxy's
+built-in web-based action file editor honors aliases when reading the actions
+files, but it expands them before writing. So the effects of your aliases are
+of course preserved, but the aliases themselves are lost when you edit sections
+that use aliases with it.
+
+Now let's define some aliases...
+
+ # Useful custom aliases we can use later.
+ #
+ # Note the (required!) section header line and that this section
+ # must be at the top of the actions file!
+ #
+ {{alias}}
+
+ # These aliases just save typing later:
+ # (Note that some already use other aliases!)
+ #
+ +crunch-all-cookies = +crunch-incoming-cookies +crunch-outgoing-cookies
+ -crunch-all-cookies = -crunch-incoming-cookies -crunch-outgoing-cookies
+ +block-as-image = +block +handle-as-image
+ allow-all-cookies = -crunch-all-cookies -session-cookies-only -filter{content-cookies}
+
+ # These aliases define combinations of actions
+ # that are useful for certain types of sites:
+ #
+ fragile = -block -filter -crunch-all-cookies -fast-redirects -hide-referrer -kill-popups -prevent-compression
+
+ shop = -crunch-all-cookies -filter{all-popups} -kill-popups
+
+ # Short names for other aliases, for really lazy people ;-)
+ #
+ c0 = +crunch-all-cookies
+ c1 = -crunch-all-cookies
+
+
+...and put them to use. These sections would appear in the lower part of an
+actions file and define exceptions to the default actions (as specified further
+up for the "/" pattern):
+
+ # These sites are either very complex or very keen on
+ # user data and require minimal interference to work:
+ #
+ {fragile}
+ .office.microsoft.com
+ .windowsupdate.microsoft.com
+ # Gmail is really mail.google.com, not gmail.com
+ mail.google.com
+
+ # Shopping sites:
+ # Allow cookies (for setting and retrieving your customer data)
+ #
+ {shop}
+ .quietpc.com
+ .worldpay.com # for quietpc.com
+ mybank.example.com
+
+ # These shops require pop-ups:
+ #
+ {-kill-popups -filter{all-popups} -filter{unsolicited-popups}}
+ .dabs.com
+ .overclockers.co.uk
+
+
+Aliases like "shop" and "fragile" are typically used for "problem" sites that
+require more than one action to be disabled in order to function properly.
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.7. Actions Files Tutorial
+
+The above chapters have shown which actions files there are and how they are
+organized, how actions are specified and applied to URLs, how patterns work,
+and how to define and use aliases. Now, let's look at an example default.action
+and user.action file and see how all these pieces come together:
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.7.1. default.action
+
+Every config file should start with a short comment stating its purpose:
+
+# Sample default.action file <ijbswa-developers@lists.sourceforge.net>
+
+
+Then, since this is the default.action file, the first section is a special
+section for internal use that you needn't change or worry about:
+
+##########################################################################
+# Settings -- Don't change! For internal Privoxy use ONLY.
+##########################################################################
+
+{{settings}}
+for-privoxy-version=3.0
+
+
+After that comes the (optional) alias section. We'll use the example section
+from the above chapter on aliases, that also explains why and how aliases are
+used:
+
+##########################################################################
+# Aliases
+##########################################################################
+{{alias}}
+
+ # These aliases just save typing later:
+ # (Note that some already use other aliases!)
+ #
+ +crunch-all-cookies = +crunch-incoming-cookies +crunch-outgoing-cookies
+ -crunch-all-cookies = -crunch-incoming-cookies -crunch-outgoing-cookies
+ +block-as-image = +block +handle-as-image
+ mercy-for-cookies = -crunch-all-cookies -session-cookies-only -filter{content-cookies}
+
+ # These aliases define combinations of actions
+ # that are useful for certain types of sites:
+ #
+ fragile = -block -filter -crunch-all-cookies -fast-redirects -hide-referrer -kill-popups
+ shop = -crunch-all-cookies -filter{all-popups} -kill-popups
+
+
+Now come the regular sections, i.e. sets of actions, accompanied by URL
+patterns to which they apply. Remember all actions are disabled when matching
+starts, so we have to explicitly enable the ones we want.
+
+The first regular section is probably the most important. It has only one
+pattern, "/", but this pattern matches all URLs. Therefore, the set of actions
+used in this "default" section will be applied to all requests as a start. It
+can be partly or wholly overridden by later matches further down this file, or
+in user.action, but it will still be largely responsible for your overall
+browsing experience.
+
+Again, at the start of matching, all actions are disabled, so there is no need
+to disable any actions here. (Remember: a "+" preceding the action name enables
+the action, a "-" disables!). Also note how this long line has been made more
+readable by splitting it into multiple lines with line continuation.
+
+##########################################################################
+# "Defaults" section:
+##########################################################################
+ { \
+ +deanimate-gifs \
+ +filter{html-annoyances} \
+ +filter{refresh-tags} \
+ +filter{webbugs} \
+ +filter{ie-exploits} \
+ +hide-forwarded-for-headers \
+ +hide-from-header{block} \
+ +hide-referrer{forge} \
+ +prevent-compression \
+ +session-cookies-only \
+ +set-image-blocker{pattern} \
+ }
+ / # forward slash will match *all* potential URL patterns.
+
+
+The default behavior is now set.
+
+The first of our specialized sections is concerned with "fragile" sites, i.e.
+sites that require minimum interference, because they are either very complex
+or very keen on tracking you (and have mechanisms in place that make them
+unusable for people who avoid being tracked). We will simply use our
+pre-defined fragile alias instead of stating the list of actions explicitly:
+
+##########################################################################
+# Exceptions for sites that'll break under the default action set:
+##########################################################################
+
+# "Fragile" Use a minimum set of actions for these sites (see alias above):
+#
+{ fragile }
+.office.microsoft.com # surprise, surprise!
+.windowsupdate.microsoft.com
+mail.google.com
+
+
+Shopping sites are not as fragile, but they typically require cookies to log
+in, and pop-up windows for shopping carts or item details. Again, we'll use a
+pre-defined alias:
+
+# Shopping sites:
+#
+{ shop }
+.quietpc.com
+.worldpay.com # for quietpc.com
+.jungle.com
+.scan.co.uk
+
+
+The fast-redirects action, which we enabled per default above, breaks some
+sites. So disable it for popular sites where we know it misbehaves:
+
+{ -fast-redirects }
+login.yahoo.com
+edit.*.yahoo.com
+.google.com
+.altavista.com/.*(like|url|link):http
+.altavista.com/trans.*urltext=http
+.nytimes.com
+
+
+It is important that Privoxy knows which URLs belong to images, so that if they
+are to be blocked, a substitute image can be sent, rather than an HTML page.
+Contacting the remote site to find out is not an option, since it would destroy
+the loading time advantage of banner blocking, and it would feed the
+advertisers (in terms of money and information). We can mark any URL as an
+image with the handle-as-image action, and marking all URLs that end in a known
+image file extension is a good start:
+
+##########################################################################
+# Images:
+##########################################################################
+
+# Define which file types will be treated as images, in case they get
+# blocked further down this file:
+#
+{ +handle-as-image }
+/.*\.(gif|jpe?g|png|bmp|ico)$
+
+
+And then there are known banner sources. They often use scripts to generate the
+banners, so it won't be visible from the URL that the request is for an image.
+Hence we block them and mark them as images in one go, with the help of our
++block-as-image alias defined above. (We could of course just as well use +
+block +handle-as-image here.) Remember that the type of the replacement image
+is chosen by the set-image-blocker action. Since all URLs have matched the
+default section with its +set-image-blocker{pattern} action before, it still
+applies and needn't be repeated:
+
+# Known ad generators:
+#
+{ +block-as-image }
+ar.atwola.com
+.ad.doubleclick.net
+.ad.*.doubleclick.net
+.a.yimg.com/(?:(?!/i/).)*$
+.a[0-9].yimg.com/(?:(?!/i/).)*$
+bs*.gsanet.com
+.qkimg.net
+
+
+One of the most important jobs of Privoxy is to block banners. Many of these
+can be "blocked" by the filter{banners-by-size} action, which we enabled above,
+and which deletes the references to banner images from the pages while they are
+loaded, so the browser doesn't request them anymore, and hence they don't need
+to be blocked here. But this naturally doesn't catch all banners, and some
+people choose not to use filters, so we need a comprehensive list of patterns
+for banner URLs here, and apply the block action to them.
+
+First comes many generic patterns, which do most of the work, by matching
+typical domain and path name components of banners. Then comes a list of
+individual patterns for specific sites, which is omitted here to keep the
+example short:
+
+##########################################################################
+# Block these fine banners:
+##########################################################################
+{ +block }
+
+# Generic patterns:
+#
+ad*.
+.*ads.
+banner?.
+count*.
+/.*count(er)?\.(pl|cgi|exe|dll|asp|php[34]?)
+/(?:.*/)?(publicite|werbung|rekla(ma|me|am)|annonse|maino(kset|nta|s)?)/
+
+# Site-specific patterns (abbreviated):
+#
+.hitbox.com
+
+
+It's quite remarkable how many advertisers actually call their banner servers
+ads.company.com, or call the directory in which the banners are stored simply
+"banners". So the above generic patterns are surprisingly effective.
+
+But being very generic, they necessarily also catch URLs that we don't want to
+block. The pattern .*ads. e.g. catches "nasty-ads.nasty-corp.com" as intended,
+but also "downloads.sourcefroge.net" or "adsl.some-provider.net." So here come
+some well-known exceptions to the +block section above.
+
+Note that these are exceptions to exceptions from the default! Consider the URL
+"downloads.sourcefroge.net": Initially, all actions are deactivated, so it
+wouldn't get blocked. Then comes the defaults section, which matches the URL,
+but just deactivates the block action once again. Then it matches .*ads., an
+exception to the general non-blocking policy, and suddenly +block applies. And
+now, it'll match .*loads., where -block applies, so (unless it matches again
+further down) it ends up with no block action applying.
+
+##########################################################################
+# Save some innocent victims of the above generic block patterns:
+##########################################################################
+
+# By domain:
+#
+{ -block }
+adv[io]*. # (for advogato.org and advice.*)
+adsl. # (has nothing to do with ads)
+adobe. # (has nothing to do with ads either)
+ad[ud]*. # (adult.* and add.*)
+.edu # (universities don't host banners (yet!))
+.*loads. # (downloads, uploads etc)
+
+# By path:
+#
+/.*loads/
+
+# Site-specific:
+#
+www.globalintersec.com/adv # (adv = advanced)
+www.ugu.com/sui/ugu/adv
+
+
+Filtering source code can have nasty side effects, so make an exception for our
+friends at sourceforge.net, and all paths with "cvs" in them. Note that -filter
+disables all filters in one fell swoop!
+
+# Don't filter code!
+#
+{ -filter }
+/(.*/)?cvs
+bugzilla.
+developer.
+wiki.
+.sourceforge.net
+
+
+The actual default.action is of course much more comprehensive, but we hope
+this example made clear how it works.
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+8.7.2. user.action
+
+So far we are painting with a broad brush by setting general policies, which
+would be a reasonable starting point for many people. Now, you might want to be
+more specific and have customized rules that are more suitable to your 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 hence has the last word, over-riding any
+previously defined actions. user.action is also a safe place for your personal
+settings, since default.action is actively maintained by the Privoxy developers
+and you'll probably want to install updated versions from time to time.
+
+So let's look at a few examples of things that one might typically do in
+user.action:
+
+# My user.action file. <fred@example.com>
+
+
+As aliases are local to the actions file that they are defined in, you can't
+use the ones from default.action, unless you repeat them here:
+
+# Aliases are local to the file they are defined in.
+# (Re-)define aliases for this file:
+#
+{{alias}}
+#
+# These aliases just save typing later, and the alias names should
+# be self explanatory.
+#
++crunch-all-cookies = +crunch-incoming-cookies +crunch-outgoing-cookies
+-crunch-all-cookies = -crunch-incoming-cookies -crunch-outgoing-cookies
+ allow-all-cookies = -crunch-all-cookies -session-cookies-only
+ allow-popups = -filter{all-popups} -kill-popups
++block-as-image = +block +handle-as-image
+-block-as-image = -block
+
+# These aliases define combinations of actions that are useful for
+# certain types of sites:
+#
+fragile = -block -crunch-all-cookies -filter -fast-redirects -hide-referrer -kill-popups
+shop = -crunch-all-cookies allow-popups
+
+# Allow ads for selected useful free sites:
+#
+allow-ads = -block -filter{banners-by-size} -filter{banners-by-link}
+
+# Alias for specific file types that are text, but might have conflicting
+# MIME types. We want the browser to force these to be text documents.
+handle-as-text = -filter +-content-type-overwrite{text/plain} +-force-text-mode -hide-content-disposition
+
+
+
+
+Say you have accounts on some sites that you visit regularly, and you don't
+want to have to log in manually each time. So you'd like to allow persistent
+cookies for these sites. The allow-all-cookies alias defined above does exactly
+that, i.e. it disables crunching of cookies in any direction, and the
+processing of cookies to make them only temporary.
+
+{ allow-all-cookies }
+ sourceforge.net
+ .yahoo.com
+ .msdn.microsoft.com
+ .redhat.com
+
+
+Your bank is allergic to some filter, but you don't know which, so you disable
+them all:
+
+{ -filter }
+ .your-home-banking-site.com
+
+
+Some file types you may not want to filter for various reasons:
+
+# Technical documentation is likely to contain strings that might
+# erroneously get altered by the JavaScript-oriented filters:
+#
+.tldp.org
+/(.*/)?selfhtml/
+
+# And this stupid host sends streaming video with a wrong MIME type,
+# so that Privoxy thinks it is getting HTML and starts filtering:
+#
+stupid-server.example.com/
+
+
+Example of a simple block action. Say you've seen an ad on your favourite page
+on example.com that you want to get rid of. You have right-clicked the image,
+selected "copy image location" and pasted the URL below while removing the
+leading http://, into a { +block } section. Note that { +handle-as-image } need
+not be specified, since all URLs ending in .gif will be tagged as images by the
+general rules as set in default.action anyway:
+
+{ +block }
+ www.example.com/nasty-ads/sponsor\.gif
+ another.example.net/more/junk/here/
+
+
+The URLs of dynamically generated banners, especially from large banner farms,
+often don't use the well-known image file name extensions, which makes it
+impossible for Privoxy to guess the file type just by looking at the URL. You
+can use the +block-as-image alias defined above for these cases. Note that
+objects which match this rule but then turn out NOT to be an image are
+typically rendered as a "broken image" icon by the browser. Use cautiously.
+
+{ +block-as-image }
+ .doubleclick.net
+ .fastclick.net
+ /Realmedia/ads/
+ ar.atwola.com/
+
+
+Now you noticed that the default configuration breaks Forbes Magazine, but you
+were too lazy to find out which action is the culprit, and you were again too
+lazy to give feedback, so you just used the fragile alias on the site, and --
+whoa! -- it worked. The fragile aliases disables those actions that are most
+likely to break a site. Also, good for testing purposes to see if it is Privoxy
+that is causing the problem or not. We later find other regular sites that
+misbehave, and add those to our personalized list of troublemakers:
+
+{ fragile }
+ .forbes.com
+ webmail.example.com
+ .mybank.com
+
+
+You like the "fun" text replacements in default.filter, but it is disabled in
+the distributed actions file. So you'd like to turn it on in your private,
+update-safe config, once and for all:
+
+{ +filter{fun} }
+ / # For ALL sites!
+
+
+Note that the above is not really a good idea: There are exceptions to the
+filters in default.action for things that really shouldn't be filtered, like
+code on CVS->Web interfaces. Since user.action has the last word, these
+exceptions won't be valid for the "fun" filtering specified here.
+
+You might also worry about how your favourite free websites are funded, and
+find that they rely on displaying banner advertisements to survive. So you
+might want to specifically allow banners for those sites that you feel provide
+value to you:
+
+{ allow-ads }
+ .sourceforge.net
+ .slashdot.org
+ .osdn.net
+
+
+Note that allow-ads has been aliased to -block, -filter{banners-by-size}, and -
+filter{banners-by-link} above.
+
+Invoke another alias here to force an over-ride of the MIME type application/
+x-sh which typically would open a download type dialog. In my case, I want to
+look at the shell script, and then I can save it should I choose to.
+
+{ handle-as-text }
+ /.*\.sh$
+
+
+user.action is generally the best place to define exceptions and additions to
+the default policies of default.action. Some actions are safe to have their
+default policies set here though. So let's set a default policy to have a
+"blank" image as opposed to the checkerboard pattern for ALL sites. "/" of
+course matches all URL paths and patterns:
+
+{ +set-image-blocker{blank} }
+/ # ALL sites
+
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+9. Filter Files
+
+On-the-fly text substitutions need to be defined in a "filter file". Once
+defined, they can then be invoked as an "action".
+
+Privoxy supports three different filter actions: filter to rewrite the content
+that is send to the client, client-header-filter to rewrite headers that are
+send by the client, and server-header-filter to rewrite headers that are send
+by the server.
+
+Privoxy also supports two tagger actions: client-header-tagger and
+server-header-tagger. Taggers and filters use the same syntax in the filter
+files, the difference is that taggers don't modify the text they are filtering,
+but use a rewritten version of the filtered text as tag. The tags can then be
+used to change the applying actions through sections with tag-patterns.
+
+Multiple filter files can be defined through the filterfile config directive.
+The filters as supplied by the developers are located in default.filter. It is
+recommended that any locally defined or modified filters go in a separately
+defined file such as user.filter.
+
+Common tasks for content filters are to eliminate common annoyances in HTML and
+JavaScript, such as pop-up windows, exit consoles, crippled windows without
+navigation tools, the infamous <BLINK> tag etc, to suppress images with certain
+width and height attributes (standard banner sizes or web-bugs), or just to
+have fun.
+
+Enabled content filters are applied to any content whose "Content Type" header
+is recognised as a sign of text-based content, with the exception of text/
+plain. Use the force-text-mode action to also filter other content.
+
+Substitutions are made at the source level, so if you want to "roll your own"
+filters, you should first be familiar with HTML syntax, and, of course, regular
+expressions.
+
+Just like the actions files, the filter file is organized in sections, which
+are called filters here. Each filter consists of a heading line, that starts
+with one of the keywords FILTER:, CLIENT-HEADER-FILTER: or
+SERVER-HEADER-FILTER: followed by the filter's name, and a short (one line)
+description of what it does. Below that line come the jobs, i.e. lines that
+define the actual text substitutions. By convention, the name of a filter
+should describe what the filter eliminates. The comment is used in the
+web-based user interface.
+
+Once a filter called name has been defined in the filter file, it can be
+invoked by using an action of the form +filter{name} in any actions file.
+
+Filter definitions start with a header line that contains the filter type, the
+filter name and the filter description. A content filter header line for a
+filter called "foo" could look like this:
+
+FILTER: foo Replace all "foo" with "bar"
+
+
+Below that line, and up to the next header line, come the jobs that define what
+text replacements the filter executes. They are specified in a syntax that
+imitates Perl's s/// operator. If you are familiar with Perl, you will find
+this to be quite intuitive, and may want to look at the PCRS documentation for
+the subtle differences to Perl behaviour. Most notably, the non-standard option
+letter U is supported, which turns the default to ungreedy matching.
+
+If you are new to "Regular Expressions", you might want to take a look at the
+Appendix on regular expressions, and see the Perl manual for the s///
+operator's syntax and Perl-style regular expressions in general. The below
+examples might also help to get you started.
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+9.1. Filter File Tutorial
+
+Now, let's complete our "foo" content filter. We have already defined the
+heading, but the jobs are still missing. Since all it does is to replace "foo"
+with "bar", there is only one (trivial) job needed:
+
+s/foo/bar/
+
+
+But wait! Didn't the comment say that all occurrences of "foo" should be
+replaced? Our current job will only take care of the first "foo" on each page.
+For global substitution, we'll need to add the g option:
+
+s/foo/bar/g
+
+
+Our complete filter now looks like this:
+
+FILTER: foo Replace all "foo" with "bar"
+s/foo/bar/g
+
+
+Let's look at some real filters for more interesting examples. Here you see a
+filter that protects against some common annoyances that arise from JavaScript
+abuse. Let's look at its jobs one after the other:
+
+FILTER: js-annoyances Get rid of particularly annoying JavaScript abuse
+
+# Get rid of JavaScript referrer tracking. Test page: http://www.randomoddness.com/untitled.htm
+#
+s|(<script.*)document\.referrer(.*</script>)|$1"Not Your Business!"$2|Usg
+
+
+Following the header line and a comment, you see the job. Note that it uses |
+as the delimiter instead of /, because the pattern contains a forward slash,
+which would otherwise have to be escaped by a backslash (\).
+
+Now, let's examine the pattern: it starts with the text <script.* enclosed in
+parentheses. Since the dot matches any character, and * means: "Match an
+arbitrary number of the element left of myself", this matches "<script",
+followed by any text, i.e. it matches the whole page, from the start of the
+first <script> tag.
+
+That's more than we want, but the pattern continues: document\.referrer matches
+only the exact string "document.referrer". The dot needed to be escaped, i.e.
+preceded by a backslash, to take away its special meaning as a joker, and make
+it just a regular dot. So far, the meaning is: Match from the start of the
+first <script> tag in a the page, up to, and including, the text
+"document.referrer", if both are present in the page (and appear in that
+order).
+
+But there's still more pattern to go. The next element, again enclosed in
+parentheses, is .*</script>. You already know what .* means, so the whole
+pattern translates to: Match from the start of the first <script> tag in a page
+to the end of the last <script> tag, provided that the text "document.referrer"
+appears somewhere in between.
+
+This is still not the whole story, since we have ignored the options and the
+parentheses: The portions of the page matched by sub-patterns that are enclosed
+in parentheses, will be remembered and be available through the variables $1,
+$2, ... in the substitute. The U option switches to ungreedy matching, which
+means that the first .* in the pattern will only "eat up" all text in between "
+<script" and the first occurrence of "document.referrer", and that the second
+.* will only span the text up to the first "</script>" tag. Furthermore, the s
+option says that the match may span multiple lines in the page, and the g
+option again means that the substitution is global.
+
+So, to summarize, the pattern means: Match all scripts that contain the text
+"document.referrer". Remember the parts of the script from (and including) the
+start tag up to (and excluding) the string "document.referrer" as $1, and the
+part following that string, up to and including the closing tag, as $2.
+
+Now the pattern is deciphered, but wasn't this about substituting things? So
+lets look at the substitute: $1"Not Your Business!"$2 is easy to read: The text
+remembered as $1, followed by "Not Your Business!" (including the quotation
+marks!), followed by the text remembered as $2. This produces an exact copy of
+the original string, with the middle part (the "document.referrer") replaced by
+"Not Your Business!".
+
+The whole job now reads: Replace "document.referrer" by "Not Your Business!"
+wherever it appears inside a <script> tag. Note that this job won't break
+JavaScript syntax, since both the original and the replacement are
+syntactically valid string objects. The script just won't have access to the
+referrer information anymore.
+
+We'll show you two other jobs from the JavaScript taming department, but this
+time only point out the constructs of special interest:
+
+# The status bar is for displaying link targets, not pointless blahblah
+#
+s/window\.status\s*=\s*(['"]).*?\1/dUmMy=1/ig
+
+
+\s stands for whitespace characters (space, tab, newline, carriage return, form
+feed), so that \s* means: "zero or more whitespace". The ? in .*? makes this
+matching of arbitrary text ungreedy. (Note that the U option is not set). The
+['"] construct means: "a single or a double quote". Finally, \1 is a
+back-reference to the first parenthesis just like $1 above, with the difference
+that in the pattern, a backslash indicates a back-reference, whereas in the
+substitute, it's the dollar.
+
+So what does this job do? It replaces assignments of single- or double-quoted
+strings to the "window.status" object with a dummy assignment (using a variable
+name that is hopefully odd enough not to conflict with real variables in
+scripts). Thus, it catches many cases where e.g. pointless descriptions are
+displayed in the status bar instead of the link target when you move your mouse
+over links.
+
+# Kill OnUnload popups. Yummy. Test: http://www.zdnet.com/zdsubs/yahoo/tree/yfs.html
+#
+s/(<body [^>]*)onunload(.*>)/$1never$2/iU
+
+
+Including the OnUnload event binding in the HTML DOM was a CRIME. When I close
+a browser window, I want it to close and die. Basta. This job replaces the
+"onunload" attribute in "<body>" tags with the dummy word never. Note that the
+i option makes the pattern matching case-insensitive. Also note that ungreedy
+matching alone doesn't always guarantee a minimal match: In the first
+parenthesis, we had to use [^>]* instead of .* to prevent the match from
+exceeding the <body> tag if it doesn't contain "OnUnload", but the page's
+content does.
+
+The last example is from the fun department:
+
+FILTER: fun Fun text replacements
+
+# Spice the daily news:
+#
+s/microsoft(?!\.com)/MicroSuck/ig
+
+
+Note the (?!\.com) part (a so-called negative lookahead) in the job's pattern,
+which means: Don't match, if the string ".com" appears directly following
+"microsoft" in the page. This prevents links to microsoft.com from being
+trashed, while still replacing the word everywhere else.
+
+# Buzzword Bingo (example for extended regex syntax)
+#
+s* industry[ -]leading \
+| cutting[ -]edge \
+| customer[ -]focused \
+| market[ -]driven \
+| award[ -]winning # Comments are OK, too! \
+| high[ -]performance \
+| solutions[ -]based \
+| unmatched \
+| unparalleled \
+| unrivalled \
+*<font color="red"><b>BINGO!</b></font> \
+*igx
+
+
+The x option in this job turns on extended syntax, and allows for e.g. the
+liberal use of (non-interpreted!) whitespace for nicer formatting.
+
+You get the idea?
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+9.2. The Pre-defined Filters
+
+The distribution default.filter file contains a selection of pre-defined
+filters for your convenience:
+
+js-annoyances
+
+ The purpose of this filter is to get rid of particularly annoying
+ JavaScript abuse. To that end, it
+
+ □ replaces JavaScript references to the browser's referrer information
+ with the string "Not Your Business!". This compliments the
+ hide-referrer action on the content level.
+
+ □ removes the bindings to the DOM's unload event which we feel has no
+ right to exist and is responsible for most "exit consoles", i.e. nasty
+ windows that pop up when you close another one.
+
+ □ removes code that causes new windows to be opened with undesired
+ properties, such as being full-screen, non-resizeable, without
+ location, status or menu bar etc.
+
+ Use with caution. This is an aggressive filter, and can break sites that
+ rely heavily on JavaScript.
+
+js-events
+
+ This is a very radical measure. It removes virtually all JavaScript event
+ bindings, which means that scripts can not react to user actions such as
+ mouse movements or clicks, window resizing etc, anymore. Use with caution!
+
+ We strongly discourage using this filter as a default since it breaks many
+ legitimate scripts. It is meant for use only on extra-nasty sites (should
+ you really need to go there).
+
+html-annoyances
+
+ This filter will undo many common instances of HTML based abuse.
+
+ The BLINK and MARQUEE tags are neutralized (yeah baby!), and browser
+ windows will be created as resizeable (as of course they should be!), and
+ will have location, scroll and menu bars -- even if specified otherwise.
+
+content-cookies
+
+ Most cookies are set in the HTTP dialog, where they can be intercepted by
+ the crunch-incoming-cookies and crunch-outgoing-cookies actions. But web
+ sites increasingly make use of HTML meta tags and JavaScript to sneak
+ cookies to the browser on the content level.
+
+ This filter disables most HTML and JavaScript code that reads or sets
+ cookies. It cannot detect all clever uses of these types of code, so it
+ should not be relied on as an absolute fix. Use it wherever you would also
+ use the cookie crunch actions.
+
+refresh tags
+
+ Disable any refresh tags if the interval is greater than nine seconds (so
+ that redirections done via refresh tags are not destroyed). This is useful
+ for dial-on-demand setups, or for those who find this HTML feature
+ annoying.
+
+unsolicited-popups