Re: Proposal: Marking HTTP As Non-Secure

Indeed, the notion that users don't care is based on an ill-founded premise
of informed consent.

Here's a copy-pasted comment I made elsewhere on this topic:

To respect a user's decision, their decision needs to be an informed one,
and it needs to be choice. I don't think there's a reasonable basis to say
either of those are the case with users using HTTP in favor of HTTPS:

First, is it a choice: given that browsers default to HTTP, when no
protocol is explicitly selected, and that many users will access the site
via external links that they don't control, I don't think it's fair to say
that users choose HTTP, they simply get HTTP.

Second, if we did say they'd made a choice, was an informed one. We, as an
industry, have done a very poor job of educating users about the security
implications of actions online. I don't believe most non-technical users
have an understanding of what the implications of the loss of the
Authentication, Integrity, or Confidentiality that coms with preferring
HTTP to HTTPS are.

Given the fact that most users don't proactively consent to having their
content spied upon or mutated in transit, and insofar as they do, it is not
informed consent, I don't believe website authors have any obligation to
provide access to content over dangerous protocols like HTTP.


Alex

On Mon Dec 15 2014 at 3:50:36 PM Adrienne Porter Felt <felt@chromium.org>
wrote:

> If someone thinks their users are OK with their website not having
> integrity/authentication/privacy, then why is it problematic that Chrome
> will start telling users about it? Presumably these users would still be OK
> with it after Chrome starts making the situation more obvious. (And if the
> users start disliking it, then perhaps they really were never OK with it in
> the first place?)
>
> On Mon, Dec 15, 2014 at 3:28 PM, <ferdy.christant@gmail.com> wrote:
>>
>> I'm a small website owner and I believe this proposal will upset a lot of
>> small hosters and website owners. In particular for simple content
>> websites, https is a burden for them, in time, cost and it not adding much
>> value. I don't need to be convinced of the security advantages of this
>> proposal, I'm just looking at the practical aspects of it. Furthermore, as
>> mentioned here there is the issue of mixed content and plugins you don't
>> own or control. I sure hope any such warning message is very subtle,
>> otherwise a lot of traffic will be driven away from websites.
>>
>> On Saturday, December 13, 2014 1:46:39 AM UTC+1, Chris Palmer wrote:
>>
>>> Hi everyone,
>>>
>>> Apologies to those of you who are about to get this more than once, due
>>> to the cross-posting. I'd like to get feedback from a wide variety of
>>> people: UA developers, web developers, and users. The canonical location
>>> for this proposal is: https://www.chromium.org/Home/
>>> chromium-security/marking-http-as-non-secure.
>>>
>>> Proposal
>>>
>>> We, the Chrome Security Team, propose that user agents (UAs) gradually
>>> change their UX to display non-secure origins as affirmatively non-secure.
>>> We intend to devise and begin deploying a transition plan for Chrome in
>>> 2015.
>>>
>>> The goal of this proposal is to more clearly display to users that HTTP
>>> provides no data security.
>>>
>>> Request
>>>
>>> We’d like to hear everyone’s thoughts on this proposal, and to discuss
>>> with the web community about how different transition plans might serve
>>> users.
>>>
>>> Background
>>>
>>> We all need data communication on the web to be secure (private,
>>> authenticated, untampered). When there is no data security, the UA should
>>> explicitly display that, so users can make informed decisions about how to
>>> interact with an origin.
>>>
>>> Roughly speaking, there are three basic transport layer security states
>>> for web origins:
>>>
>>>
>>>    -
>>>
>>>    Secure (valid HTTPS, other origins like (*, localhost, *));
>>>    -
>>>
>>>    Dubious (valid HTTPS but with mixed passive resources, valid HTTPS
>>>    with minor TLS errors); and
>>>    -
>>>
>>>    Non-secure (broken HTTPS, HTTP).
>>>
>>>
>>> For more precise definitions of secure and non-secure, see Requirements
>>> for Powerful Features <http://www.w3.org/TR/powerful-features/> and Mixed
>>> Content <http://www.w3.org/TR/mixed-content/>.
>>>
>>> We know that active tampering and surveillance attacks, as well as
>>> passive surveillance attacks, are not theoretical but are in fact
>>> commonplace on the web.
>>>
>>> RFC 7258: Pervasive Monitoring Is an Attack
>>> <https://tools.ietf.org/html/rfc7258>
>>>
>>> NSA uses Google cookies to pinpoint targets for hacking
>>> <http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/>
>>>
>>> Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine
>>> <http://www.wired.com/2014/10/verizons-perma-cookie/>
>>>
>>> How bad is it to replace adSense code id to ISP's adSense ID on free
>>> Internet?
>>> <http://stackoverflow.com/questions/25438910/how-bad-is-it-to-replace-adsense-code-id-to-isps-adsense-id-on-free-internet>
>>>
>>> Comcast Wi-Fi serving self-promotional ads via JavaScript injection
>>> <http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/>
>>>
>>> Erosion of the moral authority of transparent middleboxes
>>> <https://tools.ietf.org/html/draft-hildebrand-middlebox-erosion-01>
>>>
>>> Transitioning The Web To HTTPS <https://w3ctag.github.io/web-https/>
>>>
>>> We know that people do not generally perceive the absence of a warning
>>> sign. (See e.g. The Emperor's New Security Indicators
>>> <http://commerce.net/wp-content/uploads/2012/04/The%20Emperors_New_Security_Indicators.pdf>.)
>>> Yet the only situation in which web browsers are guaranteed not to warn
>>> users is precisely when there is no chance of security: when the origin is
>>> transported via HTTP. Here are screenshots of the status quo for non-secure
>>> domains in Chrome, Safari, Firefox, and Internet Explorer:
>>>
>>> [image: Screen Shot 2014-12-11 at 5.08.48 PM.png]
>>>
>>> [image: Screen Shot 2014-12-11 at 5.09.55 PM.png]
>>>
>>> [image: Screen Shot 2014-12-11 at 5.11.04 PM.png]
>>>
>>> [image: ie-non-secure.png]
>>>
>>> Particulars
>>>
>>> UA vendors who agree with this proposal should decide how best to phase
>>> in the UX changes given the needs of their users and their product design
>>> constraints. Generally, we suggest a phased approach to marking non-secure
>>> origins as non-secure. For example, a UA vendor might decide that in the
>>> medium term, they will represent non-secure origins in the same way that
>>> they represent Dubious origins. Then, in the long term, the vendor might
>>> decide to represent non-secure origins in the same way that they represent
>>> Bad origins.
>>>
>>> Ultimately, we can even imagine a long term in which secure origins are
>>> so widely deployed that we can leave them unmarked (as HTTP is today), and
>>> mark only the rare non-secure origins.
>>>
>>> There are several ways vendors might decide to transition from one phase
>>> to the next. For example, the transition plan could be time-based:
>>>
>>>
>>>    1.
>>>
>>>    T0 (now): Non-secure origins unmarked
>>>    2.
>>>
>>>    T1: Non-secure origins marked as Dubious
>>>    3.
>>>
>>>    T2: Non-secure origins marked as Non-secure
>>>    4.
>>>
>>>    T3: Secure origins unmarked
>>>
>>>
>>> Or, vendors might set thresholds based on telemetry that measures the
>>> ratios of user interaction with secure origins vs. non-secure. Consider
>>> this strawman proposal:
>>>
>>>
>>>    1.
>>>
>>>    Secure > 65%: Non-secure origins marked as Dubious
>>>    2.
>>>
>>>    Secure > 75%: Non-secure origins marked as Non-secure
>>>    3.
>>>
>>>    Secure > 85%: Secure origins unmarked
>>>
>>>
>>> The particular thresholds or transition dates are very much up for
>>> discussion. Additionally, how to define “ratios of user interaction” is
>>> also up for discussion; ideas include the ratio of secure to non-secure
>>> page loads, the ratio of secure to non-secure resource loads, or the ratio
>>> of total time spent interacting with secure vs. non-secure origins.
>>>
>>> We’d love to hear what UA vendors, web developers, and users think.
>>> Thanks for reading!
>>>
>>  To unsubscribe from this group and stop receiving emails from it, send
> an email to security-dev+unsubscribe@chromium.org.
>