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

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.

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.