On the surface, this seems like a great idea and privacy win - it gets
rid of all those pesky tracking cookies! But under the covers there are
a lot of issues, as mentioned by previous replies and summarized below:
* Puts the user's password at greater risk, since the user has to enter
it and potentially send it over HTTP more often. Incentivizes users to
use shorter and easier passwords, since they have to enter them more
frequently. And makes them more susceptible to phishing and password
reuse attacks.
* Bad user experience, where websites don't remember who the user is or
what their preferred language/country is.
* Even if login cookies are set over HTTPS, there are sometimes
additional cookies set over HTTP with user data in them (ex:
city/zipcode). Users may have bad experiences on websites that rely on
these secondary HTTP cookies even if they are still logged in (ex:
weather.yahoo.com for a user who is logged into yahoo.com).
* Special casing login cookies would be very tricky. A number of sites
don't label their password fields with type="password". Sites who have
second factor auth will go through an interstitial between the login
page and setting the login cookie (though I suppose the sites that have
2FA are over HTTPS).
I'm afraid doing this by default will drive away users and open up more
security issues. We could have an about:config pref for it that some
users may elect to set. But instead, we should experiment with applying
this to third parties as Benjamin suggested. We already have a
preferences to disable third party cookies, but perhaps that is too
restrictive for most users. We also have a preference to disable third
party cookies from sites that are never first party, but that gives
popular sites a competitive advantage in advertising.
So how about a preference that treats all cookies set in a third party
context as session cookies. We could restrict this to HTTP, or even
apply it to third party HTTPS cookies. This will solve the pesky
tracking cookies problem, but won't break insecure logins[1] or site
preferences. It won't force users to enter their passwords more
frequently. Since third party cookies aren't completely blocked, it
shouldn't break sites the way the third party cookie pref sometimes does
now.
~Tanvi
On 4/14/16 1:54 AM, Chris Peterson 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
