I have two concerns with this. First off, it means that users might need to actively log in to websites more often. This is a really big hassle for users, especially on mobile. We did some studies when we did FirefoxOS between the differences between native versions and web version of various apps (where both were available). One of the biggest differences, and which was annoying to no end, was that web versions tend to ask for users to log in more often, whereas native versions only asked you to log on once on initial launch. Making this worse seems like a bad thing.
This also has security implications since asking users to type username/password more often makes them more prone to phishing attacks. The second concern is that it might make users more reluctant to restart their browser in order to install an update. This also has obvious security implications. / Jonas On Thu, Apr 14, 2016 at 1: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
