A Fool’s Wisdom

On Sunday, Mozilla developers reverted a change to cookie handling that was going to make web mashup and widget developers’ lives horrible in Firefox 3 — it would likely have been a disaster for Firefox and Mozilla. Thank you team Mozilla for addressing this in such a timely manner!

The Automattic team have always been huge fans of Firefox. My colleagues including Matt, Mike, and Raanan have found time to test the Firefox 3 betas. Asa calls Beta 3  “the beta you can’t resist“. If I didn’t have a baby on the way, and too much exciting work related to WordPress 2.5, and WordPress.com VIP customers, I’d be embarrassed that I haven’t found time yet.

Recently my colleagues noticed that a number of features on WordPress.com weren’t working properly. Mike investigated, and discovered that Firefox 3b3 blocked access to 3rd party cookies. He did an excellent job reporting the issue Bug 417800: 3rd party cookies should be *sent* even when blocked from being *set*:

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3

Cookie sets should not be accepted from third party sites, but cookies should still be *sent* to third party sites.Bug 324397 was closed by changing the default of network.cookies.cookieBehavior from 0 to 1. Now Third party cookies cannot be set (e.g. within an iframe). I understand and support this behavior.However, pre-existing cookies for that third party are not currently *sent* to that third party. I believe this behavior is incorrect and is an unintended consequence of changing the default “accept cookie sets from third party sites” behavior.

Reproducible: Always

Steps to Reproduce:
1. User goes to example.com and logs in to that site. example.com cookie is set.
2. User goes to a different site: example.NET which contains a “widget” for example.com: an iframe showing example.com content to logged in users.
Actual Results:
Since Firefox 3b3 does not send pre-existing cookies to third party sites, that example.com widget does not work from example.net.

Expected Results:
Firefox should send third party cookies so that the example.com widget works.

Related bugs:
1. Bug 324397: deals with accepting cookie sets from third party sites.
2. Bug 417286: deals with UI for allowing cookie sets from a whitelist of third party sites.

And in a comment:

I don’t believe my proposal would revert the earlier decision to not accept third party cookies. I think my proposal lies between two extremes: never doing anything with 3rd party cookies (current behavior), and allowing anything with 3rd party cookies (old behavior).

For about a week it the ticket didn’t receive much attention, other than from Jo “FBI plant” Hermans, who didn’t acknowledge the pragmatic problems this change caused.

It is hard to know whether a ticket just hasn’t been noticed yet, or if it is being ignored. This situation reminded me of WordPress, like any software projects, challenges in this area, and the importance of your bug triage team and area owners.

After reviewing the bugs, from my layperson’s perspective, I reached out to the always generous Jesse Ruderman, Mozilla Security expert, and he reviewed the ticket, and he suggested that possibly the strongest argument would be to show this behavior not being consistent with the other most popular web browsers — contrary to what the other bugs described. I related this to Mike and Matt.

Like how we, WordPress developers, are incredibly sensitive and jaded about blog spam, Mozilla developers are sensitive to browser spam, so reverting any change like would only come reluctantly.

Matt updated the ticket:

http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager06.html

Even if you clear cookies and block third party cookies, you’ll still likely see pagead2.googlesyndication.com there.

That’s not really the issue though.

Good guys, normal widgets, and many sites use iframes to tie distinct sites together are being punished by behaviour that changed from b2 to b3 and there is no good guy workaround for. The new stats widget in 2.5 shows a beautiful iframe-loaded flash graph in IE6+, Safari, and Firefox through 3b2, but now in b3 it shows a login form. Even if I submit the login and get new cookies (although they already exist), if I navigate away from the page or reload it wants me to login again. (And again.)

I’m most familiar with how this breaks things around WordPress because that’s what I work with every day inside of Firefox, but would it help to find other examples of widgets or functionality broken by this change in b3?

Every project does it, but such a change shouldn’t have passed the first gate for approval mid-beta.

Mike Beltzner, Mozilla.com Director of User Experience, thankfully joined the conversation at this point:

At the very least, we need to revert the change from bug 324397. The foundational assumptions in that bug (that this wouldn’t affect web-compat) turned out to be wrong.

Then Dan Witte, Cookie Area Owner, closed the door:

(In reply to comment #9)
> As mentioned above, Bug 324397 comment #39 says the change in that bug brings
> FF in line with Safari and IE.

it turns out bug 324397 comment 39 isn’t accurate. to help clear up all the confusion around this issue, i’ve posted comparisons between FF, Safari, IE6, and IE7 in bug 417286 comment 14. to summarize:

1) IE6, IE7, and Safari 3’s third-party blocking works only when setting cookies. once a cookie is set, it can be read third-party or not. our feature has always blocked setting and reading.

2) IE6 and IE7 (at least) can use the p3p policy to determine whether to permit setting of a third-party cookie. per comment 9, it appears that Safari can also do this, though i haven’t verified that.

3) all browsers have the ability to block third party cookies in iframes.

…

in the face of the problems this feature has caused, we should revert the default pref, and leave this as an option. since it appears to be reasonably effective (at least moreso than the competition), it would be nice to add this back into the pref panel as a choice, rather than keeping it hidden - but that’s an l10n call for drivers to make. people who want this should use it in conjunction with whitelisting for legitimate sites. (given the amount of confusion around whitelisting, better discoverability of this feature seems necessary - but that’s a different topic.)

The behavior has been reverted. Thank you!

Maybe, you have to be strange like me to enjoy a bug report and solution unfolding, but I really enjoyed reading all of the strong arguments, and my two favorite teams working together.

I actually went to the ticket at this time to figure out what were the next steps to see this issue resolved. I was ecstatic that it is already resolved! My thought was that more examples of web breakages would be necessary and that I would reach out to be mashup and web widget experts like Niall Kennedy.

Jo Hermans, Jesse Ruderman, Daniel Veditz, and Dan Witte present a lot important points on web privacy in the ticket, and it is because of the Mozilla team’s approaches and actions that there isn’t another browser I trust as much for the best privacy and security experience.

I love how Firefox is always on the front line battling for the best experience, and look forward to Firefox 3 and everything else coming out of Mozilla!