Re: Proposal: Marking HTTP As Non-Secure

Chris Bentzel <cbentzel@chromium.org> wrote:
> On Thu, Dec 18, 2014 at 4:18 PM, Monica Chew <mmc@mozilla.com> wrote:
>> On Thu, Dec 18, 2014 at 12:27 PM, Chris Palmer <palmer@google.com> wrote:
>>>
>>> On Thu, Dec 18, 2014 at 12:12 PM, Monica Chew <mmc@mozilla.com> wrote:
>>>
>>> > I support the goal of this project, but I'm not sure how we can get to a
>>> > point where showing warning indicators makes sense. It seems that about
>>> > 67%
>>> > of pageviews on the Firefox beta channel are http, not https. How are
>>> > Chrome's numbers?
>>>
>>> Currently, roughly 58% of top-level navigations in Chrome are HTTPS.
>>
>> Thanks for the numbers. That's a significant gap (58% vs 33%). Do you have
>> any idea why this might be the case?
>
> It's possible this is due to Firefox not counting same-frame
> navigations (fragment change, pushState) as top-level navigations.
>
> I added Navigation.MainFrameSchemeDifferentPage recently which
> excludes these navigations, and the fraction of navigations that are
> https is significantly lower.

You are correct that the Firefox telemetry is measuring something
different from the Chrome telemetry. Basically, Firefox's telemetry is
measuring network requests made for top-level document loads, not
served from the cache (IIRC), and not involving any pushState/fragment
stuff. It was created by the Mozilla networking team for measuring
stuff that actually touches the network.

In particular, it seems to count each redirect in a redirect chain
separately, so an HTTP -> HTTPS redirect is counted as one non-secure
load and one secure load. Although this has some relevance to the UI
issue (how the UI encourages the user to attempt to load pages over
HTTP even though the site prefers HTTPS), this is probably not good
for measuring the impact of changing the address bar UI.

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.

It would also be useful to consider metrics such as what percentage of
page loads happen as a result of the end-user typing or pasting a
scheme-less domain name into the address bar, and of that percentage,
how many resulted in an HTTPS load, how many resulted in an HTTP load
even though an HTTPS load would have worked fine, and how many really
needed to be HTTP loads?

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.)

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?

Cheers,
Brian

Received on Saturday, 27 December 2014 04:12:51 UTC