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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev