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
On Wed, 22 Jun 2011 22:30:40 +0200 Georg Koppen g.koppen@jondos.de wrote:
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.
If you maintain two long sessions within the same Tor Browser Bundle instance, you're screwed -- not because the exit nodes might be watching you, but because the web sites' logs can be correlated, and the *sequence* of exit nodes that your Tor client chose is very likely to be unique.
Robert Ransom
If you maintain two long sessions within the same Tor Browser Bundle instance, you're screwed -- not because the exit nodes might be watching you, but because the web sites' logs can be correlated, and the *sequence* of exit nodes that your Tor client chose is very likely to be unique.
Ah, okay, I did not know that. Thanks for that information. I was just wondering how the proposed changes to the private browsing mode would avoid being tracked by exit mixes (as the blog post claimed).
Georg
Thus spake Georg Koppen (g.koppen@jondos.de):
If you maintain two long sessions within the same Tor Browser Bundle instance, you're screwed -- not because the exit nodes might be watching you, but because the web sites' logs can be correlated, and the *sequence* of exit nodes that your Tor client chose is very likely to be unique.
I'm actually not sure I get what Robert meant by this statement. In the absence of linked identifiers, the sequence of exit nodes should not be visible to the adversary. It may be unique, but what allows the adversary to link it to actually track the user? Reducing the linkability that allows the adversary to track this sequence is what the blog post is about...
Or are we assuming that the predominant use case is for a user to continually navigate only by following links for the duration of their session (thus being tracked by referer across circuits and exits), as opposed to entering new urls frequently?
I rarely follow a chain of links for very long. I'd say my mean link-following browsing session lifetime is waay, waay below the Tor circuit lifetime of 10min. Unless I fall into a wikipedia hole and don't stop until I hit philosophy... But that is all the same site, which can link me with temporary cache or session cookies.
Are my browsing habits atypical?
Ah, okay, I did not know that. Thanks for that information. I was just wondering how the proposed changes to the private browsing mode would avoid being tracked by exit mixes (as the blog post claimed).
See my other reply for a response to this question.
On Thu, 23 Jun 2011 10:10:35 -0700 Mike Perry mikeperry@fscked.org wrote:
Thus spake Georg Koppen (g.koppen@jondos.de):
If you maintain two long sessions within the same Tor Browser Bundle instance, you're screwed -- not because the exit nodes might be watching you, but because the web sites' logs can be correlated, and the *sequence* of exit nodes that your Tor client chose is very likely to be unique.
I'm actually not sure I get what Robert meant by this statement. In the absence of linked identifiers, the sequence of exit nodes should not be visible to the adversary. It may be unique, but what allows the adversary to link it to actually track the user? Reducing the linkability that allows the adversary to track this sequence is what the blog post is about...
By session, I meant a sequence of browsing actions that one web site can link. (For example, a session in which the user is authenticated to a web application.) If the user performs two or more distinct sessions within the same TBB instance, the browsing actions within those sessions will use very similar sequences of exit nodes.
Or are we assuming that the predominant use case is for a user to continually navigate only by following links for the duration of their session (thus being tracked by referer across circuits and exits), as opposed to entering new urls frequently?
I rarely follow a chain of links for very long. I'd say my mean link-following browsing session lifetime is waay, waay below the Tor circuit lifetime of 10min. Unless I fall into a wikipedia hole and don't stop until I hit philosophy... But that is all the same site, which can link me with temporary cache or session cookies.
The issue is that two different sites can use the sequences of exit nodes to link a session on one site with a concurrent session on another.
Robert Ransom
Thus spake Robert Ransom (rransom.8774@gmail.com):
On Thu, 23 Jun 2011 10:10:35 -0700 Mike Perry mikeperry@fscked.org wrote:
Thus spake Georg Koppen (g.koppen@jondos.de):
If you maintain two long sessions within the same Tor Browser Bundle instance, you're screwed -- not because the exit nodes might be watching you, but because the web sites' logs can be correlated, and the *sequence* of exit nodes that your Tor client chose is very likely to be unique.
I'm actually not sure I get what Robert meant by this statement. In the absence of linked identifiers, the sequence of exit nodes should not be visible to the adversary. It may be unique, but what allows the adversary to link it to actually track the user? Reducing the linkability that allows the adversary to track this sequence is what the blog post is about...
By session, I meant a sequence of browsing actions that one web site can link. (For example, a session in which the user is authenticated to a web application.) If the user performs two or more distinct sessions within the same TBB instance, the browsing actions within those sessions will use very similar sequences of exit nodes.
The issue is that two different sites can use the sequences of exit nodes to link a session on one site with a concurrent session on another.
Woah, we're in the hinterlands, tread carefully :).
When performed by websites, this attack assumes a certain duration of concurrent use that is sufficient to disambiguate the entire user population. It also assumes exact concurrent use, or the error starts to go up at an unknown and population-size dependent rate.
However, when performed by the exits, this linkability is a real concern. Let's think about that. That sounds more like our responsibility than the browser makers. Now I think I see what Georg was getting at. We didn't mention this because the blog post was directed towards the browser makers.
I've actually been pondering the exit side of this attack for years, but we've never come to a good conclusion about what solution to deploy for various reasons. There are impasses in every direction.
Observe:
Does this mean we want a more automatic version of Proposal 171, something like Robert Hogan proposed? Something per-IP or per top-level domain name? That is what I've historically argued for, but I keep getting told it will consume too many circuits and help bittorrent users (though we have recently discovered how to throttle those motherfuckers, so perhaps we should just do that).
Or does this mean that Torbutton should be handing different SOCKS usernames+passwords down to the SOCKS proxy per tab? This latter piece is very hard to do, it turns out. SOCKS usernames and passwords are not supported by the Firefox APIs. But that is the easy part, now that we have control over the source.
The harder problem is the Foxyproxy API problem.. The APIs to do this type of proxy tracking don't exist, and they don't exist because of Firefox architectural problems.. But maybe there's a bloody hack to the source that we can do because we just don't give a damn about massively violating their architecture to get exactly what we want in the most expedient way. Maybe.
I still think Tor should just do this, though. Every app should be made unlinkable by a simple policy there by default, and we should just rate limit it if it gets to intense (similar to NEWNYM rate limiting).
Thus spake Mike Perry (mikeperry@fscked.org):
Thus spake Robert Ransom (rransom.8774@gmail.com):
On Thu, 23 Jun 2011 10:10:35 -0700 Mike Perry mikeperry@fscked.org wrote:
Thus spake Georg Koppen (g.koppen@jondos.de):
If you maintain two long sessions within the same Tor Browser Bundle instance, you're screwed -- not because the exit nodes might be watching you, but because the web sites' logs can be correlated, and the *sequence* of exit nodes that your Tor client chose is very likely to be unique.
I'm actually not sure I get what Robert meant by this statement. In the absence of linked identifiers, the sequence of exit nodes should not be visible to the adversary. It may be unique, but what allows the adversary to link it to actually track the user? Reducing the linkability that allows the adversary to track this sequence is what the blog post is about...
By session, I meant a sequence of browsing actions that one web site can link. (For example, a session in which the user is authenticated to a web application.) If the user performs two or more distinct sessions within the same TBB instance, the browsing actions within those sessions will use very similar sequences of exit nodes.
The issue is that two different sites can use the sequences of exit nodes to link a session on one site with a concurrent session on another.
Woah, we're in the hinterlands, tread carefully :).
I still think Tor should just do this, though. Every app should be made unlinkable by a simple policy there by default, and we should just rate limit it if it gets to intense (similar to NEWNYM rate limiting).
Arg. The demons in my head just told me that there exists a stupid mashup web-app out there just waiting to ruin our day if we do this in Tor without browser interaction. The demons tell me at least one stupid banking or shopping-cart site checks to make sure both the IP address and the cookies match for all pieces of the app to work together across domains. I think the demons are right. I think this is why we created TrackHostExits, but the demons just laugh and tell me that the hosts are not the same in this case.
So perhaps Torbutton controlled per-tab proxy username+password is the best option? Oh man am I dreading doing that... (The demons laugh again.)
On Thu, 23 Jun 2011 11:19:45 -0700 Mike Perry mikeperry@fscked.org wrote:
So perhaps Torbutton controlled per-tab proxy username+password is the best option? Oh man am I dreading doing that... (The demons laugh again.)
If you do this, you will need to give the user some indication of each tab's ‘compartment’, and some way to move tabs between compartments.
Coloring each tab to indicate its compartment may fail for anomalous trichromats like me and *will* fail for more thoroughly colorblind users. Putting a number or symbol in each tab will confuse most users.
I suggest one compartment per browser window. (Of course, you can and should leave more detailed hooks in the browser's source if possible, in case someone wants to experiment with a different scheme.)
Robert Ransom
Thus spake Robert Ransom (rransom.8774@gmail.com):
On Thu, 23 Jun 2011 11:19:45 -0700 Mike Perry mikeperry@fscked.org wrote:
So perhaps Torbutton controlled per-tab proxy username+password is the best option? Oh man am I dreading doing that... (The demons laugh again.)
If you do this, you will need to give the user some indication of each tab's ???compartment???, and some way to move tabs between compartments.
Coloring each tab to indicate its compartment may fail for anomalous trichromats like me and *will* fail for more thoroughly colorblind users. Putting a number or symbol in each tab will confuse most users.
I suggest one compartment per browser window. (Of course, you can and should leave more detailed hooks in the browser's source if possible, in case someone wants to experiment with a different scheme.)
As soon as I sent the previous email, I wanted to edit it to change "per-tab" to something else. I think any kind of per-tab and per-window isolation does not correspond to how people have been trained to use their existing browsers.
In fact, I think we should also treat this linkability just like the window.name and referer. So, how about we set the Proposal 171 SOCKS username to a function of the hostname in the referer header (possibly caching the first referer for subsequent link navigation). If the referer is blank, use the request URL hostname. This policy should effectively give us the top-level origin isolation we want for other identifiers.
However, when performed by the exits, this linkability is a real concern. Let's think about that. That sounds more like our responsibility than the browser makers. Now I think I see what Georg was getting at. We didn't mention this because the blog post was directed towards the browser makers.
Well, my idea was not that sophisticated but yes, it belongs to the passive attacks available to exit mixes I generally had in mind (and I agree that the current domain-based proposal makes it way harder for an active mix attacker). My example used just one session. And I still would claim that even this gives an exit mix means to track users during the 10 minutes (and later if the user happens to get the same exit mix again within the same browsing session). If this is true do you mean that it is just not worth the effort or is to difficult to explain to the user (as it is highly probably that avoiding this kind of tracking implies breaking some functionality in the web (a kind of tab separation would be necessary but not sufficient))?
Georg
Thus spake Georg Koppen (g.koppen@jondos.de):
However, when performed by the exits, this linkability is a real concern. Let's think about that. That sounds more like our responsibility than the browser makers. Now I think I see what Georg was getting at. We didn't mention this because the blog post was directed towards the browser makers.
Well, my idea was not that sophisticated but yes, it belongs to the passive attacks available to exit mixes I generally had in mind (and I agree that the current domain-based proposal makes it way harder for an active mix attacker). My example used just one session. And I still would claim that even this gives an exit mix means to track users during the 10 minutes (and later if the user happens to get the same exit mix again within the same browsing session). If this is true do you mean that it is just not worth the effort or is to difficult to explain to the user (as it is highly probably that avoiding this kind of tracking implies breaking some functionality in the web (a kind of tab separation would be necessary but not sufficient))?
I'm confused now. You're basically just talking about cookies, cache, and other stored identifiers at this point, right?
Single-site linkability due to information the user has provided to the website is outside of Tor's threat model. That is what https is for (and also why we ship HTTPS-Everywhere with the Tor Browser Bundle).
I'm confused now. You're basically just talking about cookies, cache, and other stored identifiers at this point, right?
Yes.
Single-site linkability due to information the user has provided to the website is outside of Tor's threat model. That is what https is for (and also why we ship HTTPS-Everywhere with the Tor Browser Bundle).
Ah, okay that makes sense. I did not know that. Sorry for bothering you in this regard.
Georg
Thus spake Georg Koppen (g.koppen@jondos.de):
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.
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.
Yes, that seems likely.
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.
Okay. That means there is no additional toggling of Torbutton in this enhanced private mode. The user just enters it and Torbutton is running and doing its job and if the user does not want it anymore she does not toggle anything but leaves this enhanced private browsing mode and that's it, right?
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.
Yes, that would be really helpful.
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..
Hmmm... If that is the answer to my questions then there is nothing like avoiding getting tracked by exit mixes in the concept offered in the blog post. Okay. How should the "New Identity" functionality work? Is that identity generated automatically after a certain amount of time has passed or does a user have to click manually on a button every time?
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.
That sounds good. Then we probably had just different concepts of SOP in mind. I was thinking about http://tools.ietf.org/html/draft-abarth-origin-09 (see: section 3 and 4). That would treat http://example.com, http://foo.example.com and http://foo.bar.example.com as different origins (let alone mixing "http://" and "https://" and having different ports).
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.
Agreed, although the distinction is somewhat blurred here.
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 am not sure about that as "clearing" them for *certain contexts* seems a good means to prohibit information transmission *in these contexts*: If there isn't any information it cannot be transmitted (at least not by referer or windows.name).
I believe the cases where you want to prohibit the information transmission end up being the same for both of these information channels.
Yes, that's true.
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.
It makes perfect sense to me. Thanks.
Another question came to my mind: You seem to be at pains not to break parts of the web even in the anon mode even if that boils down to not implement features that would better fit the needs for people looking for unlinkability (one thing that comes to my mind here would be having a context being tab dependent additionally). Why? Why not saying: "This is Tor's anon mode. It is meant for people that strive for unlinkability and might break some functionality. You may still use Tor in normal or private browsing mode though (providing no or less unlinkability on the browser level)." Do you think that's not worth the effort as Tor's IP unlinkability is enough here (especially combined with the things you suggested in the blog post)? I do not know Tor's user base very well but could imagine that it contains a lot of users that would like to have more unlinkability than the "we do not want to break any (or almost any) part of the web for a better anonymity" fraction.
Georg
Thus spake Georg Koppen (g.koppen@jondos.de):
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.
Okay. That means there is no additional toggling of Torbutton in this enhanced private mode. The user just enters it and Torbutton is running and doing its job and if the user does not want it anymore she does not toggle anything but leaves this enhanced private browsing mode and that's it, right?
That's correct. If the user wants their regular private browsing mode back, they would presumably uninstall the extension.
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..
Hmmm... If that is the answer to my questions then there is nothing like avoiding getting tracked by exit mixes in the concept offered in the blog post. Okay.
That is not entirely true. Because identifiers would be linked to top-level urlbar domain, gone are the days where exits could insert an iframe or web-bug into any arbitrary page and use that to track the user for the duration of the session, regardless of page view.
Instead, they would be pushed back to doing some sort of top-level redirect (which we hope would be way more visible), or maybe not even that, depending on how we define redirects with respect to "top-level".
So no, we are not completely abandoning exits as an adversary with this threat model. If I'm wrong about something, or you think there are still attacks exits can perform that we should address somehow, let me know.
How should the "New Identity" functionality work? Is that identity generated automatically after a certain amount of time has passed or does a user have to click manually on a button every time?
I don't know the answer here. This may vary by browser and use case. For a communications-suite style use case, I think we probably want to detect inactivity and ask the user if they want to clear state, because communications-suites are heavy and a pain to relaunch (hence once opened, they probably will stay open).
For something lighter, like Chrome's Incognito, we may just rely on the user to leave the mode. This divergence is one of the reasons I didn't mention the feature in the blog post.
If you want to track what solution we ultimately deploy for TBB, here is the ticket you should follow: https://trac.torproject.org/projects/tor/ticket/523
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.
That sounds good. Then we probably had just different concepts of SOP in mind. I was thinking about http://tools.ietf.org/html/draft-abarth-origin-09 (see: section 3 and 4). That would treat http://example.com, http://foo.example.com and http://foo.bar.example.com as different origins (let alone mixing "http://" and "https://" and having different ports).
Yeah. The reality is we're basically picking an arbitrary heuristic for squelching this information channel to find some sweet spot that minimizes breakage for maximal gain. True same-origin policy may or may not be relevant here.
Since I personally believe any heuristic squelch is futile against bad actors, I haven't thought terribly hard about the best "sweet spot" policy. I just took what Kory Kirk came up with for a GSoC project and tweaked it slightly to make it symmetric: https://trac.torproject.org/projects/tor/ticket/2148
This policy will appear as a non-default option in 1.4.0 (it is already in 1.3.x-alpha), but I think we should make a real decision about the behavior soon, because having an option just creates a fingerprinting opportunity as I said in the blog post. I believe the fingerprinting effect of an option to be worse than doing nothing at all to referer, since it is global linkability, not just an information channel between two parties: https://trac.torproject.org/projects/tor/ticket/3100
I'm still pretty convinced the best solution for Tor is "leave referer alone", at least until someone shows me the breakage results of a thorough crawl (which would include web-app site use).
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 am not sure about that as "clearing" them for *certain contexts* seems a good means to prohibit information transmission *in these contexts*: If there isn't any information it cannot be transmitted (at least not by referer or windows.name).
Perhaps. Right before I abandoned the toggle model for torbutton, one of the last fixes I did to it was to "clear" window.name on toggle: https://trac.torproject.org/projects/tor/ticket/1968
I now believe that is the wrong way to think about things.
I think the better solution is to "clear" window.name when the user enters a new url in the urlbar, which gets covered by making window.name behave like referer in all cases: https://trac.torproject.org/projects/tor/ticket/3414
Another question came to my mind: You seem to be at pains not to break parts of the web even in the anon mode even if that boils down to not implement features that would better fit the needs for people looking for unlinkability (one thing that comes to my mind here would be having a context being tab dependent additionally). Why? Why not saying: "This is Tor's anon mode. It is meant for people that strive for unlinkability and might break some functionality. You may still use Tor in normal or private browsing mode though (providing no or less unlinkability on the browser level)." Do you think that's not worth the effort as Tor's IP unlinkability is enough here (especially combined with the things you suggested in the blog post)? I do not know Tor's user base very well but could imagine that it contains a lot of users that would like to have more unlinkability than the "we do not want to break any (or almost any) part of the web for a better anonymity" fraction.
I wish I had better science to give you here on the trade-off we're going for, but the reality is that we're best-guessing over a very complex cost/benefit landscape.
We do know for a fact that the easier Tor is to use (which includes installation, configuration, overall intuitiveness/"familiarity", compatibility, and performance), the more people will use it regularly.
We also know for a fact that the more people use Tor, the better the baseline privacy, anonymity, and censorship resistance properties all become.
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.
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.
Hmmm... If that is the answer to my questions then there is nothing like avoiding getting tracked by exit mixes in the concept offered in the blog post. Okay.
That is not entirely true. Because identifiers would be linked to top-level urlbar domain, gone are the days where exits could insert an iframe or web-bug into any arbitrary page and use that to track the user for the duration of the session, regardless of page view.
Instead, they would be pushed back to doing some sort of top-level redirect (which we hope would be way more visible), or maybe not even that, depending on how we define redirects with respect to "top-level".
So no, we are not completely abandoning exits as an adversary with this threat model. If I'm wrong about something, or you think there are still attacks exits can perform that we should address somehow, let me know.
See my last mail.
Another question came to my mind: You seem to be at pains not to break parts of the web even in the anon mode even if that boils down to not implement features that would better fit the needs for people looking for unlinkability (one thing that comes to my mind here would be having a context being tab dependent additionally). Why? Why not saying: "This is Tor's anon mode. It is meant for people that strive for unlinkability and might break some functionality. You may still use Tor in normal or private browsing mode though (providing no or less unlinkability on the browser level)." Do you think that's not worth the effort as Tor's IP unlinkability is enough here (especially combined with the things you suggested in the blog post)? I do not know Tor's user base very well but could imagine that it contains a lot of users that would like to have more unlinkability than the "we do not want to break any (or almost any) part of the web for a better anonymity" fraction.
I wish I had better science to give you here on the trade-off we're going for, but the reality is that we're best-guessing over a very complex cost/benefit landscape.
That's true.
We do know for a fact that the easier Tor is to use (which includes installation, configuration, overall intuitiveness/"familiarity", compatibility, and performance), the more people will use it regularly.
That seems to hold for every piece of software, I guess.
We also know for a fact that the more people use Tor, the better the baseline privacy, anonymity, and censorship resistance properties all become.
Agreed.
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)? 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." 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. 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)).
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.
Georg
Thus spake Georg Koppen (g.koppen@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..
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?
The web is not the right object to reason about here. The more interesting question would be "What techical properties of a service makes it impossible to get used anonymously?" That remains to be researched. At the end, maybe there isn't any (though I doubt that).
Most of the ones I can think of are problematic because of "Layer 8" issues like users divilging too much information to specific services.
That may hold for most services, yes.
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?
No, not at all. That sentence in quotes was not meant literally (in the sense that we pop up a dialog and show that sentence to the user). The idea would be (as I wrote above) not to start a race to the bottom and adapt (i.e. weaken) the unlinkability features to get the anon mode working with thoses sites as well. That in turn could mean that these sites break (worst case) while being used in anon mode or are "just" more inconvenient to use then.
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.
I would be glad if that would be the case but I doubt that (having e.g. Facebook in mind).
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.
No, you got me wrong here. The downgrading occurs while designing the anon mode not while using it. There should be just one mode in order to avoid fingerprinting issues. It is merely meant as a design principle for the dev: starting with all we can get and then downgrading our defenses until we reach a good balance between usability and anon features.
What do you have in mind in terms of stricter controls?
Hmmm... Dunno what you mean here.
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..
Yes, that's true.
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..
This depends on how one designs the single features. But I got your point.
Georg
Thus spake Georg Koppen (g.koppen@jondos.de):
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?
The web is not the right object to reason about here. The more interesting question would be "What techical properties of a service makes it impossible to get used anonymously?" That remains to be researched. At the end, maybe there isn't any (though I doubt that).
Sure, anonymity is by definition impossible for things that require a name. As long as that name can be an ephemeral pseudonym, I think we're good on the web.
But once you start getting into real personal and/or biometric (even just a photo) details, you obviously lose your anonymity set. Again, I think what we're talking about here is "Layer 8".
Most of the ones I can think of are problematic because of "Layer 8" issues like users divilging too much information to specific services.
That may hold for most services, yes.
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.
I would be glad if that would be the case but I doubt that (having e.g. Facebook in mind).
Can you provide specific concerns about facebook wrt the properties from the blog post?
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.
No, you got me wrong here. The downgrading occurs while designing the anon mode not while using it. There should be just one mode in order to avoid fingerprinting issues. It is merely meant as a design principle for the dev: starting with all we can get and then downgrading our defenses until we reach a good balance between usability and anon features.
Ok. Let's try to do this. Where do we start from? Can we start from the design I proposed and make it more strict?
What do you have in mind in terms of stricter controls?
Hmmm... Dunno what you mean here.
What changes to the design might you propose?
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..
Yes, that's true.
Amusing story: I checked to see if Google+ might be using Google Chrome's privacy-preserving web-send feature (http://web-send.org/features.html) for their "+1" like button, and I discovered that sites who source the +1 button were encoding their URLs as a GET parameter to plus.google.com. So any referer protection you might expect to gain in the short term is already gone against Google. I think identifier transmission is really what is important in this case.
I am also pretty disappointed that Google is not even opting to use their own privacy-preserving submission system. Google+ seems like a great opportuity to push the adoption of web-send, so that 3rd-party identifier isolation can be done without breakage.
Folks who are inclined to making media shitstorms should try to jump on this one..
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..
This depends on how one designs the single features. But I got your point.
If you want to suggest how to fine-tune the referer/window.name policy, let's discuss that.
More broadly, perhaps there is some balance of per-tab isolation and origin isolation that is easily achievable in Firefox? In my experience, per-tab isolation is extremely hard. How much of that have you already implemented?
What technical properties of the web makes such services impossible to use?
The web is not the right object to reason about here. The more interesting question would be "What techical properties of a service makes it impossible to get used anonymously?" That remains to be researched. At the end, maybe there isn't any (though I doubt that).
Sure, anonymity is by definition impossible for things that require a name. As long as that name can be an ephemeral pseudonym, I think we're good on the web.
But once you start getting into real personal and/or biometric (even just a photo) details, you obviously lose your anonymity set. Again, I think what we're talking about here is "Layer 8".
Sure, as no layer between 1 and 7 is involved it is per definitionem "layer" 8.
I would be glad if that would be the case but I doubt that (having e.g. Facebook in mind).
Can you provide specific concerns about facebook wrt the properties from the blog post?
Not yet, no. I am not a Facebook user and have therefore to look at research papers investigating it. And the things I read e.g. in http://www.research.att.com/~bala/papers/w2sp11.pdf or in http://www.research.att.com/~bala/papers/wosn09.pdf do not seem to break the idea proposed in the blog post. But again, there is research to be done here, I guess. Redirects (you mentioned them already) could pose a serious threat to the approach in the blog post, though (systems like Phorm http://www.cl.cam.ac.uk/~rnc1/080518-phorm.pdf come to my mind).
No, you got me wrong here. The downgrading occurs while designing the anon mode not while using it. There should be just one mode in order to avoid fingerprinting issues. It is merely meant as a design principle for the dev: starting with all we can get and then downgrading our defenses until we reach a good balance between usability and anon features.
Ok. Let's try to do this. Where do we start from? Can we start from the design I proposed and make it more strict?
Yes, good idea.
What do you have in mind in terms of stricter controls?
Hmmm... Dunno what you mean here.
What changes to the design might you propose?
There are basically two points to be mentioned here IMO:
1) Having a tab (window) isolation additionally (see my comments below)
and
2) Having some means to break the linkage between the same domain called more than once in a tab. That would be the best I can imagine and would help against attacks using redirects as well but is hard to get right. E.g. one had to give the user means to fine-tune the default setting to their needs without ending up in a UI nightmare. And there are probably numerous other pitfalls lurking here... We have already done some basic research (we supervised a BA thesis investigating this concerning cookies) but there is still a lot to do. But yes, I would like to have that feature and invest some energy to investigate if one can get it right in a meaningful way.
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..
This depends on how one designs the single features. But I got your point.
If you want to suggest how to fine-tune the referer/window.name policy, let's discuss that.
Dunno. I think the smart-spoof functionality is working pretty well. I am not sure if you take special care regarding third party content. We check for this and leave the referer unmodified as an attacker does not gain any information out of it (to the contrary it might be strange if someone does not send a referer while requesting a third party image or an other third party resource).
More broadly, perhaps there is some balance of per-tab isolation and origin isolation that is easily achievable in Firefox?
I hope so (at least if we had a Firefox fork that would not be much of a problem anymore). The Multifox Add-On (http://br.mozdev.org/multifox/all.html) claims to have implemented per tab identities and I have looked at it superficially. It is quite promising and deserves a thorough test.
In my experience, per-tab isolation is extremely hard.
I know.
How much of that have you already implemented?
Nothing yet. Frankly, I have not had the time to do so. But we have good chances to get a research grant in the near future (i.e. next 3-4 months) for the next 2 years and the tab isolation (not only for cookies but for DOM storage and similar stuff as well) and ( 2) mentioned above (we'll see how far I'll get in this regard) are my first (sub)project(s). And even if we do not get that grant implementing at least a tab separation will be my next major task I guess.
Regarding the research grant: I already wrote pde and asked him whether he has some interesting stuff that we should try to incorporate into the application. If you (Mike) have something don't hesitate and drop me a mail. We still have the opportunity to move the things we already have a bit around to get something we overlooked into our proposal (the deadline is end of July). The topic is investigating and solving issues regarding an anonymous browser (profile) and to develop one that is resilient to e.g. different fingerprinting attacks and tracking means in general.
Georg
Thus spake Georg Koppen (g.koppen@jondos.de):
Can you provide specific concerns about facebook wrt the properties from the blog post?
Not yet, no. I am not a Facebook user and have therefore to look at research papers investigating it. And the things I read e.g. in http://www.research.att.com/~bala/papers/w2sp11.pdf or in http://www.research.att.com/~bala/papers/wosn09.pdf do not seem to break the idea proposed in the blog post. But again, there is research to be done here, I guess. Redirects (you mentioned them already) could pose a serious threat to the approach in the blog post, though (systems like Phorm http://www.cl.cam.ac.uk/~rnc1/080518-phorm.pdf come to my mind).
Wrt redirects: https://trac.torproject.org/projects/tor/ticket/3600
What do you have in mind in terms of stricter controls?
Hmmm... Dunno what you mean here.
What changes to the design might you propose?
There are basically two points to be mentioned here IMO:
- Having a tab (window) isolation additionally (see my comments below)
and
- Having some means to break the linkage between the same domain called
more than once in a tab. That would be the best I can imagine and would help against attacks using redirects as well but is hard to get right. E.g. one had to give the user means to fine-tune the default setting to their needs without ending up in a UI nightmare. And there are probably numerous other pitfalls lurking here... We have already done some basic research (we supervised a BA thesis investigating this concerning cookies) but there is still a lot to do. But yes, I would like to have that feature and invest some energy to investigate if one can get it right in a meaningful way.
Yeah, the issue I see with both this and tab isolation is that it seems like it will be difficult to teach users who are used to being able to log into their gmail/etc that they have to keep doing this if they use a different tab, or try to open pieces of the interface in new tabs/windows... A non-trivial number of expert users may also like to have multiple windows open to the same site for live updates from the same service (which in some cases may prevent multiple concurrent logins).
More broadly, perhaps there is some balance of per-tab isolation and origin isolation that is easily achievable in Firefox?
I hope so (at least if we had a Firefox fork that would not be much of a problem anymore). The Multifox Add-On (http://br.mozdev.org/multifox/all.html) claims to have implemented per tab identities and I have looked at it superficially. It is quite promising and deserves a thorough test.
This is very interesting. If you get around to evaluating it, let me know. I am still concerned about the usability approach, but if this dropdown menu is smart enough, maybe it can work out. (If the download wasn't http-only I would have installed it already).
Regarding the research grant: I already wrote pde and asked him whether he has some interesting stuff that we should try to incorporate into the application. If you (Mike) have something don't hesitate and drop me a mail. We still have the opportunity to move the things we already have a bit around to get something we overlooked into our proposal (the deadline is end of July). The topic is investigating and solving issues regarding an anonymous browser (profile) and to develop one that is resilient to e.g. different fingerprinting attacks and tracking means in general.
Funding for user studies and breakage studies would be top of the list for me, esp if we're talking about tab-isolation, and browser/user behavior changes.
-
Georg Koppen -
Mike Perry -
Robert Ransom