+<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 by first blocking all URLs, and
+ then subsequently allowing three specific exceptions.
+</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>
+
+<sect2 renderas="sect3" id="no-adblock">
+<title>How can I turn off ad-blocking?</title>
+<para>
+ Ad blocking is hard-coded into the default configuration files. It has been
+ assumed that everyone using &my-app; is interested in this feature. 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
+ <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-SIZE">-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>
+ All the template pages are installed in a sub-directory appropriately named:
+ <filename>templates</filename>. These are specialized text files utilized
+ by &my-app; and can easily be modified using any text editor. Knowing something
+ about HTML will of course be helpful. You cannot rename any of these files,
+ or create completely new templates, that is not possible. But you can change
+ the page content to whatever you like. Be forewarned that these files are
+ subject to being overwritten during upgrades, so be sure to save any
+ customizations.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="blockall">
+<title>How can I remove the <quote>Go There Anyway</quote> link from
+the <emphasis>BLOCKED</emphasis> page?</title>
+<para>
+ Editing the template page (see above) may dissuade some users, but this
+ method is easily circumvented. Where you want this level of control, you should
+ build &my-app; from source, and enable various features that are
+ available as compile-time options. You should use
+ <command>configure</command> as follows:
+</para>
+<para>
+ <screen>
+ ./configure --disable-toggle --disable-editor --disable-force
+ </screen>
+</para>
+<para>
+ This will create an executable with hard-coded security features so that
+ &my-app; does not allow easy bypassing of blocks or changing the current
+ configuration. Some of these features can also by toggled on/off via options
+ in <application>Privoxy's</application> main
+ <ulink
+ url="../user-manual/config.html#ACCESS-CONTROL">config</ulink> file. But
+ compiled-in compliance is a much better method of ensuring that a block is
+ really a block.
+</para>
+<para>
+ Default builds of &my-app; are typically built with these features
+ disabled.
+</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, the bandwidth of the connection, 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, filtering may have
+ some measurable 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>
+<para>
+ Also, when filtering is enabled, typically there is a disabling of
+ compression, (see <ulink
+ url="../user-manual/actions-file.html#PREVENT-COMPRESSION">prevent-compression</ulink>).
+ This can have an impact on speed as well. Again, the page size, etc. will
+ determine how much of an impact.
+</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 situation is contributing (like
+ anti-virus software).
+ </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>