[Freedombox-discuss] How efficient is the freedombox privoxy?
Here's a relevant upstream bug (from 2012):
http://sourceforge.net/tracker/index.php?func=detail&aid=3539129&group_id=11118&atid=211118
(Side note: Interesting tracking using HTTP etags:
http://lucb1e.com/rp/cookielesscookies/ - there are probably limits on
how anonymous we can make ourselves without breaking caching. In my
browser, the uniquely identifying factor is the list of system fonts,
so who knows how far we'll have to take this!)
An easy first step could be to ensure that the user-agent header is
being replaced with something "ordinary". This will potentially break
sites using useragent sniffing.
FreedomBox's privoxy takes the normal privoxy tarball, and adds a
bunch of rules taken from HTTPS Everywhere and Adblock Plus. I am
concerned that these changes are not yet in a form where they can be
included as patches in Debian's privoxy package.
On 25 August 2013 22:38, Petter Reinholdtsen <pere at hungry.com> wrote:
> Hi. I just tested the privoxy setup in freedombox using the browser
> fingerprint service availalbe from
> <URL: https://panopticlick.eff.org/ >, and it said my "browser
> fingerprint appears to be unique among the 3,317,576 tested so far".
>
> I was using Opera as a web browser, which was said to provide at least
> 12 bits of identifying value, while the most significant part was
> HTTP_ACCEPT Headers (I got Javascript mostliy turned off).
>
> This experiment made me wonder exactly what privoxy is providing in
> freedombox, and how efficient it is. Can we adjust something to make
> it more efficient? Perhaps sort HTTP accept headers?
>
> --
> Happy hacking
> Petter Reinholdtsen
>
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
--
Tim Retout <diocles at debian.org>
Reply to: