Firefox getting smarter about third-party cookies | Hacker News Reader

Firefox getting smarter about third-party cookies

blog.mozilla.org

217 pointsgulbrandr100 comments

Well, trackers will just switch to using localstorage instead since the preference doesn't affect it [1] and it pops up no permission dialog.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=536509

It really seems like all the things browsers do to allow sites to persist data on your computer (cookies, client certificates, localStorage, WebSQL/IndexedDB, the FileSystem storage API, HTML5 Application Caching...) should all be controlled by a single set of preferences/request dialogs. They wouldn't even need to break down the requests by type; it's pretty irrelevant to a user which kind of storage is going on.

Combining this with a "forgiveness is better than permission" principle (which seems to be sorely lacking in web browsers, other than a few just-plain-strange places like alert() dialogs), the best UX might just be a warning bar stating "Example.com has reserved 1KB/5MB of your disk so it can remember its place. [Disallow]"

Disallowing would make the site think it still has a permanent store, but internally replace it with an ephemeral one (FS::TEMPORARY, session cookie, etc.) This also might make browser makers get off their lazy butts and make ephemeral versions of the rest of these mechanisms, to make this work ;)

What's wrong with a whitelist?

"Example.com has requested 1KB/5MB of your disk so it can remember its place. [Allow]"

Because almost every site uses cookies, and almost all cookies are friendly (not "tracking cookies.") It would be a large decrease in user convenience to make them have to accept every cookie ever.

Not only that, website owners are incentivized to actively subvert whitelist-based policies: shady sites would paint arrows up to the "Allow" button saying "click this to continue!", doing iframe AJAX ping-pong to verify you've given them the persistence they want before they let you through, and so forth.

And even if they didn't, the request would still become one of those things naive users think you just "have to click OK to if you want the computer to keep doing the thing"--like Windows UAC elevation.

On the other hand, giving users an equivalent option to a "hellban" on a website--the ability to make the website think it's persisting, but then it turns out not to be--has far fewer incentives. It only ends up being something you click for a reason, rather than a "mother may I" you have to just click all the time, and since getting off the blacklist wouldn't be exposed directly through the browser chrome, there'd be nowhere for a malicious site to "point an arrow."

"almost all cookies are friendly"

I would really dispute this. Compare the number of sites visited to the number of ad-tracking cookies stored in the average browser, I think you'll find a very different answer.

If you consider ad-tracking cookies set by sites {A,B,C} to be read by ad-provider X all "one cookie", then the numbers balance out. (Which I would--tracking cookies, semantically, should be considered to be stored in the ad-provider's "bucket", as far as allowing them/purging them goes.

If you consider ad-tracking cookies set by sites {A,B,C} to be read by ad-provider X all "one cookie"

I'm not really sure what you mean by this. You said "almost all cookies are friendly" and I'm pretty sure you're wrong. Even if the numbers 'balance out' (which I doubt very much) that's still not close to 'almost all cookies are friendly'.

The pro-cookie side of the privacy debate really needs to just admit there's a problem here, then we can work together to try and ensure privacy and functionality, without making reckless assumptions that somehow tracking is sanctioned or providing value to the user without even the courtesy of asking.

How about "almost all first-party cookies are friendly"?

This is pretty much what Chrome does, grouping everything under "site data". It also shows you flash cookies, though as far as I know, it doesn't show you its contents and doesn't let you block them through the third-party controls. A rather strange system.

Chrome gets about a 6/10 for this. Client certs, for at least one thing, aren't included in "site data" (it needs to be everything or it stops being an abstraction!); and for the mechanisms it does prompt for (only a few--again, making the abstraction leak), Chrome uses a whitelisting rather than blacklisting approach, which has the failure modes I mentioned in my other comment below.

You could still use the plain old browser web cache to track users. Send a unique image to each user with a long expiry time with an id embedded in it somewhere, then on the page, simply read the image using javascript/canvas to get the id.

> send a unique image ... with a long expiry time

For any given mechanism, if it has different behavior between an ephemeral session and a regular, persistent one, it should trigger the warning bar. Browser caching with distant Expires is definitely one of those. In this case, disallowing the persistence would make all the retrieved resources instead have session-length cache expiry.

Think of the full effect of the warning bar + "Disallow" button as going back and pretending you had opened the page in an Incognito/Private Browsing mode tab from the start--and then making that also happen automatically for any further pages from that domain. It session-isolates caching, cookies, and basically any other form of persistence except explicit bookmarking.

Merely making an HTTP request to a site -- any HTTP request, as far as I'm aware -- is sufficient for that site to set a cookie on your machine.

If on the other hand the site wants to store something in localstorage, the site has to run JS on your machine. That's a much higher bar.

It's a bit disingenuous to make such a claim. The bar is essentially the same since browsers execute all, 1st and 3rd-party JS by default. Loading a document is enough. For a web-browser it's quite rare to make requests without completing the transfer.

The bar is essentially the same and the changes that privacy-invading 3rd party scripts have to do to bypass the Firefox's implementation are minimal, so Mozilla may as well not make any triumphant claims until this glaring issue is fixed.

> The bar is essentially the same since browsers execute all, 1st and 3rd-party JS by default.

Not mine :-)

(But point taken)

Excellent. I know you, Mozilla guys, are on HN, so a question.

Any ETA for allowing to block Referer header from being included in cross-origin requests? If I'm on the page that pulls down something from Google Fonts, I see no reason why I should be sharing with Google the URL of the page I'm visiting.

But a request is still a request. It might not make sense to include referer data in the case you mentioned but that does not mean every cros request will fit that description.

Give me an example where sending a Referer is essential to providing me as a user with a better experience.

There are no such cases, period. Also, with an exception of dumb content protection schemes (anti-hot-linking), Referrers are used exclusively for tracking purposes and carry zero positive benefits for the users. If Mozilla is in fact "passionate about putting its users first", these headers must go. It is as simple as this.

How about newspapers that show articles when a user comes from Google but not otherwise?

How is that a better experience? This is a legitimate question, I don't think I understand what you're referring to.

I think he means that showing you an article is a better experience than not showing you an article.

Maybe he means cases where newspaper sites let users skip paywall if they are coming from google x times a month.

    Referrers are used exclusively for tracking purposes
    and carry zero positive benefits for the users.

This is short sighted. Sites can respond to referrers by improving themselves and better adapting to what users are looking for.

Sure, in theory.

Anti-hot-linking may be dumb to protect the content, but it's very useful to protect others from abusing sites as if they were free image hosters.

I run a small site, and we would occasionally get hotlinked by random people searching for images on Google, which would kill our bandwidth caps. If it weren't for referer filters, we'd have to hide any image for unregistered users.

That said, keep just first-party referers would be fine - we'd just block any image request without referer.

I don't think the referer info is ever really essential but here are some possibilities:

1) If you came from a social media site, maybe I'd highlight that particular social sharing option in a share bar, or hide others.

2) In an e-commerce store, maybe Google sent you to some page on my site that isn't really the best for your search term (product discontinued, other better matching product), I can give you a link to that other page. Google isn't necessarily magical in its ability to pick the best page on a site for a specific term. Maybe if you come from a competitor I can highlight some content that compares my product to the competitor's.

3) I've never derived a ton of benefit from it, but some sites will highlight your search term for you on a page. It could possibly also automatically scroll you to a relevant section if it's a long page and what you searched for is an exact match for some subsection.

In general it can be a valuable data point sites can use to improve the end-user experience. That being said, I can't think of anything where the value really outweighs the potential for abuse, but I think saying that it has no value to the user is short-sighted.

Isn't the Referrer header what Google Analytics et. al. use to tell you how people are finding pages on your site? Seems like that could be quite useful for a webmaster to learn more about his audience, tailoring his content to better fit the traffic coming from those sources and identifying other sites that might be abusive (e.g. scraping his content).

The ability to highlight search terms in a page.

You may disagree that is a better experience for you, but you may not make blanket statements that "there are no such cases, period".

You can use an addon like Smart Referer[1] (removes cross domain referer headers) but it does unpredictably break sites that depend on it.

Considering it requires whitelisting to avoid weird and hard to diagnose issues, it seems unlikely to be added to Firefox.

1. https://addons.mozilla.org/en-US/firefox/addon/smart-referer...

First, there are already multiple Firefox extensions that will let you totally control the Referer header. (In general, if there's something that you want to change about Firefox, you should search https://addons.mozilla.org to find a solution, because somebody's probably already created an extension that does what you want.) I think one such extension is called "RefControl."

I also brought up the issue on Mozilla's dev.privacy mailing list [1] recently. See:

https://groups.google.com/d/msg/mozilla.dev.privacy/wmPzPCdz...

In general, we cannot block the Referer header by default on cross-origin requests because we know that would break too many websites. My proposal is to strip the Referer header down to just the origin + '/', e.g. http://example.org/ instead of http://example.org/foo?search=whatever+you+searched+for.

I think it will be difficult for us to go further than that in the default configuration any time soon (and, as you can see in that thread, there's even some pushback to my extremely reasonable proposal).

Also, I know there is active work happening to bring extra control over the Referer header to Firefox's built-in prefs. This seems to be a little bit in conflict with our "Checkboxes that kill" project so I'm not sure how it will turn out.

[1] https://lists.mozilla.org/listinfo/dev-privacy

FWIW, I just followed your advice, searching Firefox Addons for "Referer". The results were not helpful at all for the goal abcd_f mentioned of blocking cross-site referrers. [Edit: Sorry, it looks like I mistyped "Referer". There is at least one promising addon on the first page.]

Also FWIW, I agree that this is indeed becoming a significant privacy issue. I too don't see why Google or Typekit or some widely used CDN should be gifted a convenient history of my web browsing just because they host popular JavaScript libraries or web fonts.

I'm intrigued by this comment:

In general, we cannot block the Referer header by default on cross-origin requests because we know that would break too many websites.

Is this because some of the third party resources are only authorised for use by certain sites and rely on Referer to establish whether a given request qualifies? Given that there is no security or verification for Referer headers, that seems like a rather broken model to start with.

I can't help thinking that if one of the big browsers forced the issue then those services would have to reconsider and do things a smarter way. That seems likely to inherently reduce the amount of unnecessary information being passed across to those third party services in the first place.

Is this not what you want? Third search result:

https://addons.mozilla.org/en-US/firefox/addon/smart-referer...

Sorry, you're right. I think I forgot to misspell "referrer" the first time I searched.

Ah I didn't even know that was a thing. I think I am so used to the misspelling that I didn't even realise - the only place I regularly come across the word is in reference to HTTP.

Here for anyone who didn't know: http://en.wikipedia.org/wiki/HTTP_referer#Origin_of_the_term...

> Is this because some of the third party resources are only authorised for use by certain sites and rely on Referer to establish whether a given request qualifies? Given that there is no security or verification for Referer headers, that seems like a rather broken model to start with.

It's just a first-order approximation to defend against hotlinking. Disabling referes wholesale has mostly worked out for me (via about:config, not an extension), but very rarely I have to turn them back on or switch to a backup browser profile or whatever.

But if you're linking to an image on your own site from your own site, the proposal not to send Referer headers across domains to third parties wouldn't do any harm.

In other words, if your interest is in blocking unauthorised hotlinking, can't you just assume anyone who doesn't include a Referer is equivalent to someone sending a Referer from a malicious site and decline the request?

Sure, that works in many cases. It's also fairly typical to host static-ish content on another domain though, in that case you would have to inspect the referer header, or otherwise conspire with your "main" domain.

RefControl is a nice addon for that, with ability to set default behaviour and override it for specific domains.

https://addons.mozilla.org/en-US/firefox/addon/refcontrol/

Any ETA for allowing to block Referer header from being included in cross-origin requests?

This feature has been supported in Firefox for a long time, but you have to set it in about:config via the "network.http.sendRefererHeader" integer.

  2 = always send
  1 = send only to same FQDN (what you seem to want)
  0 = never send

IMO this is one of the best bang-for-your-buck privacy configurations. I would love it if Mozilla changed the default from 2 to 1, and at the least, it SHOULD be an option under the Preferences -> Privacy tab.

There are lots of cases where third party cookies are used as auth tokens, not tracking tokens. Seems to me that the browser vendors should get together and come up with a better solution for browsers to store and manage auth tokens.

Right now it is done piecemeal by websites, but is confusing to end users. Having a direct, first-class API and UI in the browser that can show the user exactly what third party sites they are "logged into" and have a "Logout/Deauthorize" button next to them would be worthwhile, and have less of a chance of "breaking the web", or imposing workarounds that might hurt user experience.

BTW, how does Firefox treat a CORS XHR response? Does it allow a cookie to be set? Seems to be ad trackers could then just run a server that permits CORS, have a bit of JS that makes the request to opt it back in.

Isn't improved browser-level authentication handling (including not letting information leak via authentication) one of the things BrowserID is about?

Finally. Third party cookies provide almost zero value for users. Only use case is for log in on iframe-embedded apps such as Discus comment boards, but the ones you use yourself can be counted on one hand so adding exceptions isn't such a big issue. Adding some UI that shows that you are logged in to Discus on a particular web page would just good imo. I think the "From visited" option is an excellent trade off as a transition period until a better option for embedded authentication is available.

> Third party cookies provide almost zero value for users.

I don't like third party cookies either, but this is false. Your information is worth something to the right people. The websites you visit, mostly free, can make money off that information. The value to the user are free websites that provide you entertainment/content/etc... and are able to stay free because they are utilizing this as a revenue stream. We all know there are other ways, perhaps more moral ways, but to say it provides nothing to the user is false. It funds the websites you're visiting.

While that's often true, many (most?) users have no idea that they're making this deal (i.e. "I let you store your cookies on my computer and in return I get free stuff.").

The European "cookie law" has caused many websites to give better notice that they're planting cookies, but it's rarely clear how those cookies are being used.

There is a better way. What if I purposefully signaled my intent to potential sellers, rather than having them guess what I want (based on their data about me)? Amazon wish lists are an example (although they'd be better if I stored the list in a place of my choice, where I control who sees what, and I'm told who looks). For more on this idea, see:

http://en.wikipedia.org/wiki/Vendor_relationship_management

Let ad companies and ad supported SaS do what they are good at - Targeted ads. Target people who want the ads. Give those people the services of easy access to new products, and leave people who do not click on ads alone.

There is a simple answer to all this. Its called opt-in. If you need to harass and track users who do not want ads, then either the targeted ads are not targeted enough, or its a failed business model. Time to show which one it is.

what about in the context of a widget. I built a reservation widget and we used third party cookies to help keep your order available as you might load the widget on other sites. It was not an Ad, but for casino websites, they would have multiple domains one for each casino but shared the same reservation system... blocking third party cookies pretty much breaks the widget...

Safari has blocked third-party cookies for many years. I've never noticed any problems in real world use.

If you are already logged in to the casino site, authentication can be done through the query string to the iframe. .

I've browsed with 3'd party cookies disabled for years and very very rarely had any problem. I wouldn't say never, certain widgets do break, but those are less than one in a thousand. Only one i can recall from the top of my head is Discus.

For Discus, authenticating through the parent site will be an issue since one of the reasons for using Discus is to avoid many different logins.

I have been thinking about cookie sandboxing for a while:

The idea is to have a separate cookie store for each 2nd level domain I am visiting.

So the Facebook cookie on some site I am visiting that has a Facebook "Like" button on it is different from the actual Facebook cookie I would get from visiting Facebook.

This would make cookie tracking across sites unusable, since each site would have it's own version of a cookie.

I'm really enjoying the self-destructing cookies addon: https://addons.mozilla.org/en-us/firefox/addon/self-destruct... . It's really great to go to Facebook and see it have absolutely no idea who I am every time I go there. Plugin works very well.

Never heard of this one, and it looks really good. I'll try it right now. But will it still be useful with the new Firefox updates?

it should, it blacklists all sites by default to not persist cookies at all beyond having the window open.

Hi, I'm the author of this add-on. You might want to read the FAQ entry "Q: How is this different from disabling 3rd party cookies and installing Adblock?". Firefox's new 3rd party cookie policy is actually weaker than disabling them outright, so this will not change anything.

Back in the day, Firefox experimented with making third-party cookies session-only, but I believe this option was disabled because some websites using third-party login cookies required users to login every session.

Have you run into any problem websites with self-destructing cookies?

Disabling 3rd party cookies has never broken a single site for me. I've heard that some banks require them, though. As for Self-Destructing Cookies: it's a pretty drastic measure. Considering this, it's surprisingly compatible. Among the sites that I frequent, not a single one stopped working. Inter-domain transaction - e.g. a shop forwarding you to Paypal and back - used to be a problem, but the latest version has a heuristic for that. Still, I'm pretty sure that some people will experience fallout. You can work around that; SDC has numerous functions that can help in such cases (pause, undelete, whitelist for session).

Google is in the ad business making it tougher for them to go in this direction. Go Firefox

> Users of this build of Firefox must directly interact with a site or company for a cookie to be installed on their machine.

There are not many users that don't interact with google. While I don't expect the chrome team to add this to their feature list (even as optional), if they did, it would not really hurt google. It would actually hurt all the other "smaller" players.

Chrome will probably never make this the default, unfortunately. But, this is an option in Chrome.

Settings > Show Advanced > Privacy > Content settings... > Block third-party cookies and site data.

It's not exactly obvious, of course. :-)

This isn't exactly the same as blocking third-party cookies, and Firefox was capable of that since forever.

Firefox is going to accept third-party cookies only from sites that you already browsed before, kinda like Safari does it now.

It is my understanding that Google uses separate domains like doubleclick.net for serving ads, not google.com, so they won't gain any particular advantage there. Of course, that could change.

As I understand it, they serve those assets from the Google.com domain for safari and could do so for this.

>It would actually hurt all the other "smaller" players

Exactly. But it's not neccesary a bad thing though.

What all the "smaller players" in emerging retracking field - where 3rd party cookies are used in the first place - are doing now is nothing conceptually different from "ah, you've added iPhone to shopping cart at shopX! Now we'll show you iPhone ads for a week on every site you visit!". And user is beating her head against the wall because she bought the iPhone offile a week ago.

If 3rd party cookies will be disabled by default in significant part of browsers, all that players will need to find a ways to add some value visible to users and show it to them and convince them to enable 3rd party cookies manually because that will be just the only way to track them.

We don't know yet what that added value(s) could be, but I'm sure they will be invented. And that would be good thing.

You're right that these retargeting shops have a stupid thesis and can only exist because marketers' metrics haven't evolved enough yet (and that's changing). Highest purchase % doesn't mean you changed intent or created business, you just won the bidding war to show an ad to someone who was already going to buy, or maybe already bought.

But users will never manually enable 3rd party cookies, even if they agreed with you that the ads were adding value (which odds are they never will either).

Content has to be monetized in some way -- if not ads, then how?

All that blocking 3rd party cookies will accomplish is put most of the less technically-mature shops out of business while the smart ones figure out a way to route around using the exact same data science for targeting.

> Content has to be monetized in some way -- if not ads, then how?

Charge for it perhaps?

I guess. The NYT/WSJ are trying that already because they don't get enough from ads to do original reporting; ads can barely fund recycled opinion pieces from bloggers as a full-time job. Results are decidedly mixed.

>But users will never manually enable 3rd party cookies, even if they agreed with you that the ads were adding value

It depends. Maybe not the ads per se would be added value, will see anyway.

And by the way, ads may be the content on its own, don't you think? Ask anyone of 30+ mln people who had viewed last Pepsi&Jeff Gordon commercial on YouTube for example.

Is your criticism of retargeting based in experience? I'd love to hear more about it.

I work at a "retargeting shop" and our customers test the crap out of our tools to make sure we're actually driving results. Others may use more smoke and mirrors, but when done right, retargeting does in fact change user behavior and generate ROI.

Well, there are situations where retargeting makes a bit of sense, like selling business services on a low-traffic website.

But most e-commerce retargeting, IMHO, is trading on the fact that a naive marketing manager will put too much stock in a high conversion percentage. All of those people were, by definition, aware of the product and actively shopping. Did you create a customer? Probably not, maybe by virtue of them clicking the ad instead of going somewhere else, but that's still pretty zero-sum.

Prospecting for people who haven't previously clicked the item on your site, but would be interested, is a lot harder and potentially more valuable.

All IMHO of course.

sophisticated marketers have done hold-out tests with retargeting shown that it can drive incremental sales at a profitable roi. this includes big ecommerce brands.

granted not every viewthrough and clickhtrough conversion is driven by the advertising, but some definitely are and it is often profitable if a campaign is optimized and run well.

It could very easily be seen as a monopolistic move on their part if they were to move in that direction oddly enough.

This change will hurt small players in web advertising, but I suspect they are more likely to use shady tracking tactics than the big players. So fewer players consolidates user information, but I hope it makes those advertisers easier to track and regulate.

Indeed, they've been caught using a bug to bypass the same restrictions in iOS.

Does this affect Google Analytics (or any analytics software for that matter)? if so: How would a webmaster deal with that?

Google Analytics javascript runs on your domain and the cookies it uses are on your domain. So it should count as "first party" here.

Interesting. Isn't the website just telling to load the script from a Google server (which could count as 3rd party) and execute it?

It's loading from a 3rd party (with a 3rd-party HTTP request), but the script itself is run by the first party: scripts are owned by whichever page executes them, regardless of how that page conjured them up. That's why you can load jquery from a CDN without breaking lots of things, because jquery still "runs from" your domain, same as if it were hosted locally. Also a reason that you really need to trust the third-party host, because if you load malicious third-party JS, it runs from your domain.

Thanks, that's a neat little explanation and cleared a couple of things up for me :)

thanks for the cool explanation. That really filled in a few blanks in my understanding of the web.

There is no creation of cookies in the snippet you have to copy/paste on your website. So if some cookies are created they are not first party.

The snippet you paste is for our purposes equivalent to:

    <script src="http://www.google-analytics.com/ga.js">

Inside the script there are calls to cookie-dropping javascript functions. The browser makes no distinction between javascript loaded via a script tag from your domain, another domain, or simply inline, so any cookies it leaves or reads are "first party".

If they set cookies via HTTP on the request for www.google-analytics.com/ga.js, those would be "third party", and because google-analytics.com isn't a site anyone visits, the new firefox policy would reject them.

True, but two other big players in this space (Mixpanel and Kissmetrics) both use 3rd party cookies. Does anyone know how they plan to deal with this?

We use first party cookies and do not try to track people across websites which is what most ad networks actually do.

Hi,

Thanks for the clarification. Using 1st party cookies definitely weights Mixpanel over Kissmetrics in our eyes.

So this will be the end of remarketing? IMO remarketing is the best thing that has happened to advertisement online. It's a win-win-win situation for visitors, advertisers and publishers.

A win for me is not seeing advertising, at all, ever.

Targeted ads are not a win-win, they're creepy.

When it first came out, Chrome's killer app (to me) was performance and the lack of bloat that had infected Firefox at the time. However, FF can more than redeem itself by making privacy and allowing users to easily "go off the grid" its killer app.

This is good news for sites like Facebook that track users across multiple, unrelated sites.

Individual sites can still track you with third-party analytics tools by creating a CNAME (DNS alias) to a third-party tracking domain.

Curious for people that actively write way more JavaScript and deal with cookies more than I do:

Outside of Local Storage, is there still a loop-hole (though it defies user expectation) for ad retargeters (they must rely on third party cookies)? I feel, if not, that this will totally kill those businesses. I am neutral and just wondering if I am missing something.

Google was sued for using iframes to get around this so defying user expectation no matter the loop hole is quite dangerous.

HTTP ETags are probably the most widely used workaround for 3rd-party cookie blocking.

http://en.wikipedia.org/wiki/HTTP_ETag#Tracking_using_ETags

Not sure whether the Firefox folks have figured out a way to patch this workaround up or not.

I do think that retargeting businesses are in for a bit of pain given the headwinds re: third-party tracking across the US and world.

I have been blocking 3rd party cookies for years.

The only site that has ever had a problem was my local power company (aps.com). However, it was easy to get around because even though their site warned that 3rd party cookies were required, you could just click around it to pay your electrical bill.

I've never had a problem on any other sites that I use in at least five years, though I suspect it's been more than that.

Sounds like a superb idea. One thing though: surely this will leak my browsing history, albeit very slowly?

On balance it seems a net gain all the same.

Does anyone know what Chrome does for 1st party vs. 3rd party cookies? Are they doing this too yet?

We're following the issue closely and so far there's no indication Chrome will follow suit.

So this would essentially break all conversion tracking and the like done by advertisers, right?

We have an app that runs in an iFrame on another site (in a Google+ Hangout). Are the cookies in the iFrame going to be considered 3rd party cookies by this if they match the domain of the iFrame source?

I would expect so. From the sounds of it you may have to direct users to visit your site directly before this works.

The same issue will likely apply for Facebook apps that run inside of iframes... and I think these days that's all of them.

Firefox is getting better and better now. Great!

What's great is the mobile version of firefox also can turn off third-party cookies while the Chrome mobile has no such option.

How is this going to interact with plugins that cover similar ground (e.g. DoNotTrackMe, Ghostery)?

Reply on news.ycombinator.com