Thus spake Georg Koppen (g.koppen@xxxxxxxxx): > 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? What the upgrade does depends on how good the private browsing mode is. Historically, browser makers have been very conservative, and are reluctant to implement new features if there is any possibility of site breakage. Additionally, we expect that fingerprinting resistance will be an ongoing battle: as new browser features are added, new fingerprinting defenses will be needed. Furthermore, we'll likely be inclined to deploy unproven but better-than-nothing fingerprinting defenses (so long as they don't break much), where as the browser vendors may be more conservative on this front, too. > 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? If we operate by upgrading private browsing mode, we'll effectively have the "toggle" in a place where users have already been trained by the UI to go for privacy. Torbutton would become an addon that is only active in private browsing mode. We expect that the browser vendors will perform usability studies to determine the best way to provide users with the UI to enter private browsing mode easily. We also expect that if browser vendors become serious enough about privacy, they will be the ones who deal with all the linkability issues between the private and non-private states, not us. > 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. We also hope to provide a "New Identity" functionality to address the persistent state issue, but perhaps this also should be an explicit responsibility of the mode rather than the addon.. I hear that Google has actually done some studies of Incognito mode, and users do expect that they have to close the Incognito mode windows to clear the Incognito cookies and state from memory. They may only expect this because it's clear that they're not entirely exiting the browser via this action, though... > 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)? I don't really understand this question. The referer should be kept in these cases. > 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. Neither of these properties are really identifiers (yes yes, window.name can store identifiers, but it is more than that). Both are more like cross-page information channels. Hence it doesn't make sense to "clear" them like cookies. Instead, It makes more sense to prohibit information transmission through them in certain cases. I believe the cases where you want to prohibit the information transmission end up being the same for both of these information channels. To respond to your previous paragraph, it is debatable exactly how strict a policy we want here, but my guess is that for Tor, we have enough IP unlinkability such that the answer can be "not very", in favor of not breaking sites that use these information channels legitimately. The fact is that other information channels exist for sites to communicate information about visitors to their 3rd party content. If you consider what you actually *can* restrict in terms of information transmission between sites and their 3rd party elements, the answer is "not much". So in my mind, it becomes a question of "What would you be actually preventing by *completely disabling* referers (and window.name) entirely?" It seems to me that the answer to this question is "You only prevent accidental leakage", because bad actors can use URL params as an information channel to their 3rd party elements just fine, and tracking and ad-targeting will continue. In a world without referers, sites would actually be incentivized to do this information passing, because ad networks will be able to serve better ads and pay them more money. If someone did a crawl of the top 10k sites and found that none of them would break by disabling or restricting referers, I might change my mind for Torbutton, because it is unlikely that sites will adapt just for Torbutton users. However, you still have the property that if the browser vendors decided to disable referers, sites would build mechanisms to transmit referer-style information anyway. Hence, when talking to browser makers, it doesn't make sense to recommend that they disable referer information. They should instead simply allow sites to have better privacy controls over them if they wish. Does this reasoning make sense? I suppose it is somewhat abstract, and very conditional. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgp6CY0lUwXmg.pgp
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev