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

[Georg Koppen]

After reading Mike's blog post and the material contained in it (via
links) I thought it would be helpful to start a discussion about it.
First of all thanks for explaining the idea of improving the private
browsing mode. That aim seems worthwile but I want to focus more on the
needs for high anonymity systems like Tor (I am one of the JonDos people
to set the records straight).

Thus, first I am not sure about the relationship of the improved private
browsing and the anon mode. It seems like the former is kind of
precondition of the latter and the latter adds some special anon
features (or just layout stuff??): "We would love to be able to ship a
vastly simplified browser extension that contains only a compiled Tor
binary and some minimal addon code that simply "upgrades" the user's
private browsing mode into a fully functional anonymous mode." What
shall the upgrade do exactly? And why having again add-ons that can
probably be toggled on/off and are thus more error-prone than just
having an, say, Tor anon mode? Or is this already included in the Tor
anon mode but only separated in the blog post for explanatory purposes?

Sticking to the blog post (one of) its central idea seems to be to
isolate the identifiers and state to the top-level domain in the URL bar
as "activity in Tor Browser on one site should not trivially
de-anonymize their activity [i.e. the activity of Tor users, G.K.] on
another site to ad networks and exits". I am wondering whether this idea
really helps here at least regarding exit mixes. If one user requests
google.com, mail.google.com and other Google services within the 10
minutes interval (I am simplifying here a bit) without deploying TLS the
exit is still able to connect the whole activity and "sees" which
services that particular user is requesting/using. Even worse, if the
browser session is quite long there is a chance of recognizing that user
again if she happens to have the same exit mix more than once. Thus, I
do not see how that helps avoiding linkability for users that need/want
strong anonymity while surfing the web. Would be good to get that
explained in some detail. Or maybe I am missing a point here.

Now something to the proposed behavior of the referer and window.name.
It is said that they should adhere to the "same-origin policy where
sites from different origins get either no referer, or a referer that is
truncated to the top-level domain". Assuming I understood TorButton's
Smart-Spoofing option properly: Why is it not applied to the
referer/window.name anymore? In other words: Why is the referer (and
window.name) not kept if the user surfs within one domain (let's say
from example.com to foo.example.com and then to foo.bar.example.com)?
Before we implemented almost the same algorithm than Torbutton's
smart-spoof algo in our own extension a while ago we had some
compatibility issues (I remember yahoo.com that needed to have the
referer untouched while surfing within the domain) that got fixed by it
and never popped up again. Why stepping back? The idea "sites should
also be allowed to request an exemption to this rule on a per-site basis
using an html attribute, which could trigger a chrome permissions
request, or simply be granted automatically (on the assumption that they
could just URL smuggle the data)" seems rather awkward and not a good
solution to a problem that is not really one.

One final point: Leaving my previous section aside: Why is the referer
and window.name not treated in the same way as cookies and others in the
proposal. Why having two different policies for identifiers? I am not
sure whether there could emerge some attacks out of that distinction but
my feeling tells me that there should ideally be just one policy that
governs all those identifiers. At least it would probably be easier to
implement and to audit them.

Georg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110622/f27e1f69/attachment.pgp>