PC World 2001 November

home *** CD-ROM | disk | FTP | other *** search

/ PC World 2001 November / PCWorld_2001-11_cd.bin / Software / Topware / Proxomitron / prx4b4c6.exe / Docs / ReadMe.txt < prev

Wrap

Text File | 2001-07-21 | 35.3 KB | 912 lines

############################################# Proxomitron Version Naoko-4 BetaFive (C) 1999, 2000 Scott R. Lemmon ############################################# This is a beta release of Proxomitron. Please keep in mind that as such it may have problems. Even so, this version has reached a high level of stability and is nearing a final release. For what's new in this beta version check out the "Changes.txt" file. LEGALESE: This program is a public beta and is licensed free for individual use. However, being beta, I'd like to discourage widespread distribution of this version. Software archives in particular should distribute the most recent full release instead. Please keep in mind I make absolutely *no* guarantees of any kind as to the program's safety, fitness, functionality or suitability for any given purpose. Also I take no responsibility for any direct or indirect damages this program may cause - Use it at your own risk! This is the case for all versions of Proxomitron, but being beta this version is more apt to have serious bugs. New in version Naoko-4 Here's a quick list of most new features in Proxomitron. It may not be complete since I'm mainly focusing on things that are not necessarily apparent from the GUI. To Install first make a copy of your current Proxomitron folder then copy the contents of this zip into the new folder. The default.cfg included with this version has been updated to use new program features. However if you've customized your own default.cfg file you may want to merge it into the new file then delete any duplicates. Your original filters will be shown in red once merged (this will last until the config is reloaded). Where filters are duplicated, you'll probably want to keep the new (black) version of any filter you haven't customized. New features include... * SSL Support * Matching Blocklist/Include files * Easy method to block new ads/cookies/pages/etc * Webpage Source view * Local file filtering * URL rewriting/redirecting * Easier config file loading * CGI Proxy support * Easier Proxy password * Header filter activated proxy control * Better access control * HTTP/1.1 & persistent connection support * Many enhanced matching commands ## Bugs fixed ## * Win NT and 2000 merge filter bug fixed * Menu icon color bug fixed * Various matching bugs * Problems freezing a few .gif files * Plenty of things I forgot ;-) ## SSL Support ## Proxomitron now supports SSL (secure https) connections. This comes in two flavors - SSLeay mode and pass-thru mode. The HTTP options under the "settings" dialog control which is used by default. SSLeay/OpenSSL mode ------------------- In this mode Proxomitron decrypt incoming data, filters it, then re-encrypts it before sending it on. This allows for nearly transparent filtering and full control over https connections. This feat is accomplished using the very nice Open Source SSLeay/OpenSSL libraries (not included - see below). To use this mode Proxomitron must have access to "slleay32.dll" and "libeay32.dll" which contain all the SSL libraries and all cryptographic routines. Otherwise "Pass-Thru" mode will be used. ################################################################ Because of all the legal and patent problems involved in the USA with any program that uses encryption, Proxomitron comes with NO ENCRYPTION CODE WHATSOEVER. In order to filter SSL connection you must get a copy of two additional files - "slleay32.dll" and "libeay32.dll". These files are part of the SSLeay/OpenSSL library and contain all the needed routines to do SSL encryption and decryption. In order to work they should be relatively recent versions and must be complied with all algorithms needed for https. I know it's a pain but it's the only safe way I know to offer SSL support. The .DLL files can often be found as part of other programs that use SSL. The open-source "stunnel" application is one example. If you can locate a binary distribution of stunnel for Win32 you should be able to find the two dll's with it. Finding them is the hard part - once you do, just copy the two files into Proxomitron's program folder and check "Use SSLeay/OpenSSL" under the "HTTP" section of Proxomitron's config dialog. Here's a few URLs where compatible ssleay .dlls could be found (at least at one time). However since these are independent sites with no relation to Proxomitron this could change at any time... http://www.attrition.org/~wrlwnd/crypto/ssl/stunnel/dlls.zip http://packetstorm.securify.com/crypt/SSL/stunnel/dlls.zip http://opensores.thebunker.net/pub/mirrors/stunnel/dlls.zip ftp://mike.daewoo.com.pl/pub/stunnel/Win32/ (as separate files) Andras.net is now providing a mirror of the OpenSSL files in Hungary... http://andras.net/tools/ssl/dlls.zip NOTE: If anyone wishes to mirror these files and is located somewhere legally able to do so please let me know. OpenSSL is developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/) which includes cryptographic software written by Eric Young (eay@cryptsoft.com). and includes software written by Tim Hudson (tjh@cryptsoft.com). (See openssl.txt for the full license) ################################################################## Server Certificates And Such: There are some other limitations to this. In order for Proxomitron to act as a SSL server it must have a "Certificate". Certificates are used by web servers to identify themselves to your web browser. They must be digitally "signed" by a known company like VeriSign or your browser will generate a warning. Proxomitron's certificate is located in the "proxcert.pem" file. It's a self-signed certificate created using SSLeay (if you're familiar with SSLeay you could create a certificate of your own). As such it should *not* be considered secure. However it's only used for the connection between Proxomitron and your web browser - the connection between Proxomitron and the remote site *is* secure since it relies on the site's certificate not Proxomitron's. Normally the local connection to your browser never passes outside your PC, so its security isn't really an issue. In fact, the only reason to encrypt it at all is to make your browser think it's connecting directly to a secure site. This does have a few drawbacks though. When you first visit a secure site being filtered through Proxomitron, your browser will usually issue a warning. This happens for two reasons. First Proxomitron's certificate won't initially be recognized by your browser (normally you'll be allowed to add it though). Secondly, Proxomitron's certificate will not match the name of the site your visiting (since it can't know that ahead of time). Unfortunately (or perhaps fortunately) these warning are unavoidable since SSL was intentionally designed to prevent an intermediary from secretly intercepting your data. Proxomitron *is* intercepting your data, but under your control. One way around this is to use a sort of "half-SSL" technique. Proxomitron lets you specify in a normal non-secure "http://" URL that you want to make a SSL connection to the actual web server - just write the URL like so... Original: https://some.secure.site.com/ New : http://https..some.secure.site.com/ Change the protocol back to "http://" then add "https.." to the front of the hostname. This make it so the connection between your browser and Proxomitron is not encrypted but the connection from Proxomitron to the final server is! Since the local connection to Proxomitron is usually confined to your PC alone, this is really no less secure. However your browser thinks it's got a normal insecure connection and won't do any certificate checks. This can also be used to access secure pages from browsers that may not have https support at all. Also beware that Proxomitron does no certificate checking of it's own! If you don't trust a website and wish to check that it has a valid certificate put Proxomitron in "Bypass" mode. This will allow your browser to validate the site as it normally would. Keep in mind certificates are just used to help insure your actually connecting to the site you think you are and not some "spoofed" site. Whether they actually do this or not is debatable. Still, they have nothing to do with how encrypted your data is. Many sites (especially smaller ones) may not be using properly "signed" certificates, but this doesn't mean you're not secure connecting to them. Really all it means is they didn't cough up some money for VeriSign's official stamp of approval. Likewise, a valid certificate is no guarantee a site won't rip you off - you must still be careful before trusting a site with sensitive data. Pass-Thru mode -------------- This is similar to the support offered by many other proxies. In this mode SSL data is simply passed to the server without any alteration. This mode requires no special cytological support as the data is never decoded. However this method also gives little benefit except to allow proxy switching. Proxomitron will always use pass-thru mode when bypassed, and when the "Use SSLeay" mode is not enabled (or the SSLeay dll files are not present). ## Proxy Related Stuff ## CGI PROXY SUPPORT: ------------------ Proxies that use a URL prefix can now be used in Proxomitron. Simply add the URL to the proxy selector as you would a normal proxy (but the http:// isn't required). The only restriction is that the proxy must work by tacking the destination URL to the end. For example, if the proxy was... http://somehost.com/cgi-bin/proxy.cgi/ and you were connecting to... http://anotherhost.com/some/webpage.html Then Proxomitron will automatically form... somehost.com/cgi-bin/proxy.cgi/http://anotherhost.com/some/webpage.html While a DeleGate style proxy might look like... www.delegate.com:8080/-_- and form... www.delegate.com:8080/-_-http://anotherhost.com/some/webpage.html Just like in a web browser multiple CGI style proxies can be chained by simply combining them together... somehost.com/cgi-bin/proxy.cgi/http://www.delegate.com:8080/-_-http://anotherhost.com/some/webpage.html CHAINING REGULAR A PROXY TO CGI PROXIES: ---------------------------------------- In addition to CGI proxies it's also possible to chain a regular proxy to the start of the list. This is the equivalent of using a normal proxy in your browser while also using a CGI proxy. The syntax for this is to use '->' like so... www.aproxy.com:8080->somehost.com/cgi-bin/proxy.cgi/ ## Block List Files ## Proxomitron now supports block lists. Most often they'll contain lists of URLs to use with a filter. Actually "block list" is a bit of a misnomer though, since they can do much more than just block. In fact, they're really an extension of the normal matching expressions. A block list is a simply a text file containing a list of matching items. Each line in the list is checked until a match is found - otherwise the list returns false. Every block list file has a name (in the settings dialog), and can be included at any point in a matching expression by using "$LST(listname)". Most often this will be used in a filter's the URL match, but it's not limited to URLs alone. A list can contain any matching commands - even calls to other lists! You can also add "exclude" lines By prefixing a line with the '~' character. They can be used to limit what a list will match, and are only checked if a regular match is found first in the list. The list will return as true only if *none* of the exclude lines match. Lists can also be called in the replacement text. Here they're not really used to match anything but instead are used to set a positional variable to some value. By using the $CON(#,#) matching command, replacement text variables can be rotated based on the connection number (like multiple User-Agents or browser versions for instance). You can have up to 255 different lists and use them in any way you like. Common uses could include URLs to kill, sites to accept cookies from, pages to disable or enable JavaScript on, etc. Once set up to use a list, an "Add to blockfile" option on Proxomitron's system tray menu makes adding new URLs to a list fairly easy. Just copy a URL to the clipboard and it'll be auto-pasted into the dialog. Normally, each line in a list is treated as an independent matching expression. However long expressions can be broken up over multiple lines by indenting the lines that follow. For example... taste (this|that|these|those|the other thing) could also be written as.... taste ( this| that| these| those| the other thing) The effect is exactly the same, but you can break long lines up for easier reading - leading or trailing whitespace on each line will be ignored. List can contain comments by beginning a line with '#'. Comments normally will be ignored, but the first few lines of a list are scanned for certain "keywords" which can affect how the list works. Currently there are five keywords "NOADDURL", "junkbuster", "NoHash", "NoUrlHash", and "NoPreHash". "NOADDURL" hides the list from the "Add to blockfile" menu. It's useful to keep it from becoming cluttered by lists not used for URL matches. "JunkBuster" if found, will cause Proxomitron to attempt to read and interpret the list as a JunkBuster style blockfile. It's probably less than perfect, but seems to work fairly well with most JunkBuster lists. Note that due to differences in methodology, designing your own list by adding URLs as you find them will likely be more efficient. In particular, JunkBuster processes hostnames in reverse (root first). Proxomitron treats a URL the same as any random text, so you're better off not using an initial wildcard. For instance, "(www.|)somehost.com" will be much faster than "*somehost.com". If you need a leading wildcard try "[^/]++somehost.com". It's a little better than '*' since it only scans up to the first "/" in the URL. "NoHash", "NoUrlHash", and "NoPreHash" are used to disable various hashing algorithms used in lists. NoHash eliminates all hashing and can same memory for list that are seldom called or where speed isn't an issue. "NoUrlHash" and "NoPreHash" disable particular hash types (see below). You probably shouldn't need to use these very often (if at all). ## Blocklist Indexing (hashes) ## Proxomitron can now do an indexed hash lookup on eligible list entries. This makes finding matches in large lists *much* faster. Normally you don't need to worry much about how this works, but if you want to guarantee your blocklist will be as fast as possible here's some tips... First, not all list entries can be hashed. Proxomitron checks each item in the list to see if it's hashable. If so, it's added to a hash list - if not, it's added to a non-hashable list that must be scanned each time the list is checked. Of course, it's better to be hashable. There's two types of indexes Proxomitron can use - a fixed prefix and a URL style index. Each item in the list is checked to see if it can be indexed using either method, if so the method that can index the most characters is used for that item. The total list may have mixture of both types. "fixed prefix" are the simplest - they're just any expression that has a fixed number of characters without any wildcards. The longer the prefix is before any wildcard, the more indexable it becomes. Most user added URLs probably fall into this category, but it benefits many non-URL based lists too. Here's a few examples of eligible expressions... www.somewhere.com 127.0.0. shonen(kinfe|) foo(bar|bat)*bear ANDs are fine too as in "this*&*that" - however ORs outside of parens like "this|that" won't index since the match can begin with two different values. In this case it's better to place each on its own line. URL matches are designed to allow some leading wildcards to be used. It works by looking in the expression for the end of the hostname (marked by a ":" or "/") and indexes back from there. For it to work there must be no other wildcards between the hostname's end and the leading wildcard. Valid wildcards include "*", "\w", "[...]+", "[...]++", and "(...|)". This should cover the most useful ones for leading off URLs. Again here's some examples... *somehost.com/(anything|after|here|is|fine)/\w.html \wsomehost.com/ [^.]+.somehost.com/ [^/]++somehost.com/ (www.|)somehost.com:[0-9]+/ ([^/]++.|)somehost.com/ Unfortunately things like... ([^/]++.|)somehost.*/ ([^/]++.|)somehost.(com|net)/ won't be indexable. In these cases it may actually be faster to write them as two entries... ([^/]++.|)somehost.com/ ([^/]++.|)somehost.net/ One change blocklist authors should take note of is, when using a leading wildcard, it's very important to use the full hostname including the "/". Previously this wasn't necessary, so an entry like... [^/]++.|)microsoft. would be better written as... [^/]++.|)microsoft.com/ or perhaps multiple entries if necessary. It also means there's less of a need to write expressions like... www.(ad(server|engine|banner)|banner(site|click|)).(com|net) Instead, listing all the actual hosts to be matched will be faster - not to mention easier to maintain. ## URL: type header filter ## When designing a header filter the header "URL:" now has special meaning. Although not an actual header, it can be used to filter the URL itself - taking some action based on the URL alone or redirecting the URL to a new location. When you use "URL: [description]" as a header's name the "matching" section like the "URL" section will match against the URL itself. The only difference being the "matching" section includes the "http://" or "https://" portion in the match. To redirect the URL the replace section can include a $JUMP or $RDIR command (see below) which can include portions of the original URL captured into positional variables. Take for example.... Out = "True" Key = "URL: MS Redirect" Matching="http://www.mirosoft.com/\0" Replace="$RDIR(http://www.microsloth.com/\0)" This would invisibly redirect any URL going to "microsoft" to "microsloth" instead! Rather than creating a filter for every redirection, It's also possible to use the list "$LST(Listname)" function to create a list of redirections. Take a filter like the following... Out = "True" Key = "URL: Redirect List" Match = "http://$LST(RedirectList)" or just... Out = "True" Key = "URL: Redirect List" URL = "$LST(RedirectList)" "RedirectList" could then point to a text file containing the following.... # # Proxomitron Redirection List # NOADDURL # ms/ $JUMP(http://www.microsoft.com/) sd/ $JUMP(http://www.slashdot.org/) mail/ $JUMP(http://my.email.site.com/) This, in effect, sets up a list of "aliases" for sites you visit often. You could then enter only "mail" in your browser to go to your email page for instance. Another use would be to redirect know advertisers to an image of your choosing. For instance... Out = "True" Key = "URL: Spam Redirect" Match = "http://$LST(SpamList)" Replace = "$RDIR(http://file//C:/images/spam.gif)" The "SpamList" could then contain... # # Proxomitron Anti-Spam List # www.doubleclick.net [a-z]+.flycast.com and so on.... ## URL commands ## When requesting a page in your browser, it's now possible to embed certain commands in any URL to make it perform some additional function in Proxomitron. Commands are tacked onto the start of the hostname separated by either two dots '..' or two slashes '//'. http://command..www.host.com/rest/of/url.html Here's a list of the current commands... http://file//path Used to filter a local file as if it were a web page. Similar to the file:// URL used by most browsers. http://bypass..www.host.com/some/webpage Use to bypass filtering for a specific URL only. http://bout....www.host.com/some/webpage Bypass outgoing header filters only http://bin..www.host.com/some/webpage Bypass incoming header filters only http://bweb..www.host.com/some/webpage Bypass only the web filters http://https..www.host.com/some/secure/webpage Use to load a 'secure' https: web page without having the local page encrypted. Can be use to access secure pages from browsers that don't directly support https, or to avoid the normal https warning messages a browser may spit out. The actual remote connection is still encrypted, but Proxomitron sends the decrypted and filtered page to your browser. Note: requires SSLeay/OpenSSL .dll files to work. http://src..www.host.com/some/webpage Displays the *true* source of any web page (unaffected by JavaScript commands or dynamic HTML). Useful when the browser won't let you see the source or dynamic HTML alters it. http://dbug..www.host.com/some/webpage Displays the source like "src.." but also cause debug information to be included showing what text each web filter matched. Similar to turning on the "HTML Debug Info" option in the log window. http://load//filename?url Used to load a Proxomitron config file. Path points to the file to load. It can optionally be followed by a '?' and a URL to go to once the config has been loaded. If the config is within the Proxomitron directory, it's not necessary to type the full path... http://load//default.cfg?http://www.microsoft.com/ It's also possible to string multiple URL commands together as in... http://src..bypass..www.host.com/some/webpage ## New matching codes ## + - The run matching command has been changed slightly. It will now match 0 or more of a given expression (instead of 1 or more). You can use it with brackets to enforce minimum number of matches if needed like so... a+{1,*} Will match 1 or more a's ++ - Like '+' will match a run of items, but '++' will only match up to the point where what follows is true. It works very much like '.*' does in UNIX style regexps Examples: "[^ >]++" will work similar to "\w" "[a-z]++boat" given the word "lifeboat" will match only "life" (while "[a-z]+" would match all of "lifeboat") {min,max} or {exact number} or {min,*} Either '+' or '++' can now be followed by brackets to limit the number of repetitions matched. For example, "?+{6}" will match six characters while "?+{6,12}" needs at least 6 characters to match but will match no more than 12 characters. '*' can be used for no max as in "foo++{6,*}bar" needs at least six "foo"s to match but can have more. [#x:y] or [#x] The numeric match can now test for negative numbers. In this case use ':' instead of '-' to separate the numbers. For instance "[#-400]" will match negative 400 exactly. "[#-100:-50]" will match any number between -100 and -50 "[#-500:500]" will match any number between -500 and +500 && - Double ANDs Using two ANDs in a row works similar to using one and except the match that follows will be limited to only matching what matched before the AND. Confused? Don't be - it's really quite simple. It works like a mini-bounds you can use to further restrict the scope within a match. Consider the following... (<img*>&&*width=[#20]*) This will match any image tag that has a width of 20. The double ANDs limit the check for the width tag to just whatever "<img*>" matches. If we did this using the onld single AND like so... (<img*>&*width=[#20]*) Then a line like... <img src=foo > width=20 would also match (since we do have both "<img*>" and "*width=20*"), but this probably isn't what we want. ## The Replacement Stack (\# and \@ commands) ## Normally Proxomitron supports ten matching variables \0 to \9. In most cases this works fairly well, but what if you want to match each iteration of a matched run? For example, say you had a filter that broke a URL into segments divided by the "/" character. You could do this with a match like so... http://(*/)+ However, up till now there's been no way to capture each segment into a *different* variable. this is where the replacement stack comes in. It uses the special character "\#" which like "\0" through "\9" stores a matched value. However each time it's called it stores the matched value into a "stack" which can hold up to 20 items. It can then be used in the replacement text to "pop" an item off that stack in a first-in first-out manner. Using this we could write the above match like so... "http://(\#/)+\#" Given a replacement text of... "\# \# \# \# \# \# \#" It would convert this... "http://this/is/a/test/of/the/stack.html" into this... "this is a test of the stack.html" Each iteration of the (...)+ run pushes a different value onto the stack, then whatever's left over gets matched by the final "\#". Like the other positional variables, the stack variable can be used directly after a set of parens to capture the expression within. For instance... "http://(*/)\#+\#" would produce... "this/ is/ a/ test/ of/ the/ stack.html" The replacement text also recognizes another special escape "\@". This just dumps the entire contents of the stack in order (like using \#\#\#\#\#\#\#\#...). ## New matching commands ## An extensible syntax for matching subroutines has been added to Proxomitron. All these commands begin with "$" followed by the command name, a "(", any command parameters, finally ending with ")". All commands must be upper case to help reduce possible conflicts. Usually it's not necessary to escape the "$" when matching unless it would conflict exactly with an existing command. A command can also optionally be followed by a ';' but this isn't required and is purely to appease us 'C' folk. Generally matching functions are designed to be used in the "matching" portion of a filter, but a few like $JUMP and $LST may also be used in a filter's replacement text. $CMD(parameter values) $AV(match) This is used to match any attribute's value. It first parses and isolates the value - automatically taking things like quotes vs. no quotes into account. The match within the command is then limited to just the attribute value. Note: Any quotes surrounding the value will not be part of the match. For example, to match any image with the word "Gargalishous!" in the alt tag, you could use... <img * alt=$AV(*gargalishous!*) *> which would work for any of the following... <img src="foo" alt="My is this trout ever Gargalishous!"> <img src="foo" alt='Gee your hair is Gargalishous! Is that bison flavor?'> <img src="foo" alt=JustRawGargalishous! > Even though the match doesn't include the quotes, they'll still be consumed by the command. This means if you want to capture the entire value including quotes you could use a match like... <img * alt=($AV(\1))\2 *> Here \2 will contain the full tag with its original quotes, while \1 will just contain the raw value itself. For example given... <img src="foo" alt="Move all Zig!"> \1 = Move all Zig! \2 = "Move all Zig!" But there's also another way to do this - just use $AVQ() $AVQ(match) This is exactly like $AV(...) except it also includes any quotes in the match. Useful when you just want to capture an attribute's value like so... <img * alt=$AVQ(\1) * > which would capture any alt value into \1. $LST(blockfile) Is used to include a blockfile in any matching expression. The contents of the blockfile are tested line by line against the text to be matched until a match is found. Otherwise the expression returns false. $SET(#=value) Use to set a positional variable to a specific value. Any replacement text, including other variables, can be set entered here. Example: set variable 1 equal to "foobar" $SET(1=foobar) Set variable \1 to print the contents of \2 $SET(1=Two is \2) By placing $SET commands within a matching expression, you can set various values *only* if the matching expression reaches that point. This can be used for an if/then/else effect... match: name=(one $SET(0=Naoko) | two $SET(0=Atsuko) | three $SET(0=Michie) | $SET(0=Default)) replace: "\0 Matched" will produce the following results... if name=one -> "Naoko Matched" if name=two -> "Atsuko Matched" if name=three -> "Michie Matched" else -> "Default matched" $CON:(x,y[,z]) Will be true only if the current connection number is 'x' of 'y' (optionally for every 'z' connections). Use to rotate values based on connection. The following for example will rotate between three values in \0 ... ($CON(1,3) $SET(0=Value one of three)| $CON(2,3) $SET(0=Value two of three)| $CON(3,3) $SET(0=Value three of three)) use the 'z' option to delay the rotation to every so many connections. $IHDR(header-name:matching) $OHDR(header-name:matching) Can be use to test the value of any HTTP header. The command will be true only if the named header's value matches the 'matching' section. $OHDR test outputed headers while $IHDR tests incoming headers. For example this will only match is the "Referer" header contains 'microsoft.com' $OHDR(Referer:*.microsoft.com) Using these you can have web filter only match if specific header values are also true, or to capture and use header values into a variables to use in a filter's replacement. You can use also them in HTTP header filters to check combinations of headers for a match. $URL(matching) This can be used to test the URL inside the matching portion of a filter. Normally you would use the filter's URL match for this, but by using this command you can check for different URL based on the text matched. It's also useful to capture portions of a URL into variables. The following would capture the URL's path... $URL(www.somehost.com/\1) As elsewhere, the URL matching starts directly with the hostname so there's no need to match the "http://" portion. $TYPE(code) Content Type check command. This command can be used to limit a filter to only affect certain types of pages (like JavaScript files only). The "code" must be one of the following known types... htm - Web pages css - Cascading style sheets js - JavaScript vbs - VB Script oth - Anything else This is a fast and simple check. For more complex content-type checks you can also use "$OHDR(Content-Type:some matching value)" $RDIR(http://some.url.com/) The RDIR (redirect) command is used to transparently redirect URLs to a different location. It's also possible to redirect to a local file by using the "http://file//filename" URL command syntax. The new URL must be of a type Proxomitron understands (http, or with SSLeay, https). $JUMP(http://some.url.com/) Similar to the RDIR command, the JUMP command can be used to redirect a URL to a different location. However instead of transparent redirection this works by just telling your browser to go to that new location. It's more like using a refresh "meta" tag or setting document.location in a JavaScript. With JUMP your browser is aware of the redirection and the URL you see will be updated to reflect the new location. It works best for redirecting an entire page, while RDIR is better at invisibly redirecting individual page elements like images or java apps. Use RDIR when you want the redirection to happen "behind the scenes" and use JUMP when you want to simply go to a different site from the one requested. Use both RDIR and JUMP commands in the replacement section of *header* filters only. It's important to note that for outgoing headers the redirect will happen before the original site is ever contacted, but when used with incoming headers, the initial site must be contacted first. These commands have no effect in web filters since by this point the original page has already begun loading into your browser. In such cases you can often use JavaScript to change to a new location as in... <script> document.location="http://some.new.url/"; </script> $FILTER(bool) The $FILTER command can be used to force a particular request to be filtered or not filtered regardless of it's type. Normally only specific types are filtered (like text/html, text/css, image/gif, etc). $FILTER can be used in the match or replace of any header filter and takes a "true" or "false" value. If true, the request will be run through the web filters regardless of it's type. This only makes sense for content that's text based. You can also use it to avoid "freezing" certain GIF images by using it in a header filter along with a URL match. Take for example... Out = "True" Key="URL: Don't freeze this gif" URL="www.somewhere.com/animate_me.gif" Replace="$FILTER(False)" $USEPROXY(bool) The $USEPROXY command can override the "Use remote proxy" check box for a given connection either turning the proxy on or off. It can be use to ensure a proxy is or isn't used for with a given site or for a particular action. To have effect this command must be called in either the match or replace of an *outgoing* header filter. This is because the proxy setting must be established prior to connecting to the site. $SETPROXY(proxy:port) The $SETPROXY command will force a connection to use a particular proxy. It overrides both the "Use remote proxy" checkbox and the current proxy chosen in the proxy selector. It's useful for insuring a particular proxy is used in a given situation or with a particular URL. The proxy to set *must* be one entered into the External Proxy Selector list. This command simply looks up and sets a proxy from that list. It's usually only necessary type the first part of the proxy name - the first proxy matched in the list will be use. The partial match must be exact though (no wildcards). Like the previous command this command must be also called in either the match or replace of an *outgoing* header filter. $UESC(escaped text) The $UESC command is intended to be similar to the JavaScript unescape() command. It will convert most URL escaped characters back to their ASCII form. It's useful for unescaping URLs that may be embedded in other URLs (an increasingly common trick used by many sites to track the links you click). Often characters like ":" and "/" will be escaped by their hex equivilents ("%3A" and "%2F") making the real URL hard to use. $UESC can be used in the replacement text of a filter, and can be given any valid replacement text as input (such as \1 variables). It will convert most escaped characters back to their correct form, but spaces and any non-displayable ASCII characters will remain escaped. +++++++++++++++++++ Well that's about it for now. Many of the new features in "settings" I hope are more or less self-explanatory, but feel free to email me if you've got any questions. Also check the various context menus as blocklist features have been added to many of 'em. Keep in mind all this stuff could easily change a before an actual release - especially the syntax of new commands. I'm not exactly sure what will work best yet in all areas. -Scott-