Threats to anonymity set at and above the application layer; HTTP headers

[Nick Mathewson]

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"
category:

> * 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
> of HTTP standards and perhaps CSS and JavaScript standards)
> 
> * different user-agent versions (including leaked information about the
> platform)
> 
> * 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
portable.

(If anybody suggests proxomitron, I'll call them names for not reading
what I said about free software. ;) )

yrs,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 654 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20060521/4e79d576/attachment.pgp>