+<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.5, its
+ <ulink url="../user-manual/config.html">main configuration file</ulink>
+ 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 &my-app;, you just have to edit the
+ <ulink url="../user-manual/config.html#FORWARDING">forwarding section</ulink>
+ and 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. If 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>
+ Afterwards, 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. It is common for sites to use browser type, browser version,
+ HTTP header content, and various other techniques in order to dynamically
+ decide what to display and how to display it. What you see, and what I see,
+ might be very different. There are many, many ways that this can be handled,
+ so having hard and fast rules, is tricky.
+</para>
+
+<para>
+ <quote>User-Agent</quote> 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 just this
+ one aspect.
+</para>
+
+<para>
+ Also, 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 that can go wrong when trying to fool a web server. The
+ results of which could inadvertently cause pages to load incorrectly,
+ partially, or even not at all. And there may be no obvious clues as to just
+ what went wrong, or why. Nowhere will there be a message that says
+ <quote><emphasis>Turn off <literal>fast-redirects</literal> or else!</emphasis>
+ </quote>
+</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. Please upgrade!
+</para>
+</sect2>
+
+</sect1>
+
+
+<!-- ~~~~~ New section ~~~~~ -->
+
+<sect1 id="trouble">
+<title>Troubleshooting</title>
+
+<sect2 renderas="sect3">
+<title id="refused">I cannot connect to any websites. Or, I am getting
+<quote>connection refused</quote> message with every web page. Why?</title>
+<para>
+ Either ...
+</para>
+<para>
+<itemizedlist>
+<listitem><para>
+<application>Privoxy</application> is not running. Solution: verify
+ that &my-app; is installed correctly, has not died, and is running.
+</para></listitem>
+ <listitem><para>Or your browser is configured for a different port than what
+ <application>Privoxy</application> is using. Solution: verify that &my-app;
+ and your browser are set to the same port (<literal>listen-address</literal>).
+</para></listitem>
+ <listitem><para>Or if using a forwarding rule, you have a configuration problem or a
+ problem with a host in the forwarding chain. Solution: temporarily alter your
+ configuration and take the forwarders out of the equation.
+</para></listitem>
+ <listitem><para>
+ Or you have a firewall that is interfering and blocking you. Solution:
+ try disabling or removing the firewall as a test.
+ </para></listitem>
+</itemizedlist>
+</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,
+ Troubleshooting: the Anatomy of an Action</ulink>.
+ There is also an <ulink
+ url="../user-manual/actions-file.html#ACT-EXAMPLES">actions tutorial</ulink>
+ with general configuration information and examples.
+</para>
+
+</sect2>
+