On-the-fly text substitutions that can be invoked through the filter action need to be defined in a "filter file". Once defined, they can then be invoked as an "action". Mulitple filter files can be defined through the filterfile config directive. The filters as supplied by the developers will be found in default.filter. It is recommended that any locally defined or modified filters go in a separately defined file such as user.filter.
Typical reasons for doing these kinds of substitutions 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. The possibilities are endless.
Filtering works on any text-based document type, including HTML, JavaScript, CSS etc. (all text/* MIME types, except text/plain). 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. By default, filters are only applied to the document content, but can be extended to the headers with the supplemental actions: filter-client-headers and filter-server-headers.
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 the keyword 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.
A 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.
Now, let's complete our "foo" 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 backreference to the first parenthesis just like $1 above, with the difference that in the pattern, a backslash indicates a backreference, 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?
The distribution default.filter file contains a selection of pre-defined filters for your convenience:
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-resizable, without location, status or menu bar etc.
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.
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).
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 resizable (as of course they should be!), and will have location, scroll and menu bars -- even if specified otherwise.
Most cookies are set in the HTTP dialogue, 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 HTML and JavaScript code that reads or sets cookies. Use it wherever you would also use the cookie crunch actions.
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.
This filter attempts to prevent only "unsolicited" pop-up windows from opening, yet still allow pop-up windows that the user has explicitly chosen to open. It was added in version 3.0.1, as an improvement over earlier such filters.
Technical note: The filter works by redefining the window.open JavaScript function to a dummy function during the loading and rendering phase of each HTML page access, and restoring the function afterwards.
Attempt to prevent all pop-up windows from opening. Note this should be used with more discretion than the above, since it is more likely to break some sites that require pop-ups for normal usage. Use with caution.
This is a helper filter that has no value if used alone. It makes the banners-by-size and banners-by-link (see below) filters more effective and should be enabled together with them.
This filter removes image tags purely based on what size they are. Fortunately for us, many ads and banner images tend to conform to certain standardized sizes, which makes this filter quite effective for ad stripping purposes.
Occasionally this filter will cause false positives on images that are not ads, but just happen to be of one of the standard banner sizes.
This is an experimental filter that attempts to kill any banners if their URLs seem to point to known or suspected click trackers. It is currently not of much value and is not recommended for use by default.
Webbugs are small, invisible images (technically 1X1 GIF images), that are used to track users across websites, and collect information on them. As an HTML page is loaded by the browser, an embedded image tag causes the browser to contact a third-party site, disclosing the tracking information through the requested URL and/or cookies for that third-party domain, without the use ever becoming aware of the interaction with the third-party site. HTML-ized spam also uses a similar technique to verify email addresses.
This filter removes the HTML code that loads such "webbugs".
A rather special-purpose filter that can be used to enlarge textareas (those multi-line text boxes in web forms) and turn off hard word wrap in them. It was written for the sourceforge.net tracker system where such boxes are a nuisance, but it can be handy on other sites, too.
It is not recommended to use this filter as a default.
Many consider windows that move, or resize themselves to be abusive. This filter neutralizes the related JavaScript code. Note that some sites might not display or behave as intended when using this filter.
Some web designers seem to assume that everyone in the world will view their web sites using the same browser brand and version, screen resolution etc, because only that assumption could explain why they'd use static frame sizes, yet prevent their frames from being resized by the user, should they be too small to show their whole content.
This filter removes the related HTML code. It should only be applied to sites which need it.
Many Microsoft products that generate HTML use non-standard extensions (read: violations) of the ISO 8859-1 aka Latin-1 character set. This can cause those HTML documents to display with errors on standard-compliant platforms.
This filter translates the MS-only characters into Latin-1 equivalents. It is not necessary when using MS products, and will cause corruption of all documents that use 8-bit character sets other than Latin-1. It's mostly worthwhile for Europeans on non-MS platforms, if wierd garbage characters sometimes appear on some pages, or user agents that don't correct for this on the fly.
A filter for shockwave haters. As the name suggests, this filter strips code out of web pages that is used to embed shockwave flash objects.
Change HTML code that embeds Quicktime objects so that kioskmode, which prevents saving, is disabled.
Text replacements for subversive browsing fun. Make fun of your favorite Monopolist or play buzzword bingo.
A demonstration-only filter that shows how Privoxy can be used to delete web content on a keyword basis.
A collection of text replacements to disable malicious HTML and JavaScript code that exploits known security holes in Internet Explorer.
Presently, it only protects against Nimda and a cross-site scripting bug, and would need active maintenance to provide more substantial protection.
Some web sites have very specific problems, the cure for which doesn't apply anywhere else, or could even cause damage on other sites.
This is a collection of such site-specific cures which should only be applied to the sites they were intended for, which is what the supplied default.action file does. Users shouldn't need to change anything regarding this filter.