+<sect2 renderas="sect3" id="intercepting">
+<title>Can Privoxy run as a <quote>intercepting</quote> proxy?</title>
+<para>
+ <application>Privoxy</application> can't intercept traffic itself,
+ but it can handle requests that where intercepted and redirected
+ with a packet filter (like <application>PF</application> or
+ <application>iptables</application>), as long as the <literal>Host</literal>
+ header is present.
+ </para>
+<para>
+ As the <literal>Host</literal> header is required by HTTP/1.1 and as most
+ web sites rely on it anyway, this limitation shouldn't be a problem.
+</para>
+<para>
+ Please refer to your packet filter's documentation to learn how to
+ intercept and redirect traffic into <application>Privoxy</application>.
+ Afterward you just have to configure <application>Privoxy</application> to
+ <ulink url="../user-manual/config.html#ACCEPT-INTERCEPTED-REQUESTS">accept
+ intercepted requests</ulink>.
+</para>
+
+</sect2>
+
+<sect2 renderas="sect3" id="outlook">
+<title>How can I configure Privoxy for use with Outlook?</title>
+<para>
+ Versions of <application>Outlook</application> prior to Office 2007, use
+ <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, at least with older version of
+ Internet Explorer.
+</para>
+<para>
+ Starting with Office 2007, Microsoft is instead using the MS-Word rendering
+ engine with Outlook. It is unknown whether this can be configured to use a
+ proxy.
+ <!-- FIXME HB 2009-02-15 -->
+</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="https://sourceforge.net/tracker/?func=detail&atid=211118&aid=629518&group_id=11118">https://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 privacy 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 you 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 that 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
+ <ulink url="../user-manual/config.html#LISTEN-ADDRESS">listen-address</ulink>
+ configuration setting, 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 white-listing.
+ 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 by first blocking all URLs, and
+ then subsequently allowing three specific exceptions.
+</para>
+<para>
+ Another 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">Trust documentation</ulink>
+ for details.
+</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>
+
+<sect2 renderas="sect3" id="no-adblock">
+<title>How can I turn off ad-blocking?</title>
+<para>
+ Ad blocking is achieved through a complex application of various &my-app;
+ <ulink url="../user-manual/actions-file.html">actions</ulink>. These
+ actions are deployed against simple images, banners, flash animations,
+ text pages, JavaScript, pop-ups and pop-unders, etc., so its not as simple as
+ just turning one or two actions off. The various actions that make up
+ &my-app; ad blocking are hard-coded into the default configuration files. It
+ has been assumed that everyone using &my-app; is interested in this
+ particular feature.
+ </para>
+ <para>
+ If you want to do without this, there are several approaches you can take:
+ You can manually undo the many block rules in
+ <filename>default.action</filename>. Or even easier, just create your own
+ <filename>default.action</filename> file from scratch without the many ad
+ blocking rules, and corresponding exceptions. Or lastly, if you are not
+ concerned about the additional blocks that are done for privacy reasons, you
+ can very easily over-ride <emphasis>all</emphasis> blocking with the
+ following very simple rule in your <filename>user.action</filename>:
+ </para>
+ <para>
+ <screen>
+ # Unblock everybody, everywhere
+ { <ulink url="../user-manual/actions-file.html#BLOCK">-block</ulink> }
+ / # UN-Block *all* URLs</screen>
+</para>
+<para>
+ Or even a more comprehensive reversing of various ad related actions:
+</para>
+<para>
+ <screen>
+ # Unblock everybody, everywhere, and turn off appropriate filtering, etc
+ { <ulink url="../user-manual/actions-file.html#BLOCK">-block</ulink> \
+ <ulink url="../user-manual/actions-file.html#FILTER-BANNERS-BY-SIZE">-filter{banners-by-size}</ulink> \
+ <ulink url="../user-manual/actions-file.html#FILTER-BANNERS-BY-LINK">-filter{banners-by-link}</ulink> \
+ <literal>allow-popups</literal> \
+ }
+ / # UN-Block *all* URLs and allow ads</screen>
+</para>
+<para>
+ This last <quote>action</quote> in this compound statement,
+ <literal>allow-popups</literal>, is an <ulink
+ url="../user-manual/actions-file.html#ALIASES">alias</ulink> that disables
+ various pop-up blocking features.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="templates">
+<title>How can I have custom template pages, like the
+<emphasis>BLOCKED</emphasis> page?</title>
+<para>
+ &my-app; <quote>templates</quote> are specialized text files utilized by
+ &my-app; for various purposes and can easily be modified using any text
+ editor. All the template pages are installed in a sub-directory appropriately
+ named: <filename>templates</filename>. Knowing something about HTML syntax
+ will of course be helpful.
+</para>
+<para>
+ Be forewarned that the default templates are subject to being overwritten
+ during upgrades. You can, however, create completely new templates,
+ place them in another directory and specify the alternate path in the main
+ <filename>config</filename>. For details, have a look at the <ulink
+ url="../user-manual/config.html#templdir">templdir</ulink> option.
+</para>
+</sect2>