The restriction to third-party requests is an interesting suggestion and might provide some of the benefits Chris mentioned in the original proposal. Seems like a change done carefully and with others. best, Joe
On Thu, Apr 14, 2016 at 4:32 PM, Martin Thomson <m...@mozilla.com> wrote: > I would like to see other browsers on board before taking on these risks. > > And a lot more testing. > > For instance, is there a way to collect telemetry on the impact of > such a change without actually implementing it? Does restricting it > to 3rd party requests change things? > > On Fri, Apr 15, 2016 at 1:42 AM, Benjamin Smedberg > <benja...@smedbergs.us> wrote: >> I don't see how we can do this by default without harming our users. We can >> be confident that this will break persistent login for lots of sites. I >> appreciate the goal of moving HTTPS forward, but we are not in a position >> where we our marketshare would force changes to the web ecosystem. >> >> Before turning this on by default, could we try exposing this to advanced >> users (perhaps via test pilot or a similar extension), and try out some UI >> options so that users have some ability to override this? >> >> Or could we explore doing this first only for 3rd-party requests. >> >> I oppose this proposal as written. >> >> --BDS >> >> >> On Thu, Apr 14, 2016 at 4:54 AM, Chris Peterson <cpeter...@mozilla.com> >> wrote: >> >>> Summary: Treat cookies set over non-secure HTTP as session cookies >>> >>> Exactly one year ago today (!), Henri Sivonen proposed [1] treating >>> cookies without the `secure` flag as session cookies. >>> >>> PROS: >>> >>> * Security: login cookies set over non-secure HTTP can be sniffed and >>> replayed. Clearing those cookies at the end of the browser session would >>> force the user to log in again next time, reducing the window of >>> opportunity for an attacker to replay the login cookie. To avoid this, >>> login-requiring sites should use HTTPS for at least their login page that >>> set the login cookie. >>> >>> * Privacy: most ad networks still use non-secure HTTP. Content sites that >>> use these ad networks are prevented from deploying HTTPS themselves because >>> of HTTP/HTTPS mixed content breakage. Clearing user-tracking cookies set >>> over non-secure HTTP at the end of every browser session would be a strong >>> motivator for ad networks to upgrade to HTTPS, which would unblock content >>> sites' HTTPS rollouts. >>> >>> However, my testing of Henri's original proposal shows that too few sites >>> set the `secure` cookie flag for this to be practical. Even sites that >>> primarily use HTTPS, like google.com, omit the `secure` flag for many >>> cookies set over HTTPS. >>> >>> Instead, I propose treating all cookies set over non-secure HTTP as >>> session cookies, regardless of whether they have the `secure` flag. Cookies >>> set over HTTPS would be treated as "secure so far" and allowed to persist >>> beyond the current browser session. This approach could be tightened so any >>> "secure so far" cookies later sent over non-secure HTTP could be downgraded >>> to session cookies. Note that Firefox's session restore will persist >>> "session" cookies between browser restarts for the tabs that had been open. >>> (This is "eternal session" feature/bug 530594.) >>> >>> To test my proposal, I loaded the home pages of the Alexa Top 25 News >>> sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set >>> over HTTPS and only 7 had the `secure` flag. About 900 were third-party >>> cookies. Treating non-secure cookies as session cookies means that over >>> 1100 cookies would be cleared at the end of the browser session! >>> >>> CONS: >>> >>> * Sites that allow users to configure preferences without logging into an >>> account would forget the users' preferences if they are not using HTTPS. >>> For example, companies that have regional sites would forget the user's >>> selected region at the end of the browser session. >>> >>> * Ad networks' opt-out cookies (for what they're worth) set over >>> non-secure HTTP would be forgotten at the end of the browser session. >>> >>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368 >>> >>> Link to standard: N/A >>> >>> Platform coverage: All platforms >>> >>> Estimated or target release: Firefox 49 >>> >>> Preference behind which this will be implemented: >>> network.cookie.lifetime.httpSessionOnly >>> >>> Do other browser engines implement this? No >>> >>> [1] >>> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ >>> [2] http://www.alexa.com/topsites/category/Top/News >>> _______________________________________________ >>> dev-platform mailing list >>> dev-platform@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-platform >>> >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
