[tor-dev] Improving Private Browsing Mode/Tor Browser

[Mike Perry]

Thus spake Georg Koppen (g.koppen at jondos.de):

> > Hence, I tend to make decisions in favor of the usability direction
> > over minor details, especially ones that don't really prevent bad
> > actors/adversaries from accomplishing their goals.
> 
> That is definitely a good approach. But maybe there is research to be
> done here as well. Just a rough (and in part research) idea that I had
> in mind while asking you the question above: What about if we first
> started looking at different services offered in the web whether they
> can be deployed anonymously *at all* (or maybe more precisely (but not
> much): that can be deployed in a way that there is either no linkability
> at all or the linkability is not strong enough to endanger the user)
> (that would be worth some research, I guess)?

What technical properties of the web makes such services impossible to
use? Most of the ones I can think of are problematic because of "Layer
8" issues like users divilging too much information to specific
services.

> We would probably find some services where we had to say: "Well,
> there is no way to get them used anonymously due to their nature and
> the power of the companies and/or owners behind them." (Facebook
> comes here to my mind as a candidate and the Google universe as well
> due to the power Google has).  Should we say we make the Tor anon
> mode compatible with these services nevertheless (due to usability
> issues) and abandon stronger anonymity measures? I would say no. Not
> at all. Rather we should be honest and say: "Dear User, surfing
> anonymously AND using Facebook does not work.  You may use the Tor
> anon mode for that purpose though but there is a high probability
> that it breaks functionality." 

How do we be "honest"? Filter their browsing?

> The idea of getting more users due to being not too strict here
> might be appealing but is not the right decision in the end. I think
> one has to realize that there are services in the web that are
> *designed* in a way that one EITHER may use them OR use anonymity
> services. Sure, the devil is in the details (e.g.  there are
> probably a lot of services that may be usable anonymously but then
> are accompanied with a certain lack of usability. What about them?
> Should we decide against usability again or should we loosen our
> means to provide unlinkability here?) but that does not mean there
> is no way to find a good solution though. 

At the end of the day, I don't believe we have to sacrifice much in
terms of usability if we properly reason through the adversary
capabilities.

> In short (and still roughly): I would like to start thinking from
> having all means available to surf the web anonymously and then
> downgrade them piece-by-piece to reach a trade-off between anonymity
> and usability.  Services that may not be used anonymously at all
> would not trigger such a painful downgrade ("painful" as one usually
> tries first to hack around existing problems encountering
> unbelievable design issues and bugs and has to concede finally that
> it is in the user's interest to exclude that feature (again)).

Downgrading privacy would be a UI nightmare that no one would
understand how to use, but assuming we can solve that problem: if we
can find a way to apply these downgrade options to specific urlbar
domains, this might make sense. Otherwise you introduce too many
global fingerprinting issues by providing different privacy options.

What do you have in mind in terms of stricter controls?

> > The need for science especially comes in on the fingerprinting arena.
> > Some fingerprinting opportunities may not actually be appealing to
> > adversaries. Some may even appear appealing in theory, but in practice
> > would be noticeable to the user, too noisy, and/or too error-prone.
> > Hence I called for more panopticlick-style studies, especially of
> > Javascript features, in the blog post.
> 
> Yes, that is definitely a good idea though I tend to avoid them all even
> if currently no adversary is using them (especially if no usability
> issue is at stake). First: no one knows whether one did not miss an
> attacker using this kind of attack vector and second: Getting rid of
> attack vectors is a good thing per se.

But going back to your original point, I contend you're not getting
rid of any attack vectors by eliminating window.name and referer
transmission. The adversary still has plenty of other ways to
transmit the same information to 3rd party elements..

You're just preventing "accidental" information leakage at the cost of
breaking functionality.

The ad networks will adapt to this sort of change, and then you're
right back where you started in terms of actual tracking, after years
of punishing your users with broken sites..


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110711/edde7dca/attachment.pgp>