Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Chris Peterson]

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

[Xidorn Quan]

On Thu, Apr 14, 2016 at 6:54 PM, Chris Peterson <cpet...@mozilla.com>
wrote:

>
> Do other browser engines implement this? No
>

I have no particular thought about the idea itself, but it seems to me this
is a breaking change to the web.

As it's a major breaking change, I don't think we should do this without
support and action from other browser vendors.

We should at least ask Chrome to coincide with us in the same time frame.

- Xidorn

[Aryeh Gregor]

On Thu, Apr 14, 2016 at 11:54 AM, Chris Peterson <cpet...@mozilla.com> wrote:
> * 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.

This also applies to any site that does login over insecure HTTP,
right? Hopefully this isn't the Alexa top 25, but there's a long tail
of small sites out there that lots of users spend lots of time on,
like web forums, which last I checked do not typically use HTTPS. I'm
concerned that this change would significantly degrade a lot of users'
experience. To the user, this looks like "In Firefox I have to log in
again every time, but in other browsers I don't."

Moreover, if a site has login over insecure HTTP, clearing cookies at
the end of each session makes use of the site less secure, not more.
It will force users to submit their passwords in plaintext at the
beginning of every session, which allows the attacker to take over as
the user forever. If the user only logs in once and keeps the cookies
for a long period (e.g., 30 days), an attacker who intercepts only one
session would only be able to control the user's account until the
cookie expires.

Also, the user's password could be used to log in as the user on other
sites, because of password reuse, whereas the cookie cannot be used
this way. These other sites could include banks, e-mail, etc., even
if the site being attacked is a small web forum or such. This is a
much more severe vulnerability in practice than just taking over the
current session.

It might be possible to special-case login cookies, perhaps defined as
cookies that are set in response to submission of a password field,
and let them persist beyond the end of the session. I would still be
wary of the UX implications of forgetting preferences, though.

[Benjamin Smedberg]

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 <cpet...@mozilla.com>
wrote:

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Kyle Huey]

Why should we be the ones to take the web compat hit on this?

- Kyle

[Jonas Sicking]

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

[Eric Rescorla]

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

[Haik Aftandilian]

On Thu, Apr 14, 2016 at 1:54 AM, Chris Peterson <cpet...@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.
>

​Wouldn't that only be true for sites that limit users to one login session
at a time? For sites that allow more than one login session​, when the user
logs in again each time, the original session cookie would not be
invalidated until the site decides to forget it. So if an attacker sniffed
the login cookie, they could replay it even after the user logged in again.
I know I have persistent logins to some sites on more than one computer,
but don't know how typical that is.

Haik

[Tanvi Vyas]

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

[Martin Thomson]

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
<benj...@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
>
>

[Joseph Lorenzo Hall]

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
> <benj...@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 <cpet...@mozilla.com>
>> wrote:
>>

>>> _______________________________________________
>>> dev-platform mailing list
>>> dev-pl...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>> _______________________________________________
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> _______________________________________________
> dev-platform mailing list
> dev-pl...@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

[Karl Dubost]

Chris,

Le 14 avr. 2016 à 17:54, Chris Peterson <cpet...@mozilla.com> a écrit :
> Instead, I propose treating all cookies set over non-secure HTTP as session cookies, regardless of whether they have the `secure` flag. […] To test my proposal, I loaded the home pages of the Alexa Top 25 News sites [2].

To test the proposal, I think:

1. It should be on the 1,000 to 10,000 top Alexa Web sites.
2. It should take into account all sites that are just setting preferences over HTTP.
cookies are not always used for username/password but apart of tracking for ads, they also are used for keeping the state on some choices such as languages, number of results returned, etc (without an account).

If we surprise the users with something giving the impression of a broken user experience compared to other browsers. We will get more Web compat reports which are not compat report.

More specifically we have to weight how do we help users?

Some scenario I could see.
* A preference explaining users that could ask the browser to forget about their insecure cookies and explaining the consequences for their user experience. And how to switch it off.
* A common action of all browsers together at the same time (unlikely to happen but we can try).





--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

[Chris Peterson]

Thanks for all the feedbck. I anticipated this proposal might not be
practical with real world sites, so it's better to halt it here. :) I
should have framed this email as an RFC instead of an intent to ship.

Focusing on third-party session cookies is an interesting idea.
"Sessionizing" non-HTTPS third-party cookies would encourage ad networks
and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed
content problems. Much later, we could consider sessionizing even HTTPS
third-party cookies.

I'll think about telemetry probes that could be added to better
understand these scenarios. I'm surprised we don't have much telemetry
about cookie usage. Monica Chew wrote [1] about a Mozilla study of
cookies, but that was only 573 users back in 2013.


chris

[1] http://monica-at-mozilla.blogspot.com/2013/10/cookie-counting.html

On 4/14/16 1:54 AM, Chris Peterson wrote:

[Francois Marier]

On 15/04/16 03:58 AM, Tanvi Vyas wrote:
> 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.

We seem to have this already: network.cookie.thirdparty.sessionOnly

Francois

[Jason Duell]

On Thu, Apr 14, 2016 at 10:54 PM, Chris Peterson <cpet...@mozilla.com>
wrote:

>

> Focusing on third-party session cookies is an interesting idea.
> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks
> and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed
> content problems. Much later, we could consider sessionizing even HTTPS
> third-party cookies.
>

How about we sessionize only 3rd party HTTP cookies from sites that are on
our tracking protection list? That seems the most targeted way to
encourage ad networks to bump up to HTTPS with a minimal amount of
collateral damage to other users of 3rd party HTTP cookies.

> We seem to have this already: network.cookie.thirdparty.sessionOnly

Correct, that's what it does.

Jason

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



--

Jason

[Jason Duell]

On Fri, Apr 15, 2016 at 2:12 AM, Jason Duell <jdu...@mozilla.com> wrote:

> On Thu, Apr 14, 2016 at 10:54 PM, Chris Peterson <cpet...@mozilla.com>
> wrote:
>
>>

>> Focusing on third-party session cookies is an interesting idea.
>> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks
>> and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed
>> content problems. Much later, we could consider sessionizing even HTTPS
>> third-party cookies.
>>
>

> How about we sessionize only 3rd party HTTP cookies from sites that are on
> our tracking protection list? That seems the most targeted way to
> encourage ad networks to bump up to HTTPS with a minimal amount of
> collateral damage to other users of 3rd party HTTP cookies.
>

(We could presumably keep a list of CDNs too and sessionize those as well)

Jason

> > We seem to have this already: network.cookie.thirdparty.sessionOnly
>
> Correct, that's what it does.
>
> Jason
>
>
>
>>

>> _______________________________________________
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
> --
>
> Jason
>

--

Jason

[Tantek Çelik]

On Thu, Apr 14, 2016 at 10:54 PM, Chris Peterson <cpet...@mozilla.com> wrote:

> Thanks for all the feedbck. I anticipated this proposal might not be
> practical with real world sites, so it's better to halt it here. :) I should
> have framed this email as an RFC instead of an intent to ship.
>

Thanks Chris for bringing up this "modest proposal". I for one
definitely had the feeling of "I would flip this on and try it
immediately for myself."


However, As EKR pointed out, Kyle Huey's

> Why should we be the ones to take the web compat hit on this?

is the fundamentally biggest issue.


There were numerous other issues brought up as well about what makes
the user more/less secure, typing in / sending their password more
times etc. that are potentially more debatable.


I'd like to see (a) revised/refined proposal(s) that ask(s):


What steps can we take in this direction WITHOUT breaking web compat?


E.g. since one of the issues raised is that *every* time a user
enters/submits a password over HTTP (not secure), it opens them to
being sniffed etc., thus it's good to discourage the frequency.

Some STRAW PROPOSALS that I expect others here (and UX folks) to
easily improve on:

1. Warning (perhaps similar to the invalid red glow) on password
inputs in forms with HTTP "action"

2. Warning (similarly) on HTTP-auth password dialogs

Both with wording making it clear that *the site* is requesting this
"password in the clear", and perhaps a suggestion to especially use
different passwords for any such sites.


The intent being to educate users about the sites that are asking them
to take more risks, and encouraging at least incrementally better
password (creating/use) behaviors.

Chris Peterson <cpet...@mozilla.com> wrote:
>
> Focusing on third-party session cookies is an interesting idea.
> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks and
> CDNs to use HTTPS, allowing content sites to use HTTPS without mixed content
> problems. Much later, we could consider sessionizing even HTTPS third-party
> cookies.

This is an interesting refinement, and perhaps worthy of testing
behind a flag to see how much "breaks".

> I'll think about telemetry probes that could be added to better understand
> these scenarios. I'm surprised we don't have much telemetry about cookie
> usage. Monica Chew wrote [1] about a Mozilla study of cookies, but that was
> only 573 users back in 2013.
>
>
> chris
>
> [1] http://monica-at-mozilla.blogspot.com/2013/10/cookie-counting.html

More telemetry on these scenarios would help inform both proposals and
decisions regarding this.

For that matter, how much telemetry do we have on frequency of user
password submissions on HTML forms over HTTP, or insecure HTTP-auth?

Thanks,

Tantek

[Matthew N.]

On 2016-04-15 7:47 AM, Tantek Çelik wrote:
> What steps can we take in this direction WITHOUT breaking web compat?
>
>
> E.g. since one of the issues raised is that *every* time a user
> enters/submits a password over HTTP (not secure), it opens them to
> being sniffed etc., thus it's good to discourage the frequency.
>
> Some STRAW PROPOSALS that I expect others here (and UX folks) to
> easily improve on:
>
> 1. Warning (perhaps similar to the invalid red glow) on password
> inputs in forms with HTTP "action"

We are making progress towards this and Aislinn Grigas from UX worked on
a design for something like this:
https://bugzilla.mozilla.org/attachment.cgi?id=8678150

We already started developer-specific warnings in the web console and in
the address bar of Nightly + Developer Edition:
https://hacks.mozilla.org/2016/01/login-forms-over-https-please/

There are some dependencies to fix before doing user-facing warnings
which we're currently working on. You can follow along in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1217162

> 2. Warning (similarly) on HTTP-auth password dialogs

This is https://bugzilla.mozilla.org/show_bug.cgi?id=1185145 which I
haven't seen a design for yet but should be less risky to implement than
for <input>. It is in the Firefox privacy/security team backlog.

Meta bug related to dealing with insecure login forms:
https://bugzilla.mozilla.org/show_bug.cgi?id=1217142

Thanks,
Matthew N.

[Chris Peterson]

On 4/15/16 7:47 AM, Tantek Çelik wrote:
> What steps can we take in this direction WITHOUT breaking web compat?

Would this feature actually break web compatibility? Or just needlessly
annoy users?

In his original post, Henri argued that clearing non-HTTPS cookies
between sessions would not "Break the Web". There would be no user- or
site-detectable changes mid-session. Clearing cookies between sessions
could be user-detectable if they get logged out or lose their shopping
cart. Sites, OTOH, must already handle the cases were a user's cookies
are lost between sessions. Users could clear their cookies, use Private
Browsing mode, or log into the site from a different browser or device.


chris

[Mike Taylor]

On 4/15/16 11:37 PM, Chris Peterson wrote:
> On 4/15/16 7:47 AM, Tantek Çelik wrote:
>> What steps can we take in this direction WITHOUT breaking web compat?
>
> Would this feature actually break web compatibility? Or just needlessly
> annoy users?

I think this is one of the fuzzy browser UX/sec/perf issues that is
often perceived as webcompat (cf. scrolling perf for parallax sites,
servers using RC4 in TLS, etc.).

Developers see it works well in Browser A, doesn't work in Browser B ->
"Best Used in Browser B".

Or users just hop over to Browser A because it's a PITA to deal with,
assuming Browser B is buggy.

(That said, I wouldn't be surprised if some top site out there falls
over on a second visit w/o a cookie it was expecting.)

--
Mike Taylor
Web Compat, Mozilla

[Haik Aftandilian]

On Fri, Apr 15, 2016 at 7:37 PM, Chris Peterson <cpet...@mozilla.com>
wrote:

​Tanvi brought up this point.

On Thu, Apr 14, 2016 at 12:58 PM, Tanvi Vyas <ta...@mozilla.com> wrote:
​...​

* 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).

​...​

Sites might depend on a combination of https and non-https cookies and then
act strangely when a user returns to the site with only the https cookies.

Haik​

​​

[Martin Thomson]

On 17 Apr 2016 2:37 AM, "Haik Aftandilian" <haftan...@mozilla.com> wrote:
>
> Sites might depend on a combination of https and non-https cookies and
then
> act strangely when a user returns to the site with only the https cookies.

This is also known as a security vulnerability. See
https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/zheng

[Chris Peterson]

On 4/15/16 2:12 AM, Jason Duell wrote:
>> > Focusing on third-party session cookies is an interesting idea.
>> > "Sessionizing" non-HTTPS third-party cookies would encourage ad networks
>> > and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed
>> > content problems. Much later, we could consider sessionizing even HTTPS
>> > third-party cookies.
>> >
> How about we sessionize only 3rd party HTTP cookies from sites that are on
> our tracking protection list? That seems the most targeted way to
> encourage ad networks to bump up to HTTPS with a minimal amount of
> collateral damage to other users of 3rd party HTTP cookies.

The IAB recently announced a "LEAN Ads" initiative [1]: Light, Encrypted
(HTTPS), Ad Choice supported, and Non-invasive.

When the IAB agrees ad networks should use HTTPS, clearing HTTP cookies
from third parties and/or sites on the Tracking Protection list becomes
an easier sell, policy-wise. We're not talking about blocking cookies or
content, just reducing the cookie lifetime.


[1] http://www.iab.com/news/lean/

[Richard Barnes]

Could we just disable HTTP auth for connections not protected with TLS? At
least Basic auth is manifestly insecure over an insecure transport. I
don't have any usage statistics, but I suspect it's pretty low compared to
form-based auth.

--Richard

> Meta bug related to dealing with insecure login forms:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1217142
>
> Thanks,
> Matthew N.
>

[Matthew N.]

On 2016-04-18 7:59 AM, Richard Barnes wrote:
> Could we just disable HTTP auth for connections not protected with TLS? At
> least Basic auth is manifestly insecure over an insecure transport. I
> don't have any usage statistics, but I suspect it's pretty low compared to
> form-based auth.

I also don't have data but I suspect that would break a lot of intranet
sites where I believe HTTP auth is more common. I think we need to be
even more careful about compat issues like this since it totally
prevents you from accessing the service instead of having a somewhat
broken experience. It seems like something we would want to announce far
in advance and I suspect there will still be too many affected sites
even with a years notice. Starting with warnings could help to reduce
the compat issue down the road if we decide to stop support as not
everyone will here about our deprecation plans.

Matthew

[Panos Astithas]

On Fri, Apr 15, 2016 at 5:47 PM, Tantek Çelik <tan...@cs.stanford.edu>
wrote:

> However, As EKR pointed out, Kyle Huey's
>
> > Why should we be the ones to take the web compat hit on this?
>
> is the fundamentally biggest issue.
>

I realize I'm late to this thread and the discussion has moved the original
proposal towards something more refined and hence more likely to succeed,
but I'd still like to make a case for this tradeoff:

We should be the ones doing this, because we want to be known as the most
secure, most private browser.

This is isn't an easy position to reach or maintain. It's not as clear-cut
as the fastest browser, or the less memory-demanding browser, but it is one
we have identified as holding a competitive advantage for. Security and
privacy impact usability, that is a well-known fact, otherwise we'd all be
using Tor by now. So let's iterate on this or other similar proposals,
let's ship them off by default, let's provide great onboarding experiences,
documentation, whatever it takes, but let's not shy away from even trying.
Because what other path has a better chance to help us get to where we want
to be?

Thanks,
Panos

[Chris Peterson]

On 4/19/16 1:58 AM, Panos Astithas wrote:
>>> Why should we be the ones to take the web compat hit on this?
>> >
>> > is the fundamentally biggest issue.
>> >
> I realize I'm late to this thread and the discussion has moved the original
> proposal towards something more refined and hence more likely to succeed,
> but I'd still like to make a case for this tradeoff:
>
> We should be the ones doing this, because we want to be known as the most
> secure, most private browser.
>
> This is isn't an easy position to reach or maintain. It's not as clear-cut
> as the fastest browser, or the less memory-demanding browser, but it is one
> we have identified as holding a competitive advantage for.

The challenge is that users experience broken websites (web compat)
firsthand, but privacy and security are invisible.

[Adam Roach]

On 4/18/16 09:59, Richard Barnes wrote:
> Could we just disable HTTP auth for connections not protected with TLS? At
> least Basic auth is manifestly insecure over an insecure transport. I
> don't have any usage statistics, but I suspect it's pretty low compared to
> form-based auth.

As a follow up from this: we added telemetry to answer the exact
question about how prevalent Basic auth over non-TLS connections was.
Now that 49 is off Nightly, I pulled the stats for our new little counter.

It would appear telemetry was enabled for approximately 109M page
loads[1], of which approximately 8.7M[2] used HTTP auth -- or
approximately 8% of all pages. (This is much higher than I expected --
approximately 1 out of 12 page loads uses HTTP auth? It seems far less
dead than we anticipated).

749k of those were unencrypted basic auth[2]; this constitutes
approximately 0.7% of all recorded traffic.

I'll look at the 49 Aurora stats when it has enough data -- it'll be
interesting to see how much if it is nontrivially different.

/a


[1]
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2016-06-06&keys=__none__!__none__!__none__&max_channel_version=nightly%252F49&measure=HTTP_PAGELOAD_IS_SSL&min_channel_version=null&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-05-04&table=0&trim=1&use_submission_date=0

[2]
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2016-06-06&keys=__none__!__none__!__none__&max_channel_version=nightly%252F49&measure=HTTP_AUTH_TYPE_STATS&min_channel_version=null&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-05-04&table=0&trim=1&use_submission_date=0



--
Adam Roach
Principal Platform Engineer
Office of the CTO

[Jason Duell]

This data also smells weird to me. 8% of pages using basic auth seems very
very high, and only 0.7% of basic auth being done unencypted seems low.

Perhaps we should chat in London (ideally with Honza Bambas) and make sure
we're getting the telemetry right here.

Jason

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

--

Jason

[Gijs Kruitbosch]

On 11/06/2016 03:27, Jason Duell wrote:
> This data also smells weird to me. 8% of pages using basic auth seems very
> very high, and only 0.7% of basic auth being done unencypted seems low.

Nitpick: it's 0.7% of total traffic - 749k / 8.7 million ~> 8.6% of
basic auth is over unencrypted connections.

~ Gijs

[Gijs Kruitbosch]

On 11/06/2016 03:27, Jason Duell wrote:

> This data also smells weird to me. 8% of pages using basic auth seems very
> very high, and only 0.7% of basic auth being done unencypted seems low.

Nitpick: it's 0.7% of total traffic - 749k / 8.7 million ~> 8.6% of
basic auth is over unencrypted connections.

~ Gijs

>

[David Burns]

Is there a way that we can gather if people are using this for testing web
sites? This might account for those numbers.

For example, there is basic support, and I mean really basic support, in
Selenium to handle Basic auth and we suggest to people that setting up a
proxy in the middle to handle that handshake. I suspect in these cases
people won't have all the necessary security setup if it is behind some
kind of firewall. Just a thought.

David

On 11 June 2016 at 03:27, Jason Duell <jdu...@mozilla.com> wrote:

> This data also smells weird to me. 8% of pages using basic auth seems very
> very high, and only 0.7% of basic auth being done unencypted seems low.
>

> --
>
> Jason

[Chris H-C]

I concur. 1 in every 12 loads require an HTTP auth prompt? Seems very high.
Visual inspection of the probe implementations [1] [2] show no obvious
faults, so I'm not sure what's going on here.

[1]
https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#782
[2]
https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#1608