+<para>
+ Until a better solution comes along, disable filtering on these pages,
+ particularly the <literal>js-annoyances</literal> and
+ <literal>unsolicited-popups</literal> filters. If you run into this problem
+ with a recent &my-app; version, please send a problem report.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="slowcrawl">
+<title>I just installed Privoxy, and all my
+browsing has slowed to a crawl. What gives? </title>
+<para>
+ This should not happen, and for the overwhelming number of users world-wide,
+ it does not happen. I would suspect some inadvertent interaction of software
+ components such as anti-virus software, spyware protectors, personal
+ firewalls or similar components. Try disabling (or uninstalling) these one
+ at a time and see if that helps. Either way, if you are using a
+ recent &my-app; version, please report the problem.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="preventcomp">
+<title>Why do my filters work on some sites but not on others? </title>
+<para>
+ It's probably due to compression. It is a common practice for web servers to
+ send their content <quote>compressed</quote> in order to speed things up, and
+ then let the browser <quote>uncompress</quote> them. When compiled with zlib support
+ &my-app; can decompress content before filtering, otherwise you may want to enable
+<ulink
+ url="../user-manual/actions-file.html#PREVENT-COMPRESSION">prevent-compression</ulink>.
+</para>
+<para>
+ As of &my-app; 3.0.9, zlib support is enabled in the default builds.
+</para>
+</sect2>
+
+
+<sect2 renderas="sect3" id="ssl-warnings">
+<title>On some HTTPS sites my browser warns me about unauthenticated content,
+ the URL bar doesn't get highlighted and the lock symbol appears to be broken.
+ What's going on?</title>
+<para>
+ Probably the browser is requesting ads through HTTPS and &my-app;
+ is blocking the requests. Privoxy's error messages are delivered
+ unencrypted and while it's obvious for the browser that the HTTPS
+ request is already blocked by the proxy, some warn about unauthenticated
+ content anyway.
+</para>
+<para>
+ To work around the problem you can redirect those requests to an invalid
+ local address instead of blocking them. While the redirects aren't
+ encrypted either, many browsers don't care. They simply follow the
+ redirect, fail to reach a server and display an error message instead
+ of the ad.
+</para>
+<para>
+ To do that, enable logging to figure out which requests get blocked by
+ &my-app; and add the hosts (no path patterns) to a section like this:
+</para>
+<para>
+<screen>
+<![CDATA[
+{+redirect{http://127.0.0.1:0/} -block -limit-connect}
+.ivwbox.de:443/
+]]>
+</screen>
+</para>
+<para>
+ Additionally you have to configure your browser to contact
+ <quote>127.0.0.1:0</quote> directly (instead of through &my-app;).
+</para>
+<para>
+ To add a proxy exception in <application>Mozilla Firefox</application>
+ open the <quote>Preferences</quote>, click the <quote>Settings</quote>
+ button located on the <quote>Network</quote> tab in the <quote>Advanced</quote>
+ section, and add <quote>127.0.0.1:0</quote> in the <quote>No Proxy for:</quote>
+ field.
+</para>
+</sect2>
+
+
+<sect2 renderas="sect3" id="se-linux">
+<title>I get selinux error messages. How can I fix this?</title>
+<para>
+ Please report the problem to the creator of your selinux policies.
+</para>
+<para>
+ The problem is that some selinux policy writers aren't familiar
+ with the application they are trying to <quote>secure</quote> and
+ thus create policies that make no sense.
+</para>
+<para>
+ In <application>Privoxy's</application> case the problem usually
+ is that the policy only allows outgoing connections for certain
+ destination ports (e.g. 80 and 443). While this may cover the
+ standard ports, websites occasionally use other ports as well.
+ This isn't a security problem and therefore <application>Privoxy's</application>
+ default configuration doesn't block these requests.
+</para>
+<para>
+ If you really want to block these ports (and don't be able
+ to load websites that don't use standard ports), you should
+ configure Privoxy to block these ports as well, so it doesn't
+ trigger the selinux warnings.
+</para>
+</sect2>
+
+
+<sect2 renderas="sect3" id="gentoo-ricers">
+<title>I compiled &my-app; with Gentoo's portage and it appears to be very slow. Why?</title>
+<para>
+ Probably you unintentionally compiled &my-app; without threading support
+ in which case requests have to be serialized and only one can be served
+ at the same time.
+</para>
+<para>
+ Check your <quote>USE</quote> flags and make sure they include
+ <quote>threads</quote>. If they don't, add the flag and rebuild &my-app;.
+</para>
+<para>
+ If you compiled &my-app; with threading support (on POSIX-based systems),
+ the <quote>Conditional #defines</quote> section on <ulink
+ url="http://config.privoxy.org/show-status">http://config.privoxy.org/show-status</ulink>
+ will list <quote>FEATURE_PTHREAD</quote> as <quote>enabled</quote>.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="tainted-sockets">
+<title>What are tainted sockets and how do I prevent them?</title>
+<para>
+ &my-app; marks sockets as tainted when it can't use them to
+ serve additional requests.
+ This does not necessarily mean that something went wrong and
+ information about tainted sockets is only logged if connection
+ debugging is enabled (debug 2).
+</para>
+<para>
+ For example server sockets that were used for CONNECT requests
+ (which are used to tunnel https:// requests) are considered tainted
+ once the client closed its connection to &my-app;.
+ Technically &my-app; could keep the connection to the server open,
+ but the server would not accept requests that do not belong to the
+ previous TLS/SSL session (and the client may even have terminated
+ the session).
+</para>
+<para>
+ Server sockets are also marked tainted when a client requests a
+ resource, but closes the connection before &my-app; has completely
+ received (and forwarded) the resource to the client.
+ In this case the server would (probably) accept additional requests,
+ but &my-app; could not get the response without completely reading
+ the leftovers from the previous response.
+</para>
+<para>
+ These are just two examples, there are currently a bit more than
+ 25 scenarios in which a socket is considered tainted.
+</para>
+<para>
+ While sockets can also be marked tainted as a result of a technical
+ problem that may be worth fixing, the problem will be explicitly
+ logged as error.
+</para>
+</sect2>
+
+<sect2 renderas="sect3" id="pcre-stack-limit">
+<title>After adding my custom filters, &my-app; crashes when visitting certain websites</title>
+<para>
+ This can happen if your custom filters require more memory than &my-app;
+ is allowed to use.
+ Usually the problem is that the operating system enforces a stack size limit
+ that isn't sufficient.
+</para>
+<para>
+ Unless the problem occurs with the filters available in the default configuration,
+ this is not considered a Privoxy bug.
+</para>
+<para>
+ To prevent the crashes you can rewrite your filter to use less ressources,
+ increase the relevant memory limit or recompile pcre to use less stack space.
+ For details please see the
+ <ulink url="http://pcre.org/original/doc/html/pcrestack.html">pcrestack man page</ulink>
+ and the documentation of your operating system.
+</para>
+</sect2>
+