
Firefox getting smarter about third-party cookies - gulbrandr
https://blog.mozilla.org/privacy/2013/02/25/firefox-getting-smarter-about-third-party-cookies/
======
ferongr
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>

~~~
derefr
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 ;)

~~~
mike-cardwell
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.

~~~
derefr
> 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.

------
abcd_f
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.

~~~
briansmith
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...](https://groups.google.com/d/msg/mozilla.dev.privacy/wmPzPCdzIU8/Vrugn8XquL4J)

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>

~~~
Silhouette
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.

~~~
ben0x539
> 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.

~~~
Silhouette
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?

~~~
ben0x539
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.

------
cromwellian
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.

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

------
Too
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.

~~~
chez17
> 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.

~~~
troymc
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>

------
mortenlarsen
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.

------
zzzeek
I'm really enjoying the self-destructing cookies addon:
[https://addons.mozilla.org/en-us/firefox/addon/self-
destruct...](https://addons.mozilla.org/en-us/firefox/addon/self-destructing-
cookies/) . 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.

~~~
baby
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?

~~~
ove
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.

~~~
cpeterso
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?

~~~
ove
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).

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

~~~
uulbiy
> 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.

~~~
snaky
>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.

~~~
jbooth
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.

~~~
brandnewlow
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.

~~~
jbooth
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.

~~~
tpiddy
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.

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

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

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

~~~
mjn
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.

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

------
Kiro
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.

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

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

------
Apocryphon
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.

------
adorton
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.

------
suhail
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.

~~~
pixelmonkey
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.

------
jmomo
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.

------
JonnieCache
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.

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

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

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

------
silverlight
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?

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

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

------
chick
Firefox is getting better and better now. Great!

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

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

