This seems like the right question. -Ekr
On Thu, Apr 14, 2016 at 9:17 AM, Kyle Huey <m...@kylehuey.com> wrote: > Why should we be the ones to take the web compat hit on this? > > - Kyle > On Apr 14, 2016 1:55 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
