+</sect2>
+
+<sect2 renderas="sect3">
+<title id="lanconfig">How can I set up Privoxy to act as a proxy for my
+ LAN?</title>
+<para>
+ By default, <application>Privoxy</application> only responds to requests
+ from <literal>127.0.0.1</literal> (localhost). To have it act as a server for
+ a network, this needs to be changed in the <ulink
+ url="../user-manual/config.html">main configuration file</ulink>. Look for
+ the <literal><ulink
+ url="../user-manual/config.html#LISTEN-ADDRESS">listen-address</ulink></literal>
+ option, which may be commented out with a <quote>#</quote> symbol. Make sure
+ it is uncommented, and assign it the address of the LAN gateway interface,
+ and port number to use. Assuming your LAN address is 192.168.1.1 and you
+ wish to run <application>Privoxy</application> on port 8118, this line
+ should look like:
+</para>
+
+<para>
+ <screen>
+ listen-address 192.168.1.1:8118</screen>
+</para>
+
+<para>
+ Save the file, and restart <application>Privoxy</application>. Configure
+ all browsers on the network then to use this address and port number.
+</para>
+
+<para>
+ Alternately, you can have <application>Privoxy</application> listen on
+ all available interfaces:
+</para>
+
+<para>
+ <screen>
+ listen-address :8118</screen>
+</para>
+
+<para>
+ And then use <application>Privoxy's</application>
+ <ulink
+ url="../user-manual/config.html#PERMIT-ACCESS">permit-access</ulink>
+ feature to limit connections. A firewall in this situation is recommended
+ as well.
+</para>
+
+<para>
+ The above steps should be the same for any TCP network, regardless of
+ operating system.
+</para>
+
+<para>
+ If you run <application>Privoxy</application> on a LAN with untrusted users,
+ we recommend that you double-check the <ulink
+ url="../user-manual/config.html#ACCESS-CONTROL">access control and security</ulink>
+ options!
+</para>
+
+</sect2>
+
+
+<sect2 renderas="sect3">
+<title id="noseeum">Instead of ads, now I get a checkerboard pattern. I don't want to see anything.</title>
+<para>
+ The replacement for blocked images can be controlled with the <ulink
+ url="../user-manual/actions-file.html#SET-IMAGE-BLOCKER"><literal>set-image-blocker</literal>
+ action</ulink>. You have the choice of a checkerboard pattern, a transparent 1x1 GIF
+ image (aka <quote>blank</quote>), 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 <literal><ulink
+ url="../user-manual/actions-file.html#HANDLE-AS-IMAGE">handle-as-image</ulink></literal>
+ <emphasis>and</emphasis> <literal><ulink
+ url="../user-manual/actions-file.html#BLOCK">block</ulink></literal> action.
+</para>
+<para>
+ If you want to see nothing, then change the <ulink
+ url="../user-manual/actions-file.html#SET-IMAGE-BLOCKER"><literal>set-image-blocker</literal>
+ action</ulink> to <quote>blank</quote>. This can be done by editing the
+ <filename>default.action</filename> file, or trough the <ulink
+ url="http://config.privoxy.org/show-status">web-based actions file editor</ulink>.
+</para>
+
+</sect2>
+
+<sect2 renderas="sect3">
+<title id="whyseeum">Why would anybody want to see a checkerboard pattern?</title>
+<para>
+ Remember that <link linkend="whatsanad">telling which image is an ad and which
+ isn't</link>, 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
+ erroneously blocked. Some people might also enjoy seeing how many banners
+ they <emphasis>don't</emphasis> have to see..
+</para>
+
+</sect2>
+
+<sect2 renderas="sect3">
+<title id="blockedbytext">I see some images being replaced by a text
+instead of the checkerboard image. Why and how do I get rid of this?</title>
+<para>
+ 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.
+</para>
+<para>
+ 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.
+</para>
+<para>
+ 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 <quote>See why</quote> 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.
+</para>
+</sect2>
+
+
+<sect2 renderas="sect3" id="srvany">
+<title>Can Privoxy run as a service
+on Win2K/NT/XP?</title>
+<para>
+<![%p-newstuff;[
+ Yes. Version 3.0.4 introduces full <application>Windows</application> service
+ functionality. See <ulink url="../user-manual/installation.html#installation-pack-win">
+ the User Manual</ulink> for details on how to install and configure
+ <application>Privoxy</application> as a service.
+</para>
+<para>
+ Earlier ]]>3.x versions could run as a system service using <command>srvany.exe</command>.
+ See the discussion at <ulink
+ url="http://sourceforge.net/tracker/?func=detail&atid=361118&aid=485617&group_id=11118">http://sourceforge.net/tracker/?func=detail&atid=361118&aid=485617&group_id=11118</ulink>,
+ for details, and a sample configuration.
+</para>
+</sect2>
+
+
+<sect2 renderas="sect3" id="otherproxy">
+<title>How can I make Privoxy work with other
+proxies like Squid or Tor?</title>
+<para>
+ This can be done and is often useful to combine the benefits of
+ <application>Privoxy</application> with those of a another proxy.
+ See the <ulink
+ url="../user-manual/config.html#FORWARDING">forwarding chapter</ulink>
+ in the <ulink url="../user-manual/index.html">User Manual</ulink> which
+ describes how to do this, and the <link linkend="TOR">
+ How do I use Privoxy together with
+ Tor</link> section below.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="port-80">
+<title>Can I just set Privoxy to use port 80
+and thus avoid individual browser configuration?</title>
+
+<para>
+ No, its more complicated than that. This only works with special kinds
+ of proxies known as <quote>transparent</quote> proxies (see below).
+</para>
+
+</sect2>
+
+<sect2 renderas="sect3" id="transparent">
+<title>Can Privoxy run as a <quote>transparent
+</quote> proxy?</title>
+<para>
+ No, <application>Privoxy</application> currently does not have this ability,
+ though it may be added in a future release. Transparent proxies require
+ special handling of the request headers beyond what
+ <application>Privoxy</application> is now capable of.
+</para>
+
+<para>
+ Chaining <application>Privoxy</application> behind another proxy that has
+ this ability should work though.
+ See the <ulink
+ url="../user-manual/config.html#FORWARDING">forwarding chapter</ulink>
+ in the <ulink url="../user-manual/index.html">User Manual</ulink>. As
+ a transparent proxy to be used for chaining we recommend Transproxy
+ (<ulink url="http://transproxy.sourceforge.net/">http://transproxy.sourceforge.net/</ulink>).
+</para>
+
+</sect2>
+
+<sect2 renderas="sect3" id="outlook">
+<title>How can I configure Privoxy for use with Outlook
+ Express?</title>
+<para>
+ <application>Outlook Express</application> uses <application>Internet Explorer</application>
+ components to both render HTML, and fetch any HTTP requests that may be embedded in an HTML email.
+ So however you have <application>Privoxy</application> configured to work
+ with IE, this configuration should automatically be shared.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="outlook-more">
+<title>How can I have separate rules just for HTML mail?</title>
+<para>
+ The short answer is, you can't. <application>Privoxy</application> has no way
+ of knowing which particular application makes a request, so there is no way to
+ distinguish between web pages and HTML mail.
+ <application>Privoxy</application> just blindly proxies all requests. In the
+ case of <application>Outlook Express</application> (see above), OE uses
+ IE anyway, and there is no way for <application>Privoxy</application> to ever
+ be able to distinguish between them (nor could any other proxy type application for
+ that matter).
+</para>
+<para>
+ For a good discussion of some of the issues involved (including privacy and
+ security issues), see
+ <ulink url="http://sourceforge.net/tracker/?func=detail&atid=211118&aid=629518&group_id=11118">http://sourceforge.net/tracker/?func=detail&atid=211118&aid=629518&group_id=11118</ulink>.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="sneaky-cookies">
+<title>I sometimes notice cookies sneaking through. How?</title>
+<para>
+ <ulink
+ url="http://en.wikipedia.org/wiki/Browser_cookie">Cookies</ulink> can be
+ set in several ways. The classic method is via the
+ <literal>Set-Cookie</literal> HTTP header. This is straightforward, and an
+ easy one to manipulate, such as the &my-app; concept of
+ <ulink url="../user-manual/actions-file.html#SESSION-COOKIES-ONLY">session-cookies-only</ulink>.
+ There is also the possibility of using
+ <ulink url="http://en.wikipedia.org/wiki/Javascript">Javascript</ulink> to
+ set cookies (&my-app; calls these <literal>content-cookies</literal>). This
+ is trickier because the syntax can vary widely, and thus requires a certain
+ amount of guesswork. It is not realistic to catch all of these short of
+ disabling Javascript, which would break many sites. And lastly, if the
+ cookies are embedded in a HTTPS/SSL secure session via Javascript, they are beyond
+ <application>Privoxy's</application> reach.
+</para>
+<para>
+ All in all, &my-app; can help manage cookies in general, can help minimize
+ the loss of privacy posed by cookies, but can't realistically stop all
+ cookies.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="evil-cookies">
+<title>Are all cookies bad? Why?</title>
+<para>
+ No, in fact there are many beneficial uses of
+ <ulink
+ url="http://en.wikipedia.org/wiki/Browser_cookie">cookies</ulink>. Cookies are just a
+ method that browsers can use to store data between pages, or between browser
+ sessions. Sometimes there is a good reason for this, and the user's life is a
+ bit easier as a result. But there is a long history of some websites taking
+ advantage of this layer of trust, and using the data they glean from you and
+ your browsing habits for their own purposes, and maybe to your potential
+ detriment. Such sites are using you and storing their data on your system.
+ That is why the security conscious watch from whom those cookies come, and why
+ they really <emphasis>need</emphasis> to be there.
+</para>
+<para>
+ See the
+ <ulink url="http://en.wikipedia.org/wiki/Browser_cookie">Wikipedia cookie
+ definition</ulink> for more.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="allow-cookies">
+<title>How can I allow permanent cookies for my trusted sites?</title>
+
+<para>
+ There are several actions that relate to cookies. The default behavior is to
+ allow only <quote>session cookies</quote>, 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.
+</para>
+<para>
+ To disable all cookie actions, so that cookies are allowed unrestricted,
+ both in and out, for <literal>example.com</literal>:
+</para>
+<para>
+ <screen>
+ { -crunch-incoming-cookies -crunch-outgoing-cookies -session-cookies-only -filter{content-cookies} }
+ .example.com</screen>
+</para>
+<para>
+ Place the above in <filename>user.action</filename>. 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. <filename>user.action</filename>
+ includes an alias for this situation, called
+ <literal>allow-all-cookies</literal>.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="multiples">
+<title>Can I have separate configurations for different users?</title>
+<para>
+ Each instance of <application>Privoxy</application> has its own
+ configuration, including such attributes as the TCP port that it listens on.
+ What you can do is run multiple instances of <application>Privoxy</application>, each with
+ a unique <literal>listen-address</literal> and configuration path, and then
+ each of these can have their own configurations. Think of it as per-port
+ configuration.
+</para>
+<para>
+ Simple enough for a few users, but for large installations, consider having
+ groups of users that might share like configurations.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="whitelists">
+<title>Can I set-up Privoxy as a whitelist of
+<quote>good</quote> sites?</title>
+<para>
+ Sure. There are a couple of things you can do for simple whitelisting.
+ Here's one real easy one:
+</para>
+ <screen>
+ ############################################################
+ # Blacklist
+ ############################################################
+ { <ulink url="../user-manual/actions-file.html#BLOCK">+block</ulink> }
+ / # Block *all* URLs
+
+ ############################################################
+ # Whitelist
+ ############################################################
+ { <ulink url="../user-manual/actions-file.html#BLOCK">-block</ulink> }
+ kids.example.com
+ toys.example.com
+ games.example.com</screen>
+<para>
+ This allows access to only those three sites.
+</para>
+<para>
+ A more interesting approach is <application>Privoxy's</application>
+ <literal>trustfile</literal> concept, which incorporates the notion of
+ <quote>trusted referrers</quote>. See the <ulink
+ url="../user-manual/config.html#TRUSTFILE">User Manual Trust</ulink>
+ documentation.
+</para>
+<para>
+ These are fairly simple approaches and are not completely foolproof. There
+ are various other configuration options that should be disabled (described
+ elsewhere here and in <ulink url="../user-manual/">the User Manual</ulink>)
+ so that users can't modify their own configuration and easily circumvent the
+ whitelist.
+</para>
+</sect2>
+
+</sect1>
+
+<!-- ~ End section ~ -->
+
+
+<!-- ~~~~~ New section ~~~~~ -->
+
+<sect1 id="misc"><title>Miscellaneous</title>
+
+<sect2 renderas="sect3">
+<title id="slowsme">How much does Privoxy slow my browsing down? This
+has to add extra time to browsing.</title>
+<para>
+ How much of an impact depends on many things, including the CPU of the host
+ system, how aggressive the configuration is, which specific actions are being triggered,
+ the size of the page, etc.
+</para>
+<para>
+ Overall, 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 typically being
+ retrieved and displayed. The actual processing time required by
+ <application>Privoxy</application> 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 (if ad
+ blocking is being used).
+</para>
+
+<para>
+ <quote>Filtering</quote> content via the <literal><ulink
+ url="../user-manual/actions-file.html#FILTER">filter</ulink></literal> or
+ <literal><ulink
+ url="../user-manual/actions-file.html#DEANIMATE-GIFS">deanimate-gifs</ulink></literal>
+ actions will certainly cause a perceived slowdown, since the entire document
+ needs to be buffered before displaying. And on very large documents, there may be
+ some impact. How much depends on the page size, the actual definition of the
+ filter(s), etc. See below. Most other actions have little to no impact on
+ speed.
+</para>
+
+</sect2>
+
+
+<sect2 renderas="sect3" id="loadingtimes"><title>I notice considerable
+delays in page requests compared to the old Junkbuster. What's wrong?</title>
+<para>
+ If you use any <literal><ulink
+ url="../user-manual/actions-file.html#FILTER">filter</ulink></literal> action,
+ such as filtering banners by size, web-bugs etc, or the <literal><ulink
+ url="../user-manual/actions-file.html#DEANIMATE-GIFS">deanimate-gifs</ulink></literal>
+ 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.
+</para>
+<para>
+ The loading time typically does not really change much 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
+ more noticeable on slower dialup connections. Extremely large documents
+ may have some impact on the time to load the page where there is filtering
+ being done. But overall, the difference should be very minimal. If there is a
+ big impact, then probably some other problem is contributing.
+ </para>
+<para>
+ Filtering is automatically disabled for inappropriate MIME types. But note
+ that if the web server mis-reports the MIME type, then content that should
+ not be filtered, could be. <application>Privoxy</application> only knows how
+ to differentiate filterable content because of the MIME type as reported by
+ the server, or because of some configuration setting that enables/disables
+ filtering.
+
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="configurl"><title>What are "http://config.privoxy.org/" and
+"http://p.p/"?</title>
+<para>
+ <ulink url="http://config.privoxy.org/">http://config.privoxy.org/</ulink> is the
+ address of <application>Privoxy</application>'s built-in user interface, and
+ <ulink url="http://p.p/">http://p.p/</ulink> is a shortcut for it.
+</para>
+<para>
+ Since <application>Privoxy</application> sits between your web browser and the Internet,
+ it can simply intercept requests for these addresses and answer them with its built-in
+ <quote>web server</quote>.
+</para>
+<para>
+ This also makes for a good test for your browser configuration: If entering the
+ URL <ulink url="http://config.privoxy.org/">http://config.privoxy.org/</ulink>
+ takes you to a page saying <quote>This is Privoxy ...</quote>, everything is OK.
+ If you get a page saying <quote>Privoxy is not working</quote> instead, then
+ your browser didn't use <application>Privoxy</application> for the request,
+ hence it could not be intercepted, and you have accessed the <emphasis>real</emphasis>
+ web site at config.privoxy.org.
+</para>
+<para>
+ With recent versions of <application>Privoxy</application> (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 <ulink
+ url="../user-manual/actions-file.html">actions files</ulink>.
+</para>
+
+<para>
+ Note that the built-in URLs from earlier versions of <application>Junkbuster</application>
+ / <application>Privoxy</application>, 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;.
+</para>
+</sect2>
+
+<!--
+ out of date 09/02/06 HB
+<sect2 renderas="sect3" id="blocklist"><title>Do you still maintain the blocklists?</title>
+ <para>
+ No. The patterns for blocking now reside (among other things) in the <ulink
+ url="../user-manual/actions-file.html">actions files</ulink>, which are
+ actively maintained instead. See next question ...
+</para>
+</sect2>
+-->
+<sect2 renderas="sect3" id="newads"><title>How can I submit new ads, or report
+problems?</title>
+<para>
+Please see the <link linkend="contact">Contact section</link> for
+various ways to interact with the developers.
+</para>
+
+</sect2>
+
+<sect2 renderas="sect3" id="noonecares"><title>Why doesn't anyone answer my support
+request?</title>
+<para>
+Rest assured that it has been read and considered. Why it is not answered,
+could be for various reasons, including no one has a good answer for it, no
+one has had time to yet investigate it thoroughly, it has been reported
+numerous times already, or because not enough information was provided to help
+us help you. Your efforts are not wasted, and we do appreciate them.
+</para>
+
+</sect2>
+
+
+<sect2 renderas="sect3" id="ip"><title>How can I hide my IP address?</title>
+<para>
+ If you run both the browser and the proxy locally, you cannot hide your IP
+ address with <application>Privoxy</application> or ultimately any other
+ software. The server needs to know your IP address so that it knows where to
+ send the responses back.
+</para>
+<para>
+ There are many publicly usable "anonymous" proxies out there, which
+ provide a further level of indirection between you and the web server.
+</para>
+<para>
+ However, these proxies are called "anonymous" because you don't need
+ a password, not because they would offer any real anonymity.
+ Most of them will log your IP address and make it available to the
+ authorities in case you violate the law of the country they run in. 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.
+</para>
+<para>
+ Your best bet is to chain <application>Privoxy</application>
+ with <ulink url="http://tor.eff.org/">Tor</ulink>,
+ an <ulink url="http://www.eff.org/">EFF</ulink> supported onion routing system.
+ The configuration details can be found in
+ <ulink url="#TOR">How do I use <application>Privoxy</application> together with <application>Tor</application> section</ulink>
+ just below.
+</para>
+<!--
+<para>
+ 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 large
+ LAN, and we are looking into that.
+</para>
+ I assume this is about sending fake forward IP addresses?
+ David and I looked into it and considered it a waste of time to implement.
+ Fabian 2006-09-04
+-->
+</sect2>
+
+<sect2 renderas="sect3">
+<title id="anonforsure">Can Privoxy guarantee I am anonymous?</title>
+<para>
+ No. Your chances of remaining anonymous are greatly improved, but unless you
+ <ulink url="#TOR">chain <application>Privoxy</application> with <application>Tor</application></ulink>
+ or a similar system and know what you're doing when it comes to configuring
+ the rest of your system, it would be safest to assume that everything you do
+ on the Web can be traced back to you.
+</para>
+<para>
+ <application>Privoxy</application> can remove various information about you,
+ and allows <emphasis>you</emphasis> more freedom to decide which sites
+ you can trust, and what details you want to reveal. But it neither
+ hides your ip address, nor can it guarantee that the rest of the system
+ behaves correctly. There are several possibilities how a web sites can find
+ out who you are, even if you are using a strict <application>Privoxy</application>
+ configuration and chained it with <application>Tor</application>.
+</para>
+<para>
+ Most of <application>Privoxy's</application> protection can be easily subverted
+ by an insecure browser configuration, therefore you should use a browser that can
+ be configured to only execute code from trusted sites, and be careful which sites you trust.
+ For example there is no point in having <application>Privoxy</application>
+ modify the User-Agent header, if websites can get all the information they want
+ through JavaScript, ActiveX, Flash, Java etc.
+</para>
+<para>
+ A few browsers disclose the user's email address in certain situations, such
+ as when transferring a file by FTP. <application>Privoxy</application>
+ 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 <application>NSClean</application>.
+</para>
+<para>
+ 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!
+</para>
+
+</sect2>
+
+<sect2 renderas="sect3">
+<title id="proxytest">A test site says I am not using a Proxy.</title>
+<para>
+ Good! Actually, they are probably testing for some other kinds of proxies.
+ Hiding yourself completely would require additional steps.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="tor"><title>How do I use Privoxy
+ together with Tor?</title>
+<para>
+ Before you configure <application>Privoxy</application> to use <application>Tor</application>
+ (<ulink url="http://tor.eff.org/">http://tor.eff.org/</ulink>),
+ please follow the User Manual chapters
+ <ulink url="../user-manual/installation.html">2. Installation</ulink> and
+ <ulink url="../user-manual/startup.html">5. Startup</ulink> to make sure
+ <application>Privoxy</application> itself is setup correctly.
+</para>
+<para>
+ If it is, refer to <ulink url="http://tor.eff.org/documentation.html.en">Tor's
+ extensive documentation</ulink> to learn how to install <application>Tor</application>,
+ and make sure <application>Tor</application>'s logfile says that
+ <quote>Tor has successfully opened a circuit</quote> and it
+ <quote>looks like client functionality is working</quote>.
+</para>
+<para>
+ If either <application>Tor</application> or <application>Privoxy</application>
+ isn't working, their combination most likely will neither. Testing them on their
+ own will also help you to direct problem reports to the right audience.
+ If <application>Privoxy</application> isn't working, don't bother the
+ <application>Tor</application> developers. If <application>Tor</application>
+ isn't working, don't send bug reports to the <application>Privoxy</application> Team.
+</para>
+<para>
+ If you verified that <application>Privoxy</application> and <application>Tor</application>
+ are working, it is time to connect them. As far as <application>Privoxy</application>
+ is concerned, <application>Tor</application> is just another proxy that can be reached
+ by socks4 or socks4a. Most likely you are interested in <application>Tor</application>
+ to increase your anonymity level, therefore you should use socks4a,
+ to make sure <application>Privoxy's</application> DNS requests are
+ done through <application>Tor</application> and thus invisible to your local network.
+</para>
+
+<![%p-newstuff;[
+<para>
+ Since <application>Privoxy</application> 3.0.4, its configuration (section 5.2)
+ is already prepared for <application>Tor</application>, if you are using a
+ default <application>Tor</application> configuration and run it on the same
+ system as Privoxy, you just have to uncomment the line:
+</para>
+<para>
+ <screen>
+# forward-socks4a / 127.0.0.1:9050 .
+ </screen>
+</para>
+<para>
+ This is enough to reach the Internet, but additionally you should
+ uncomment the following forward rules, to make sure your local network is still
+ reachable through Privoxy:
+</para>
+<para>
+ <screen>
+# forward 192.168.*.*/ .
+# forward 10.*.*.*/ .
+# forward 127.*.*.*/ .
+ </screen>
+</para>
+<para>
+ Unencrypted connections to systems in these address ranges will
+ be as (un)secure as the local network is, but the alternative is
+ that you can't reach the network at all.
+ If you also want to be able to reach servers in your local
+ network by using their names, you will need additional
+ exceptions that look like this:
+</para>
+<para>
+ <screen>
+# forward localhost/ .
+ </screen>
+</para>
+<para>
+ Save the modified configuration file and open
+ <ulink url="http://config.privoxy.org/show-status">http://config.privoxy.org/show-status/</ulink>
+ in your browser, confirm that <application>Privoxy</application> has reloaded its configuration
+ and that there are no other forward lines, unless you know that you need them. I everything looks good,
+ refer to
+ <ulink url="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#head-0e1cc2ac330ede8c6ad1ac0d0db0ac163b0e6143">Tor
+ Faq 4.2</ulink> to learn how to verify that you are really using <application>Tor</application>.
+</para>
+<para>
+ Afterward, please take the time to at least skim through the rest
+ of <application>Tor's</application> documentation. Make sure you understand
+ what <application>Tor</application> does, why it is no replacement for
+ application level security, and why you shouldn't use it for unencrypted logins.
+</para> ]]>
+</sect2>
+
+<sect2 renderas="sect3">
+<title id="sitebreak">Might some things break because header information or
+content is being altered?</title>
+
+<para>
+ 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.
+</para>
+
+<para>
+ <quote>User-Agent</quote> 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.
+</para>
+
+<para>
+ 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 <quote>User Agent</quote> 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
+ <quote>Referer</quote> header; they may fail or break if unavailable. The
+ weather maps of Intellicast have been blocked by their server when no
+ <quote>Referer</quote> 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.
+</para>
+
+<para>
+ Similar thoughts apply to modifying JavaScript, and, to a lesser degree,
+ HTML elements.
+</para>
+
+<para>
+ 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.
+</para>
+
+</sect2>
+
+
+<sect2 renderas="sect3">
+<title id="caching">Can Privoxy act as a <quote>caching</quote> proxy to
+speed up web browsing?</title>
+<para>
+ No, it does not have this ability at all. You want something like
+ <ulink url="http://www.squid-cache.org/">Squid</ulink> for this. And, yes,
+ before you ask, <application>Privoxy</application> can co-exist
+ with other kinds of proxies like <application>Squid</application>.
+ See the <ulink url="../user-manual/config.html#FORWARDING">forwarding
+ chapter</ulink> in the <ulink url="../user-manual/index.html">user
+ manual</ulink> for details.
+</para>
+</sect2>
+
+<sect2 renderas="sect3">
+<title id="firewall">What about as a firewall? Can Privoxy protect me?</title>
+<para>
+ Not in the way you mean, or in the way a true firewall can.
+ <application>Privoxy</application> can help protect your privacy, but not
+ protect you from intrusion attempts. It is, of course, perfectly possible
+ and recommended to use <emphasis>both</emphasis>.
+</para>
+</sect2>
+
+<sect2 renderas="sect3">
+<title id="wasted">I have large empty spaces / a checkerboard pattern now where
+ads used to be. Why?</title>
+<para>
+ 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.
+</para>
+<para>
+ 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.
+</para>
+<para>
+ So we won't support this in the default configuration, but you can of course
+ define appropriate filters yourself.
+</para>
+</sect2>
+
+<sect2 renderas="sect3">
+<title id="ssl">How can Privoxy filter Secure (HTTPS) URLs?</title>
+<para>
+ Since secure HTTP connections are encrypted SSL sessions between your browser
+ and the secure site, and are meant to be reliably <emphasis>secure</emphasis>,
+ there is little that <application>Privoxy</application> can do but hand the raw
+ gibberish data though from one end to the other unprocessed.
+</para>
+<para>
+ The only exception to this is blocking by host patterns, as the client needs
+ to tell <application>Privoxy</application> the name of the remote server,
+ so that <application>Privoxy</application> can establish the connection.
+ If that name matches a host-only pattern, the connection will be blocked.
+</para>
+<para>
+ 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
+ <application>Privoxy</application>'s ad blocking.
+</para>
+<para>
+ <quote>Content cookies</quote> (those that are embedded in the actual HTML or
+ JS page content, see <literal><ulink
+ url="../user-manual/actions-file.html#FILTER-CONTENT-COOKIES">filter{content-cookies}</ulink></literal>),
+ 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.
+</para>
+
+</sect2>
+
+<sect2 renderas="sect3">
+<title id="secure">Privoxy runs as a <quote>server</quote>. How
+secure is it? Do I need to take any special precautions?</title>
+<para>
+ There are no known exploits that might affect
+ <application>Privoxy</application>. On Unix-like systems,
+ <application>Privoxy</application> can run as a non-privileged
+ user, which is how we recommend it be run. Also, by default
+ <application>Privoxy</application> only listens to requests
+ from <quote>localhost</quote> only. The server aspect of
+ <application>Privoxy</application> is not itself directly exposed to the
+ Internet in this configuration. If you want to have
+ <application>Privoxy</application> 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
+ <application>Privoxy</application> configuration file and check all <ulink
+ url="../user-manual/config.html#ACCESS-CONTROL">access control and security
+ options</ulink>. All LAN hosts can then use this as their proxy address
+ in the browser proxy configuration, but <application>Privoxy</application>
+ 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.
+</para>
+
+</sect2>
+
+<sect2 renderas="sect3" id="turnoff">
+<title>How can I temporarily disable Privoxy?</title>
+<para>
+ The easiest way is to access <application>Privoxy</application> with your
+ browser by using the remote toggle URL: <ulink
+ url="http://config.privoxy.org/toggle">http://config.privoxy.org/toggle</ulink>.
+ See the <ulink url="../user-manual/appendix.html#BOOKMARKLETS">Bookmarklets section</ulink>
+ of the <citetitle>User Manual</citetitle> for an easy way to access this
+ feature.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="reallyoff">
+<title>When <quote>disabled</quote> is Privoxy totally
+out of the picture?</title>
+<para>
+ No, this just means all filtering and actions are disabled.
+ <application>Privoxy</application> is still acting as a proxy, but just not
+ doing any of the things that <application>Privoxy</application> would
+ normally be expected to do. It is still a <quote>middle-man</quote> in
+ the interaction between your browser and web sites.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="crunch">
+<title>My logs show Privoxy <quote>crunches</quote>
+ads, but also its own internal CGI pages. What is a <quote>crunch</quote>?</title>
+<para>
+ A <quote>crunch</quote> simply means <application>Privoxy</application> intercepted
+ <emphasis>something</emphasis>, nothing more. Often this is indeed ads or
+ banners, but <application>Privoxy</application> uses the same mechanism for
+ trapping requests for its own internal pages. For instance, a request for
+ <application>Privoxy's</application> configuration page at: <ulink
+ url="http://config.privoxy.org">http://config.privoxy.org</ulink>, 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 <quote>crunch</quote>.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="downloads">
+<title>Can Privoxy effect files that I download
+from a webserver? FTP server?</title>
+<para>
+ 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
+ <application>Privoxy</application>. If there is a match for a <literal><ulink
+ url="../user-manual/actions-file.html#BLOCK">block</ulink></literal> pattern,
+ it will still be blocked, and of course this is obvious.
+ </para>
+ <para>
+ Filtering is potentially more of a concern since the results are not always
+ so obvious, and the effects of filtering are there whether the file is simply
+ viewed, or downloaded. And potentially whether the content is some obnoxious
+ advertisement, or Mr. Jimmy's latest/greatest source code jewel. Of course,
+ one of these presumably is <quote>bad</quote> content that we don't want, and
+ the other is <quote>good</quote> content that we do want.
+ <application>Privoxy</application> is blind to the differences, and can only
+ distinguish <quote>good from bad</quote> by the configuration parameters
+ <emphasis>we</emphasis> give it.
+</para>
+<para>
+ <application>Privoxy</application> knows the differences in files according
+ to the <quote>Document Type</quote> as reported by the webserver. If this is
+ reported accurately (e.g. <quote>application/zip</quote> for a zip archive),
+ then <application>Privoxy</application> knows to ignore these where
+ appropriate. <application>Privoxy</application> potentially can filter HTML
+ as well as plain text documents, subject to configuration parameters of
+ course. Also, documents that are of an unknown type (generally assumed to be
+ <quote>text/plain</quote>) can 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 rare) cases.
+</para>
+<para>
+ Note that versions later than 3.0.2 do NOT filter document types reported as
+ <quote>text/plain</quote>. Prior to this, <application>Privoxy</application>
+ did filter this document type.
+</para>
+<para>
+ In short, filtering is <quote>ON</quote> if a) the Document Type as reported
+ by the webserver is appropriate <emphasis>and</emphasis> b) the configuration
+ allows it (or at least does not disallow it). That's it. There is no magic
+ cookie anywhere to say this is <quote>good</quote> and this is
+ <quote>bad</quote>. It's the configuration that let's it all happen or not.
+</para>
+<para>
+ If you download text files, you probably do not want these to be filtered,
+ particularly if the content is source code, or other critical content. Source
+ code sometimes might be mistaken for Javascript (i.e. the kind that might
+ open a pop-up window). It is recommended to turn off filtering for download
+ sites (particularly if the content may be plain text files and you are using
+ version 3.0.2 or earlier) in your <filename>user.action</filename> file. And
+ also, for any site or page where making <emphasis>any</emphasis> changes at
+ all to the content is to be avoided.
+</para>
+<para>
+ <application>Privoxy</application> does not do FTP at all, only HTTP
+ and HTTPS (SSL) protocols, so please don't try.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="downloads2">
+<title>I just downloaded a Perl script, and Privoxy
+altered it! Yikes, what is wrong!</title>
+<para>
+ Please read above.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="hostsfile">
+<title>Should I continue to use a <quote>HOSTS</quote> file for ad-blocking?</title>
+<para>
+ One time-tested technique to defeat common ads is to trick the local DNS
+ system by giving a phony IP address for the ad generator in the local
+ <filename>HOSTS</filename> file, typically using <literal>127.0.0.1</literal>, aka
+ <literal>localhost</literal>. This effectively blocks the ad.
+</para>
+<para>
+ There is no reason to use this technique in conjunction with
+ <application>Privoxy</application>. <application>Privoxy</application>
+ does essentially the same thing, much more elegantly and with much more
+ flexibility. A large <filename>HOSTS</filename> file, in fact, not only
+ duplicates effort, but may get in the way. It is recommended to remove
+ such entries from your <filename>HOSTS</filename> file. If you think
+ your hosts list is neglected by <application>Privoxy's </application>
+ configuration, consider adding your list to your <filename>user.action</filename> file:
+</para>
+<para>
+ <screen>
+ { +block }
+ www.ad.example1.com
+ ad.example2.com
+ ads.galore.example.com
+ etc.example.com</screen>
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="seealso">
+<title>Where can I find more information about Privoxy
+and related issues?</title>
+<!-- Include seealso.sgml boilerplate: -->
+ &seealso;
+<!-- end boilerplate -->
+
+<!--
+<para>
+ Please see the
+ <ulink url="../user-manual/seealso.html">user-manual</ulink> for
+ others references.
+</para>
+-->
+</sect2>
+
+<sect2 renderas="sect3" id="microsuck">
+<title>I've noticed that Privoxy changes <quote>Microsoft</quote> to
+<quote>MicroSuck</quote>! Why are you manipulating my browsing?</title>
+
+<para>
+ We're not. The text substitutions that you are seeing are disabled
+ in the default configuration as shipped. You have either manually
+ activated the <quote><literal>fun</literal></quote> filter which
+ is clearly labeled <quote>Text replacements for subversive browsing
+ fun!</quote> or you are using an older Privoxy version and have implicitly
+ activated it by choosing the <quote>Adventuresome</quote> profile in the
+ web-based editor.
+</para>
+</sect2>
+
+</sect1>
+
+
+<!-- ~~~~~ New section ~~~~~ -->
+
+<sect1 id="trouble">
+<title>Troubleshooting</title>
+
+<sect2 renderas="sect3">
+<title id="refused">I am getting <quote>connection refused</quote>
+with every web page?</title>
+<para>
+ Either <application>Privoxy</application> is not running, or your
+ browser is configured for a different port than what
+ <application>Privoxy</application> is using.
+</para>
+
+<para>
+ Early <application>Privoxy</application> 2.x versions (and also
+ <application>Junkbuster</application>) 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 <ulink
+ url="../user-manual/config.html#LISTEN-ADDRESS"><literal>listen-address</literal>
+ option</ulink> in <application>Privoxy's</application> <ulink
+ url="../user-manual/config.html">main configuration file</ulink>.
+</para>
+
+</sect2>
+
+<sect2 renderas="sect3">
+<title id="flushit">I just added a new rule, but the steenkin ad is
+still getting through. How?</title>
+<para>
+ 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 <application>Privoxy</application>
+ will not be in the picture. The best thing to do is try flushing the browser's
+ caches. And then try again.
+</para>
+
+<para>
+ 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 <ulink
+ url="http://config.privoxy.org/show-url-info">http://config.privoxy.org/show-url-info</ulink>
+ and see if it really matches your new rule. Blocking ads is like blocking
+ spam: a lot of tinkering is required to stay ahead of the game.
+</para>
+
+</sect2>
+
+<sect2 id="badsite" renderas="sect3">
+<title >One of my favorite sites does not work with Privoxy.
+What can I do?</title>
+
+<para>
+ First verify that it is indeed a <application>Privoxy</application> problem,
+ by toggling off <application>Privoxy</application> through <ulink
+ url="http://config.privoxy.org/toggle">http://config.privoxy.org/toggle</ulink>,
+ 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).
+</para>
+
+<para>
+ If still a problem, go to <ulink
+ url="http://config.privoxy.org/show-url-info">http://config.privoxy.org/show-url-info</ulink>
+ 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 <ulink
+ url="http://config.privoxy.org/show-status">http://config.privoxy.org/show-status</ulink>
+ and select the appropriate actions files for editing.
+</para>
+<para>
+ 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!
+</para>
+<para>
+ 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 <literal>{ fragile }</literal> section in <filename>user.action</filename>,
+ which is an alias that turns off most <quote>dangerous</quote>
+ actions, but is also likely to turn off more actions then needed, and thus lower
+ your privacy and protection more than necessary,
+</para>
+<para>
+ Troubleshooting actions is discussed in more detail in the <ulink
+ url="../user-manual/appendix.html#ACTIONSANAT">User Manual appendix</ulink>.
+ There is also an <ulink
+ url="../user-manual/actions-file.html#ACT-EXAMPLES">actions tutorial</ulink>.
+</para>
+
+</sect2>
+
+
+<!-- ~~~~~ New section ~~~~~ -->
+<sect2 id="dun" renderas="sect3">
+<title>After installing Privoxy, I have to log in
+every time I start IE. What gives?</title>
+
+<para>
+ This is a quirk that effects the installation of
+ <application>Privoxy</application>, 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.
+</para>
+
+<para>
+ When setting up an NT based Windows system with
+ <application>Privoxy</application> 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.
+</para>
+
+<para>
+ When setting up <application>Privoxy</application> 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
+ <application>Privoxy</application>. 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!
+</para>
+
+<para>
+ 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.
+</para>
+
+<para>
+[Thanks to Ray Griffith for this submission.]
+</para>
+</sect2>
+
+
+<!-- ~~~~~ New section ~~~~~ -->
+<sect2 id="ftp" renderas="sect3">
+<title>I cannot connect to any FTP sites. Privoxy
+ is blocking me.</title>
+ <para>
+ <application>Privoxy</application> cannot act as a proxy for FTP traffic,
+ so do not configure your browser to use <application>Privoxy</application>
+ as an FTP proxy. The same is true for <emphasis>any protocol other than HTTP
+ or HTTPS (SSL)</emphasis>.
+ </para>
+ <para>
+ Most browsers understand FTP as well as HTTP. If you connect to a site, with
+ a URL like <literal>ftp://ftp.example.com</literal>, your browser is making
+ an FTP connection, and not a HTTP connection. So while your browser may
+ speak FTP, <application>Privoxy</application> does not, and cannot proxy
+ such traffic.
+ </para>
+ <para>
+ To complicate matters, some systems may have a generic <quote>proxy</quote>
+ setting, which will silently various protocols, including
+ <emphasis>both</emphasis> HTTP and FTP proxying! So it is possible to
+ accidentally enable FTP proxying in these cases. And of course, if this
+ happens, <application>Privoxy</application> will indeed cause problems since
+ it does not know FTP. <![%p-newstuff;[Newer version will give a sane error
+ message if a FTP connection is attempted.]]>
+ </para>
+ <para>
+ Will <application>Privoxy</application> ever proxy FTP traffic? Unlikely.
+ There just is not much reason, and the work to make this happen is more than
+ it may seem.
+ </para>
+</sect2>
+
+<!-- ~~~~~ New section ~~~~~ -->
+<sect2 id="osxie" renderas="sect3">
+<title>In Mac OSX, I can't configure Microsoft Internet Explorer to use
+ Privoxy as the HTTP proxy.</title>
+ <para>
+ 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 <literal>127.0.0.1</literal> in the entry field.
+ Enter <literal>8118</literal> in the Port field. The next time you start
+ IE, it should reflect these values.
+ </para>
+</sect2>
+
+<!-- ~~~~~ New section ~~~~~ -->
+<sect2 renderas="sect3" id="osxuninstall">
+<title>In Mac OSX, I dragged the Privoxy folder to the trash in order to
+ uninstall it. Now the finder tells me I don't have sufficient privileges to
+ empty the trash.</title>
+ <para>
+ Just dragging the <application>Privoxy</application> folder to the trash is
+ not enough to delete it. <application>Privoxy</application> supplies an
+ <application>uninstall.command</application> file that takes care of
+ these details. Open the trash, drag the <application>uninstall.command</application>
+ file out of the trash and double-click on it. You will be prompted for
+ confirmation and the administration password.
+ </para>
+ <para>
+ The trash may still appear full after this command; emptying the trash
+ from the desktop should make it appear empty again.
+ </para>
+</sect2>
+
+
+<!-- ~~~~~ New section ~~~~~ -->
+<sect2 renderas="sect3" id="osximages">
+<title>In Mac OSX Panther (10.3), images often fail to load and/or I
+ experience random delays in page loading. I'm using
+ <literal>localhost</literal> as my browser's proxy setting.</title>
+ <para>
+ We believe this is due to an IPv6-related bug in OSX, but don't fully
+ understand the issue yet. In any case, changing the proxy setting to
+ <literal>127.0.0.1</literal> instead of <literal>localhost</literal>
+ works around the problem.
+ </para>
+</sect2>
+
+<!-- ~~~~~ New section ~~~~~ -->
+<sect2 renderas="sect3" id="blankpage">
+<title>I get a completely blank page at one site. <quote>View Source</quote>
+ shows only: <markup><![CDATA[<html><body></body></html>]]></markup>. Without
+ Privoxy the page loads fine.</title>
+ <para>
+ Chances are that the site suffers from a bug in
+ <ulink url="http://www.php.net/"><application>PHP</application></ulink>,
+ which results in empty pages being sent if the client explicitly requests
+ an uncompressed page, like <application>Privoxy</application> does.
+ This bug has been fixed in PHP 4.2.3.
+ </para>
+ <para>
+ To find out if this is in fact the source of the problem, try adding
+ the site to a <literal>-prevent-compression</literal> section in
+ <filename>user.action</filename>:
+ </para>
+ <screen>
+ # Make exceptions for ill-behaved sites:
+ #
+ {-prevent-compression}
+ .example.com</screen>
+ <para>
+ 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).
+ </para>
+</sect2>
+
+<!-- ~~~~~ New section ~~~~~ -->
+<sect2 renderas="sect3" id="error503">
+<title>Why am I getting a 503 Error (WSAECONNREFUSED) on every page?</title>
+ <para>
+ More than likely this is a problem with your TCP/IP networking. 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 personal firewall type products
+ may cause similar type problems if not configured correctly.
+ </para>
+</sect2>
+
+<sect2 renderas="sect3" id="nohostname">
+<title>My logs show many <quote>Unable to get my own hostname</quote> lines.
+Why?</title>
+<para>
+ <application>Privoxy</application> tries to get the hostname of the system
+ its running on from the IP address of the system interface it is bound to
+ (from the <filename>config</filename> file
+ <emphasis>listen-address</emphasis> setting). If the system cannot supply
+ this information, <application>Privoxy</application> logs this condition.
+</para>
+<para>
+ Typically, this would be considered a minor system configuration error. It is
+ not a fatal error to <application>Privoxy</application> however, but may
+ result in a much slower response from <application>Privoxy</application> on
+ some platforms due to DNS timeouts.
+</para>
+<para>
+ This can be caused by a problem with the local <filename>HOSTS</filename>
+ file. If this file has been changed from the original, try reverting it to
+ see if that helps.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="inuse">
+<title>When I try to launch Privoxy, I get an
+error message <quote>port 8118 is already in use</quote> (or similar wording).
+Why?</title>
+<para>
+ Port 8118 is <application>Privoxy's</application> default TCP
+ <quote>listening</quote> port. Typically this message would mean that there
+ is already one instance of <application>Privoxy</application> running, and
+ you are actually trying to start a second <application>Privoxy</application>
+ on the same port, which will not work. (You can have multiple instances but
+ they must be assigned different ports.) How and why this might happen varies
+ from platform to platform, but you need to check your installation and
+ start-up procedures.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="demoronizer">
+<title>
+ Pages with UTF-8 fonts are garbled.
+</title>
+<para>
+ This is caused by the <quote>demoronizer</quote> filter. You should either
+ upgrade <application>Privoxy</application>, or at least upgrade to the most
+ recent <filename>default.action</filename> file available from <ulink
+ url="http://sourceforge.net/project/showfiles.php?group_id=11118">SourceForge</ulink>.
+ Or you can simply disable the demoronizer filter.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="demoronizer2">
+<title>
+ Why are binary files (such as images) corrupted when Privoxy
+ is used?
+</title>
+<para>
+ This may also be caused by the <quote>demoronizer</quote> filter,
+ in conjunction with a web server that is misreporting a file type. Binary
+ files are exempted from <application>Privoxy's</application> filtering
+ (unless the web server by mistake says the file is something else). Either
+ upgrade <application>Privoxy</application>, or go to the most recent
+ <filename>default.action</filename> file available from <ulink
+ url="http://sourceforge.net/project/showfiles.php?group_id=11118">SourceForge</ulink>.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="demoronizer3">
+<title>
+ What is the <quote>demoronizer</quote> and why is it there?
+</title>
+<para>
+ The original demoronizer was a Perl script that cleaned up HTML pages which
+ were created with certain Microsoft products. MS has used proprietary extensions
+ to standardized font encodings (ISO 8859-1), which has caused problems for pages
+ that are viewed with non-Microsoft products (and are expecting to see a
+ standard set of fonts). The demoronizer corrected these errors so the pages
+ displayed correctly. <application>Privoxy</application> borrowed from this
+ script, introducing a filter based on the original demoronizer, which in turn could
+ correct these errors on the fly.
+</para>
+<para>
+ But this is only needed in some situations, and will cause serious problems in some
+ other situations.
+</para>
+<para>
+ If you are using Microsoft products, you do not need it. If you need to view
+ pages with UTF-8 characters (such as Cyrillic or Chinese), then it will
+ cause corruption of the fonts, and thus <emphasis>should not be on</emphasis>.
+</para>
+<para>
+ On the other hand, if you use non-Microsoft products, and you occasionally
+ notice wierd characters on pages, you might want to try it.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="windowopen">
+<title>
+ Why do I keep seeing <quote>PrivoxyWindowOpen()</quote> in raw source code?
+</title>
+<para>
+ <application>Privoxy</application> is attempting to disable malicious
+ <ulink url="http://en.wikipedia.org/wiki/Javascript">Javascript</ulink>
+ in this case, with the <literal>unsolicited-popups</literal>
+ filter. <application>Privoxy</application> cannot tell very well
+ <quote>good</quote> code snippets from <quote>bad</quote> code snippets.
+</para>
+<para>
+ If you see this in HTML source, and the page displays without problems, then
+ this is good, and likely some pop-up window was disabled. If you see this
+ where it is causing a problem, such as a downloaded program source code file,
+ then you should set an exception for this site or page such that the
+ integrity of the page stays in tact by disabling all filtering.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="dnserrors">
+<title>
+ I am getting too many DNS errors like <quote>404 No Such Domain</quote>. Why
+ can't Privoxy do this better?
+</title>
+<para>
+ There are potentially several factors here. First of all, the DNS resolution
+ is done by the underlying operating system -- not
+ <application>Privoxy</application> itself. <application>Privoxy</application>
+ merely initiates the process and hands it off, and then later reports
+ whatever the outcome was. And tries to give a coherent message if there seems
+ to be a problem. In some cases, this might otherwise be mitigated by the
+ browser itself which might try some work-arounds and alternate approaches (e.g
+ adding <quote>www.</quote> to the URL). In other cases, if
+ <application>Privoxy</application> is being chained with another proxy, this
+ could complicate the issue, and cause undue
+ delays and timeouts. In the case of a <quote>socks4a</quote> proxy, the socks
+ server handles all the DNS. <application>Privoxy</application> would just be
+ the <quote>messenger</quote> which is reporting whatever problem occurred
+ downstream, and not the root cause of the error.
+</para>
+<![%p-newstuff;[
+<para>
+ In any case, v. 3.0.4 includes various improvements to help
+ <application>Privoxy</application> better handle these cases.
+</para>]]>
+</sect2>
+
+<sect2 renderas="sect3" id="allcpu">
+<title>
+ At one site Privoxy just hangs, and starts taking
+ all CPU. Why is this?
+</title>
+<para>
+ This is probably a manifestation of the <quote>100% cpu</quote> problem that
+ occurs on pages containing many (thousands upon thousands) of blank lines. The blank lines
+ are in the raw HTML source of the page, and the browser just ignores them. But the
+ pattern matching in <application>Privoxy's</application> page filtering
+ mechanism is trying to match against absurdly long strings and this becomes
+ very CPU-intensive, taking a long, long time to complete. Until a better
+ solution comes along, disable filtering on these pages, particularly the
+ <literal>js-annoyances</literal> and <literal>unsolicited-popups</literal>
+ filters.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="slowcrawl">
+<title>I just installed Privoxy, and all my
+browsing has slowed to a crawl. What gives? </title>
+<para>
+ This should not happen, and for the overwhelming number of users world-wide,
+ it does not happen. I would suspect some inadvertent interaction of software
+ components such as anti-virus software, spyware protectors, personal
+ firewalls or similar components. Try disabling (or uninstalling) these one
+ at a time and see if that helps.
+</para>
+</sect2>
+
+
+</sect1>
+
+ <!-- ~~~~~ New section ~~~~~ -->
+ <sect1 id="contact"><title>Contacting the developers, Bug Reporting and Feature Requests</title>
+<!-- Include contacting.sgml -->
+ &contacting;
+<!-- end contacting -->
+ </sect1>
+
+<!-- ~~~~~ New section ~~~~~ -->
+<sect1 id="copyright"><title>Privoxy Copyright, License and History</title>
+
+ <!-- Include copyright.sgml -->
+ ©right;
+ <!-- end -->
+
+
+ <para>
+ Portions of this document are <quote>borrowed</quote> from the original
+ <application>Junkbuster</application> (tm) FAQ, and modified as
+ appropriate for <application>Privoxy</application>.
+ </para>
+
+ <!-- ~~~~~ New section ~~~~~ -->
+ <sect2><title>License</title>
+ <!-- Include copyright.sgml: -->
+ &license;
+ <!-- end copyright -->
+ </sect2>
+ <!-- ~ End section ~ -->
+
+ <!-- ~~~~~ New section ~~~~~ -->
+ <sect2><title>History</title>
+ <!-- Include history.sgml -->
+ &history;
+ <!-- end -->
+ </sect2>
+
+ </sect1>
+ <!-- ~ End section ~ -->
+
+
+<!-- ~~~~~ New section ~~~~~ -->
+<!--
+<sect1 id="seealso"><title>See also</title>
+-->
+<!-- Include seealso.sgml -->
+<!--
+ &see;
+-->
+<!-- end -->
+<!--
+</sect1>
+-->
+
+<!-- hhmts end -->
+ <!--
+ Tue 09/11/01 06:38:14 PM EST: Test SGML doc by Hal Burgiss.
+
+ This program is free software; you can redistribute it
+ and/or modify it under the terms of the GNU General