Copyright &my-copy; 2001, 2002 by Privoxy Developers $Id: faq.sgml,v 1.1.1.1 2003/05/23 11:17:04 lionel Exp $ This is here to keep vim syntax file from breaking :/ If I knew enough to fix it, I would. PLEASE DO NOT REMOVE! HB: hal@foobox.net ]]> This FAQ gives quick answers to frequently asked questions about Privoxy. It can't and doesn't replace the User Manual. &p-intro; You can find the latest version of the document at http://www.privoxy.org/faq/. Please see the Contact section if you want to contact the developers. &history; Privoxy is the Privacy Enhancing Proxy. Also, its content modification and junk suppression allow you to browse your private edition of the web. Junkbusters Corporation continues to offer their original version of the Internet Junkbuster, so publishing our Junkbuster-derived software under the same name led to confusion. There are also potential legal complications from the continued use of the Junkbuster name, which is a registered trademark of Junkbusters Corporation. There are, however, no objections from Junkbusters Corporation to the Privoxy project itself, and they, in fact, still share our ideals and goals. The developers also believed that there are so many changes from the original code, that it was time to make a clean break from the past and make a name in their own right. Privoxy picks up where Junkbuster left off. All the old features remain. The new Privoxy still blocks ads and banners, still manages cookies, and still helps protect your privacy. But, these are all enhanced, and many new features have been added, all in the same vein. The configuration has changed significantly as well. This is something that users will notice right off the bat if upgrading from Junkbuster 2.0.x. The blocklist cookielist, imagelist and much more has been combined into the actions files, with a completely different syntax. See the note to upgraders for details. Privoxy's new features include: &newfeatures; A web proxy is a service, based on a software such as Privoxy, that clients (i.e. browsers) can use instead of connecting directly to the web servers on the Internet. The clients then ask the proxy to fetch the objects they need (web pages, images, movies etc) on their behalf, and when the proxy has done so, it hands the results back to the client. There are many reasons to use web proxies, such as security (firewalling), efficiency (caching) and others, and there are just as many different proxies to accommodate those needs. Privoxy is a proxy that is solely focused on privacy protection and junk elimination. Sitting between your browser(s) and the Internet, it is in a perfect position to filter outbound personal information that your browser is leaking, as well as inbound junk. It uses a variety of techniques to do this, all of which are under your control via the various configuration files and options. Privoxy's approach to blocking ads is twofold: First, there are certain patterns in the locations (URLs) of banner images. This applies to both the path (you wouldn't guess how many web sites serve their banners from a directory called banners!) and the host (blocking the big banner hosting services like doublecklick.net already helps a lot). Privoxy takes advantage of this fact by using URL patterns to sort out and block the requests for banners. Second, banners tend to come in certain sizes. But you can't tell the size of an image by its URL without downloading it, and if you do, it's too late to save bandwidth. Therefore, Privoxy also inspects the HTML sources of web pages while they are loaded, and replaces references to images with standard banner sizes by dummy references, so that your browser doesn't request them anymore in the first place. Both of this involves a certain amount of guesswork and is, of course, freely configurable. Actually, it's a black art ;-) And yes, it is always possible to have a broad rule accidentally block or change something by mistake. There is a good chance you may run into such a situation at some point. It is tricky writing rules to cover every conceivable possibility, and not occasionally get false positives. But this should not be a big concern since the Privoxy configuration is very flexible, and includes tools to help identify these types of situations so they can be addressed as needed, allowing you to customize your installation. (See the Troubleshooting section below.) Modern browsers do indeed have some of the same functionality as Privoxy. Maybe this is adequate for you. But Privoxy is much more versatile and powerful, and can do a number of things that browsers just can't. In addition, a proxy is good choice if you use multiple browsers, or have a LAN with multiple computers. This way all the configuration is in one place, and you don't have to maintain a similar configuration for possibly many browsers. Privoxy is licensed under the GNU General Public License (GPL). It is free to use, copy, modify or distribute as you wish under the terms of this license. Please see the Copyright section for more information on the license and copyright. Or the LICENSE file that should be included. There is no warranty of any kind, expressed, implied or otherwise. That is something that would cost real money ;-) There is no registration either. Privoxy really is free in every respect! We, of course, welcome donations and could use money for domain registering, buying software to test Privoxy with, and, of course, for regular world-wide get-togethers (hahaha). If you enjoy the software and feel like helping us with a donation, just drop us a note. If you are a vendor of a web-related software like a browser, web server or proxy, and would like us to ensure that Privoxy runs smoothly with your product, you might consider supplying us with a copy or license. We can't, however, guarantee that we will fix all potential compatibility issues as a result. Well, helping the team is always a good idea. We welcome new developers, packaging gurus or documentation writers. Simply get an account on SourceForge.net and mail your id to the developers mailing list. Then read the Developer's Manual. Once we have added you to the team, you'll have write access to the CVS repository, and together we'll find a suitable task for you. Any browser that can be configured to use a proxy, which should be virtually all browsers. Direct browser support is not necessary since Privoxy runs as a separate application and talks to the browser in the standardized HTTP protocol, just like a web server does. &supported; As long as there is some way to set a HTTP proxy for the client, then yes, any application can be used, whether it is strictly speaking a browser or not. Though this may not be the best approach for dealing with some of the common abuses of HTML in email. See How can I configure Privoxy with Outlook Express? below for more on this. Be aware that HTML email presents a number of unique security and privacy related issues, that can require advanced skills to overcome. The developers recommend using email clients that can be configured to convert HTML to plain text for these reasons. We recommend you un-install Junkbuster first to minimize conflicts and confusion. You may want to save your old configuration files for future reference. The configuration files and syntax have substantially changed, so you will need to manually port your old patterns. See the note to upgraders and installation chapter in the user manual for details. Note: Some installers may automatically un-install Junkbuster, if present! All browsers must be told to use Privoxy as a proxy by specifying the correct proxy address and port number in the appropriate configuration area for the browser. See below. You should also flush your browser's memory and disk cache to get rid of any cached junk items, and any stored cookies. If you set up the Privoxy to run on the computer you browse from (rather than your ISP's server or some networked computer on a LAN), the proxy will be on 127.0.0.1 (sometimes referred to as localhost, which is the special name used by every computer on the Internet to refer to itself) and the port will be 8118 (unless you have Privoxy to run on a different port with the listen-address config option). When configuring your browser's proxy settings you typically enter the word localhost or the IP address 127.0.0.1 in the boxes next to HTTP and Secure (HTTPS) and then the number 8118 for port. This tells your browser to send all web requests to Privoxy instead of directly to the Internet. Privoxy can also be used to proxy for a Local Area Network. In this case, your would enter either the IP address of the LAN host where Privoxy is running, or the equivalent hostname. Port assignment would be same as above. Note that Privoxy doesn't listen on any LAN interfaces by default. Privoxy does not currently handle protocols such as FTP, SMTP, IM, IRC, ICQ, or other Internet protocols. Did you configure your browser to use Privoxy as a proxy? It does not sound like it. See above. You might also try flushing the browser's caches to force a full re-reading of pages. You can verify that Privoxy is running, and your browser is correctly configured by entering the special URL: http://config.privoxy.org/. This should take you to a page titled This is Privoxy.. with access to Privoxy's internal configuration. If you see this, then you are good to go. If you receive a page saying Privoxy is not running, then the browser is not set up to use your Privoxy installation. If you receive anything else (probably nothing at all), it could either be that the browser is not set up correctly, or that Privoxy is not running at all. Check the log file. Based on your feedback and the continuing development, updated actions files will be made available on the files section of our project page. If you wish to receive an email notification whenever we release updates of Privoxy or the actions file, subscribe to our announce mailing list, ijbswa-announce@lists.sourceforge.net. The syntax, number, and purpose of configuration files has substantially changed from Junkbuster and earlier versions of Privoxy. The old files, like blocklist will not work at all. If you are upgrading from a 2.0.x version, you will need to port your configuration data to the new format. Note that even the pattern syntax has changed! Even configuration files from the 2.9.x versions will need to be adapted, as configuration syntax has been very much in flow in the 2.9.x series. Actions files are where various actions that Privoxy might take while processing a certain request, are configured. Typically, you would define a set of default actions that apply to all URLs, then add exceptions to these defaults where needed. Actions can be defined on a URL pattern basis, i.e. for single URLs, whole web sites, groups or parts thereof etc. Actions can also be grouped together and then applied to requests matching one or more patterns. There are many possible actions that might apply to any given site. As an example, if you are blocking cookies as one of your default actions, but need to accept cookies from a given site, you would need to define an exception for this site in one of your actions files, preferably in user.action. For a comprehensive discussion of the actions concept, please refer to the actions file chapter in the user manual. It includes a list of all actions and an actions file tutorial to get you started. Actions files are just text files in a special syntax and can be edited with a text editor. But probably the easiest way is to access Privoxy's user interface with your web browser at http://config.privoxy.org/ (Shortcut: http://p.p/) and then select View & change the current configuration from the menu. As of Privoxy v2.9.15, three actions files are being included, to be used for different purposes: These are default.action, the main actions file which is actively maintained by the Privoxy developers, user.action, where users are encouraged to make their private customizations, and standard.action, which is for internal Privoxy use only. Please see the actions chapter in the user manual for a more detailed explanation. Earlier versions included three different versions of the default.action file. The new scheme allows for greater flexibility of local configuration, and for browser based selection of pre-defined aggressiveness levels. The default configuration shouldn't impact the usability of any of these services. It will, however, make all cookies temporary, so that your browser will forget your login credentials in between browser sessions. If you would like not to have to log in manually each time you access those websites, simply turn off all cookie handling for them in the user.action file. An example for yahoo might look like: # Allow all cookies for Yahoo login: # { -crunch-incoming-cookies -crunch-outgoing-cookies -session-cookies-only } .login.yahoo.com Configuring Privoxy is not entirely trivial. To help you get started, we provide you with three different default action profiles in the web based actions file editor at http://config.privoxy.org/show-status. The following table shows you, which of the most important features are enabled in each configuration: Feature Cautious Intermadiate Radical Ad-blocking by URL yes yes yes Ad-filtering by size yes yes yes GIF de-animation no yes yes Referer forging no yes yes Cookie handling none session-only kill Pop-up killing no yes yes Fast redirects no no yes HTML taming yes yes yes JavaScript taming yes yes yes Web-bug killing yes yes yes Fun text replacements no no yes Image tag reordering no no yes Ad-filtering by link no no yes Demoronizer no no yes Where the defaults are likely to break some sites, exceptions for known popular problem sites are included, but in general, the more aggressive your default settings are, the more exceptions you will have to make later. See the user manual for a more deatiled discussion. It should be noted that the Radical profile is not only more aggressive, but also includes fun and, extreme usage of most of Privoxy's features. Use at your own risk! It may seem strange that regular users can edit the config files with their browsers, although the whole /etc/privoxy hierarchy belongs to the user privoxy, with only 644 permissions. When you use the browser-based editor, Privoxy itself is writing to the config files. Because Privoxy is running as the user privoxy, it can update the config files. If you run Privoxy for multiple untrusted users (e.g. in a LAN), you will probably want to turn the web-based editor and remote toggle features off by setting enable-edit-actions 0 and enable-remote-toggle 0 in the main configuration file. Note that in the default configuration, only local users (i.e. those on localhost) can connect to Privoxy, so this is not (normally) a security problem. The default.filter file is where filters are defined, which can be used to modify or remove, web page content on the fly. Filters apply to anything in the page source, including HTML tags, and JavaScript. Regular expressions are used to accomplish this. There are a number of pre-defined filters to deal with common annoyances. The filters are only defined here, to invoke them, you need to use the filter action in one of the actions files. Filtering is automatically disabled for inappropriate MIME types. If you are familiar with regular expressions, and HTML, you can look at the provided default.filter with a text editor and define your own filters. This is potentially a very powerful feature, but requires some expertise in both regular expressions and HTML/HTTP. Presently, there is no GUI editor option for this part of the configuration, but you can disable/enable the various pre-defined filters of the included default.filter file with the web-based actions file editor. By default, Privoxy only responds to requests from 127.0.0.1 (localhost). To have it act as a server for a network, this needs to be changed in the main configuration file. Look for the listen-address option, which may be commented out with a # symbol. Make sure it is uncommented, and assign it the address of the LAN gateway interface, and port number to use. Assuming your server's LAN address is 192.168.1.1 and you wish to run Privoxy on port 8118, this line should look like: listen-address 192.168.1.1:8118 Save the file, and restart Privoxy. Configure all browsers on the network then to use this address and port number. Alternately, you can have Privoxy listen on all available interfaces: listen-address :8118 And then use Privoxy's permit-access feature to limit connections. A firewall in this situation is recommended as well. The above steps should be the same for any TCP network, regardless of operating system. If you run Privoxy on a LAN with untrusted users, we recommend that you double-check all access control and security options! The replacement for blocked images can be controlled with the set-image-blocker action. You have the choice of a checkerboard pattern, a transparent 1x1 GIF image (aka blank), or a redirect to a custom image of your choice. Note that this choice only has effect for images which are blocked as images, i.e. whose URLs match both a handle-as-image and block action. If you want to see nothing, then change the set-image-blocker action to blank. This can be done by editing the default.action file, or trough the web-based actions file editor. Remember that telling which image is an ad and which isn't, is mostly guesswork. While we hope that the standard configuration is rather smart, it can and will make errors. The checkerboard image is visually decent, but it shows you that and where images were blocked, which can be very helpful in case some navigation aid or otherwise innocent image was erraneously blocked. Some people might also enjoy seeing how many banners they don't have to see.. This happens when the banners are not embedded in the HTML code of the page itself, but in separate HTML (sub)documents that are loaded into (i)frames or (i)layers, and these external HTML documents are blocked. Being non-images they get replaced by a substitute HTML page rather than a substitute image, which wouldn't work out technically, since the browser expects and accepts only HTML when it has requested an HTML document. The substitute page adapts to the available space and shows itself as a miniature two-liner if loaded into small frames, or full-blown with a large red "BLOCKED" banner if space allows. If you prefer the banners to be blocked by images, you must see to it that the HTML documents in which they are embedded are not blocked. Clicking the See why link offered in the substitute page will show you which rule blocked the page. After changing the rule and un-blocking the HTML documents, the browser will try to load the actual banner images and the usual image blocking will (hopefully!) kick in. Yes, it can run as a system service using srvany.exe. See the discussion at http://sourceforge.net/tracker/?func=detail&atid=361118&aid=485617&group_id=11118, for details, and a sample configuration. Version 3.0.1 fixes the problem where the icon and menu where not available in the taskbar for this usage. This can be done and is often useful to combine the benefits of Privoxy with those of a caching proxy. See the forwarding chapter in the user manual which describes how to do this. No, its more complicated than that. This only works with special kinds of proxies known as transparent proxies (see below). No, Privoxy currently does not have this ability, though it is planned for a future release. Transparent proxies require special handling of the request headers beyond what Privoxy is now capable of. Chaining Privoxy behind another proxy that has this ability should work though. See the forwarding chapter in the user manual. As a transparent proxy to be used for chaining we recommend Transproxy (http://www.transproxy.nlc.net.au/). Outlook Express uses Internet Explorer components to both render HTML, and fetch any HTTP requests that may be embedded in an HTML email. So however you have Privoxy configured to work with IE, this configuration should automatically be shared. The short answer is, you can't. Privoxy has no way of knowing which particular application makes a request, so there is no way to distinguish between web pages and HTML mail. Privoxy just blindly proxies all requests. In the case of Outlook Express (see above), OE uses IE anyway, and there is no way for Privoxy to ever be able to distinguish between them (nor could any other proxy type application for that matter). For a good discussion of some of the issues involved (including privacy and security issues), see http://sourceforge.net/tracker/?func=detail&atid=211118&aid=629518&group_id=11118. There are several actions that relate to cookies. The default behavior is to allow only session cookies, which means the cookies only last for the current browser session. This eliminates most kinds of abuse related to cookies. But there may be cases where we want cookies to last. To disable all cookie actions, so that cookies are allowed unrestricted, both in and out, for example.com: { -crunch-incoming-cookies -crunch-outgoing-cookies -session-cookies-only -filter{content-cookies} } .example.com Place the above in user.action. Note some of these may be off by default anyway, so this might be redundant, but there is no harm being explicit in what you want to happen. user.action includes an alias for this situation, called allow-cookies. It should not slow you down any in real terms, and may actually help speed things up since ads, banners and other junk are not being displayed. The actual processing time required by Privoxy itself for each page, is relatively small in the overall scheme of things, and happens very quickly. This is typically more than offset by time saved not downloading and rendering ad images. Filtering content via the filter or deanimate-gifs actions may cause a perceived slowdown, since the entire document needs to be buffered before displaying. See below. If you use any filter action, such as filtering banners by size, web-bugs etc, or the deanimate-gifs action, the entire document must be loaded into memory in order for the filtering mechanism to work, and nothing is sent to the browser during this time. The loading time does not really change in real numbers, but the feeling is different, because most browsers are able to start rendering incomplete content, giving the user a feeling of "it works". This effect is especially noticeable on slow dialup connections. Filtering is automatically disabled for inappropriate MIME types. http://config.privoxy.org/ is the address of Privoxy's built-in user interface, and http://p.p/ is a shortcut for it. Since Privoxy sits between your web browser and the Internet, it can simply intercept requests for these addresses and answer them with its built-in web server. This also makes for a good test for your browser configuration: If entering the URL http://config.privoxy.org/ takes you to a page saying This is Privoxy ..., everything is OK. If you get a page saying Privoxy is not working instead, then your browser didn't use Privoxy for the request, hence it could not be intercepted, and you have accessed the real web site at config.privoxy.org. With recent versions of Privoxy (version 2.9.x and later), the user interface features information on the run time status, the configuration, and even a built-in editor for the actions files. Note that the built-in URLs from earlier versions of Junkbuster / Privoxy, http://example.com/show-proxy-args and http://i.j.b/, are no longer supported. If you still use such an old version, you should really consider upgrading to &p-version;. No. The patterns for blocking now reside (among other things) in the actions files, which are actively maintained instead. See next question ... Yes, absolutely! Please see the Contact section for how to do that. Please note that you (technically) need the latest Privoxy version for this to work. If you run both the browser and the proxy locally, you cannot hide your IP address with Privoxy or any other software. The server needs to know your IP address to send the answers back to you. Fortunately there are many publicly usable anonymous proxies out there, which solve the problem by providing a further level of indirection between you and the web server, shared by many people, and thus letting your requests "drown" in white noise of unrelated requests as far as user tracking is concerned. Most of them will, however, log your IP address and make it available to the authorities in case you abuse that anonymity for criminal purposes. In fact you can't even rule out that some of them only exist to *collect* information on (those suspicious) people with a more than average preference for privacy. You can find a list of anonymous public proxies at multiproxy.org and many more through Google. A particularly interesting project is the JAP service offered by the Technical University of Dresden (http://anon.inf.tu-dresden.de/index_en.html). There is, however, even in the single-machine case the possibility to make the server believe that your machine is in fact a shared proxy serving a whole big LAN, and we are looking into that. No. Your chances of remaining anonymous are greatly improved, but unless you are an expert on Internet security it would be safest to assume that everything you do on the Web can be traced back to you. Privoxy can remove various information about you, and allows you more freedom to decide which sites you can trust, and what details you want to reveal. But it's still possible that web sites can find out who you are. Here's one way this can happen. A few browsers disclose the user's email address in certain situations, such as when transferring a file by FTP. Privoxy does not filter FTP. If you need this feature, or are concerned about the mail handler of your browser disclosing your email address, you might consider products such as NSClean. Browsers available only as binaries could use non-standard headers to give out any information they can have access to: see the manufacturer's license agreement. It's impossible to anticipate and prevent every breach of privacy that might occur. The professionally paranoid prefer browsers available as source code, because anticipating their behavior is easier. Trust the source, Luke! Definitely. More and more sites use HTTP header content to decide what to display and how to display it. There is many ways that this can be handled, so having hard and fast rules, is tricky. User-Agent in particular is often used in this way to identify the browser, and adjust content accordingly. Changing this now (at least not further than removing the OS information) is not recommended, since so many sites do look for it. You may get undesirable results by changing this. For instance, different browsers use different encodings of Russian and Czech characters, certain web servers convert pages on-the-fly according to the User Agent header. Giving a User Agent with the wrong operating system or browser manufacturer causes some sites in these languages to be garbled; Surfers to Eastern European sites should change it to something closer. And then some page access counters work by looking at the Referer header; they may fail or break if unavailable. The weather maps of Intellicast have been blocked by their server when no Referer or cookie is provided, is another example. (But you can forge both headers without giving information away). There are many other ways things can go wrong when trying to fool a web server. Similar thoughts apply to modifying JavaScript, and, to a lesser degree, HTML elements. If you have problems with a site, you will have to adjust your configuration accordingly. Cookies are probably the most likely adjustment that may be required, but by no means the only one. No, it does not have this ability at all. You want something like Squid for this. And, yes, before you ask, Privoxy can co-exist with other kinds of proxies like Squid. See the forwarding chapter in the user manual for details. Not in the way you mean, or in the way a true firewall can. Privoxy can help protect your privacy, but not protect you from intrusion attempts. It is, of course, perfectly possible and recommended to use both. It would be technically possible eliminate the banners in a way that frees their screen estate in many cases, by doing all banner blocking with filters, i.e. eliminating the whole image references from the HTML pages instead of letting them stay in, and blocking the resulting requests for the banners themselves. But this would consume considerable CPU resources, would likely destroy the layout of many web pages which rely on the banners consuming a certain amount of screen space, and would fail in other cases, where the screen space is reserved e.g. by tables anyway. Also, making the banners disappear without a visual trace complicates troubleshooting. So we won't support this in the default configuration, but you can of course define appropriate filters yourself. Since secure HTTP connections are encrypted SSL sessions between your browser and the secure site, and are meant to be reliably secure, there is little that Privoxy can do but hand the raw gibberish data though from one end to the other unprocessed. The only exception to this is blocking by host patterns, as the client needs to tell Privoxy the name of the remote server, so that Privoxy can establish the connection. If that name matches a host-only pattern, the connection will be blocked. As far as ad blocking is concerned, this is less of a restriction than it may seem, since ad sources are often identifiable by the host name, and often the banners to be placed in an encrypted page come unencrypted nonetheless for efficiency reasons, which exposes them to the full power of Privoxy's ad blocking. Content cookies (those that are embedded in the actual HTML or JS page content, see filter{content-cookies}), in an SSL transaction will be impossible to block under these conditions. Fortunately, this does not seem to be a very common scenario since most cookies come by traditional means. There are no known exploits that might affect Privoxy. On Unix-like systems, Privoxy can run as a non-privileged user, which is how we recommend it be run. Also, by default Privoxy only listens to requests from localhost only. The server aspect of Privoxy is not itself directly exposed to the Internet in this configuration. If you want to have Privoxy serve as a LAN proxy, this will have to be opened up to allow for LAN requests. In this case, we'd recommend you specify only the LAN gateway address, e.g. 192.168.1.1, in the main Privoxy configuration file and check all access control and security options. All LAN hosts can then use this as their proxy address in the browser proxy configuration, but Privoxy will not listen on any external interfaces. ACLs can be defined in addition, and using a firewall is always good too. Better safe than sorry. The easiest way is to access Privoxy with your browser by using the remote toggle URL: http://config.privoxy.org/toggle. See the Bookmarklets section of the User Manual for an easy way to access this feature. No, this just means all filtering and actions are disabled. Privoxy is still acting as a proxy, but just not doing any of the things that Privoxy would normally be expected to do. It is still a middle-man in the interaction between your browser and web sites. A crunch simply means Privoxy intercepted something, nothing more. Often this is indeed ads or banners, but Privoxy uses the same mechanism for trapping requests for its own internal pages. For instance, a request for Privoxy's configuration page at: http://config.privoxy.org, is intercepted (i.e. it does not go out to the 'net), and the familiar CGI configuration is returned to the browser, and the log consequently will show a crunch. From the webserver's perspective, there is no difference between viewing a document (i.e. a page), and downloading a file. The same is true of Privoxy. If there is a match for a block pattern, it will still be blocked, and of course this is obvious. Filtering is potentially more of a concern since the results are not always so obvious. Privoxy knows the differences in files according to the Document Type as reported by the webserver. If this is reported accurately (e.g. application/zip for a zip archive), then Privoxy knows to ignore these where appropriate. It is possible, however, that documents that are of an unknown type (generally assumed to be text/plain) will be filtered, as will those that might be incorrectly reported by the webserver. If such a file is a downloaded file that is intended to be saved to disk, then any content that might have been altered by filtering, will be saved too, for these (probably very rare) cases. Privoxy does not do FTP at all, only HTTP protocols. &seealso; We're not. The text substitutions that you are seeing are disabled in the default configuration as shipped. You have either manually activated the fun filter which is clearly labeled Text replacements for subversive browsing fun! or you have implicitly activated it by choosing the Radical profile in the web-based editor. Either Privoxy is not running, or your browser is configured for a different port than what Privoxy is using. The old Privoxy (and also Junkbuster) used port 8000 by default. This has been changed to port 8118 now, due to a conflict with NAS (Network Audio Service), which uses port 8000. If you haven't, you need to change your browser to the new port number, or alternately change the listen-address option in Privoxy's main configuration file. If the ad had been displayed before you added its URL, it will probably be held in the browser's cache for some time, so it will be displayed without the need for any request to the server, and Privoxy will not be in the picture. The best thing to do is try flushing the browser's caches. And then try again. If this doesn't help, you probably have an error in the rule you applied. Try pasting the full URL of the offending ad into http://config.privoxy.org/show-url-info and see if it really matches your new rule. First verify that it is indeed a Privoxy problem, by toggling off Privoxy through http://config.privoxy.org/toggle, and then shift-reloading the problem page (i.e. holding down the shift key while clicking reload. Alternatively, flush your browser's disk and memory caches). If still a problem, go to http://config.privoxy.org/show-url-info and paste the full URL of the page in question into the prompt. See which actions are being applied to the URL, and which matches in which actions files are responsible for that. Now, armed with this information, go to http://config.privoxy.org/show-status and select the appropriate actions files for editing. You can now either look for a section which disables the actions that you suspect to cause the problem and add a pattern for your site there, or make up a completely new section for your site. In any case, the recommended way is to disable only the prime suspect, reload the problem page, and only if the problem persists, disable more and more actions until you have identified the culprit. You may or may not want to turn the other actions on again. Remember to flush your browser's caches in between any such changes! Alternately, if you are comfortable with a text editor, you can accomplish the same thing by editing the appropriate actions file. Probably the easiest way to deal with such problems when editing by hand is to add your site to a { fragile } section in user.action, which is an alias that turns off most dangerous actions, but is also likely to turn off more actions then needed, and thus lower your privacy and protection more than necessary, Troubleshooting actions is discussed in more detail in the user-manual appendix. There is also an actions tutorial. This is a quirk that effects the installation of Privoxy, in conjunction with Internet Explorer and Internet Connection Sharing on Windows 2000 and Windows XP. The symptoms may appear to be corrupted or invalid DUN settings, or passwords. When setting up an NT based Windows system with Privoxy you may find that things do not seem to be doing what you expect. When you set your system up you will probably have set up Internet Connection Sharing (ICS) with Dial up Networking (DUN) when logged in with administrator privileges. You will probably have made this DUN connection available to other accounts that you may have set-up on your system. E.g. Mum or Dad sets up the system and makes accounts suitably configured for the kids. When setting up Privoxy in this environment you will have to alter the proxy set-up of Internet Explorer (IE) for the specific DUN connection on which you wish to use Privoxy. When you do this the ICS DUN set-up becomes user specific. In this instance you will see no difference if you change the DUN connection under the account used to set-up the connection. However when you do this from another user you will notice that the DUN connection changes to make available to "Me only". You will also find that you have to store the password under each different user! The reason for this is that each user's set-up for IE is user specific. Each set-up DUN connection and each LAN connection in IE store the settings for each user individually. As such this enforces individual configurations rather than common ones. Hence the first time you use a DUN connection after re-booting your system it may not perform as you expect, and prompt you for the password. Just set and save the password again and all should be OK. [Thanks to Ray Griffith for this submission.] Privoxy cannot act as a proxy for FTP traffic, so do not configure your browser to use Privoxy as an FTP proxy. The same is true for any protocol other than HTTP or HTTPS. Most browsers understand FTP as well as HTTP. If you connect to a site, with a URL like ftp://ftp.example.com, your browser is making an FTP connection, and not a HTTP connection. So while your browser may speak FTP, Privoxy does not, and cannot proxy such traffic. Microsoft Internet Explorer (in versions like 5.1) respects system-wide network settings. In order to change the HTTP proxy, open System Preferences, and click on the Network icon. In the settings pane that comes up, click on the Proxies tab. Ensure the "Web Proxy (HTTP)" checkbox is checked and enter 127.0.0.1 in the entry field. Enter 8118 in the Port field. The next time you start IE, it should reflect these values. Just dragging the Privoxy folder to the trash is not enough to delete it. Privoxy supplies an uninstall.command file that takes care of these details. Open the trash, drag the uninstall.command file out of the trash and double-click on it. You will be prompted for confirmation and the administration password. The trash may still appear full after this command; emptying the trash from the desktop should make it appear empty again. Chances are that the site suffers from a bug in PHP, which results in empty pages being sent if the client explicitly requests an uncompressed page, like Privoxy does. This bug has been fixed in PHP 4.2.3. To find out if this is in fact the source of the problem, try adding the site to a -prevent-compression section in user.action: # Make exceptions for ill-behaved sites: # {-prevent-compression} .example.com If that works, you may also want to report the problem to the site's webmasters, telling them to use zlib.output_compression instead of ob_gzhandler in their PHP applications (workaround) or upgrade to PHP 4.2.3 or later (fix). More than likely this is a problem with the network stack. ZoneAlarm has been reported to cause this symptom -- even if not running. The solution is to either fight the ZA configuration, or uninstall ZoneAlarm, and then find something better behaved in its place. Other firewall type products may cause similar type problems if not configured correctly. &contacting; ©right; Portions of this document are borrowed from the original Junkbuster (tm) FAQ, and modified as appropriate for Privoxy. &license; &history;