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

Re: Proposal: Marking HTTP As Non-Secure

From: Chris Palmer <palmer@google.com>
Date: Thu, 18 Dec 2014 13:46:12 -0800
Message-ID: <CAOuvq20sNGbK59hsuTF0H==jAEp6YgaPKXMip-StdVLBKkJi3w@mail.gmail.com>
To: Monica Chew <mmc@mozilla.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>
Sigh. Re-posting this, because the Mozilla list doesn't like large attachments.

To see the equivalent, go to https://www.google.com and click on the
green lock in the Omnibox.

On Thu, Dec 18, 2014 at 1:41 PM, Chris Palmer <palmer@google.com> wrote:
> On Thu, Dec 18, 2014 at 1:18 PM, Monica Chew <mmc@mozilla.com> wrote:
>> Thanks for the numbers. That's a significant gap (58% vs 33%). Do you have
>> any idea why this might be the case?
> I don't, unfortunately.
> I think we (Chrome) are going to try measuring HTTPS vs. HTTP
> deployment in other ways too, and then we might see discrepancies.
>> 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).
> That's part of why we plan to gate the change on increasing HTTPS
> adoption. Gervase liked that idea, too.
>> 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.
> Citation needed...?
> (If you're arguing that we should all compile with -Werror, I'll
> surely agree with you. Chrome does. But I assume you did not mean to
> suggest we should do the equivalent for HTTP navigation, at least not
> yet...)
>> Again, what's the action that typical
>> users are going to take when they see a passive indicator?
> First, keep in mind that you can't argue that showing the passive
> indicator will be both ignored and crying wolf. It's one or the other.
> Which argument are you making?
> That said,
> * Those few users who do look at it will at least be able to discern
> the truth. Currently, they cannot.
> * Site operators are likely to discern the truth, and may be motivated
> to deploy HTTPS, if they feel that their user base might demand it.
> (Complementarily, as site operators seek to use more powerful,
> app-like features like Service Workers, they will increasingly deploy
> HTTPS because they have to.)
> * As we make the web more powerful and more app-like, we (Chrome) seek
> to join the "what powerful permissions does this origin have?" views
> and controls with the "by the way, how authentic is this origin?"
> view. (See attached Chrome screenshot, showing that they are already
> significantly merged. In my other window I am working on a patch to
> make this easier to use.) As users become increasingly aware of these
> controls, they may become increasingly aware of the authenticity
> marking. And then they may make decisions about granting permissions
> differently, or at least with more information. Basically, "how real
> and how powerful is this origin" is gradually becoming a first-class
> UX piece.
> But, fundamentally, we owe it to users to tell the truth. I don't see
> that the status quo is defensible.
Received on Thursday, 18 December 2014 21:46:44 UTC

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