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

Proposal: Marking HTTP As Non-Secure

From: Chris Palmer <palmer@google.com>
Date: Fri, 12 Dec 2014 16:46:34 -0800
Message-ID: <CAOuvq23pYcKPMj5A6umqY56Lqy9eSNqOeYLjY7Gs8i1dnRVmRQ@mail.gmail.com>
To: "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>
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:


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

The goal of this proposal is to more clearly display to users that HTTP
provides no data security.


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.


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

NSA uses Google cookies to pinpoint targets for hacking

Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine

How bad is it to replace adSense code id to ISP's adSense ID on free

Comcast Wi-Fi serving self-promotional ads via JavaScript injection

Erosion of the moral authority of transparent middleboxes

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
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]


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:


   T0 (now): Non-secure origins unmarked

   T1: Non-secure origins marked as Dubious

   T2: Non-secure origins marked as Non-secure

   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:


   Secure > 65%: Non-secure origins marked as Dubious

   Secure > 75%: Non-secure origins marked as Non-secure

   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!
Received on Saturday, 13 December 2014 00:47:02 UTC

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