W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: Proposal: Marking HTTP As Non-Secure

From: Monica Chew <mmc@mozilla.com>
Date: Thu, 18 Dec 2014 13:18:55 -0800
Message-ID: <CAGSmrUvGX=So+TbLm=XmX0wJv+6W5SAReTOHNm5WjuJAHY1rqQ@mail.gmail.com>
To: Chris Palmer <palmer@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, blink-dev <blink-dev@chromium.org>, security-dev <security-dev@chromium.org>, "dev-security@lists.mozilla.org" <dev-security@lists.mozilla.org>
On Thu, Dec 18, 2014 at 12:27 PM, Chris Palmer <palmer@google.com> wrote:

> On Thu, Dec 18, 2014 at 12:12 PM, Monica Chew <mmc@mozilla.com> wrote:
> > I support the goal of this project, but I'm not sure how we can get to a
> > point where showing warning indicators makes sense. It seems that about
> 67%
> > of pageviews on the Firefox beta channel are http, not https. How are
> > Chrome's numbers?
> Currently, roughly 58% of top-level navigations in Chrome are HTTPS.

Thanks for the numbers. That's a significant gap (58% vs 33%). Do you have
any idea why this might be the case?

> > Security warnings are often overused and therefore ignored [1]; it's even
> > worse to provide a warning for something that's not actionable. I think
> we'd
> > have to see very low plaintext rates (< 1%) in order not to habituate
> users
> > into ignoring a plaintext warning indicator.
> (a) Users are currently habituated to treat non-secure transport as
> OK. The status quo is terrible.
> (b) What Peter Kasting said: we propose a passive indicator, not a
> pop-up or interstitial.

I understand the desire here, but a passive indicator is not going to
change the status quo if it's shown 42% of the time (or 67% of the time, in
Firefox's case). Other passive indicators (e.g., Prop 65 warnings if you
live in California, or compiler warnings that aren't failures) haven't
succeeded in changing the status quo. Again, what's the action that typical
users are going to take when they see a passive indicator?

Received on Friday, 19 December 2014 13:52:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:44 UTC