Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

partial third-party cookie blocking

2,501 views
Skip to first unread message

Sid Stamm

unread,
Jan 14, 2013, 1:24:23 PM1/14/13
to
Jonathan Mayer has implemented a halfway-block feature for third party
cookies.

Right now, Firefox can only block BOTH { setting + getting } of third
party cookies, so we can't turn it off by default. At least one other
browser has something about half-way that allows the getting of cookies
in third party contexts (but blocks setting). The effect is that sites
you visit directly can set cookies, but sites you don't visit directly
cannot.

Anyway, I think we should ship this feature. I think we should ship it
enabled by default, but we need to do a few things first:

1. Write the code (almost done)
2. Make sure users know the difference between this and full-strength
third-party cookie blocking.
3. Make sure it doesn't cause too much breakage in the web experience.

jmayer is working hard on the code. There's a reasonable UI in the bug
that teases out accepting cookies "from visited" as a new feature.

https://bugzilla.mozilla.org/show_bug.cgi?id=818340

We are working on a test pilot study around cookies that might help us
get a good picture of how much is going to break when we turn this on.
If anyone out there has some data that can educate this, I'd appreciate
it. :)

-Sid

Benjamin Smedberg

unread,
Jan 14, 2013, 2:57:20 PM1/14/13
to dev-p...@lists.mozilla.org
>
> Right now, Firefox can only block BOTH { setting + getting } of third
> party cookies, so we can't turn it off by default. At least one other
> browser has something about half-way that allows the getting of cookies
> in third party contexts (but blocks setting). The effect is that sites
> you visit directly can set cookies, but sites you don't visit directly
> cannot.
* What other browser is doing this?
* What is considered "third-party" in this context? e.g. are iframes
third-party?
* What will the behavior be when this kind of content attempts to set a
cookie? Will it silently fail, or throw errors?
* I know we tried this once before with some kind of dual-key cookie
setup. How is this proposal different and are we confident that we
solved the problems that killed the first attempt?

>
> 2. Make sure users know the difference between this and full-strength
> third-party cookie blocking.

You're talking about the 0.1% users? I can't imagine most users care.

Do you plan on flipping the default pref immediately after the code
lands, or wait a cycle to shake out regressions and flip the default at
the beginning of the next cycle?

--BDS

Sid Stamm

unread,
Jan 14, 2013, 4:42:13 PM1/14/13
to Benjamin Smedberg
On 1/14/13 11:57 AM, Benjamin Smedberg wrote:
> * What other browser is doing this?

Safari does this for all its users by default (that's suggested by the
title of the bug, https://bugzilla.mozilla.org/show_bug.cgi?id=818340).
They've been doing it for quite some time now.

> * What is considered "third-party" in this context? e.g. are iframes
> third-party?

Same as for our existing cookie stuff. Things that are different origin
than the top level document.

> * What will the behavior be when this kind of content attempts to set a
> cookie? Will it silently fail, or throw errors?

Silently fail. We could toss an error in the web console, but I'm not
convinced we need to add more messages there. To the web server it will
seem as if the Set-Cookie header was lost in transmission.

> * I know we tried this once before with some kind of dual-key cookie
> setup. How is this proposal different and are we confident that we
> solved the problems that killed the first attempt?

This is different. This won't affect cookies for sites that already set
a cookie on the browser. For example, I visit a.com (get a cookie),
then visit b.com that includes a.com content. a.com is a third party,
but since I already have a cookie it gets to set/get cookies in a third
party context. If b.com has another third party reference to c.com, but
I don't have c.com cookies, get/set cookies doesn't work for c.com.

>> 2. Make sure users know the difference between this and full-strength
>> third-party cookie blocking.
>
> You're talking about the 0.1% users? I can't imagine most users care.

Good point. I guess it would make sense to at least gut-check the UI
changes somehow.

> Do you plan on flipping the default pref immediately after the code
> lands, or wait a cycle to shake out regressions and flip the default at
> the beginning of the next cycle?

I'd like to land the code and change the default to this new state at
the same time, but if you think we need to let it stew for a while
before flipping the pref, we could probably do that too.

-Sid

Sid Stamm

unread,
Jan 31, 2013, 2:09:16 PM1/31/13
to bre...@mozilla.org
In the bug, Brendan posted:

https://bugzilla.mozilla.org/show_bug.cgi?id=818340#c32

> Does anyone know what the effect of this is on the average user?
>
> Obviously third-party cookie surveillance is a privacy concern --
> Mozilla built Collusion to show how many tracking entities there are,
> and how they relate. But the current commerce patterns on the web
> depend on cookies, with some user benefits as well as costs and
> risks.
>
> Yes, I'm saying targeted ads based on cookies that this patch would
> block are sometimes a new win for some users. Maybe not enough to
> justify the downside, but who knows? I do not. I see no one on this
> bug trying to assess.
>
> I personally want us to get to a better, user-centric model that
> supports ads and commerce without tracking by parties engaged in
> non-transparent business practices. Users ideally should be able to
> opt into a self-profiling system, client-based and highly private
> (after all, we already keep your history, you trust Firefox to keep
> this information private), that can selectively disclose abstracted
> or even (depending on to whom) precise/concrete information that
> helps give the user more value than today's cookie-based world.
>
> Given such a system, I'd even want something like: opt into this
> better "user profiling" agent and at the same time turn off all
> third-party cookies.
>
> There are tons of ways to track users, of course. See
> http://www.businessinsider.com/facebooks-plan-to-kill-the-tracking-cookie-2013-1
> and look past the hype that implies cookies won't work. We don't want
> to start an arms race or play whack-a-mole. But in order to move the
> debate to a better place, we need innovation.
>
> Without something innovative, such as the better user agent with
> opt-in disclosure to select second parties, we risk "escalation" --
> ultimately to regulators who can't innovate. Regulators under
> political pressure tend to simply freeze existing structures, locking
> in incumbents.
>
> Speaking of advantaging the incumbents, this patch won't touch
> existing cookie stores chock-full of already-set, long-lived
> third-party cookies, right? That doesn't seem great on its face even
> if this patch makes life better with respect to third-party cookies
> the user might face in the future.
>
> We need a newsgroup thread or better to discuss this further, unless
> I've missed an analysis of what the impact of this patch on Firefox
> users in the large, especially loss of useful ads (if such exist),
> might be.
>
> /be


Sid Stamm

unread,
Jan 31, 2013, 2:27:09 PM1/31/13
to bre...@mozilla.org, Monica Chew
Hi Brendan,

>> Yes, I'm saying targeted ads based on cookies that this patch would
>> block are sometimes a new win for some users. Maybe not enough to
>> justify the downside, but who knows? I do not. I see no one on this
>> bug trying to assess.

I'm not convinced this is entirely about targeted ads. To me it's about
opaque profile building without consent or obvious user benefit. I
don't mind targeted ads, but I am not comfortable with companies I've
never heard of knowing where I browse.

In parallel to this work, mmc is developing a test pilot study to better
understand how third party cookies are used. I think testing this in
nightly to see what breaks is valuable, though from the use cases I've
looked at things like SSO and Facebook Connect (when I'm logged in) and
the like will all continue to work.

>> I personally want us to get to a better, user-centric model that
>> supports ads and commerce without tracking by parties engaged in
>> non-transparent business practices. Users ideally should be able to
>> opt into a self-profiling system, client-based and highly private
>> (after all, we already keep your history, you trust Firefox to keep
>> this information private), that can selectively disclose abstracted
>> or even (depending on to whom) precise/concrete information that
>> helps give the user more value than today's cookie-based world.
>>
>> Given such a system, I'd even want something like: opt into this
>> better "user profiling" agent and at the same time turn off all
>> third-party cookies.

Yes, this would be fantastic! I think in the short term, we should try
to make our Firefox defaults live up to users expectations. Simply
based on how collusion was received, people are frequently shocked at
the sheer number of sites that cookie them. This makes me think it's
reasonable to believe that users expect cookies from sites they visit
and not from sites they don't (because they may not know these sites
exist).

>> There are tons of ways to track users, of course. See
>> http://www.businessinsider.com/facebooks-plan-to-kill-the-tracking-cookie-2013-1
>>
>> and look past the hype that implies cookies won't work. We don't want
>> to start an arms race or play whack-a-mole. But in order to move the
>> debate to a better place, we need innovation.
>>
>> Without something innovative, such as the better user agent with
>> opt-in disclosure to select second parties, we risk "escalation" --
>> ultimately to regulators who can't innovate. Regulators under
>> political pressure tend to simply freeze existing structures, locking
>> in incumbents.

My opinion is that we're already there; I feel like there's significant
pressure to do something about cookies so their use doesn't get
specifically regulated.

>> Speaking of advantaging the incumbents, this patch won't touch
>> existing cookie stores chock-full of already-set, long-lived
>> third-party cookies, right? That doesn't seem great on its face even
>> if this patch makes life better with respect to third-party cookies
>> the user might face in the future.

Many people clear cookies regularly because they've been told it's the
"safe" thing to do. My mom does this even though I never told her to --
I think she got it from the local news. But you're right, for old
profiles, the leftovers minimize benefit. I don't think anyone is
suggesting this feature is perfect, but rather fairly simple to
implement and a step in the right direction.

-Sid

jduell...@gmail.com

unread,
Jan 31, 2013, 2:46:24 PM1/31/13
to bre...@mozilla.org, Monica Chew
On Thursday, January 31, 2013 11:27:09 AM UTC-8, Sid Stamm wrote:
>
> I'm not convinced this is entirely about targeted ads. To me it's about
> opaque profile building without consent or obvious user benefit. I
> don't mind targeted ads, but I am not comfortable with companies I've
> never heard of knowing where I browse.

Am I correct to think that one effect of this patch would be that it would encourage centralization of the cookie tracking industry into the Big Players (Google/Yahoo/Facebook/etc), who would become the only sites practically capable of setting 3rd party cookies to a near-universal user base? With attendant interesting/ambiguous tradeoffs (fewer players mean it's easier for government to regulate practices, etc).

Jason

Brendan Eich

unread,
Jan 31, 2013, 4:06:25 PM1/31/13
to Sid Stamm, dev-p...@lists.mozilla.org, Monica Chew
Sid Stamm wrote:
> Hi Brendan,
>
>>> Yes, I'm saying targeted ads based on cookies that this patch would
>>> block are sometimes a new win for some users. Maybe not enough to
>>> justify the downside, but who knows? I do not. I see no one on this
>>> bug trying to assess.
>
> I'm not convinced this is entirely about targeted ads.

No "entirely", agreed. But "partially", right? E.g., Doubleclick (Google).

> To me it's about opaque profile building without consent or obvious
> user benefit. I don't mind targeted ads, but I am not comfortable
> with companies I've never heard of knowing where I browse.

Who is in favor of that, when stated that way? Yet that's the web and
its commerce-patterns we all use, and "good tracking" and "bad tracking"
are muddled (assuming there is "good tracking") because both involve
cookies set by sites I've never visited (I have never been to
doubleclick.com).

How do you know this patch won't regress the net-win outcome for too
many users? I simply do not know, hence my concern.

> In parallel to this work, mmc is developing a test pilot study to
> better understand how third party cookies are used. I think testing
> this in nightly to see what breaks is valuable, though from the use
> cases I've looked at things like SSO and Facebook Connect (when I'm
> logged in) and the like will all continue to work.

That is important to validate. It also seems different from what
happened "last time" (three years ago? dwitte's work, but my memory may
be failing me). Who will test thoroughly and report back?

/be

lada...@mozilla.com

unread,
Jan 31, 2013, 7:01:50 PM1/31/13
to
What granularity will be applied to the setting heuristic? What I mean by that is:
a) I visit www.socialnetwork.com, they try to set a cookie from api.socialnetwork.com. Does this succeed?
b) I visit www.randomblog.com that includes a +1billion button from api.socialnetwork.com. Does that work, since I never visited api.socialnetwork.com directly?
c) What about banking websites that embed 3rd party payment / clearing providers in iframes? You'll never visit those 3rd parties directly, yet they are essential to user interaction on important site. Vis a vis Safari, last time I tried visiting one of these in Safari I got an error that Safari was not a supported browser. :/
Lucas.

Monica Chew

unread,
Jan 31, 2013, 8:03:53 PM1/31/13
to jduell mcbugs, dev-p...@lists.mozilla.org
I think it's true that for every counter-measure, there will be
counter-counter-measures attempted, including switching to local
storage that's equivalent to cookies but not controlled by cookie
prefs, using redirects to bypass the 1st party restrictions, and
what you mentioned.

Does that mean we should never try partial solutions? I don't think so.

Monica

Jonathan Mayer

unread,
Jan 31, 2013, 8:17:13 PM1/31/13
to
Jason,

The impact will assuredly vary by an online business's size, sector,
and implementation. Google, for example, hosts many of its third-
party services from dedicated domains (e.g. doubleclick.net and google-
analytics.com). Those services would not get a free pass under the
new cookie policy. Facebook, on the other hand, hosts most of its
third-party services from facebook.com. It would not be so limited.

The aim of this new cookie policy is to better conform to user trust
and desired functionality. It's certainly not perfect, and I would be
glad to participate in future efforts to both better reflect general
preferences and facilitate individual customization. In the interim,
I think the new policy is plainly an improvement over the status quo.

Best,
Jonathan

Jonathan Mayer

unread,
Jan 31, 2013, 8:46:21 PM1/31/13
to

On Jan 31, 4:01 pm, ladam...@mozilla.com wrote:
> What granularity will be applied to the setting heuristic?  What I mean by that is:
> a) I visitwww.socialnetwork.com, they try to set a cookie from api.socialnetwork.com.  Does this succeed?

Yes. This would succeed under both the old and new cookie blocking
features. The test for whether a domain is third-party is a
comparison of public suffix + 1 (see mozIThirdPartyUtil).

> b) I visitwww.randomblog.comthat includes a +1billion button from api.socialnetwork.com.  Does that work, since I never visited api.socialnetwork.com directly?

The button should display and click as usual. If the user has never
visited socialnetwork.com or any subdomain (to be precise, if the user
has never received a cookie from socialnetwork.com or any subdomain),
then the button would not be able to set cookies.

> c) What about banking websites that embed 3rd party payment / clearing providers in iframes?  You'll never visit those 3rd parties directly, yet they are essential to user interaction on important site.  Vis a vis Safari, last time I tried visiting one of these in Safari I got an error that Safari was not a supported browser. :/

I haven't come across Safari-incompatible content in years, presumably
owing in some measure to the popularity of iOS devices. At any rate,
it's certainly true that services that require measures to accomodate
Safari would have to extend those measures to Firefox.

>   Lucas.

Bil Corry

unread,
Feb 1, 2013, 3:56:52 PM2/1/13
to Jonathan Mayer, dev-p...@lists.mozilla.org
On Feb 1, 2013, at 2:52 AM, "Jonathan Mayer" <jma...@stanford.edu> wrote:

> I haven't come across Safari-incompatible content in years, presumably
> owing in some measure to the popularity of iOS devices. At any rate,
> it's certainly true that services that require measures to accomodate
> Safari would have to extend those measures to Firefox.

What you refer to as "measures to accomodate" was referred to earlier by Monica as "counter-counter-measures".

If a website works around the Safari cookie limitation in some manner to make the website usable for Safari users, is the website being accomodating, or is it deploying a counter-counter-measure?


- Bil

Bil Corry

unread,
Feb 1, 2013, 4:42:07 PM2/1/13
to Jonathan Mayer, dev-p...@lists.mozilla.org
The reason Google uses dedicated hosts is to keep content segregated so that a compromise in one service doesn't impact all of them.

Dedicated hosts also allows a company to outsource some portion of their web infrastructure without having to give the vendor control over a sub-domain of the main web property.

If Google and others decide, for competitive reasons, to consolidate their services to a single domain, it'll represent a step back in security.

I wonder what other trade-offs and long-term consequences there are for adopting the Safari cookie behavior.


- Bil

Brendan Eich

unread,
Feb 1, 2013, 5:15:34 PM2/1/13
to
On Jan 31, 5:17 pm, Jonathan Mayer <jma...@stanford.edu> wrote:
> In the interim,
> I think the new policy is plainly an improvement over the status quo.

Evidence? This is going to be tough to demonstrate except by large-
scale user testing and careful bug-report and support-call screening.

It is good to have Safari blazing this trail, but sites do stupid user-
agent sniffing and Firefox users could suffer painful loss of service
until such server-side code is fixed. That can take a while, since the
pain is felt most by the early adopters, whose cohort size is small.

/be

Brian Smith

unread,
Feb 1, 2013, 6:17:08 PM2/1/13
to Sid Stamm, bre...@mozilla.org, dev-p...@lists.mozilla.org
Sid Stamm wrote:
> In the bug, Brendan posted:
> > There are tons of ways to track users, of course. See
> > http://www.businessinsider.com/facebooks-plan-to-kill-the-tracking-cookie-2013-1
> > and look past the hype that implies cookies won't work. We don't
> > want to start an arms race or play whack-a-mole. But in order to
> > move the debate to a better place, we need innovation.

I understand this part as arguing that, basically, cookies are the devil we know, and it's better to deal with the devil we know than the devil we don't know.

I think it would be straightforward to say that in any case we block cookies, we must block the localStorage/IndexedDB/etc. counterpart. But, there are several other mechanisms for tracking users including fingerprinting, HTTP ETags, etc. Blocking tracking based on those alternative techniques is difficult and potentially has a lot of collateral damage in the product, such as reduced functionality and/or reduced performance. We've seen that multiple module owners have objected to even having a pref to enable various higher-privacy/worse-functionality settings, for good reasons. I think it makes sense to be concerned that we will end up backing ourselves into a corner by pushing ad networks to use mechanisms that we will never be able to block.

> > Speaking of advantaging the incumbents, this patch won't touch
> > existing cookie stores chock-full of already-set, long-lived
> > third-party cookies, right? That doesn't seem great on its face
> > even if this patch makes life better with respect to third-party
> > cookies the user might face in the future.

I think this is just a quality-of-implementation issue with the patch. I think this concern can be resolved in a reasonable way.

> > We need a newsgroup thread or better to discuss this further,
> > unless I've missed an analysis of what the impact of this patch
> > on Firefox users in the large, especially loss of useful ads
> > (if such exist), might be.

I don't know about "useful ads," but I do think that Jason Duell made a very good point in his message. This kind of change gives a huge advantage to Google, Facebook, Twitter, and other giants, because they would become *the* sites that could set cookies. Meanwhile, ad networks like The Deck (http://decknetwork.net/) will be penalized. But, is The Deck really the type of network that people are really concerned about? Aren't people more concerned about Facebook and Google, who not only track them, but know exactly who they are, who they socialize with, the contents of their personal messages, what they've done in the real world, and what they plan to do in the future in the real world?

Also, do we think that Apple was 100% altruistic in its blocking of third-party cookies? It seems to me that that choice is also the most financially profitable for them, because it puts Apple more in charge of advertising in Safari and on the iPhone. In fact, Google would also benefit from implementing this policy in Chrome, since they end up loading stuff from Google at startup, so they will nearly always be able to set a first-party cookie right away. Same with Microsoft and Bing. (BTW, Chrome doesn't *directly* implement any special optimizations to make google.com faster than other sites. However, many of the optimizations it does do are most effective for google.com due to the various ways that the Google website is set up to be the default for various things in the browser.)

My interpretation of Brendan's comments is that we're about to hit a bunch of sites (often, it seems, the wrong sites) with a big stick, and we should make sure we are willing to deal with the fallout of that before we start swinging. I agree with that. But, also, we cannot be paralyzed by fear of the worst-case scenerios.

Sid suggested I post my thoughts here in case others found them to be helpful. but, I haven't researched this issue in enough detail to help make the go/no-go decision here. Please let me know if there is anything I can do to help.

Cheers,
Brian

Brendan Eich

unread,
Feb 1, 2013, 8:06:18 PM2/1/13
to Brian Smith, bre...@mozilla.org, Sid Stamm, dev-p...@lists.mozilla.org
Brian Smith wrote:
> Sid Stamm wrote:
>> In the bug, Brendan posted:
>>> There are tons of ways to track users, of course. See
>>> http://www.businessinsider.com/facebooks-plan-to-kill-the-tracking-cookie-2013-1
>>> and look past the hype that implies cookies won't work. We don't
>>> want to start an arms race or play whack-a-mole. But in order to
>>> move the debate to a better place, we need innovation.
>
> I understand this part as arguing that, basically, cookies are the devil we know, and it's better to deal with the devil we know than the devil we don't know.

No, this was the part where I (started to) argue we need innovation
beyond cookies.

As stated plainly in the bug comment and here, I simply do not know
whether the patch will bite back for enough users that it hurts more
than it helps. Do you?

See my more recent bug comment, though
(https://bugzilla.mozilla.org/show_bug.cgi?id=818340#c37). I'm
notionally in favor of the patch, provided we deal with possible
problems here if possible, and via telemetry and other monitoring
post-landing.

> I think it would be straightforward to say that in any case we block cookies, we must block the localStorage/IndexedDB/etc. counterpart. But, there are several other mechanisms for tracking users including fingerprinting, HTTP ETags, etc.

There are a great number of possible tracking hacks. You've heard about
the personalized document.lastModified hack?

> Blocking tracking based on those alternative techniques is difficult and potentially has a lot of collateral damage in the product, such as reduced functionality and/or reduced performance. We've seen that multiple module owners have objected to even having a pref to enable various higher-privacy/worse-functionality settings, for good reasons. I think it makes sense to be concerned that we will end up backing ourselves into a corner by pushing ad networks to use mechanisms that we will never be able to block.

That's a good point, and one raised before. How do we know we won't
start an arms race, though?

I think it's better to provide a peaceful alternative. Client-side
(private cloud, if good for back-up) innovation should provide something
much better for both users and commercial players that operate
transparently and in their customers' interests, generally speaking.

My hope is we have enough time to do both: a bit of escalation with the
proposed patch, a good chunk of innovation on the user agent side.

>>> Speaking of advantaging the incumbents, this patch won't touch
>>> existing cookie stores chock-full of already-set, long-lived
>>> third-party cookies, right? That doesn't seem great on its face
>>> even if this patch makes life better with respect to third-party
>>> cookies the user might face in the future.
>
> I think this is just a quality-of-implementation issue with the patch. I think this concern can be resolved in a reasonable way.

How can the patch tell, by looking only at the cookie store, whether the
user has visited such a site? History may not be reliable. What's the
quality-of-impl fix?

>>> We need a newsgroup thread or better to discuss this further,
>>> unless I've missed an analysis of what the impact of this patch
>>> on Firefox users in the large, especially loss of useful ads
>>> (if such exist), might be.
>
> I don't know about "useful ads," but I do think that Jason Duell made a very good point in his message. This kind of change gives a huge advantage to Google, Facebook, Twitter, and other giants, because they would become *the* sites that could set cookies.

Google does not set tracking cookies from google.com, rather
doubleclick.net or whatever it is. A site I never visit. So I'm not sure
what you write here is true, but in general, "escalation" risks
incumbents becoming advantaged.

> Meanwhile, ad networks like The Deck (http://decknetwork.net/) will be penalized. But, is The Deck really the type of network that people are really concerned about? Aren't people more concerned about Facebook and Google, who not only track them, but know exactly who they are, who they socialize with, the contents of their personal messages, what they've done in the real world, and what they plan to do in the future in the real world?

Yup.

> Also, do we think that Apple was 100% altruistic in its blocking of third-party cookies?

LOL, who ever said such a thing!

> It seems to me that that choice is also the most financially profitable for them, because it puts Apple more in charge of advertising in Safari and on the iPhone. In fact, Google would also benefit from implementing this policy in Chrome, since they end up loading stuff from Google at startup, so they will nearly always be able to set a first-party cookie right away.

See above -- there's a good wall at Google between search and
advertizing. Different eTLD+1 names, different business units.

> My interpretation of Brendan's comments is that we're about to hit a bunch of sites (often, it seems, the wrong sites) with a big stick, and we should make sure we are willing to deal with the fallout of that before we start swinging. I agree with that. But, also, we cannot be paralyzed by fear of the worst-case scenerios.

Agreed. We need data. What we can't get in advance, or via TestPilot, we
will have to get via Telemetry, and keep our eyes on.

> Sid suggested I post my thoughts here in case others found them to be helpful. but, I haven't researched this issue in enough detail to help make the go/no-go decision here. Please let me know if there is anything I can do to help.

Thanks for posting. Have you done any custom telemetry work? Just asking
;-).

/be

Devdatta Akhawe

unread,
Feb 1, 2013, 9:11:13 PM2/1/13
to Brendan Eich, Brian Smith, bre...@mozilla.org, Sid Stamm, dev-p...@lists.mozilla.org
> See my more recent bug comment, though
> (https://bugzilla.mozilla.org/show_bug.cgi?id=818340#c37). I'm notionally in
> favor of the patch, provided we deal with possible problems here if
> possible, and via telemetry and other monitoring post-landing.

The first email was about turning this on by default. I suggest
landing with default off, and measuring the breakage if we had turned
it on by default. This can give us some data on whether we should turn
it on.


--dev

Brian Smith

unread,
Feb 1, 2013, 9:34:17 PM2/1/13
to Brendan Eich, bre...@mozilla.org, Sid Stamm, dev-p...@lists.mozilla.org
Brendan Eich wrote:
> Brian Smith wrote:
> No, this was the part where I (started to) argue we need innovation
> beyond cookies.

Yes, I think everybody agrees on this, based on lunch discussions with the people working on anti-tracking features.

> As stated plainly in the bug comment and here, I simply do not know
> whether the patch will bite back for enough users that it hurts more
> than it helps. Do you?

No, I don't know. That's what I was trying to say at the end of my email.

> That's a good point, and one raised before. How do we know we won't
> start an arms race, though?

I think we will definitely start an arms race. The only question is the scope of it.

> My hope is we have enough time to do both: a bit of escalation with
> the proposed patch, a good chunk of innovation on the user agent
> side.

Sure. This would require us to consider the needs of advertisers to a similar extent that we consider the needs of other web developers. I suspect this is something that will be easy enough for us to agree to try, but I also suspect that the process will be pretty difficult and painful.

> >>> Speaking of advantaging the incumbents, this patch won't touch
> >>> existing cookie stores chock-full of already-set, long-lived
> >>> third-party cookies, right? That doesn't seem great on its face
> >>> even if this patch makes life better with respect to third-party
> >>> cookies the user might face in the future.
> >
> > I think this is just a quality-of-implementation issue with the
> > patch. I think this concern can be resolved in a reasonable way.
>
> How can the patch tell, by looking only at the cookie store, whether
> the user has visited such a site? History may not be reliable. What's
> the quality-of-impl fix?

The people working on this feature can probably come up with a better fix. But, my off-the-top-of-my-head suggestion is that we could do something like the following:

1. Every cookie already stored in the cookie database defaults to being third-party-only.
2. Every time we visit a site, mark all stored cookies that should be considered first-party for that site as not-third-party-only.
3. Don't add any new third-party-only cookies.
4. At some point in the future, remove all the third-party-only cookies.

This relies somewhat on the fact that the internet basically works on the assumption that cookies are ephemeral; every site has to deal with cookies expiring and/or being deleted anyway. The length of time we wait to purge old third-party-only cookies could be very short without destroying the world. But, it would probably be good to have a large window (months?) to make this change as transparent to users as possible.

BTW, it is tempting to try to find a way to do this using just by playing with the expiration times of the cookies. An exercise for readers, perhaps.

> > I don't know about "useful ads," but I do think that Jason Duell
> > made a very good point in his message. This kind of change gives a
> > huge advantage to Google, Facebook, Twitter, and other giants,
> > because they would become *the* sites that could set cookies.
>
> Google does not set tracking cookies from google.com, rather
> doubleclick.net or whatever it is. A site I never visit. So I'm not
> sure what you write here is true, but in general, "escalation"
> risks incumbents becoming advantaged.

[...]

> See above -- there's a good wall at Google between search and
> advertizing. Different eTLD+1 names, different business units.

Yes, but let's third-party advertising on the web is eliminated completely by blocking third-party cookies in this way. It would hurt Google but it also helps them, because then advertising on google.com (and Facebook, Twitter, etc.) becomes more of a necessity for advertisers, and thus more valuable/profitable. And, other sites get less revenue and/or incur larger costs for setting up their own first-party ad systems. And, at any time, the big players (Google, et al.) can just change their policies to allow more sharing of information between their business units to enable their own third party ad programs to function as though none of this never happened.

I am only one person, but the tracking that bothers me most is this kind of tracking that is so closely linked with my real-world identity, like what the +1, Facebook Like, and Tweet This buttons are doing. And, those are being served generally from the same eTLD+1 as the main properties of those companies. Also, we shouldn't read too much into "same eTLD+1" because two "unrelated" domains can still share information, at least when you visit the main property.

> Thanks for posting. Have you done any custom telemetry work? Just
> asking ;-).

I think there are people working on this feature who know how to do the telemetry work already. I will be glad to help them if they need it, though.

Cheers,
Brian

Sid Stamm

unread,
Feb 7, 2013, 11:45:19 AM2/7/13
to Devdatta Akhawe, Brendan Eich, Brian Smith, bre...@mozilla.org
This makes sense if we are convinced it is very likely to cause problems
resulting in it being disabled. I don't think this is the case and we
don't gain much by pushing it to nightly and waiting for telemetry
numbers to come in. We should just push it to nightly and take the tiny
risk that we have to push a two-liner to pref it off.

We should still gather telemetry (especially as bsmith says, to gather a
baseline), but we can get preliminary/informal testing done NOW while we
work on the telemetry patch. This is why we have our multi-channel
release model: bake time. Lets use it.

-Sid

Jonathan Mayer

unread,
Feb 7, 2013, 8:21:21 PM2/7/13
to Devdatta Akhawe, Brendan Eich, Brian Smith, bre...@mozilla.org
In the interest of efficiency, I'm drawing together a few on- and off-list points.

* Doesn't this cookie policy have some false positives and negatives?

For sure. Some instances of third-party tracking (e.g. Twitter buttons) aren't always covered, and some unobjectionable practices (e.g. iframed Facebook apps) may be covered. There's plenty of follow-on work to do in evaluating and improving the policy. In the interim, we shouldn't let the perfect be the enemy of the good.

* Won't third-party trackers just work around the new cookie policy?

Websites that circumvent the new cookie policy may face serious legal consequences, including Federal Trade Commission enforcement and private litigation.

* Didn't Apple implement Safari's cookie policy to mess with its competitors?

The feature dates back to Safari 1.0, which launched in 2003. It wasn't an anti-Google move. At any rate, I don't think Apple's motives should have much influence on the Mozilla community's decision making :)

* What if we land the new policy but disable it by default?

Sid addressed this, and I share his views. I would add that one of the very reasons for providing a relaxed cookie policy is to allow enabling it by default.

Jonathan

Corry, Bil

unread,
Feb 8, 2013, 5:16:59 AM2/8/13
to Jonathan Mayer, Brian Smith, bre...@mozilla.org, Brendan Eich, dev-p...@lists.mozilla.org, Devdatta Akhawe
While the below appears well-reasoned, the issue is it's framed entirely around privacy.

Developers building a web application rely on cookies to maintain state, and when the browser doesn't appear to work properly, they consider it damage and route around it.

What you refer to as "circumvention," developers would call "working around a non-standard browser quirk."

That's because cookies were not designed to convey the privacy choice of the user and developers do not expect the absence of a cookie to mean "do not store state for me." When cookies go away, devs may use other methods to store state - their endgoal is to make their app work for the user.

A user's privacy choice should be conveyed via DNT, that's what DNT is for.

If Mozilla really wants to convey privacy signals using cookies, it should work to update RFC 6265 to specify this behavior so that everyone has the same context and expectation.

I have two suggestions if this lands in a future release:

1. Launch an education campaign letting devs know that the cookie behavior is changing and if they work around it, they're on the hook for the legal and financial implications. It'd be cruel to set this trap without any warning to those who will get ensnared.

2. Rather than blocking cookies, make them session cookies. At least the web apps will continue to work and the cookie will evict when the browser is closed. It also mostly avoids the issue of devs working around the behavior without understanding the legal exposure.


- Bil
> _______________________________________________
> dev-privacy mailing list
> dev-p...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-privacy

Monica Chew

unread,
Feb 8, 2013, 2:15:36 PM2/8/13
to dev-p...@lists.mozilla.org
>From my point of view, there are two successful outcomes from this discussion.

1) The patch lands and doesn't need to be rolled back.
2) The patch lands and is rolled back due to user complaints, and the bug is resolved WONTFIX. This is a great outcome, because it gives us concrete data about what solutions don't work, doesn't depend on yet another review cycle for the telemetry patch, and it's still progress.

The worst possible outcome is that the bug remains opened for years and the patch languishes. I agree with many of the concerns discussed above and in fact argued against writing the patch in the first place in https://bugzilla.mozilla.org/show_bug.cgi?id=818337#c2. However, now that the patch has been written and reviewed by a cookie peer, it seems like a gross misuse of contributors' time and goodwill not to try it out on at least nightly users.

If it would make people feel better to test this on nightly users for more than one release cycle, then I suggest wrapping the new default pref in #ifdef RELEASE_BUILD (https://bugzilla.mozilla.org/show_bug.cgi?id=820148).

Thanks,
Monica

Sid Stamm

unread,
Feb 8, 2013, 5:08:19 PM2/8/13
to Monica Chew
Hi Monica,

On 02/08/2013 11:15 AM, Monica Chew wrote:
>> From my point of view, there are two successful outcomes from this
>> discussion.
>
> 1) The patch lands and doesn't need to be rolled back.
> 2) The patch lands and is rolled back due to user complaints, and
> the bug is resolved WONTFIX.

I think there's a third outcome that we shouldn't discount, though
perhaps not as good as the other two: the patch lands, but due to
breakage we have to revert the default to today's status quo. This is
better than letting the patch sit and languish in a bug, but I think
this is the worst-best outcome.


> The worst possible outcome is that the bug remains opened for years
> and the patch languishes. I agree with many of the concerns discussed
> above and in fact argued against writing the patch in the first place
> in https://bugzilla.mozilla.org/show_bug.cgi?id=818337#c2.

I really don't want this to happen, and I doubt if it will. We need to
either determine this is productive and useful or build enough data to
WONTFIX the patch and I think everyone here agrees that we need closure
-- we just don't agree on which..

However,
> now that the patch has been written and reviewed by a cookie peer, it
> seems like a gross misuse of contributors' time and goodwill not to
> try it out on at least nightly users.
>
> If it would make people feel better to test this on nightly users for
> more than one release cycle, then I suggest wrapping the new default
> pref in #ifdef RELEASE_BUILD
> (https://bugzilla.mozilla.org/show_bug.cgi?id=820148).

Hey, this is cool, I didn't know about that #ifdef. Looks like if we
land it now, we can ship it to the world on the regular trains (21) and
while the functionality would ship in 21 it would automatically be
preffed off when it hits Beta -- unless of course we decide to change
that before the 21 beta branch date.

-Sid

Sid Stamm

unread,
Feb 8, 2013, 6:22:23 PM2/8/13
to Corry, Bil
Bil,

> 2. Rather than blocking cookies, make them session cookies. At least
> the web apps will continue to work and the cookie will evict when the
> browser is closed. It also mostly avoids the issue of devs working
> around the behavior without understanding the legal exposure.

I'm trying to fully understand your concerns. Can you provide a few use
case examples that break under this proposal but not if we make them
session cookies?

-Sid

Sid Stamm

unread,
Feb 8, 2013, 9:29:38 PM2/8/13
to bre...@secure.meer.net, Monica Chew, jma...@stanford.edu
Hi All,

Okay, we've stirred the pot a little bit and a few questions have
bubbled up to the top as needing answers. (I'll reply to my own message
with my thoughts on each as bullets after the question.)

1. What if sites start telling Firefox users they don't support the
browser (and to use another one)?

2. Won't landing this patch and changing the default accelerate an
"arms race" for third-party state storage?

3. We tried things like this before, and they were reversed. Why is
this different?

4. Will nightly/aurora be enough time to test this out?

5. Won't this disadvantage the small guys and give the upper hand to big
entities like Google and Facebook who have first-party relationships
with users too?

6. What about localStorage and friends?

7. Won't this be ineffective since most Firefox users already have
these third-party cookies in their profile?

Let me know if I missed a concern that's not on the list.

My current thinking is that we should land this next week once we've
finished hashing these out and then follow-up shortly thereafter with
some telemetry measurements and a test-pilot study to measure the effect
of this and similar changes.

-Sid

Sid Stamm

unread,
Feb 8, 2013, 9:35:35 PM2/8/13
to bre...@secure.meer.net, Monica Chew, jma...@stanford.edu
As promised, here are my thoughts on these questions. I feel comfortable
with most of this but we:
* need a good story for #1 and 7,
* a plan for #6 (bugs filed),
* and Brendan to make a call on three timing and schedule questions:
(should it land in 21 or 22? if 21, should we hold it back at the merge?
should we revert the default when this goes to beta?).

> 1. What if sites start telling Firefox users they don't support the
> browser (and to use another one)?

* Lucas brought this up, though I'm not aware of any live sites that are
currently doing this. ACTION: need someone to find a few examples of
sites that do this to one of the major browsers due to cookie handling.
Personally, I think the best way to test whether this will happen or
not is to land the feature in nightly, socialize it, and get some
feedback from web devs.

> 2. Won't landing this patch and changing the default accelerate an
> "arms race" for third-party state storage?

* Yes, this is a risk, so as Brendan pointed out we must also be working
on other "peaceful alternatives". This is accelerant. We also need
flame retardant. The W3C is proposing a "site-based-exception" API;
perhaps we can do something similar for third-party cookies so sites can
ask for them back. We have the plumbing to permit third party cookies
per-site, but the UI isn't accessible. I don't intend to stop with this
patch.

> 3. We tried things like this before, and they were reversed. Why is
> this different?

* Double-keying cookies was a bigger change; it changed the cookie model
in a more fundamental way. I liked that more, but try explaining
two-key cookies to a non-technical person. It's more complicated to
understand.
* Previously, we tried to block *all* third party cookies (not just
those for unvisited sites). See bug 324397. This breaks much more, and
I suspect single sign-on is one of the things.

> 4. Will nightly/aurora be enough time to test this out?

* Let's assume we land in time for 21. The merge for 21 is really soon,
and as Monica pointed out we could tag the code to automatically
pref-off when it eventually gets merged to Beta. We can also hold it
back in nightly for 22 if necessary.
* If we use the #ifdef trick to autopref it off in Beta, we can more
quickly push the bits out to everyone without changing the defaults.
Then we can more easily ship a test pilot study to moar users (beta
users, for example) to test it. This is much easier than packaging the
patch up in a test pilot study (which may be next to impossible since
this required C++ hacking). I say lets land it and let it ride the train.

> 5. Won't this disadvantage the small guys and give the upper hand to big
> entities like Google and Facebook who have first-party relationships
> with users too?

* Possibly, but it will also encourage the small players to cooperate
with their first parties for cookies. This is what Google does for
analytics (stores the cookies in the first party domain and uses
JavaScript to transfer the cookie data into their domain). I don't think
this cooperation is a bad thing since IMO the first parties have a duty
to pick third parties that are in their users' best interest; requiring
them to cooperate more closely means they will probably spend more time
considering the effect of using those third parties.

> 6. What about localStorage and friends?

* Brian brought up the idea that we should fix *all* state tools and
cookies in one fell swoop. I think that, while we should get to it
eventually, we should chomp off one bite at first and then consider
doing the others next or we risk scope creep and never shipping anything.

> 7. Won't this be ineffective since most Firefox users already have
> these third-party cookies in their profile?

* I swear I read a study that suggested a large chunk of people clear
cookies at least monthly. I'll try to find it. I think that's good enough.

-Sid

Asa Dotzler

unread,
Feb 11, 2013, 2:12:21 PM2/11/13
to Bil Corry, Jonathan Mayer
The question this raises for me is "If a website works around the Safari
cookie handling, will we get that same workaround or are we expecting
those sites to simply break for Firefox users?"

- A

Asa Dotzler

unread,
Feb 11, 2013, 2:21:28 PM2/11/13
to Sid Stamm, bre...@secure.meer.net, Monica Chew, jma...@stanford.edu
On 2/8/2013 6:35 PM, Sid Stamm wrote:
> As promised, here are my thoughts on these questions. I feel comfortable
> with most of this but we:
> * need a good story for #1 and 7,
> * a plan for #6 (bugs filed),
> * and Brendan to make a call on three timing and schedule questions:
> (should it land in 21 or 22? if 21, should we hold it back at the merge?
> should we revert the default when this goes to beta?).

I'd like to weigh in on timing and schedule here.

We're most of the way through 21 and some of my biggest concerns here
are user impact related to changing web platform basics. How much are we
going to break the web for our users is top of mind for me.

I think we should definitely hold off until the opening of Firefox 22 or
land knowing we don't intend to uplift to 21. We should maximize the
feedback opportunities we have and I wouldn't be comfortable with
anything less than a complete mozilla-central cycle.


>> 1. What if sites start telling Firefox users they don't support the
>> browser (and to use another one)?
>
> * Lucas brought this up, though I'm not aware of any live sites that are
> currently doing this. ACTION: need someone to find a few examples of
> sites that do this to one of the major browsers due to cookie handling.
> Personally, I think the best way to test whether this will happen or
> not is to land the feature in nightly, socialize it, and get some
> feedback from web devs.

Agreed. We're not going to find broken websites without enabling this
feature for more users. The best chances we have are to maximize the
number of pre-release users who have this and watch their feedback very
closely.


>> 4. Will nightly/aurora be enough time to test this out?
>
> * Let's assume we land in time for 21. The merge for 21 is really soon,
> and as Monica pointed out we could tag the code to automatically
> pref-off when it eventually gets merged to Beta. We can also hold it
> back in nightly for 22 if necessary.
> * If we use the #ifdef trick to autopref it off in Beta, we can more
> quickly push the bits out to everyone without changing the defaults.
> Then we can more easily ship a test pilot study to moar users (beta
> users, for example) to test it. This is much easier than packaging the
> patch up in a test pilot study (which may be next to impossible since
> this required C++ hacking). I say lets land it and let it ride the train.

We need to plan for easy mitigation if things don't go well. The design
should accommodate the easiest and safest disable mechanisms for each
train, all the way up to release. For example, we should be ready with a
chemspill plan that can safely flip the switch for release users.

- A

Asa Dotzler

unread,
Feb 11, 2013, 2:29:46 PM2/11/13
to
On 1/14/2013 10:24 AM, Sid Stamm wrote:
> Jonathan Mayer has implemented a halfway-block feature for third party
> cookies.
>
> Right now, Firefox can only block BOTH { setting + getting } of third
> party cookies, so we can't turn it off by default. At least one other
> browser has something about half-way that allows the getting of cookies
> in third party contexts (but blocks setting). The effect is that sites
> you visit directly can set cookies, but sites you don't visit directly
> cannot.
>
> Anyway, I think we should ship this feature. I think we should ship it
> enabled by default, but we need to do a few things first:
>
> 1. Write the code (almost done)
> 2. Make sure users know the difference between this and full-strength
> third-party cookie blocking.
> 3. Make sure it doesn't cause too much breakage in the web experience.
>
> jmayer is working hard on the code. There's a reasonable UI in the bug
> that teases out accepting cookies "from visited" as a new feature.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=818340
>
> We are working on a test pilot study around cookies that might help us
> get a good picture of how much is going to break when we turn this on.
> If anyone out there has some data that can educate this, I'd appreciate
> it. :)

Sid, I'm in favor of moving forward on this, cautiously. As long as we
have confidence at each step of the way that we're not breaking
significant numbers of users or sites, this is a good move.

Assume this spends 6 weeks in mozilla-central. How will we decide if it
should be uplifted. What about from Aurora to Beta and to release?

I've heard Telemetry and Test Pilot mentioned. What are the plans there?
Also, is Support involved? They'll be an early indicator of problems
here. Finally, is there any way for us to spider some top sites list and
see what kind of cookie setting we're getting and if any of those top
sites are using mechanisms that would fail with our changes?

- A

Sid Stamm

unread,
Feb 11, 2013, 3:37:03 PM2/11/13
to Asa Dotzler, Jonathan Mayer, Monica Chew
On 02/11/2013 11:29 AM, Asa Dotzler wrote:
> Assume this spends 6 weeks in mozilla-central. How will we decide if it
> should be uplifted. What about from Aurora to Beta and to release?

Should we just do what we usually do? Put it on the train, monitor
telemetry/support channels and pull it off the train (or hold it back)
if something comes up? We don't usually have criteria for "advancing"
things on the train; instead we need to know what will block it.

What type of event/reaction/situation would cause you to advocate
holding it back or backing it out?

> I've heard Telemetry and Test Pilot mentioned. What are the plans there?

Telemetry bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=837326
After this discussion wraps up, I'll start a new one with hope of
nailing down what metrics to gather for the questions we need answered.

Monica is working on a more robust cookie study in Test Pilot that will
uncover more about cookies than just how this one patch affects the web.

> Also, is Support involved? They'll be an early indicator of problems
> here.

Yes, I've looped them in and will send them a heads-up when it lands.
They'll be working directly with me to ensure we've got inbound concerns
spelled out and take any action necessary.

> Finally, is there any way for us to spider some top sites list and
> see what kind of cookie setting we're getting and if any of those top
> sites are using mechanisms that would fail with our changes?

Jonathan, have you any data on this kind of thing?
I believe Monica's test pilot study was going to measure this "in the wild".

-Sid

mco...@gmail.com

unread,
Feb 12, 2013, 2:13:42 PM2/12/13
to Asa Dotzler, Jonathan Mayer, Monica Chew
On Monday, 11 February 2013 15:37:03 UTC-5, Sid Stamm wrote:

> Should we just do what we usually do? Put it on the train, monitor
> telemetry/support channels and pull it off the train (or hold it back)
> if something comes up? We don't usually have criteria for "advancing"
> things on the train; instead we need to know what will block it.

I think this is a flaw of the current train model, and we should not follow that model for this feature, or any other change which has obvious potential downsides that would outweigh the benefits of that change.

For something of this nature, which has serious real-world implications for how the Web works (especially in terms of how the bills get paid for many sites), I would expect that advancing on the trains requires some measurable success against agreed criteria, and measurable containment of harm. I know we're not great at that now, but I think it's how we have to start thinking as engineers.

-- Mike

Sid Stamm

unread,
Feb 12, 2013, 10:34:59 PM2/12/13
to mco...@gmail.com, Asa Dotzler, Jonathan Mayer, Monica Chew
On 2/12/13 11:13 AM, mco...@gmail.com wrote:
> For something of this nature, which has serious real-world
> implications for how the Web works (especially in terms of how the
> bills get paid for many sites), I would expect that advancing on the
> trains requires some measurable success against agreed criteria, and
> measurable containment of harm. I know we're not great at that now,
> but I think it's how we have to start thinking as engineers.

I can see how that would be useful, but I'm not convinced we need to
assume features guilty until proven innocent. I'll make sure when this
patch lands we keep it on nightly (at least through the next merge) and
we can work out criteria for advancement or back-holding.

Often times with security and privacy features it's really hard to
measure success -- many of them simply mean that nothing "bad" happens,
and we have to try them out to see if the unexpected will happen.
Measuring failure is easier, though, as a breach or anomaly means
failure. Perhaps what we need is a set of failure criteria and watch
for failure/regression as it rides the trains.

So telemetry. Yes, we should figure out what we want to know and what
constitutes success versus failure -- then measure it. Wanna start that
discussion?

-Sid

mco...@gmail.com

unread,
Feb 13, 2013, 1:55:48 AM2/13/13
to mco...@gmail.com, Asa Dotzler, Jonathan Mayer, Monica Chew
On Tuesday, 12 February 2013 22:34:59 UTC-5, Sid Stamm wrote:

> I can see how that would be useful, but I'm not convinced we need to
> assume features guilty until proven innocent. I'll make sure when this
> patch lands we keep it on nightly (at least through the next merge) and
> we can work out criteria for advancement or back-holding.

At the least, I feel like there are poorly-defined success criteria for this patch. I don't think it's a matter of guilty until proven innocent, but I will assert that we should not change core functionality without a strong understanding of what we expect as the overall outcome of that change. Perhaps "useless until proven useful" is a fair assessment? This is not an area of code where we can accept anything less than than solidly reasoned changes, even with the noble goal of improving user privacy.

To be clear, I'm currently okay with landing (post-merge) on Nightly to get feedback. I'm not convinced we should let this patch ride the trains (regardless of default) until we have a much better story about why this benefits users overall, and why it won't just cause developers to adopt techniques that trivially bypass this protection. Google Analytics is already using first-party cookies (just search on "__utm" to see how widely this is used), so it seems as if this can be trivially bypassed without resorting to the myriad of other ways to track users without cookies. That would mean every tracker is recording data as the first party, making tracking and blocking much more complex. If that happens, we're back where we are now, except that we won't have a useful answer to users who really want to block this type of thing. That's a significant net loss.

We should absolutely identify indicators that we're failing hard, but I question the notion that we can't describe success in a way we can measure. That said, I've yet to come up with a success state that doesn't rely on developers doing essentially nothing to evade the restrictions, so I suspect getting to measurable indicators is going to be extra hard here. I'm happy to do what I can to make that work, but I think it will require some deep thought about how this will play out and how we get to where we want to be.

-- Mike

Afowler

unread,
Feb 13, 2013, 4:34:26 PM2/13/13
to mco...@gmail.com, Asa Dotzler, Jonathan Mayer, Monica Chew
On Tuesday, February 12, 2013 10:55:48 PM UTC-8, mco...@gmail.com wrote:

> To be clear, I'm currently okay with landing (post-merge) on Nightly to get feedback. I'm not convinced we should let this patch ride the trains (regardless of default) until we have a much better story about why this benefits users overall, and why it won't just cause developers to adopt techniques that trivially bypass this protection. Google Analytics is already using first-party cookies (just search on "__utm" to see how widely this is used), so it seems as if this can be trivially bypassed without resorting to the myriad of other ways to track users without cookies. That would mean every tracker is recording data as the first party, making tracking and blocking much more complex. If that happens, we're back where we are now, except that we won't have a useful answer to users who really want to block this type of thing. That's a significant net loss.

If the goal here is to stop tracking, then I think your comment is correct. A default change like this may have only short-term value to our users. However, I don't think that should be the goal. We continue to hear from our users that it's the nontransparent, unaccountable nature of third party tracking that gives them concern. While a first party's data handling practices may be complex, there's a direct relationship and an opportunity to learn about and, increasingly, control those practices via various mechanisms. In that context, tracking and personalization become more trustworthy and in the users' direct purview.

Brian Smith

unread,
Feb 23, 2013, 11:16:21 PM2/23/13
to Sid Stamm, bre...@secure.meer.net, dev-p...@lists.mozilla.org, jma...@stanford.edu, Monica Chew
Sid Stamm wrote:
> > 6. What about localStorage and friends?
>
> * Brian brought up the idea that we should fix *all* state tools and
> cookies in one fell swoop. I think that, while we should get to it
> eventually, we should chomp off one bite at first and then consider
> doing the others next or we risk scope creep and never shipping
> anything.

I didn't mean to suggest that it all has to happen at once. I would say that it might actually be useful to delay doing this for a while to see how many sites switch to localStorage-based hacks. We may learn something interesting. But, I think we should have a bug to track this. I am not sure if "block localStorage in third-party iframes from sites I haven't visited" is the right scope. Is it?

> > 7. Won't this be ineffective since most Firefox users already have
> > these third-party cookies in their profile?
>
> * I swear I read a study that suggested a large chunk of people clear
> cookies at least monthly. I'll try to find it. I think that's good
> enough.

Did you find the study?

IMO, if we're going to do this, it is worth doing it right. In the absence of compelling data indicating otherwise, if we figure that pretty much everybody has a doubleclick tracking cookie already, then I think we have to assume that a marge majority of our users will be tracked by doubleclick in perpetuity unless we fix this aspect of the bug too. I don't want us to have to water down our claims about how well the feature works and I don't want us to unintentionally mislead people about the effectiveness of the feature. Also, I think the plan I outlined earlier in this thread for how to accomplish this would not be difficult to implement, even if it doesn't have immediate effects. So, I think it would be good to get started on fixing this part soon.

Cheers,
Brian

Justin Dolske

unread,
Feb 23, 2013, 11:54:24 PM2/23/13
to
On 2/23/13 8:16 PM, Brian Smith wrote:

> IMO, if we're going to do this, it is worth doing it right. In the
> absence of compelling data indicating otherwise, if we figure that
> pretty much everybody has a doubleclick tracking cookie already, then
> I think we have to assume that a marge majority of our users will be
> tracked by doubleclick in perpetuity unless we fix this aspect of the
> bug too.

Could (and should :) we do something like: Add a timestamp for when the
last first-party visit was for the site, and if you've not made a
first-party visit within X weeks, drop the cookie.

The idea being to continue to allow "grandfathered" cookies to work for
a while, but drop them if the browser sees that the users behavior
wouldn't have actually allowed them to have been set in the first place.

Justin

mark.regi...@gmail.com

unread,
Feb 24, 2013, 12:00:29 AM2/24/13
to Benjamin Smedberg
On Tuesday, January 15, 2013 8:42:13 AM UTC+11, Sid Stamm wrote:
> On 1/14/13 11:57 AM, Benjamin Smedberg wrote:
> > * What is considered "third-party" in this context? e.g. are iframes
>
> > third-party?
>
>
> Same as for our existing cookie stuff. Things that are different origin
>
> than the top level document.

Can anyone clarify the exact situations that will allow a 3rd-party cookie to be set?

The FAQ (http://webpolicy.org/2013/02/22/the-new-firefox-cookie-policy/#firefox-cookie-policy-fn3) states:

"If a Firefox user appears to have intentionally interacted with your content, take the same approach as for Safari users.4 Examples of content within this category include Facebook apps and comment widgets where a user has typed text.

If a user does not seem to have intentionally interacted with your content, or if you’re uncertain, you should ask for permission before setting cookies. Most analytics services, advertising networks, and unclicked social widgets would come within this category."


This implies that cookies will not only be set in top-level windows (including pop-up windows), but also in iframes that have received any DOM event (click, touch, key press, or even move).

Brian Smith

unread,
Feb 24, 2013, 12:04:33 AM2/24/13
to Justin Dolske, dev-p...@lists.mozilla.org
Justin Dolske wrote:
> Could (and should :) we do something like: Add a timestamp for when
> the last first-party visit was for the site, and if you've not made
> a first-party visit within X weeks, drop the cookie.
>
> The idea being to continue to allow "grandfathered" cookies to work
> for a while, but drop them if the browser sees that the users
> behavior wouldn't have actually allowed them to have been set in
> the first place.

Brilliant!

Cheers,
Brian

Earlier in the thread, Brian Smith wrote:

joakim....@gmail.com

unread,
Feb 24, 2013, 11:37:42 AM2/24/13
to
On Monday, January 14, 2013 7:24:23 PM UTC+1, Sid Stamm wrote:
> Jonathan Mayer has implemented a halfway-block feature for third party
>
> cookies.
>
>
>
> Right now, Firefox can only block BOTH { setting + getting } of third
>
> party cookies, so we can't turn it off by default. At least one other
>
> browser has something about half-way that allows the getting of cookies
>
> in third party contexts (but blocks setting). The effect is that sites
>
> you visit directly can set cookies, but sites you don't visit directly
>
> cannot.
>
>
>
> Anyway, I think we should ship this feature. I think we should ship it
>
> enabled by default, but we need to do a few things first:
>
>
>
> 1. Write the code (almost done)
>
> 2. Make sure users know the difference between this and full-strength
>
> third-party cookie blocking.
>
> 3. Make sure it doesn't cause too much breakage in the web experience.
>
>
>
> jmayer is working hard on the code. There's a reasonable UI in the bug
>
> that teases out accepting cookies "from visited" as a new feature.
>
>
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=818340
>
>
>
> We are working on a test pilot study around cookies that might help us
>
> get a good picture of how much is going to break when we turn this on.
>
> If anyone out there has some data that can educate this, I'd appreciate
>
> it. :)
>
>
>
> -Sid

Many implementations contains a workaround for the mentioned Safari behaviour. A while back they allowed form posting to the 3rd party domain, but that was removed in later Safari versions. The workaround changed to requesting a user interaction like pressing a button to continue on the 3rd party domain. Will this workaround also be applicable to Firefox when this is released?

Mxx

unread,
Feb 24, 2013, 1:51:56 PM2/24/13
to
It is my understanding that the dire for this feature is to protect users from tracking and not to break websites' regular functionality. Wasn't DNT header created specifically for that? Is there a proof that DNT failed and things need to be 'escalate' to the next level? It took a lot of effort to get all the browsers and advertising industry on board with that. Why the sudden change in attitude?
Are there browser statistics on what percentage of 3rd party cookies are advertising-related and what percentage are functional? I wouldn't be surprised if it was about equal split. Blocking them by default will piss off advertising/tracking/publishing industry from one end and publishing industry from the other end since it will break their website's functionality.
The support channels should be ready for a flood of "stuck in a login loop" and "never ending redirects" complaints.

kits...@gmail.com

unread,
Feb 24, 2013, 3:03:48 PM2/24/13
to
How would this affect the rather large amount of Facebook applications that are intentionally iframed thirt-party sites and where the primary content is from a third sites? Currently these applications have no reason to touch their own domain on the top level frame as navigation happens by instructing facebook where to go. I.e.

http://apps.facebook.com/1234567890/index iframes http://example.org/index
http://apps.facebook.com/1234567890/test iframes http://example.org/test

One issue in early versions of Safari 5 is that their cookie policy blocked cookies being set by iframed third party frames, so we would need to redirect out of Facebook, onto our own domain, set a cookie and then go back. This was the only browser that did so, and it has since stopped with that behaviour, I would very much prefer not to get that back.

It seems to me that what would end up happening is that trackers and widget authors that feel they need cookies check for their cookie, if it's missing send the user to a return-to-referrer url and stick one on. Causing seemly random navigations. If the website has multiple widgets installed, this could happen multiple times as third-parties make sure their cookies are being set before the user sees the content they are after. Issues that can be worked around will get worked around by web developers, which in effect defeating the whole purpose of the patch while degrading the user experience.

Asa Dotzler

unread,
Feb 24, 2013, 5:11:04 PM2/24/13
to
On 2/24/2013 10:51 AM, Mxx wrote:
> It is my understanding that the dire for this feature is to protect users from tracking and not to break websites' regular functionality.

That is not the driver for this feature. We are not trying to stop
tracking with this feature. We are trying to make tracking relationships
more obvious to the user.

- A

Asa Dotzler

unread,
Feb 24, 2013, 5:13:18 PM2/24/13
to
On 2/24/2013 12:03 PM, kits...@gmail.com wrote:
> How would this affect the rather large amount of Facebook applications that are intentionally iframed thirt-party sites and where the primary content is from a third sites?

This should work just fine for Facebook applications. I've been running
with this setting since its first availability and I have experienced no
problems with any Facebook applications.

If you have specific sites that you can demonstrate break as a result of
this change, please let us know. Speculations around catastrophic web
breakages aren't particularly helpful without specific examples of
actual breakage.

- A

mxx...@gmail.com

unread,
Feb 24, 2013, 10:01:32 PM2/24/13
to
How is blocking by default going to make it more obvious? Once sites will start nagging users to go into their browser options to turn it off 3rd party cookie blocking? Or will there be a prompt asking user if they want to accept each and every 3rd party cookie?

By blocking cookies by default are you not making that decision for your users without consulting them. This was similar issue with DNT header being enabled by default in IE10. MS made a decision on users behalf without asking for their consent.

If Firefox will block 3rd party cookies by default, wouldn't it be helpful to sites if it send a signal that it does that. This way sites right away can adjust their behavior/logic and know at the 1st request time what to do rather than try to set/read cookie action every single time, then perform other redirects and tricks to try to accomplish what it needs to. I can see that having a negative user experience/performance.

> This should work just fine for Facebook applications. I've been running
> with this setting since its first availability and I have experienced no
> problems with any Facebook applications.

But this is experience of a single user with a limited number of sites.
How will shopping carts work that do multiple redirects to/from paypal, google wallet, amazon merch and similar sites?
What about sites that use rpxnow.com and similar for their login/authentication systems?
How will this affect RUM services like Torbit, lognormal/soasta and similar?
How about Liveperson and similar 'customer engagement/support' applications?

Dennis Dayman

unread,
Feb 24, 2013, 10:47:43 PM2/24/13
to
On Sunday, February 24, 2013 9:01:32 PM UTC-6, mxx...@gmail.com wrote:
> On Sunday, February 24, 2013 5:11:04 PM UTC-5, Asa Dotzler wrote:

> By blocking cookies by default are you not making that decision for your users without consulting them. This was similar issue with DNT header being enabled by default in IE10. MS made a decision on users behalf without asking for their consent.

just tell visiting users you don't support FF and to download Google Chrome... :)

I know, that isn't a solution for this, but man its tempting.

-Dennis

Bil Corry

unread,
Feb 25, 2013, 6:48:54 AM2/25/13
to Asa Dotzler, dev-p...@lists.mozilla.org
I fired up Nightly and set the DNT preference to 0 (aka "Tell sites I want to be tracked"). So even though I said I wanted to be tracked, when I visited a site with third-party content, all third-party cookies were blocked.

This brings up some questions:

1. To me, as a user, this is non-intuitive. Is there a way to harmonize cookie behavior with the DNT preference?

2. What does Mozilla recommend as a best practice for third-parties that have permission to track, but can't because of this new cookie policy?

3. If third-parties can't ever set state on the browser, then what's the point of DNT (since tracking is always blocked)?

4. Mozilla publicly came out against a default choice for tracking[1], yet this new cookie policy runs counter to that position by blocking tracking by default. Does Mozilla still believe tracking is an expressed user preference? Or only for DNT, but not cookies? It's somewhat hollow to say DNT should be a user-expressed preference, then prevent tracking regardless of that preference.


- Bil


[1] http://blog.mozilla.org/privacy/2012/05/31/do-not-track-its-the-users-voice-that-matters/




Sid Stamm

unread,
Feb 25, 2013, 4:26:12 PM2/25/13
to Brian Smith, Sid Stamm, bre...@secure.meer.net, jma...@stanford.edu, Monica Chew
On 02/23/2013 08:16 PM, Brian Smith wrote:
>>>>> 7. Won't this be ineffective since most Firefox users
>>>>> already have these third-party cookies in their profile?
>>>
>>> * I swear I read a study that suggested a large chunk of people
>>> clear cookies at least monthly. I'll try to find it. I think
>>> that's good enough.
> Did you find the study?

Not sure if this is the same study. I'm still digging for more examples.

http://www.aleecia.com/authors-drafts/tprc-behav-AV.pdf

"9% said they never clear cookies, 9% believe they clear cookies
themselves annually or less than once a year, 16% a few times a year,
10% monthly, 17% a few times a month, 16% a few times a week, 12% daily,
and 8% clear cookies every time they close their browser. This is
self-reported data, but about 70% believe they clear cookies at least
once a year."

So if I read it right, 53% are likely to erase cookies within the first
month of encountering this feature.

-Sid

Alexander Hanff

unread,
Feb 25, 2013, 4:39:20 PM2/25/13
to dev-p...@lists.mozilla.org, bre...@secure.meer.net, Sid Stamm, jma...@stanford.edu, Monica Chew
I would take that with a very large pinch of salt. Psychology has taught us
for decades that people often tell lies to interviewers and on
questionnaires - it is very common for participants to say what they think
the researcher wants to hear and there is also the added factor of people
who say they do something because they don't want to "look stupid".

My experience of working with people in the field is very few "ordinary"
users (the vast majority of home PC users) do any sort of housework
whatsoever - most of them don't even bother to update their anti-virus let
alone clear their cookies.

I would be more than a little surprised to find that anything like 53% of
the worlds' PC users ever clear their cookies, let alone once a month - I
doubt even 25% do.

Alexander Hanff
_______________________________________________
dev-privacy mailing list
dev-p...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-privacy

Sid Stamm

unread,
Feb 25, 2013, 4:47:31 PM2/25/13
to Alexander Hanff, bre...@secure.meer.net, jma...@stanford.edu, dev-p...@lists.mozilla.org, Monica Chew
On 02/25/2013 01:39 PM, Alexander Hanff wrote:
> I would take that with a very large pinch of salt. Psychology has taught us
> for decades that people often tell lies to interviewers and on
> questionnaires - it is very common for participants to say what they think
> the researcher wants to hear and there is also the added factor of people
> who say they do something because they don't want to "look stupid".

Agreed, which is why I'm still digging around for other studies that
measure, not ask. It's just a data point (better than none). If you've
got another study, point it out!

> My experience of working with people in the field is very few "ordinary"
> users (the vast majority of home PC users) do any sort of housework
> whatsoever - most of them don't even bother to update their anti-virus let
> alone clear their cookies.

My experience has been the opposite; my interactions corroborate what is
in that research paper (roughly half do something to clear cookies).
This is why I'd like to see research data that measures so we're not
relying solely on interview-honesty and gut feelings.

-Sid

lisamo...@gmail.com

unread,
Feb 26, 2013, 1:23:03 AM2/26/13
to
life is too short

Artur Kania

unread,
Feb 26, 2013, 12:40:19 PM2/26/13
to
Hi

I have different use-case which will be broken if Firefox will block 3rd party cookies. User is visiting a.com - b.com want's to integrate some features to a.com - so it's running some javascript on a.com, also it's using iframes to communicate/authenticate with b.com services using JSONP ( it needs cookies on b.com to authenticate requests ) - it's commonly security pattern for browser that don't support CORS ajax reqeusts.
If user never before visited b.com whole flow will be broken - only option is to detect that cookies are blocked, and ask user to visit b.com.
What are your thoughts about it?

Sid Stamm

unread,
Feb 26, 2013, 12:58:16 PM2/26/13
to Artur Kania
On 2/26/13 9:40 AM, Artur Kania wrote:
> Hi
>
> I have different use-case which will be broken if Firefox will block
> 3rd party cookies. User is visiting a.com - b.com want's to integrate
> some features to a.com - so it's running some javascript on a.com,
> also it's using iframes to communicate/authenticate with b.com
> services using JSONP ( it needs cookies on b.com to authenticate
> requests )


> - it's commonly security pattern for browser that don't
> support CORS ajax reqeusts.

Is this a common pattern targeted at browsers like Firefox that *do*
support CORS ajax requests?

> If user never before visited b.com whole
> flow will be broken - only option is to detect that cookies are
> blocked, and ask user to visit b.com. What are your thoughts about
> it?

Do you have a specific example of a live site that uses this pattern?
I'd like to peek at an implementation.

-Sid

kani...@gmail.com

unread,
Feb 26, 2013, 1:43:49 PM2/26/13
to Artur Kania
> > - it's commonly security pattern for browser that don't
>
> > support CORS ajax reqeusts.
>

Sorry, your right - Firefox supports CORS, bad example - apologize

>
> Is this a common pattern targeted at browsers like Firefox that *do*
>
> support CORS ajax requests?
>
>
>
> > If user never before visited b.com whole
>
> > flow will be broken - only option is to detect that cookies are
>
> > blocked, and ask user to visit b.com. What are your thoughts about
>
> > it?
>
>
>
> Do you have a specific example of a live site that uses this pattern?
>
> I'd like to peek at an implementation.
>

I'm want describe situation when a.com is including code from b.com - as i wrote
b.com is creating iframe ( hosted on b.com ) that is communicating with b.com services - it uses cookie that are set on b.com ( don't wont/can't set them on a.com ) to authenticate requests and receive data which is send back to a.com main window. Even when using CORS - we would need to have cookies set on b.com
Use-case is - first time user - never before visited b.com - is opening a.com
In that case browser will not set cookies on b.com for him. It can be designed in different way ( proxy etc )
Sorry but don't have example of any live site - but still i think it is possible for services that want to include some widgets/features to other pages.

adechavagn...@gmail.com

unread,
Feb 26, 2013, 2:53:18 PM2/26/13
to
On Monday, January 14, 2013 7:24:23 PM UTC+1, Sid Stamm wrote:
> Jonathan Mayer has implemented a halfway-block feature for third party
>
> cookies.
>
>
>
> Right now, Firefox can only block BOTH { setting + getting } of third
>
> party cookies, so we can't turn it off by default. At least one other
>
> browser has something about half-way that allows the getting of cookies
>
> in third party contexts (but blocks setting). The effect is that sites
>
> you visit directly can set cookies, but sites you don't visit directly
>
> cannot.
>
>
>
> Anyway, I think we should ship this feature. I think we should ship it
>
> enabled by default, but we need to do a few things first:
>
>
>
> 1. Write the code (almost done)
>
> 2. Make sure users know the difference between this and full-strength
>
> third-party cookie blocking.
>
> 3. Make sure it doesn't cause too much breakage in the web experience.
>
>
>
> jmayer is working hard on the code. There's a reasonable UI in the bug
>
> that teases out accepting cookies "from visited" as a new feature.
>
>
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=818340
>
>
>
> We are working on a test pilot study around cookies that might help us
>
> get a good picture of how much is going to break when we turn this on.
>
> If anyone out there has some data that can educate this, I'd appreciate
>
> it. :)
>
>
>
> -Sid

Is this great idea been inspired by google the first contributor to firefox? It will be the only one to be able to put cookie on every firefox user (as it has paid 1Mds$ to be on the first page)... for is own benefit only of course!
-Alex

Sid Stamm

unread,
Feb 26, 2013, 5:21:11 PM2/26/13
to adechavagn...@gmail.com
On 2/26/13 11:53 AM, adechavagn...@gmail.com wrote:
> Is this great idea been inspired by google the first contributor to
> firefox? It will be the only one to be able to put cookie on every
> firefox user (as it has paid 1Mds$ to be on the first page)... for is
> own benefit only of course! -Alex

I am pretty sure the default home page in Firefox is "about:home", which
is local content (except for some snippets that come from Mozilla). If
you do a search from that page, yes, you go to google.com, but not if
you don't do a search.

-Sid

Alexander Hanff

unread,
Feb 26, 2013, 5:30:37 PM2/26/13
to dev-p...@lists.mozilla.org
I mentioned to you yesterday Sid that on a fresh install of Mozilla Firefox
the second you open Firefox for the first time a Google.Com cookie is placed
in the sqllite file without ever visiting a web site or doing a search.
This immunizes Google from this new policy.

Alexander Hanff

-----Original Message-----
From: dev-privacy-bounces+a.hanff=think-pr...@lists.mozilla.org
[mailto:dev-privacy-bounces+a.hanff=think-pr...@lists.mozilla.org] On
Behalf Of Sid Stamm
Sent: 26 February 2013 23:21
To: dev-p...@lists.mozilla.org
Subject: Re: partial third-party cookie blocking

Sid Stamm

unread,
Feb 26, 2013, 6:02:01 PM2/26/13
to Alexander Hanff
On 2/26/13 2:30 PM, Alexander Hanff wrote:
> I mentioned to you yesterday Sid that on a fresh install of Mozilla Firefox
> the second you open Firefox for the first time a Google.Com cookie is placed
> in the sqllite file without ever visiting a web site or doing a search.
> This immunizes Google from this new policy.

You're right about the cookies, but those are not search cookies from
about:home. Those are for the safebrowsing phishing/malware protection
service.

We'd like to isolate those cookies from your web cookies so google.com
isn't given this elevated status. The idea is to have a separate cookie
jar for safebrowsing cookies. If you or someone you know would be
interested in writing a patch for this, we could use the help (and I'll
help out with it).

https://wiki.mozilla.org/Privacy/Features/Multiple_Cookie_Jars

-Sid

let4...@gmail.com

unread,
Feb 27, 2013, 6:48:03 AM2/27/13
to
Hi,
This is a big mistake to introduce such feature, because FireFox has big auditory. This action will brake advertisement ecosystem quality and targeting. It will block DMP, SSP and DSP business.
NAI has an answer for enabling feature "Do Not Track" by default. But this answer relates to this topic too:


Why NAI Cannot Support DNT On-by-Default

Media coverage related to Microsoft’s recently expressed intent to implement Internet Explorer 10’s ‘Do Not Track’ (DNT) function by default in its next release has compelled thoughtful responses from many stakeholders in the digital advertising and publishing ecosystem and NAI member inquiries.

NAI can’t accept a browser mechanism that threatens the health and vitality of the entire online ecosystem. This does not mean we oppose user choice; in fact, we’ve been working at the W3C and elsewhere on standards for browser-based choice mechanisms. The DAA, too, has committed to implement a browser-based choice mechanism based on its guiding principles.

But with a default-on mechanism, the impact on small online publishers and third-party technology providers, which are vital to today’s Internet, would be nothing short of catastrophic. Publishers of free content, services, and entertainment may move behind pay walls, or may disappear altogether, if they can’t monetize their content with targeted ads. For many third party companies, which facilitate interest-based ads or personalization, a default-on system jeopardizes their business – meaning no business. I don’t like to inject hyperbole into this discussion, but we are talking about no less than thousands of lost jobs and billions of dollars in lost revenue.

Others have raised concerns that the Internet becomes a handful of giant publishers and providers who will develop advertising models that work around Do Not Track altogether. Such an outcome may be OK for some stakeholders in the debate – a reasonable casualty of default Do Not Track — but that is little comfort to the threatened businesses in the NAI who are working hard now to create relevant advertising while respecting consumer privacy.

Numerous tools and choice mechanisms (such as browser settings, plug ins, and self-regulatory programs) already exist today for consumers who have privacy concerns about interest-based advertising. A new browser choice mechanism could be beneficial to the Internet, but not if it presents an “off switch” to every online user without explaining the consequences of flipping that switch for the online content they enjoy, and certainly not if that switch is flipped by default by the largest online players.

If you have questions about these commitments or our position on DNT being turned on by default, we encourage you to contact us directly.

http://www.networkadvertising.org/blog/why-nai-cannot-support-dnt-default

Tetsuharu OHZEKI [:saneyuki_s]

unread,
Feb 27, 2013, 11:47:57 AM2/27/13
to dev-p...@lists.mozilla.org
Hi, I have an question.

I feel from Sid or Jonathan's comment, we are testing the new policy &
looking for feedbacks about it.

However, why have we finished to introduce the telemetry data
collection for measuring effect of blocking some third party cookies
yet?

The bug has already been filed in 2013-02-01. But its comment are is
very silent and there is not any patch.
https://bugzilla.mozilla.org/show_bug.cgi?id=837326

For testing something & looking for feedback them, I think we should
introduce the telemetry for measuring effetct. And it need to
introduce immidiately with tested function. It's all the more
necessary in this case which may have big impact that we cannot
predict well.
If there is no measuring, Some people would seems that this test of
the new policy has had some of speculation.

When will we introduce the telemetry about it? Wil we land it in this week?

Sid Stamm

unread,
Feb 27, 2013, 12:48:16 PM2/27/13
to Tetsuharu OHZEKI [:saneyuki_s]
On 2/27/13 8:47 AM, Tetsuharu OHZEKI [:saneyuki_s] wrote:
> For testing something & looking for feedback them, I think we should
> introduce the telemetry for measuring effetct. And it need to
> introduce immidiately with tested function. It's all the more
> necessary in this case which may have big impact that we cannot
> predict well.
> If there is no measuring, Some people would seems that this test of
> the new policy has had some of speculation.

We landed the feature without telemetry because people can *try* it and
*tell* us what breaks. This can be done immediately.

But yes, I agree, we need to gather telemetry data too.

> When will we introduce the telemetry about it? Wil we land it in this week?

Probably not this week, but we're hoping very soon. If anyone wants to
pitch in and help figure out what questions to answer and then write the
telemetry patch (Jono?), please do!

-Sid

Tanvi Vyas

unread,
Feb 27, 2013, 2:06:23 PM2/27/13
to Mxx, Justin Dolske, dev-p...@lists.mozilla.org
On 2/24/13 10:51 AM, Mxx wrote:
> Are there browser statistics on what percentage of 3rd party cookies are advertising-related and what percentage are functional? I wouldn't be surprised if it was about equal split. Blocking them by default will piss off advertising/tracking/publishing industry from one end and publishing industry from the other end since it will break their website's functionality.
> The support channels should be ready for a flood of "stuck in a login loop" and "never ending redirects" complaints.

I have third party cookies blocked all together (and have for probably
about a year) so all third parties, regardless of whether they were once
a first party, can't read or write cookies. I have been able to
complete almost all my tasks with this setting. The only time I had to
open a new browser or browser profile was for purchasing something on
target.com or logging into citibank.com. I haven't tested what happens
on those two sites with the partial third-party cookie block.

Clicking "show prices" for hotels on tripadvisor.com also behaves a
little differently (new tabs instead of new windows?) but is still fully
functional.

The best ways to test this new feature and to see if it breaks
functionality are 1) download nightly and try it out (maybe clear your
cookies first so only actual first parties are allowed in a third party
context) and 2) telemetry.

On 2/23/13 8:54 PM, Justin Dolske wrote:
> On 2/23/13 8:16 PM, Brian Smith wrote:
>
>> IMO, if we're going to do this, it is worth doing it right. In the
>> absence of compelling data indicating otherwise, if we figure that
>> pretty much everybody has a doubleclick tracking cookie already, then
>> I think we have to assume that a marge majority of our users will be
>> tracked by doubleclick in perpetuity unless we fix this aspect of the
>> bug too.
>
> Could (and should :) we do something like: Add a timestamp for when the
> last first-party visit was for the site, and if you've not made a
> first-party visit within X weeks, drop the cookie.
>
> The idea being to continue to allow "grandfathered" cookies to work for
> a while, but drop them if the browser sees that the users behavior
> wouldn't have actually allowed them to have been set in the first place.
>
> Justin

This might not work. Imagine a site that requires a 2-factor-auth
cookie but that a user doesn't log into frequently (maybe a bank account
or a 401K). Not sure if these 2-factor-auth cookies ever expire, but if
they do, some don't expire for more than a month (maybe 90 days?). When
the user visits this site after 2 months of having the new pref, it will
request the 2nd factor auth data (maybe an account number). This will
happen to the user every two months when they want to check their 401K
status until we drop the "grandfathered" cookies code.

Maybe we are okay with this? Maybe we can account for when the cookie
was created, and if it was created after the partial-third party cookie
setting was set, then we don't delete the somewhat stale cookies. This
way, the user only has to deal with this second factor auth issue once.

~Tanvi

Jono Xia

unread,
Feb 27, 2013, 2:43:48 PM2/27/13
to dev-p...@lists.mozilla.org, gregg...@mozilla.com

> Probably not this week, but we're hoping very soon. If anyone wants to
> pitch in and help figure out what questions to answer and then write the
> telemetry patch (Jono?), please do!
>

Yes! It sounds like writing the patch to collect this data is pretty
important, and I have at least a vague idea how to do it, so I will
volunteer to take that on.

I would say the data to collect would be
1. Count of 3rd party cookies that would be blocked under the proposed
policy (and maybe their domains, if collecting those domains is
copacetic with our privacy policy)
2. Count of 3rd party cookies that would not be blocked under the policy
(so we have something to compare to)
3. Timestamps at which the user cleared cookies, so we can answer the
question of how frequently they're cleared.

(Adding Gregg to the conversation)

Hi Gregg,
You've been following the discussion about blocking third-party cookies
from sites the user hasn't visited, yes?

I've been out of the loop on Test Pilot -- does the User Research team
have any studies in the pipeline about cookies that would help answer
the above questions? I don't want to duplicate work here.

Since this is not particularly a user-interface-related study, it seems
like Telemetry rather than Test Pilot is probably the way to go -- does
everybody agree on that?

Thanks,
--Jono

clin...@gmail.com

unread,
Feb 27, 2013, 10:36:01 PM2/27/13
to
Hi all,

I just wanted to put out a situation. I have used embedded iframes for shopping carts (there are indeed carts which can be placed in an iframe, and cookies set in an iframe are considered third party in my understanding). These shopping carts don't let the viewer of the site to go to the main site where the owner of the page set up his embeddable store.

The requirement for this feature to allow third party cookies is to allow it if the person has gone to the actual site.

Wouldn't this break this and other similar iframe based plugins?

- Clint

Bil Corry

unread,
Feb 28, 2013, 3:15:02 AM2/28/13
to Sid Stamm, dev-p...@lists.mozilla.org
This breaks:

http://www.aboutads.info/choices/


- Bil

-----Original Message-----
From: dev-privacy-bounces+bcorry=paypa...@lists.mozilla.org [mailto:dev-privacy-bounces+bcorry=paypa...@lists.mozilla.org] On Behalf Of Sid Stamm
Sent: Wednesday, February 27, 2013 6:48 PM
To: dev-p...@lists.mozilla.org
Subject: Re: partial third-party cookie blocking

nigel.ed...@gmail.com

unread,
Feb 28, 2013, 10:39:47 AM2/28/13
to Sid Stamm, dev-p...@lists.mozilla.org
On Thursday, 28 February 2013 08:15:02 UTC, Bil Corry wrote:
> This breaks:
>
>
>
> http://www.aboutads.info/choices/
>
>
>
>
>
> - Bil



Then this will also break:
http://www.youronlinechoices.com/uk/your-ad-choices

(This is the Europe-wide self-regulatory initiative for 29 countries that gives individual users the ability to control opt-out/in of OBA - online behavioural advertising.)

goo...@nartowicz.co.uk

unread,
Feb 28, 2013, 10:49:58 AM2/28/13
to Sid Stamm, dev-p...@lists.mozilla.org
I don't see the issue here. Websites to manage tracking cookies don't work because tracking cookies are blocked. Seems like this is the intention of the change rather than a failure. The policy is now opt-in for Firefox users rather than opt-out through a website that just sets more tracking cookies.

--ian

goo...@nartowicz.co.uk

unread,
Feb 28, 2013, 10:56:29 AM2/28/13
to
I'm confused about the same-origin policy for iframes.

I have an addon that creates an iframe using javascript, and loads a third party page in it. That page set cookies, in apparent defiance of the preference. The cookies are not for the same origin as the page the frame is nested in and there are no other cookies set with the same origin.

Am I wrong? Is an addon somehow a special case? Is this a bug? Is it a known and accepted loophole?

--ian

goo...@nartowicz.co.uk

unread,
Feb 28, 2013, 10:49:58 AM2/28/13
to mozilla.d...@googlegroups.com, Sid Stamm, dev-p...@lists.mozilla.org
On Thursday, February 28, 2013 3:39:47 PM UTC, nigel.ed...@gmail.com wrote:

nigel.ed...@gmail.com

unread,
Feb 28, 2013, 10:39:47 AM2/28/13
to mozilla.d...@googlegroups.com, Sid Stamm, dev-p...@lists.mozilla.org
On Thursday, 28 February 2013 08:15:02 UTC, Bil Corry wrote:
> This breaks:
>
>
>
> http://www.aboutads.info/choices/
>
>
>
>
>
> - Bil



Jonathan Mayer

unread,
Feb 28, 2013, 3:19:32 PM2/28/13
to Sid Stamm, dev-p...@lists.mozilla.org
For discussion of the interplay with self-regulatory opt-out pages like aboutads and youronlinechoices, see https://bugzilla.mozilla.org/show_bug.cgi?id=846159

Jonathan Mayer

unread,
Feb 28, 2013, 3:22:31 PM2/28/13
to
Third-party iframes should be covered by the new policy. If you can confirm an instance where they're not (using ordinary web content), please report it on Bugzilla.

Jonathan Mayer

unread,
Feb 28, 2013, 3:19:32 PM2/28/13
to mozilla.d...@googlegroups.com, Sid Stamm, dev-p...@lists.mozilla.org
On Thursday, February 28, 2013 7:39:47 AM UTC-8, nigel.ed...@gmail.com wrote:

kani...@gmail.com

unread,
Mar 5, 2013, 4:01:27 PM3/5/13
to
Hi

I would like to confirm one thing - regarding CORS(+withCredentials)
ajax usage with cookies since i could not find any information about this.

Will firefox also block setting cookies by CORS request response headers?
I found that Safari(6) is doing it which from this new policy perspective is ok.
But on the other hand it's making CORS+withCredentials less useful.

Jonathan Mayer

unread,
Mar 6, 2013, 1:22:42 PM3/6/13
to
There are bugs open on CORS and JSONP compatibility:
https://bugzilla.mozilla.org/show_bug.cgi?id=844622
https://bugzilla.mozilla.org/show_bug.cgi?id=848437

Could you give a practical use case that you're concerned about? The only possibility that comes to mind is a third-party-only authentication flow. I'm unaware of any major service that's implemented that way, and it would be a bad idea for security reasons (i.e. no HTTPS UI).

Jonathan Mayer

unread,
Mar 6, 2013, 2:07:03 PM3/6/13
to
I should add that another possibility is a cookie-free authentication mechanism that's used in a third-party context. (See the CORS bug.) I'm also not aware of any major service implemented this way; real-world use cases welcome.

Sid Stamm

unread,
Mar 6, 2013, 5:56:38 PM3/6/13
to Jono Xia, gregg...@mozilla.com
Hey Jono!

This is a great start at a list. I would recommend pairing research
questions with each proposed collection so it's clear what we're gonna
try to know.

On 02/27/2013 11:43 AM, Jono Xia wrote:
> I would say the data to collect would be
> 1. Count of 3rd party cookies that would be blocked under the proposed
> policy (and maybe their domains, if collecting those domains is
> copacetic with our privacy policy)

This is a good idea. What we really want to know is, "What kind of
sites will not be able to set cookies?" Alexa categorizes sites,
perhaps we can measure how many cookies per category are blocked? I'm
imagining two histograms where the buckets are each category. One
histogram counts blocked cookies per category and the other allowed
cookies per category. What do you think?

I'm not sure we can collect domains via telemetry, but perhaps we can
measure some stats about cookie blockage per domain.

> 2. Count of 3rd party cookies that would not be blocked under the policy
> (so we have something to compare to)

I'd like to know both this and: what portion of domains where I send
requests are disallowed cookies? There may be a few very persistent
domains that try to set cookies frequently. Or it may be spread out.
It would be good to know how widespread the blocking will be.

> 3. Timestamps at which the user cleared cookies, so we can answer the
> question of how frequently they're cleared.

Yes. This is important. Perhaps we can measure the timestamp on the
oldest cookie in the cookie db and report that as a lower bound on
cookie lifetime.

Thoughts?

-Sid

sweeney....@gmail.com

unread,
Mar 11, 2013, 3:24:43 PM3/11/13
to
On Monday, January 14, 2013 1:24:23 PM UTC-5, Sid Stamm wrote:
> Jonathan Mayer has implemented a halfway-block feature for third party
>
> cookies.
>
>
>
> Right now, Firefox can only block BOTH { setting + getting } of third
>
> party cookies, so we can't turn it off by default. At least one other
>
> browser has something about half-way that allows the getting of cookies
>
> in third party contexts (but blocks setting). The effect is that sites
>
> you visit directly can set cookies, but sites you don't visit directly
>
> cannot.
>
>
>
> Anyway, I think we should ship this feature. I think we should ship it
>
> enabled by default, but we need to do a few things first:
>
>
>
> 1. Write the code (almost done)
>
> 2. Make sure users know the difference between this and full-strength
>
> third-party cookie blocking.
>
> 3. Make sure it doesn't cause too much breakage in the web experience.
>
>
>
> jmayer is working hard on the code. There's a reasonable UI in the bug
>
> that teases out accepting cookies "from visited" as a new feature.
>
>
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=818340
>
>
>
> We are working on a test pilot study around cookies that might help us
>
> get a good picture of how much is going to break when we turn this on.
>
> If anyone out there has some data that can educate this, I'd appreciate
>
> it. :)
>
>
>
> -Sid


What about 3rd party cookies used in a 1st party context? I know that some technologies (ours included) drop a 3rd party cookie that is solely for use by the visited site. In this case, a cookie is being set by a 3rd party to enable functionality on the visited site that is not used in any way by the 3rd party or any other party. The function of the cookie is no different than that of a 1st party cookie. Is there any possible way to account for such a scenario?

-SW

Jono Xia

unread,
Mar 11, 2013, 6:57:56 PM3/11/13
to Sid Stamm, dev-p...@lists.mozilla.org, gregg...@mozilla.com
Hi Sid,
Sorry I haven't finished this yet. I had a deadline for another project
and spent all last week on that instead.
Anyway, I talked to the telemetry guys about what it would take to
implement this. As you said, I don't think we can collect domains via
telemetry. It could be done via Test Pilot, though. I put together the
following list of pros and cons of Telemetry vs Test Pilot and would
like to hear your thoughts about which would be better.


Pros of test pilot:
- privacy policy, being opt-in, lets us ask for more info about
domains where blocking happens/doesn't happen than would be kosher with
telemetry
- easier to implement (maybe?) since doesn't require landing patch
with modifications to cookie manager and telemetry ping. (Also, I could
write it much faster, given my Test Pilot experience, than I could
implement a telemetry probe, which would be a first-time for me.)

Pros of telemetry:
- can reach nightly users, whereas test pilot mostly reaches
beta/aurora (although some nightly users install the add-on)
- start getting results immediately (well, as soon as telemetry ping
happens) rather than waiting for experiment time period to complete as
with test pilot
- get slightly more representative cross-section of users (maybe?
they're still nightly users either way)

What do you think?
--Jono

Sid Stamm

unread,
Mar 13, 2013, 1:24:30 PM3/13/13
to Jono Xia, gregg...@mozilla.com
On 3/11/13 3:57 PM, Jono Xia wrote:
> What do you think?

I think we should do both Telemetry and Test Pilot studies for this.
The time to deployment for Telemetry is significantly lower right now,
so I think we should start with that and then take on TP studies with
remaining queries.

I'm more than happy to help you get a telemetry patch landed, if you can
take lead and dig in to figure out what we should measure and also how. :)

-Sid

Sid Stamm

unread,
Mar 13, 2013, 1:26:08 PM3/13/13
to sweeney....@gmail.com
Hi Sweeney,

On 3/11/13 12:24 PM, sweeney....@gmail.com wrote:
> What about 3rd party cookies used in a 1st party context? I know that
> some technologies (ours included) drop a 3rd party cookie that is
> solely for use by the visited site. In this case, a cookie is being
> set by a 3rd party to enable functionality on the visited site that
> is not used in any way by the 3rd party or any other party. The
> function of the cookie is no different than that of a 1st party
> cookie. Is there any possible way to account for such a scenario?

Why do you drop a third party cookie when a first party cookie would
serve the same purpose? Is it to correlate data across a few distinct
domains?

-Sid

Monica Chew

unread,
Mar 13, 2013, 4:02:04 PM3/13/13
to dev-p...@lists.mozilla.org
Jono, it's awesome that you're working on this. I agree with Sid. More reasons to do telemetry:

- It's the only thing that can give a longitudinal view of how cookie accept/reject behavior changes over time. Test Pilot studies typically last only a week, but telemetry's always on.
- Test Pilot demographics are highly skewed towards power users, who almost certainly have different browsing patterns. Telemetry is separable by release channel.
- Test Pilot is current disabled (https://bugzilla.mozilla.org/show_bug.cgi?id=832702).

Monica

3rdcoas...@gmail.com

unread,
Mar 13, 2013, 8:55:55 PM3/13/13
to sweeney....@gmail.com
Hey Sid,

You seem active here, and I've been scouring this thread for a bit trying to understand ad tech implications. Would you shed some light on the following scenario as I really dont see it explicitly spelled out:


1) As a consumer I visit target.com:
- 1st party cookie set by Target.com

2) Simulatneous to that a bunch of ad tech companies set pixels & cookies as well - these are 3rd party cookies:
- Turn (a dsp turn.com)
- Dotomi (dotomi,com an ad retargeting company)
- quantcast (quantcast.com analytics provider)
- doubleclick / google (doubleclick.com / google.com etc)

3) Let's say doubleclick then makes another pixel call to another domain - (someadexchange.com)


Are all of the number 2's acceptable (even though they are considered 3rd party), while the 3rd example someadexchange.com would be blocked?

Lets leave the whole previous site visit concept out of the equation for now.

Thanks

Sweeney Williams

unread,
Mar 14, 2013, 9:43:49 AM3/14/13
to dev-p...@lists.mozilla.org
One thing I forgot to add is that in our case, using a 3rd party cookie
allows correlation of data for a distinct company across their various
domains and also allows for streamlined deployment.

-SW

Sid Stamm

unread,
Mar 14, 2013, 12:09:40 PM3/14/13
to 3rdcoas...@gmail.com, sweeney....@gmail.com
On 03/13/2013 05:55 PM, 3rdcoas...@gmail.com wrote:

> 1) As a consumer I visit target.com:
> - 1st party cookie set by Target.com
>
> 2) Simulatneous to that a bunch of ad tech companies set pixels &
cookies as well - these are 3rd party cookies:
> - Turn (a dsp turn.com)
> - Dotomi (dotomi,com an ad retargeting company)
> - quantcast (quantcast.com analytics provider)
> - doubleclick / google (doubleclick.com / google.com etc)
>
> 3) Let's say doubleclick then makes another pixel call to another domain - (someadexchange.com)
>
>
> Are all of the number 2's acceptable (even though they are
> considered 3rd party), while the 3rd example someadexchange.com would
> be blocked?
>
> Lets leave the whole previous site visit concept out of the equation
> for now.

We can't really ignore the "previous site visit" concept, but we can
start with a new install of Firefox and discuss "first visit"
situations. Given your scenario, and assuming a fresh cookie store (no
cookies), one visit to target.com would only result in target.com
cookies. The rest (part 2 and 3) are blocked.

If I click on an ad and get redirected through a quantcast page (for
example) or the someadexchange.com page, that site can set cookies
(they're a first party since they're loading in the top level of the tab).

Does this help? Once a domain has set a cookie, it can continue to set
cookies or modify them as a third party.

-Sid

Jordan Williams

unread,
Mar 14, 2013, 8:52:14 PM3/14/13
to
I've just discovered this group today, and I've been reading for the
last few hours. I have a bit of experience in this area, having
developed an addon which does all this (cookie proposal) and more. In
it's development, we went through the same processes mentioned in this
thread: grandfathering in cookies, first parties can set cookies as
third parties, limiting cookie lifespan, "click to activate" cookies,
disallowing http cookies for non-first parties, etc. We've done tests
for beacons, Etags, localStorage, and LSOs as well. Our current work is
around a technical categorization of cookies for use in preference rules
and exceptions. Basically we're categorizing cookies on the web.

Backing up for a moment, "We know what is best for our users", doesn't
sound like it should be a Mozilla philosophy. That sounds more like MS
or Oracle. To think that tracking is the only functionality that this
proposed change will affect is naive; like not believing in global
warming. Every broken web service due to this change is a win for
Chrome. Of course providing protection for users is important, but are
you going to install x-ray passenger scanners in your airports? FF
shouldn't be the one to enforce morality/legalities at the expense of
user experience. And that's what this is: morality, not security.
Whether or not Mozilla should do this is a pointless discussion
apparently; it's obvious that you think you should, so I'll not bother
arguing it further, I'll just end with "Mozilla should enable the
community", not set defaults that break the web.

Given that "change is upon us", the focus is rightfully on how to
minimize negative impact and maximize user protection. Let me start with
some information gleaned from my work: by far the most important cookies
for third party service providers are set using document.cookie. And by
an equally large margin, advertiser tracking cookies are set using HTTP
requests.

From the standpoint that blocking all cookies from third parties* is
too fascist, the simplest way to stop user tracking while not
interfering heavily with third party services is to only block third
party HTTP cookies, not third party document-set cookies. Ad publishers
are MUCH more picky about what JS they allow on their pages than
beacons, so this wouldn't just cause a migration away from HTTP-set
cookies. This restriction could even be stricter, but this would induce
complications which, in my opinion, detract from the overall simplicity.

Not to mention, that blocking third party cookies outright (ie. not
doing my proposal) would just force trackers/providers to use
localStorage instead - which has less transparency and user awareness.

Thanks for the interesting read, looking forward to comments -
JOrdan

3rdcoas...@gmail.com

unread,
Mar 15, 2013, 1:44:53 PM3/15/13
to 3rdcoas...@gmail.com, sweeney....@gmail.com
This is very helpful, thanks Sid. So last question, if someone installs the new Mozilla build does it wipe any of the previously set cookies (3rd party)? I am thinking it does not, and only if the user deletes all existing cookies would numbers 2 & 3 be blocked upon visiting a site for the first time (#1).

thanks

Sid Stamm

unread,
Mar 15, 2013, 4:18:21 PM3/15/13
to 3rdcoas...@gmail.com, sweeney....@gmail.com
On 03/15/2013 10:44 AM, 3rdcoas...@gmail.com wrote:
> This is very helpful, thanks Sid. So last question, if someone
> installs the new Mozilla build does it wipe any of the previously set
> cookies (3rd party)? I am thinking it does not, and only if the user
> deletes all existing cookies would numbers 2 & 3 be blocked upon
> visiting a site for the first time (#1).

Currently Firefox does nothing with existing cookies. We're looking
into how frequently people clear their cookies (it might not be
necessary for us to do anything for them). But we're also evaluating
other options like expiring cookies that aren't used in a first party
context for a while.

Nothing concrete yet, do you have some ideas?

-Sid

claude....@gmail.com

unread,
Mar 25, 2013, 4:57:20 PM3/25/13
to
Hi,

Our web application is a composite one where external apps can be injected in the main content flow. For example a reading activity can embed an assignment. We are naturally using IFrames for that. As the apps that are embedded are usually complex pre-existing apps, they are more often than not relying on session cookies and are originating from another domain.

We have kind of ignored the Mac/Safari issue up until now, but with this move, we must be more pro-active as the size of the potentially impacted population is much bigger (and from what I get things that were working will stop suddenly to work when the FF update is pushed).

So what I am after is the recommended approach: should the embedded app recognize the cookie set was not honored and fire up a pop-up so set in a main window? Is that the recommended approach? Or is there a less intrusive (I’ve read DOM actions in the IFrame) that could be taken?

Any guideline on how our embedded apps could be made ready would be appreciated!

Thanks,

Claude

stephane...@gmail.com

unread,
Apr 9, 2013, 6:21:01 AM4/9/13
to
Hi Claude,

I am more or less in the same situation (actually, more more than less).

Did you get make any progress in your research or dis you get any insights from your original post ?

Many thanks !

Stephane

Bil Corry

unread,
Apr 9, 2013, 6:52:54 AM4/9/13
to dev-p...@lists.mozilla.org
I never saw a response to my inquiry below. The crux of it is this: I'm a third-party site that receives DNT:0, so the user has explicitly chosen to allow me to track them, but Firefox is blocking my cookies with this feature.

What does Mozilla recommend I do to set state on the browser? I can only assume based on how this feature is designed that Mozilla's position is that the user must set DNT:0 AND enable cookies from third-parties. Is that correct? Or will you be providing a playbook of workarounds for sites to use when DNT:0 is received?

I did notice on the privacy roadmap[1] that this feature is listed as a P3 under "Not Yet Awesome Enough". Are there plans to also implement the P2 just above it, "Create API so sites can request third-party cookies"? Seems like that one is also needed to move this closer to the stated goal of making "tracking relationships more obvious to the user."

As it stands now, Firefox disregards the user's DNT choice to be tracked and silently breaks some sites. Can you provide an explanation of how this feature is making tracking relationships more obvious to the user? Because all I see is a feature that by default silently blocks third-party cookies with the user completely unaware of what is transpiring.

Obviously you can ship what you want, but if the expectation is that the user must change two different settings to enable tracking, then that isn't a meaningful choice for the user. You might as well be honest and declare Firefox to be a privacy-only browser; you can default to DNT:1, enable third-party cookie blocking, build in other technological measures to counter "tracking", and be done with it. You can't claim to support user choice[2] if you ship this feature as-is because there isn't any meaningful user choice being offered.


- Bil

[1] https://wiki.mozilla.org/Privacy/Roadmap/2012
[2] http://blog.mozilla.org/privacy/2012/05/31/do-not-track-its-the-users-voice-that-matters/


-----Original Message-----
From: Bil Corry
Sent: Monday, February 25, 2013 12:49 PM
To: Asa Dotzler; dev-p...@lists.mozilla.org
Subject: RE: partial third-party cookie blocking

On 2/23/2013 11:11 PM, Asa Dotzler wrote:
> On 2/24/2013 10:51 AM, Mxx wrote:
> > It is my understanding that the dire for this feature is to protect
> users from tracking and not to break websites' regular functionality.
>
> That is not the driver for this feature. We are not trying to stop
> tracking with this feature. We are trying to make tracking
> relationships more obvious to the user.

I fired up Nightly and set the DNT preference to 0 (aka "Tell sites I want to be tracked"). So even though I said I wanted to be tracked, when I visited a site with third-party content, all third-party cookies were blocked.

This brings up some questions:

1. To me, as a user, this is non-intuitive. Is there a way to harmonize cookie behavior with the DNT preference?

2. What does Mozilla recommend as a best practice for third-parties that have permission to track, but can't because of this new cookie policy?

3. If third-parties can't ever set state on the browser, then what's the point of DNT (since tracking is always blocked)?

4. Mozilla publicly came out against a default choice for tracking[1], yet this new cookie policy runs counter to that position by blocking tracking by default. Does Mozilla still believe tracking is an expressed user preference? Or only for DNT, but not cookies? It's somewhat hollow to say DNT should be a user-expressed preference, then prevent tracking regardless of that preference.


- Bil


[1] http://blog.mozilla.org/privacy/2012/05/31/do-not-track-its-the-users-voice-that-matters/

Bil Corry

unread,
Apr 9, 2013, 7:02:37 AM4/9/13
to dev-p...@lists.mozilla.org
I never saw a response to my inquiry below. The crux of it is this: I'm a third-party site that receives DNT:0, so the user has explicitly chosen to allow me to track them, but Firefox is blocking my cookies with this feature.

What does Mozilla recommend I do to set state on the browser? I can only assume, based on how this feature is designed, that Mozilla's position is that the user must set DNT:0 AND enable cookies from third-parties. Is that correct? Or will you be providing a playbook of workarounds for sites to use when DNT:0 is received?

joeb...@gmail.com

unread,
Apr 12, 2013, 1:20:05 AM4/12/13
to
Blocking 3rd party cookies by default seems like "censoring" the Internet. I should have the choice by default, not Firefox. If Firefox does this, I will not use it anymore. Futhermore, when it comes to ads, I'd rather get an ad that I'm actually interested in.

felix....@gmail.com

unread,
Apr 12, 2013, 12:24:13 PM4/12/13
to
This implementation doesn't really help the user, it just helps the biggest publishers Google and Facebook. With that implementation you kick smaller companies out of business but still allow the biggest publishers (google, facebook) to track users across the web by using third party cookies.
By the way, why isn't it possible for publishers to decide who is allowed to drop third party cookies on its website?
One could introduce a new header <meta allowcookiesfrom="...."> or <meta blockcookiesfrom="..."> .

I think it's a good idea to let both the user and the website decide who is allowed to drop and read third party cookies.

If the feature stays as it is I see it just as a big, big help for google in building a pure monopoly.


Sid Stamm

unread,
Apr 15, 2013, 5:46:51 PM4/15/13
to joeb...@gmail.com
You still have the choice; we're not attempting to take that away. You
can turn third party cookies back on, or (in contrast) block all of
cookies if you want. You can even pick which sites are allowed to use
third-party cookies (though the UI for this is not quite awesome yet).

-Sid

Dennis Dayman

unread,
Apr 17, 2013, 9:53:57 AM4/17/13
to dev-p...@lists.mozilla.org, Sid Stamm
Agree that their is choice switch, but the choice seems to be yours (mozilla) and not the consumer which seems like your telling them they are to dumb to do this

Webster define's Choice

the act of choosing
power of choosing

Basically saying the individual makes the choices

Why can't Mozilla create a proper set-up wizard like IE that gives the consumer choice at install or upgrade? Seems harmless and not hard vs. you burying this chosen method and them not knowing that have choice.

Again, I have no issues with blocking cookies whether first or third, but its how you NOT giving the user ability to choose for themselves.

-Dennis

Sid Stamm

unread,
Apr 17, 2013, 11:40:00 AM4/17/13
to Dennis Dayman
On 04/17/2013 06:53 AM, Dennis Dayman wrote:
> Why can't Mozilla create a proper set-up wizard like IE that gives
> the consumer choice at install or upgrade? Seems harmless and not
> hard vs. you burying this chosen method and them not knowing that
> have choice.

Setup wizards aren't very effective from a user experience point of
view. There is a limit to how many things we can ask before people
decide "Firefox is annoying me" and never actually use it to browse the
web -- and then how do we know what is "most important" to ask? There
are literally hundreds of different things users can configure in the
Firefox settings pane, and surely we're not going to ask them what they
want for each and every one of those! Of course we very well could
supply a "cancel" button or "express" configuration in such a wizard,
but that very popular option would be chosen by most people and their
Firefox would continue to carry the factory defaults -- effectively
behaving the same as what we're doing now.

> Again, I have no issues with blocking cookies whether first or third,
> but its how you NOT giving the user ability to choose for
> themselves.

Can you help me understand how this isn't providing choice? My
impression is that it provides *more* choice than before because we're
introducing a new option.

Firefox users will always be able to change their cookie settings back
to accepting all, blocking third party cookies fully, or blocking all
cookies -- all in addition to this new setting which happens to be the
new default. They have the power to choose (to put it in Webster's words).

-Sid

alexbl...@gmail.com

unread,
May 9, 2013, 12:19:06 PM5/9/13
to
> This won't affect cookies for sites that already set
> a cookie on the browser

for what reason?
what is the difference between site i have visited, and site i havent?

this makes huge preferences for web-monopolies like Google, Facebook, so on. And it is doesnt seems pretty fair.

Tetsuharu OHZEKI

unread,
Jun 20, 2013, 11:16:37 AM6/20/13
to dev-p...@lists.mozilla.org
I read the post of Brendan's latest blog:
https://brendaneich.com/2013/06/the-cookie-clearinghouse/

In the post, I read like that Firefox introduces a exception list
(black list or white one) approach as Safe Browsing for blocking 3rd
party cookie problem.

I understand Mozilla works for online privacy, and cheer its work.
But this problem is not like so. I think it is bad approach about
introducing exception list based system for blocking 3rd party cookie.

Safe Browsing system has very cleary criterion and fair approach.
Because its criterion is whether the website spreads the malware, or
not. It's very simple and fair.

However, the situation of 3rd party cookie is different from Safe
Browsing.There is no clear rules to decide whether the website is bad
"exception" or not. It's very ambiguity. So how do we decide the
website is "exception"? It would be very floating definition by
person. Of course, the website which is not respect DNT policy may be
good definition. (In some country, Do Not Track approach is not legal
definition.) But we cannot inspect in his server, thus we don't have
a way to check it perfectly.

I think that the "exception list" approach is not good for resolving
3rd party cookies problem. And Safari-like 3rd party cookie policy by
default enabled is not resolve any problem. This is not good for web.

--
Tetsuharu OHZEKI <saneyuki_s>
saneyuk...@gmail.com

Monica Chew

unread,
Jun 20, 2013, 6:24:44 PM6/20/13
to Tetsuharu OHZEKI, dev-p...@lists.mozilla.org
Hello,

> However, the situation of 3rd party cookie is different from Safe
> Browsing.There is no clear rules to decide whether the website is bad
> "exception" or not. It's very ambiguity. So how do we decide the
> website is "exception"? It would be very floating definition by
> person. Of course, the website which is not respect DNT policy may be
> good definition. (In some country, Do Not Track approach is not legal
> definition.) But we cannot inspect in his server, thus we don't have
> a way to check it perfectly.

This is a valid point. You are right that it is not a perfect solution. In many ways the Cookie Clearinghouse approach reminds me of managing trusted CA lists. In both cases, the policy around who is "trusted" is difficult to specify, can't be enforced technically, can only be audited occasionally, and is rife with trouble. I don't think the question should be whether or not the Cookie Clearinghouse approach (or the trusted CA approach) is perfect, but whether it's better than the nothing. I think it might be.

> I think that the "exception list" approach is not good for resolving
> 3rd party cookies problem. And Safari-like 3rd party cookie policy by
> default enabled is not resolve any problem. This is not good for web.

I did not get the sense from Brendan's blog post that the Cookie Clearinghouse approach was the end of the story. Firefox isn't just going to implement something without regard to whether it breaks the web. In fact, Cookie Clearinghouse is an attempt to *not* break the web. We shouldn't let fear prevent us from experimentation, even if that experiment fails.

Thanks,
Monica

Bil Corry

unread,
Jun 21, 2013, 10:30:23 AM6/21/13
to Monica Chew, Tetsuharu OHZEKI, dev-p...@lists.mozilla.org
> I don't think the question should be whether or not the Cookie
> Clearinghouse approach (or the trusted CA approach) is perfect,
> but whether it's better than the nothing. I think it might be.

I suppose it depends on which "nothing" you're looking at. If Mozilla simply leaves the cookie policy alone, all sites continue to work and users can still choose to block third-party cookies if they accept its given compatibility challenges. As a user, that's the default setting I want - a browser that works out of the box.

I know the thought is to block advertisers from tracking users, but there's two problems with this approach, 1) there are non-advertising use cases that this breaks, and 2) advertisers are already moving to other state mechanisms, which leaves only the non-advertising use cases to bear the brunt of this feature. Granted, the Cookie Clearinghouse will help to some extent, but it's reactive and the earliest we'll see it in Firefox is toward the end of the year.

The largest issue with the proposed cookie blocking scheme is that it silently fails, so the user believes the problem is with the website, when in fact the problem is with their (soon-to-be-default) settings. Perhaps the more charitable websites will educate the user on how to make the browser work again, which will require the user to change the cookie setting back to "normal" - what a pain for users and websites, with no net gain.

If Mozilla is really going to push out the cookie blocking feature, it should do what NoScript, AdBlockPlus, and similar tools offer - a UI experience that alerts when items are blocked and allows the user to enable those blocked items. At least that gives the user a fighting chance to know what is going wrong. Additionally, the stated goal for this feature is to make cookies more transparent, what better way than to provide a UI that shows all the blocked cookies and allows the user to unblock them. It can work in conjunction with the Cookie Clearinghouse and wouldn't be much different than the IE compatibility view feature where there's a whitelist, but it also offers a UI for the user to override.

The other related option to consider is an API so that websites can request an exception to the third-party cookie blocking. It's on the 2012 privacy roadmap, so presumably someone has given it some thought.

> We shouldn't let fear prevent us from experimentation, even if that
> experiment fails

Can you share the criteria of what constitutes failure for this feature?


- Bil




It is loading more messages.
0 new messages