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
