+<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> 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 affect 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.
+</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>
+ <screen>
+ { +block }
+ www.ad.example1.com
+ ad.example2.com
+ ads.galore.example.com
+ etc.example.com</screen>
+</sect2>
+