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

On Sat, Dec 20, 2014 at 2:53 AM, Jiri Danek <softwaredevjirka@gmail.com>
wrote:
>
> 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).