With or without Javascript
Tor Browser has a default policy of blocking third party cookies. Cookies can only be set or retrieved by request of domain in the URL bar, regardless of resource fetches from third party websites.
- "can news.com attach a cookie to my TBB session?"
- Yes. Cookies are an extension of the HTTP protocol. They do not require active script content on the page to function. Infact in many cases they are intentionally taken out of reach of javascript through the
HttpOnly tag that can be included when they're initially set, meaning these cookies cannot be accessed directly by javascript.
- "can food.com access a previously attached cookie from my TBB session?"
- Yes. Assuming the cookie hasn't expired (they have an expire date that's decided when they're first set) and you're using the same session (I.E. you haven't used New Identity) you will resend the cookies with every HTTP request.
- "can data.com connect news story X to recipe Y based on attached cookies from first two steps?"
- No. Cookies are bound to a hostname (and optionally a path on the hostname). news.com can set, and will be resupplied previously set, cookies for news.com, it will never see or set cookies for food.com or data.com. This is obvious when you consider the usage of cookies as a means of authentication, if evil.com could access cookies for bank.com then evil.com could use those to steal your login session and try to masquerade as you with bank.com.
So...with a fresh identity and javascript disabled, you visit news.com. news.com tries to set a cookie, it is successful. data.com (I am assuming this is what you're asking about) has some content embedded in news.com. data.com tries to set a cookie for data.com through news.com, it fails because it is a third party it also does not receive any previously set cookies for data.com because it is a third party and it cannot see the cookies for news.com for the same reason. food.com is the same. Furthermore, food.com and news.com both used distinct circuits because tor browser isolates circuits based on the first party domain. data.com cannot link food.com to news.com or any of them between each other assuming they only use cookies.
However...
Cookies are a long established, well studied, and overt session tracking mechanism. There are plenty of covert ways to use other mechanisms in browsers for tracking users and the simple scenario presented in the question doesn't reflect a realistic adversaryadvertiser.
With javascript enabled and a script controlled (or at least written) by data.com embedded on both food.com and news.com, it turns out it's possible for it to link these, thanks to XMLHTTPRequest.withCredentials = true;Correction: I created a test for this (because withCredentials seemed insane) by trying to use javascript to set and retrieve a cookie from a third party domain using this, it seems that the cookies policy overrules this and denies the third party setting or getting it.
There are ways news.com, data.com and food.com could collude to do this without javascript or cookies. I'm not going to try to exhaustively enumerate them here, that's left as an exercise for the reader. For the curious, there is a good overview of them in this document from the Chrome security team.
If you do not want to have your browsing on news.com, food.com, and data.com linked together use New Identity, that's what it's there for!
Updated to include XMLHTTPRequest.withCredentials
Updated to correct XMLHTTPRequest.withCredentials
