Threats to anonymity set at and above the application layer; HTTP headers
nickm at freehaven.net
Sun May 21 19:55:54 UTC 2006
On Fri, May 19, 2006 at 11:51:54AM -0700, Seth David Schoen wrote:
> It's pretty well understood that anonymity can be lost at higher protocol
> layers even when it's well protected at lower layers.
Hi, Seth. This is a pretty good summary of higher-layer issues; thanks!
I think there are some things we can do at a Tor level, some things
that need higher-level app filtering, some things that need app
support, and some stuff we don't know how to solve at all.
I. I think these are in the "probably no automatic solution exists"
> * typing speed
> * language comprehension and selection
> * language proficiency
> * idiosyncratic language use
> * idiosyncratic language errors (cf. Rao and Rohatgi)
I could be wrong about the last two; many smart people think that
automated or semiautomated textual normalization is possible.
II. Needs app support:
> * timing of access (what time zone are you in, when do you usually do
> something?) -- for communications with non-randomized latency < 1 day
(I don't think there's much we can do about this at the Tor level;
if people were going to use something like Mixminion in large
numbers, they would've started by now.)
> * typing patterns (cf. Cliff Stoll's _Cuckoo's Egg_ and the Song et
> * al. paper)
(You'd need a client that aggregated keypresses, as ssh can do with
passwords, as IRC does with lines of text, etc.)
III. App support and filtering are worthwhile targets:
> * cookies and their equivalents (cf. Martin Pool's "meantime", a cookie
> equivalent using client-side information that was intended for a
> totally different purpose -- cache control)
> * unique browser or other application headers or behavior (distinguishing
> MSIE from Firefox from Opera? not just based on User-agent but based on
> request patterns, e.g. for inline images, and different interpretations
> * different user-agent versions (including leaked information about the
> * different privoxy versions and configurations
> 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.
Right, we need one of these. Ideally, it would be for a Free Sotware
proxy that isn't completely unsupported and unmaintained: privoxy is
showing its age. I have hopes for proxymodo if it ever becomes
(If anybody suggests proxomitron, I'll call them names for not reading
what I said about free software. ;) )
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 654 bytes
Desc: not available
More information about the tor-talk