Kai Raven <kairaven@xxxxxxxx> wrote:
> On 20.05.2006/09:13, you wrote:
> > I think a low-hanging target is the uniqueness of HTTP headers sent
> > by particular users of HTTP and HTTPS over Tor. Accept-Language,
> > User-Agent, and a few browser-specific features are likely to reveal
> > locale and OS and browser version -- sometimes relatively uniquely,
> > as when someone uses a Linux distribution that ships with a highly
> > specific build of Firefox -- and this combination may serve to make
> > people linkable or distinguishable in particular contexts.
> For this reasons i have changed the Accept-Language and User-Agent
> header, but only for the locale.
I use a generated Firefox User-Agent string which is rebuild
every few minutes by <http://www.fabiankeil.de/sourcecode/uagen.pl>.
While I don't blend in with the Windows using crowd, the User-Agent
is different for each website visit and therefore can't be used to
track my visits.
The website owner might notice that I don't surf
with a windows box, that I use Tor and probably Privoxy,
block cookies and don't execute his code, but I can live
with that and it's not enough information for a unique
> > Privoxy does _not_, depending on its configuration, necessarily
> > remove or rewrite all of the potentially relevant HTTP protocol
> > headers. Worse, different Privoxy configurations may actually
> > introduce _new_ headers or behaviors that further serve to
> > differentiate users from one another.
> Ack. For this reasons, i have deactivated all functions for script,
> cookie or ad filtering and header manipulation by simply commenting the
> actionsfile options in the main configuration file.
> So, Privoxy is only used as a wrapper for Tor (i don't like the Firefox
> builtin socks_remote_dns function ) and i can only see, that Privoxy adds
> May 20 08:29:14 Privoxy(02960) Header: addh-unique: Host: www.eff.org
> May 20 08:29:14 Privoxy(01136) Header: addh: X-Forwarded-For: 127.0.0.1
The Host header is required for HTTP/1.1 and probably was already
present anyway. Adding X-Forwarded-For is unusual though.
I'm using several action files and get:
Header: New HTTP Request-Line: GET /links.html HTTP/1.1
Header: scan: GET /links.html HTTP/1.1
Header: scan: Host: 192.168.0.49:8000
Header: scan: User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US;
rv:18.104.22.168) Gecko/20060506 Firefox/22.214.171.124
Header: scan: Accept:
Header: scan: Accept-Language: en
Header: scan: Accept-Encoding: gzip,deflate
Header: scan: Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Header: scan: Keep-Alive: 600
Header: scan: Proxy-Connection: keep-alive
Header: scan: Referer: http://192.168.0.49:8000/
Header: Referer: http://192.168.0.49:8000/ (not modified, still on
Header: Modified: User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; sk-SK;
rv:126.96.36.199) Gecko/20060505 Firefox/188.8.131.52
Header: Suppressed offer to compress content
Header: crumble crunched: Keep-Alive: 600!
Header: crumble crunched: Proxy-Connection: keep-alive!
Header: Accept-Language header crunched and replaced with: Accept-Language:
Header: addh-unique: Host: 192.168.0.49:8000
Header: Adding: Connection: close
I'm using minor Privoxy improvements
but they don't change the behaviour of the
ATM I believe most site owners only check the headers
which later show up in the Servers log file.
For example I think having a Accept-Language header which
matches the locale in the User-Agent is less important than using
a valid User-Agent and a valid Referer. I also think nobody cares
if my request headers have "Connection: close" or "Keep-Alive: 600"
> For the handling of cookies, ads and scripts, i'm using Adblock,
> NoScript, CookieButton and CookieCuller. Ok, that is difficult or
> unusable in a networked environment with the need of centralized proxy
> and client management.
Where do you see the difference if ads and cookies are blocked/modified
by Privoxy or by the browser? If the website owner is interested
if cookies are touched, she can still tell.
> > A remedy for this would be to try to create a standardized Privoxy
> > configuration and set of browser headers, and then try to convince as
> > many Tor users as possible to use that particular configuration.
> > (One way to do this is to try to convince everyone who makes a
> > Tor+Privoxy distribution or product to use the agreed-upon default
> > configuration.) The goal is not to prevent people from controlling
> > their own Privoxy configurations or doing more things to protect
> > their privacy; rather, it is to try to reduce the variety in headers
> > and behaviors seen by web servers contacted by Tor users on
> > different platforms.
> See above...couldn't default configurations and standardized browsers
> / proxys, used only by Tor & Privoxy users, reveal Tor users more easily,
> if not used by all users?
If the website owner really wants to know if Tor is used, he just
needs to check the ip address. A common Privoxy configuration wouldn't
> I think, a Privoxy version with deactivated actions (or a simple, free
> and secure socks_wrapper as a replacement for Privoxy) and a database with
> User-Agent and Accept-Language headers (more relevant headers?) of
> all browsers in all languages, as shipped by the OS or browser vendor
> together with a short explanation, how to switch them permanently
> (about:config, useragent...) or temporary with Extensions like User
> Agent Switcher or PrefBar would be more useful.
Unfortunately there will never be an agreement what
a good default browser an proxy configuration looks like.
My idea of a good default configuration blocks all cookies,
doesn't execute any code and blocks all SSL connections
(as they circumvent Privoxy's filters), but lets the user
make exceptions for trusted sites.
The Mozilla project however thinks (and most of the other
browser creators agree) it's a better idea to execute every
code that comes along, to accept all cookies without telling
the users and saving them as long as specified.
As most of Firefox's user base read and believed Firefox
was "safe" and "protecting the user's privacy" they don't
touch the default configuration and happily surf without
privacy, assuming the opposite.
Even if the user later installs Privoxy, she probably uses a
weak configuration because otherwise "it breaks sites" and she
is too lazy to check the cause and find a real solution.