Note: This ONLY applies to privoxy 3.0.6 and earlier. +
Just dragging the Privoxy folder to the trash is - not enough to delete it. Privoxy supplies an @@ -548,11 +554,11 @@ CLASS="APPLICATION" CLASS="APPLICATION" >uninstall.command
file that takes care of - these details. Open the trash, drag the uninstall.command - file out of the trash and double-click on it. You will be prompted for + file out of the trash and double-click on it. You will be prompted for confirmation and the administration password.We believe this is due to an IPv6-related bug in OSX, but don't fully +> We believe this is due to an IPv6-related bug in Mac OS X, but don't fully understand the issue yet. In any case, changing the proxy setting to
This can be caused by a problem with the local HOSTShosts file. If this file has been changed from the original, try reverting it to see if that helps. Make sure whatever name(s) are used for the local system, that they resolve both ways.
You should also be able to work around the problem with the + hostname option.
Until a better solution comes along, disable filtering on these pages, + particularly the js-annoyances and and + unsolicited-popups - filters.
filters. If you run into this problem + with a recent Privoxy version, please send a problem report.As of Privoxy 3.0.9, zlib support is enabled in the default builds.
Probably the browser is requesting ads through HTTPS and Privoxy + 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.
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.
To do that, enable logging to figure out which requests get blocked by + Privoxy and add the hosts (no path patterns) to a section like this:
{+redirect{http://127.0.0.1:0/} -block -limit-connect}
+.ivwbox.de:443/ |
Additionally you have to configure your browser to contact + "127.0.0.1:0" directly (instead of through Privoxy).
To add a proxy exception in Mozilla Firefox + open the "Preferences", click the "Settings" + button located on the "Network" tab in the "Advanced" + section, and add "127.0.0.1:0" in the "No Proxy for:" + field.
Please report the problem to the creator of your selinux policies.
The problem is that some selinux policy writers aren't familiar + with the application they are trying to "secure" and + thus create policies that make no sense.
In Privoxy's 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 Privoxy's + default configuration doesn't block these requests.
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.
Probably you unintentionally compiled Privoxy without threading support + in which case requests have to be serialized and only one can be served + at the same time.
Check your "USE" flags and make sure they include + "threads". If they don't, add the flag and rebuild Privoxy.
If you compiled Privoxy with threading support (on POSIX-based systems), + the "Conditional #defines" section on http://config.privoxy.org/show-status + will list "FEATURE_PTHREAD" as "enabled".