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

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.

In current implementations, there's no signaling by the browser to say
"this site isn't encrypted." There's the *absence* of signaling about
security, but that's not the same thing as positively saying that a site
was delivered over an insecure channel.

This is pretty critical because in the absence of clear messaging, you're
relying on the site to be conscientious and forthcoming about the security
of their transport. If I go to download.com to find an antivirus (not to
pick on cnet, but it's a common example) I see nothing to tell me that the
connection is insecure; the browser's not alerting me and the site isn't
going to volunteer that tidbit either -- nothing to show me that my
security software may be tampered with in transit. Sites are free to make
their own assertions of security without being contradicted by the browser,
even though the browser knows better.

As has been pointed out, the browser can't tell whether a site is safe or
trustworthy or follows all the necessary best-practices; nobody can
reliably, and that's not the browser's job. But the browser CAN tell
whether the connection to that site is secured. That's its job. And right
now it's only doing half of that job, giving positive feedback but not
negative. By affirmatively identifying insecurity, we can close that loop
and give the user complete and unambiguous messaging about the security of
his connection.

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.

-tylerl