Hi Monica, Your study says "Set-Cookie headers are not the only method for setting cookies, but they are sufficiently prevalent to be representative" but this is inaccurate.
You did not measure javascript writes to document.cookies so must have missed the majority of cookies. For example google-analytics script creates __utmX cookies (one with a 2 year expiry) via writes to document.cookies and is on over 70% of the top 100,000 websites making them the most ubiquitous cookies out there, and your study missed them. These (javascript generated) cookies can be first or third party (they can be created by script inside third-party frames). The only way that third-party cookie using organisations have for co-opting first-party cookies is to get the first-party site to install a script library that writes to document.cookies, and then communicate this in URL query parameters or postMessage events. This puts some organisation road blocks in helping to reduce its prevalence. You are correct that bug 818340 does not handle this third-party co-option of first-party cookies, but it does give users a way to block many cookies placed by non-script content, both via document.cookies writes and HTTP response headers. If your study has not uncovered a downside from doing that there is no reason why is should not be deployed. Even in the unlikely event a problem (with the default) did appear, this could be alleviated by only enabling the block when the DNT signal was set. The first-party co-option case could then be addressed in a follow on. Mike -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: 25 October 2013 16:55 To: [email protected] Subject: [Bug 818340] Block cookies from sites I haven't visited Do not reply to this email. You can add comments to this bug at https://bugzilla.mozilla.org/show_bug.cgi?id=818340 --- Comment #134 from Monica Chew [:mmc] (please use needinfo) <[email protected]> 2013-10-25 08:55:20 PDT --- My interpretation of the data from http://monica-at-mozilla.blogspot.com/2013/10/cookie-counting.html is that this patch does not make a difference, either way -- it affects 9% of third-party cookies, and many of the organizations using third-party cookies have workarounds that allow them to set third-party cookies in a first-party context. It seems clear that we need to do something and equally clear that this patch is not the answer. I think this patch was useful in understanding challenges in doing privacy-related work, but has reached the end of its usefulness. Beyond the scope of this bug, it doesn't seem possible to do experimentation in this area without a coherent strategy. Small technical changes incur a lot of non-engineering overhead resulting in stop energy. We need to be smarter about how we approach the problem, not just throw together a bunch of piecemeal changes. -- Configure bugmail: https://bugzilla.mozilla.org/userprefs.cgi?tab=email ------------------------------- Product/Component: Core :: Networking: Cookies ------- Tracking Flags: ------- status-firefox22:disabled ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
