- From: Chris Palmer <palmer@google.com>
- Date: Mon, 29 Dec 2014 12:59:52 -0800
- 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