Closed Bug 999170 Opened 8 years ago Closed 6 years ago

Back out bug 851606 to enable bug 818340 on the default 3rd-party cookie policy for releases

Categories

(Core :: Networking: Cookies, defect)

31 Branch
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: rsx11m.pub, Unassigned)

References

Details

(Keywords: site-compat)

+++ This bug was initially created as a clone of Bug #851606 +++

> Making sure we're tracking whether or not we should uplift bug 818340.

Currently, bug 851606 disables the feature to block 3rd-party cookies from websites not previously visited by default for release versions.

(Quoting rsx11m from bug 818340 comment #145)
> (In reply to Jonathan Mayer from bug 818340 comment #98)
> > > See also: https://brendaneich.com/2013/06/the-cookie-clearinghouse/
> > 
> > I'm a member of the Cookie Clearinghouse Advisory Board. It's an exciting
> > initiative! I don't, however, see why this patch should wait even longer
> > while that project spins up. We shouldn't make the perfect the enemy of the
> > good. Moreover, in effect, shipping this patch as-is would be functionally
> > identical to supporting Cookie Clearinghouse now, in that the lists are
> > presently blank.
> 
> So, bug 885136 on the Cookie Clearinghouse has been won't-fixed for now given
> that those efforts have apparently stalled. For the last six months now,

(actually, a bit longer as for the previous releases, the patch was manually backed out prior to the merges before introducing the current #ifdef solution.)

> bug 851606 has been in effect, disabling the feature in the releases by default
> while keeping it for the nightly and beta builds (not having  a consistent
> behavior between testing and release builds by itself is probably discouraged).
> 
> Thus, isn't it time to revisit this and consider backing out mozilla-central changeset 076b8758ecb0?
> 
> This is a useful feature, would be nice to have users benefit from it by default in the releases too.
> [...]

I'm marking the version specifically as 31 branch given that it will be the next ESR branch, thus a decision one way or the other may affect users for another year.
I agree that having different default behavior in Nightly/Aurora vs other channels is disruptive, and disagree that backing out bug 851606 is the right way to solve it.

This pref now breaks our own services (see bug 998033) and it would be mistake to enable it especially for ESR without a UI for remediation.

Now that Cookie Clearinghouse is shuttered there's not a clear path forward for that.
(In reply to Monica Chew [:mmc] (please use needinfo) from comment #1)
> This pref now breaks our own services (see bug 998033)

Actually, that appears to already be fixed.

https://github.com/mozilla/fxa-content-server/commit/c75bf6801eb764bfd773c0b831381dd6a58157ea
> Actually, that appears to already be fixed.
> https://github.com/mozilla/fxa-content-server/commit/c75bf6801eb764bfd773c0b831381dd6a58157ea

The "fix" is to work around the policy by using localStorage instead of cookies, which is exactly what other sites would do to work around this. 

This policy is ineffectual as it stands (applies to cookies, but not localStorage or cache), and extending the policy to other forms of storage would then break FxA as currently implemented in Desktop, as well as other "non-tracking" 3rd party services.
(In reply to Chris Karlof [:ckarlof] from comment #3)
> This policy is ineffectual as it stands (applies to cookies, but not
> localStorage or cache)

Partially effective is not the same as ineffective.
(In reply to Chris Karlof [:ckarlof] from comment #3)
> The "fix" is to work around the policy by using localStorage instead of
> cookies, which is exactly what other sites would do to work around this. 

Maybe I'm mixing this up, but isn't the user asked for permission when a site requests to put data into offline storage? At least on SeaMonkey he or she is, thus having to give an explicit consent.
Nothing's significantly changed since the decision in bug 851606 to not release this, as far as I know. That suggests WONTFIX here.

If we want to address the inconsistency between Nightly/Aurora and Beta/Release in the interim, we should back out bug 818340 from Nightly/Aurora.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #6)
> Nothing's significantly changed since the decision in bug 851606 to not
> release this, as far as I know. That suggests WONTFIX here.

There have been at least two substantial changes since Brendan pressed pause on cookie blocking. First, the alternative path (Cookie Clearinghouse) has stalled out. Second, the whole Brendan thing. If the Mozilla community affirmatively decides to bail on third-party privacy, so be it. But that's certainly not a decision that's been made yet.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Yes, it was my understanding from bug 851606 that waiting for a Cookie Clearinghouse was a substantial (if not the triggering) factor in delaying bug 818340 on the release builds. I wouldn't have filed this follow-up reopening the discussion if bug 885136 hadn't been won't-fixed as those efforts seem to have stalled at least, if not abandoned. This suggests to reconsider the decisions made in bug 851606 for a semi-permanent backout on releases in light of the other mechanism not coming any time soon.
Status: REOPENED → NEW
What's the best way to get an actual decision here? Schedule a community meeting in Mountain View? It would be a shame to let this languish for another year.
(In reply to Jonathan Mayer from comment #7)
> First, the alternative path (Cookie Clearinghouse) has stalled out.

That means we have even less of a solution to the problems preventing us from implementing the policy - that's an additional argument in favor of WONTFIXing this.

> Second, the whole Brendan thing.

Not relevant.
Status: NEW → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → WONTFIX
Well, so waiting for the Cookie Clearinghouse was an important reason to defer this policy on the release channel, now the apparent lack of a Cookie Clearinghouse being available any time soon is an important reason to not implement this policy on the release channel as well. Somewhat twisted logic.

Instead of stubbornly won't-fixing this bug, I was hoping for some definition which criteria have to be met to introduce this feature on release by default as well, then keeping the bug open until such are satisfied to the extent that the policy will be employed. Also, if there are loopholes present like the offline storage web applications can use (unless "localstore" literally refers to localstore.rdf, where I wouldn't know why websites should have access to those), and Firefox doesn't ask the user for consent when permitting such storage, wouldn't it obviously be better to fix that issue as a dependency rather than just arguing that it is a workaround?
(In reply to rsx11m from comment #11)
> loopholes present like the offline storage web applications can use [...]
> and Firefox doesn't ask the user for consent when permitting such storage,

Firefox defines pref("browser.offline-apps.notify", true); by default as well, thus I don't know how this mechanism could possibly be used to bypass cookie restrictions without the user noticing it.
Again, what's the best way to constructively resolve this? There are plainly views for and against. Let's actually talk, instead of flipping NEW -> WONTFIX -> REOPENED -> NEW -> WONTFIX -> ...

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #10)
> (In reply to Jonathan Mayer from comment #7)
> > First, the alternative path (Cookie Clearinghouse) has stalled out.
> 
> That means we have even less of a solution to the problems preventing us
> from implementing the policy - that's an additional argument in favor of
> WONTFIXing this.

We had a good approach. We paused it for a better approach. The better approach is stalled. So now let's go back to the good approach.

> > Second, the whole Brendan thing.
> 
> Not relevant.

This isn't a political point. Brendan was probably the greatest obstacle to progress on the patch. He's no longer working on the issue, to the best of my knowledge.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Re my comment #11, understanding now that localStorage is yet another mechanism parallel to cookies and web-application offline storage. Having had a look at http://scarybeastsecurity.blogspot.com/2009/12/bypassing-intent-of-blocking-third.html it appears that bug 536509 should close that loophole and even has a draft patch posted. Thus, I'd see bug 818340 and bug 536509 as complementary measures.

(In reply to Jonathan Mayer from comment #13)
> We had a good approach. We paused it for a better approach. The better
> approach is stalled. So now let's go back to the good approach.

Exactly.
Status: REOPENED → NEW
I hope http://yahoopolicy.tumblr.com/post/84363620568/yahoos-default-a-personalized-experience happening helps this move along a bit more quickly.
Why, in the first place, did bug 885136 become WONTFIX, instead of just assigning it to nobody@mozilla.org ? Even if a developer has gone (for the time being), open-source community is able to find out another, in my opinion.
(In reply to Mardeg from comment #15)
> http://yahoopolicy.tumblr.com/post/84363620568/yahoos-default-a-personalized-experience

While DNT is certainly a commendable initiative, its inherent problem is that this mechanism relies on websites voluntarily obeying it. The big players in the tracking business not unexpectedly didn't sign up (Yahoo leaving it), and some are even bluntly adding the DNT header to their tracking heuristics.

That's even more a reason to take action on the browser side already with decent defaults to give the user more control on tracking (3rd-party cookies obviously being one component of this).
(In reply to comment #16)
> Why, in the first place, did bug 885136 become WONTFIX, instead of just
> assigning it to nobody@mozilla.org ? Even if a developer has gone (for the time
> being), open-source community is able to find out another, in my opinion.

WONTFIX is a signal that even if someone writes a patch to implement the functionality specified on the bug, it will not get accepted into our code base.
To be read as: Even if someone else picks up the Cookie Clearinghouse efforts and builds it, Mozilla wouldn't use it? This sounds like perfect fodder for Firefox/Google conspiracy theories. :-D
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #18)
> WONTFIX is a signal that even if someone writes a patch to implement the
> functionality specified on the bug, it will not get accepted into our code
> base.

I know that, and that's exactly why I'm asking the reason. To be clear, Monica wrote

> Cookie clearinghouse has stopped work so far as I know.

, and that is not a good reason to stop entirely developing Cookie Clearinghouse, because bug 885136 seems the only rightful blocker of *this* bug. I, unlike Jonathan and Brendan, don't think CCH would be the better approach than what it is now. However, Brendan explained its merits on his blog and it had been their common goal. Now I'm just curious why it disappeared all of a sudden. Too bloat to support?

> To be read as: Even if someone else picks up the Cookie Clearinghouse
> efforts and builds it, Mozilla wouldn't use it? This sounds like perfect
> fodder for Firefox/Google conspiracy theories. :-D

I think it's not that bad.
(In reply to Jonathan Mayer from comment #13)
> We had a good approach. We paused it for a better approach. The better
> approach is stalled. So now let's go back to the good approach.

Not how I see it. We had an approach that caused too much collateral damage. We launched an effort to address that collateral damage with a different approach. That approach stalled. We're back to just having an approach that causes too much collateral damage.

I'm not any more interested in WONTFIX/REOPEN back and forth than you are, andthe bug's state has little effect on convincing anyone of anything. Back and forth here isn't a useful way to change the status quo, and the status quo is WONTFIX - hitting the "REOPEN" button isn't going to change that.
(In reply to O. Atsushi (Torisugari) from comment #20)
> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #18)
> > WONTFIX is a signal that even if someone writes a patch to implement the
> > functionality specified on the bug, it will not get accepted into our code
> > base.

WONTFIX is also a way to have the bug's state reflect reality. An open bug that has no chance of being fixed isn't very useful (and is potentially misleading). Feel free to reopen the bug, but it doesn't really make much difference in practice if no one's going to fix it.
(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #21)
> We had an approach that caused too much collateral damage.

According to the online advertising industry's trade groups, sure. According to Mozilla's own bug reports, no. That's just not true.
(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #21)
> I'm not any more interested in WONTFIX/REOPEN back and forth than you are,
> andthe bug's state has little effect on convincing anyone of anything. Back
> and forth here isn't a useful way to change the status quo, and the status
> quo is WONTFIX - hitting the "REOPEN" button isn't going to change that.

Well, as you should know there is a subtle difference: NEW means "it's still on the table" whereas I'd read WONTFIX as "forget about it" with little chance to get ever implemented. Also, NEW bugs show up in default searches whereas WONTFIXed ones don't. There have been plenty of bugs lingering around for years in a NEW state which eventually got fixed once the conditions were right or someone got around to prepare and post a patch, and in this case it indicates that there's still a job to do.

The chance I'd certainly see here is that the workarounds currently allowing websites to bypass the measure can be fixed, and hopefully will so in the future, thus making this cookie-blocking policy more effective (i.e., a dependence on bug 536509 and possibly others). On the other hand I don't see the reason why those should be hard dependencies as the studies cited in bug 818340 don't seem to support your "caused too much collateral damage" assessment at all. So, what are the supporting data for that statement?
Status: NEW → RESOLVED
Closed: 8 years ago6 years ago
Resolution: --- → WONTFIX
Patrick, I'd assume that it's customary to at least provide an explanation for the reason of won't-fixing a bug at *this* time. Simply declaring it a WONTFIX without any comment is not acceptable conduct in an open-source community. Thanks!
Flags: needinfo?(mcmanus)
comment 22.
Flags: needinfo?(mcmanus)
comment 24.

That was two years ago, a couple of related bugs were fixed since that we were waiting for. Unless we are restricted to 0- and 1-liners in bugzilla discussions these days, I was assuming a more current reason than "I close this bug because I feel that I want to do so right now."

Having said that, it's obvious that Firefox drivers have created facts and successfully ignored arguments in favor of this mechanism. There are other approaches now in place such as active tracking protection, which may be more effective if maintained properly, thus I'd see the "reflect reality" part. Nevertheless, handling of 3rd-party cookies would be orthogonal and thus complementary.

Anyway, if someone wants to keep this request alive, feel free to reopen this bug.
You need to log in before you can comment on or make changes to this bug.