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

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

On 1/14/13 11:57 AM, Benjamin Smedberg wrote:
> * 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?

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

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.

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.

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

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:

> 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. :/

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.

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.

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.

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

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.

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

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

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

> Brian Smith wrote:
> 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?

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

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

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

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

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.

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

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

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?).

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

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

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?

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

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.

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.

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.

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.

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.

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

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.

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.

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.  :)
>
>
>

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.

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.

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.

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?

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

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

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.

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

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

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

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

Alexander Hanff

-----Original Message-----
From: dev-privacy-bounces+a.hanff=think-privacy.com@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

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.

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.

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

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.

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

> 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!
>

-----Original Message-----
From: dev-privacy-bounces+bcorry=paypal.com@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

On Thursday, 28 February 2013 08:15:02 UTC, Bil Corry  wrote:
> This breaks:
>
>
>
>         http://www.aboutads.info/choices/
>
>
>
>
>
> - Bil
 

On Thursday, February 28, 2013 3:39:47 PM UTC, nigel.ed...@gmail.com wrote:

On Thursday, 28 February 2013 08:15:02 UTC, Bil Corry  wrote:

> This breaks:
>
>
>
>         http://www.aboutads.info/choices/
>
>
>
>
>
> - Bil
 

On Thursday, February 28, 2013 7:39:47 AM UTC-8, nigel.ed...@gmail.com wrote:

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)

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

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

On 3/11/13 3:57 PM, Jono Xia wrote:
> What do you think?

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?

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.

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

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.  

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.

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

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

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

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

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

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

> You are right that leaving everything alone means that no browser changes
> will break the web. However, by now I think it is clear that a substantial
> minority (11%) of users do care about tracking [1],

> and further more hardly
> any users (< 1%), even technological enthusiasts, know about or can manage
> their cookie settings effectively [2]. Going back to the CA analogy,
> accepting all CA authorities by default would certainly not break the web in
> the sense that pages will render effectively, but I am willing to bet that
> most people on this list would think that enabling all CA authorities by
> default is not a good idea [3]. I think the point of this effort was to move
> the ecosystem so that all users benefit, not just technology enthusiasts and
> privacy geeks.
>
> [1] https://dnt-dashboard.mozilla.org/
> [2] http://monica-at-mozilla.blogspot.com/2013/02/writing-for-98.html
> [3] https://www.google.com/search?q=diginotar+revoke

> > 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 current, experimental policy is only on by default in Nightly and Aurora
> users (0.1%), and so does not break the web for the vast majority of Firefox
> users who are on stable or slightly behind [4]. From my reading of Brendan's
> blog post the plan is to try out the Cookie Clearinghouse before progressing
> the new policy, so there shouldn't be a time when the false positive case you
> mention breaks the web for stable Firefox users.
>
> [4] http://en.wikipedia.org/wiki/Template:Firefox_usage_share

> > > 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?
>
> I think that some reasonable success criteria would include:
>
> - Cookie Clearinghouse is able to come up with well-defined criteria for the
> lists and a reasonable way to maintain them
> - Firefox is able to consume the lists with negligible performance overhead
> - The lists function as intended (< x% for some small x false positives or
> negatives for stable Firefox users)
> - To your point about user confusion, in the case of false positives or false
> negatives, the UI is sufficiently enlightening for enough people to report
> the false positive or negative into Cookie Clearinghouse

On 06/24/2013 03:53 PM, Ian Thomas wrote:
> Other than the posts by Bil Corey, the recent discussion on this
> thread seems to be about the details of the technical implementation.
> Have we even agreed that this is a good move for the eco system of
> the web, and especially for people who are privacy sensitive?

> In my opinion it is impossible to prevent a user being tracked from
> one website to another as there are just too many ways of passing
> data, each of them serving a useful purpose. If we were to block all
> of them then the web wouldn't be anything like as powerful as it is
> today.

> That's not to say we should give up on privacy, but we should
> concentrate on the areas where we might succeed: initiatives such as
> Do Not Track and other more political and educational approaches.

> You should also not assume that users do not want to be tracked.
> Millions of people opt-in to having their grocery shopping habits
> tracked in return for a 1% discount and the occasional money-off
> coupon.

On Tuesday, 25 June 2013 00:31:11 UTC+1, Sid Stamm  wrote:
> I don't think we all agree it's the best route, but it's worth trying
> out.  At least as initially conceived (in a way that blocks all
> unvisited sites) it has user-expectation and accuracy problems. Brendan
> has written up some of his concerns.
> https://brendaneich.com/2013/05/c-is-for-cookie/

> > In my opinion it is impossible to prevent a user being tracked from

>
> I wouldn't write it off as impossible, but yeah, it's incredibly hard
> and would probably greatly degrade the web experience.

> Can we make cookies more useful *and* more transparent?  Can we drive
> the fair players away from cookies onto some tech that's more useful for
> their purposes and also in better control of the users?

> I don't want to assume users hate tracking, but the opt-in rate to DNT
> is staggering -- higher than any off-by-default feature in Firefox.
> This means quite a few people want tracking control of some sort.

> Not sure where you're shopping, but my frequent shopper card gives me
> more like 10%, the card doesn't automatically present itself and I know
> when the card is used and that it is used by only the grocery store (not
> the library or parking meters).  So it's already far less subtle than
> cookies.

> If you track my purchases via swiped credit card without
> telling me it's for more than payments -- that's more like cookies.

> It would be interesting if the DNT Dashboard
> also showed the number of signals received for DNT-0, DNT-unset (missing),
> and DNT-other (if any).  For example, what would it mean if DNT-0 was also
> 11%?  Those numbers could be interesting.

> Small aside: does the DNT
> Dashboard count raw requests, that is, could someone just ping the blocklist
> endpoint repeatedly to up-vote their favorite DNT signal?

> > It would be interesting if the DNT Dashboard also showed the number of
> > signals received for DNT-0, DNT-unset (missing), and DNT-other (if
> > any).  For example, what would it mean if DNT-0 was also 11%?  Those
> > numbers could be interesting.
>
> For Desktop users, the latest figures are:
>
> DNT not set = 89.28%
> DNT: 0 = 0.03%
> DNT: 1 = 10.68%