+<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 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 might want to
+ 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 your browser can't reach the network at all. Then again,
+ that may actually be desired and if you don't know for sure
+ that your browser has to be able to reach the local network,
+ there's no reason to allow it.
+</para>
+<para>
+ If you want your browser 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="https://wiki.torproject.org/wiki/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 probably don't want to
+ 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>
+ The <quote>User-Agent</quote> is sometimes used in this way to identify
+ the browser, and adjust content accordingly.
+</para>
+
+<para>
+ Also, different browsers use different encodings of non-English
+ 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. 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> or
+ <ulink url="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</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 some firewall vendors claim they can.
+ <application>Privoxy</application> can help protect your privacy, but can't
+ protect your system from intrusion attempts. It is, of course, perfectly possible
+ 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 is technically possible to eliminate banners and ads in a way that frees
+ their allocated page space. This could easily be done by blocking with
+ <application>Privoxy's</application> filters,
+ and eliminating the <emphasis>entire</emphasis> image references from the
+ HTML page source.
+</para>
+<para>
+ But, this would consume considerably more CPU resources (IOW, slow things
+ down), would likely destroy the layout of some web pages which rely on the
+ banners utilizing a certain amount of page space, and might fail in other
+ cases, where the screen space is reserved (e.g. by HTML tables for instance).
+ Also, making ads and banners disappear without any trace complicates
+ troubleshooting, and would sooner or later be problematic.
+</para>
+<para>
+ The better alternative is to instead let them stay, and block the resulting
+ requests for the banners themselves as is now the case. This leaves either
+ empty space, or the familiar checkerboard pattern.
+</para>
+<para>
+ So the developers won't support this in the default configuration, but you
+ can of course define appropriate filters yourself to achieve this.
+</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>
+ 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> listens to requests from <quote>localhost</quote>
+ only.
+</para>
+<para>
+ 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>Can I temporarily disable Privoxy?</title>
+<para>
+ &my-app; doesn't have a transparent proxy mode,
+ but you can toggle off blocking and content filtering.
+</para>
+<para>
+ The easiest way to do that is to point your browser
+ to the remote toggle URL: <ulink
+ url="http://config.privoxy.org/toggle">http://config.privoxy.org/toggle</ulink>.
+</para>
+<para>
+ 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. Note that this is a feature that may need to be enabled in the main
+ <filename>config</filename> file.
+</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 optional filtering and actions are disabled.
+ <application>Privoxy</application> is still acting as a proxy, but just
+ doing less 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. See below to bypass
+ the proxy.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="turnoff2">
+<title>How can I tell Privoxy to totally ignore certain sites?</title>
+<para>
+ Bypassing a proxy, or proxying based on arbitrary criteria, is purely a browser
+ configuration issue, not a &my-app; issue. Modern browsers typically do have
+ settings for not proxying certain sites. Check your browser's help files.
+</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>
+<para>
+ Since version 3.0.7, Privoxy will also log the crunch reason.
+ If you are using an older version you might want to upgrade.
+</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>Content 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 content 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 lets 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 and seriously slow down your system.
+ 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>
+
+<sect2 renderas="sect3" id="valid">
+<title>Does Privoxy produce <quote>valid</quote> HTML (or XHTML)?</title>
+
+<para>
+ Privoxy generates HTML in both its own <quote>templates</quote>, and possibly
+ whenever there are text substitutions via a &my-app; filter. While this
+ should always conform to the HTML 4.01 specifications, it has not been
+ validated against this or any other standard.
+</para>
+</sect2>
+
+