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

Re: Proposal: Marking HTTP As Non-Secure

From: Chris Palmer <palmer@google.com>
Date: Mon, 29 Dec 2014 12:59:52 -0800
Message-ID: <CAOuvq20BXM-oLW7SQr2ncAZm8GfAVbW3cvAe53iGcG0P_8nXnw@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: Chris Bentzel <cbentzel@chromium.org>, Monica Chew <mmc@mozilla.com>, "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>
On Fri, Dec 26, 2014 at 8:12 PM, Brian Smith <brian@briansmith.org> wrote:

> Even Chrome's 58% number is probably under-estimating the number of
> navigations that *could* happen loaded over HTTPS. I think a key to
> making a successful UI change like the one proposed is to identify
> HTTP loads that could be HTTPS loads, and actively make them HTTPS
> loads, similar to what HTTPS Everywhere does. Both browsers do this
> with HSTS and HSTS preloading, but that approach is too conservative.
> We need to find a way to measure this gap between "could be HTTPS" and
> "is HTTPS" and then more actively close that gap.

I agree, but assuming that navigations can be upgraded to HTTPS can
sometimes lead to surprising results, or at least ineffective results.

* https://example.com redirects to http://example.com (now we've
slowed down the page load time for no benefit, except perhaps
telemetry)

* https://example.com is the admin interface; http://example.com is
the public site (i.e. different applications distinguished only by the
URL's scheme)

> It would also be useful to consider search metrics. When I search for
> "RFC 5246" with Google Search or Yahoo! Search, the top result is
> http://tools.ietf.org/html/rfc5246. But,
> HTTPS://tools.ietf.org/html/rfc5246 has the exact-same content. How
> often does this happen? What can be done to make search engines
> consider the HTTPS:// variant the canonical, default, choice? (Note:
> RFC 5246 is the TLS 1.2 specification.)

Yeah, that's a bug we need to fix. I think we gradually are? I have
pinged the relevant people.

> Are the Chrome numbers available broken down by geography and/or
> language? I think it is likely to be the case that different
> populations (e.g. German language websites vs. Chinese-language
> websites) have quite different mixes of HTTP vs. HTTPS usage.
> Comparing some of the country-specific Alexa lists seems to support
> this idea. Peoples' understanding and reaction to security indicator
> changes is likely to be varied by locale too. Also, it is likely that
> some locales will reach whatever thresholds for triggering a UX change
> well before other locales. Should such UX changes be rolled out
> separately by locale?

I think you are probably right, but I am not sure we should balkanize the web.
Received on Monday, 29 December 2014 21:00:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC