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

Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

From: Adrienne Porter Felt <felt@chromium.org>
Date: Sat, 20 Dec 2014 10:51:43 -0800
Message-ID: <CAFE8Ch5MEm-d3yrtQboVVXyty8ZJ0yGjwDUp1FK2DD8VHo1HUQ@mail.gmail.com>
To: Jiri Danek <softwaredevjirka@gmail.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 Sat, Dec 20, 2014 at 2:53 AM, Jiri Danek <softwaredevjirka@gmail.com>
> Are there plans to update this proposal with UI ideas that individual
> browsers come up with if the proposal is accepted? I don't think this is
> something that should be discussed too much (because bikeshedding), but I'd
> love to get to see it before it goes out ;)
> On Sat, Dec 20, 2014 at 12:37 AM, 'Tyler Larson' via blink-dev <
> blink-dev@chromium.org> wrote:
>> On Fri, Dec 19, 2014 at 1:34 PM, Monica Chew <mmc@mozilla.com> wrote:
>>> Why not shift the onus from the user to the site operators? I would love
>>>> to see a "wall of shame" for the Alexa top 1M sites that don't support
>>>> HTTPS,
>>> Just to follow up on this, from section 5.4 of
>>> http://randomwalker.info/publications/cookie-surveillance-v2.pdf, 87%
>>> of the sites from Alexa top 500 serve HTTP by default, and 66% of them
>>> don't serve HTTPS at all, as measured by using HTTPS-Everywhere.
>>> Thanks,
>>> Monica
>> Shaming operators of unencrypted sites completely muddies the message and
>> makes it looks like this effort is about coercing site operators into using
>> HTTPS rather than being about directly improving user experience.
>> This isn't about shaming unencrypted sites or coercing everyone to adopt
>> TLS; it's about delivering to the user the information he expects. If site
>> owners respond by adding encryption, that's not a bad result. But we can't
>> make this about forcing sites to change their security posture. Sites are
>> still free to deliver content insecurely; that's not changing. All that's
>> changing is that browsers will no longer overlook the very real threat of
>> tampering and abuse of that connection.
>  Up until now I thought it is (at least in part) about purposeful shaming
> into adopting TLS. Thanks for the clarification.

That is explicitly a non-goal. Given a threshold-based approach, we need to
use /other/ techniques to website owners into adopting TLS before we can
start changing the UI treatment.

> Regarding user experience, I have an issue with statements "Website is
> secure/insecure encrypted/unencrypted". These things have been said in this
> discussion many times by some people. I hope that the browser UIs will not
> resort to such inaccurate simplifications. It is only the _connection_ that
> is secured/encrypted. The only thing browser can do about the website is to
> authenticate it.
> It seems to me that the word "secure" became somewhat fuzzy in meaning. It
> would be great if the browsers could hint to users who dig into it (click
> the indicator icon, say) what secure connection really means in this
> context: encrypted communication + authenticated communication partner, or
> absence of these things. The /chromium-security/education/tls page looks
> useful.
> Other option would be to focus on the "threat model" point of view and let
> the user know that the "connection is protected from being tampered with".
> I admit that is a mouthful, though.

FWIW the string used on Chrome on Android in the OriginInfoBubble is "Your
connection to this site is private"; that string will be coming to desktop
too. With that being said, it's generally necessary to oversimplify because
no one wants to read a long explanation in the browser (that is what help
pages are for).
Received on Saturday, 20 December 2014 18:52:10 UTC

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