[cabfpub] Browser UI Future - Chrome

[Ryan Sleevi]

On today's call, some CA members expressed unfamiliarity with the
public goals of the Chrome team regarding the future of browser UI
related to TLS. While these have been shared in past meetings, I
realize there's no single, comprehensive post that contains the past
discussions, so hopefully this can serve as a useful starting point in
understanding both where we were, where we are, and where we're going.

Our basic plan was first shared in 2014, at
https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
, and we've been working towards that for the past several years.

You can see some of that progress at
https://security.googleblog.com/2015/10/simplifying-page-security-icon-in-chrome.html
, https://blog.chromium.org/2016/09/moving-towards-more-secure-web.html
, and https://blog.chromium.org/2017/04/next-steps-toward-more-connection.html
- each moving us closer to that overall plan.

To understand some of the peer-reviewed research that has supported
and informed these changes, the following literature may be helpful:
https://research.google.com/pubs/pub41323.html
https://research.google.com/pubs/pub41927.html
https://research.google.com/pubs/pub43265.html
https://research.google.com/pubs/pub45366.html
https://research.google.com/pubs/pub45374.html

Hopefully, this helps CAs be aware of where our long-term goal is for
the connection security indicators, which only refer to the connection
security of the transport to the domain specified in the URL, based on
both the available and continued research into seeing the Web more
encrypted.

It is important as well to remember that our most important and
significant goal is to see the Web encrypted by default, which is in
line with other organizations, such as
the IAB ( https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/
) and the W3C ( https://w3ctag.github.io/web-https/ ). UI that
promotes HTTP, as it does today, by virtue of giving no indicators
positive or negative, harms those goals. Thus, our focus is on
introducing negative indicators that accurately reflect when there is
no connection security, while also working to reduce the confusion
introduced by the myriad of positive indicators by aligning to a
single, neutral state.

That said, the UI is merely a second-order side-effect of this overall
effort, which includes a broad spectrum of efforts ranging from
working with sites and CDNs to migrate to HTTPS, such as via our HTTPS
Transparency Report, and working in various standards fora on
improving both the performance of HTTPS as well as the ease in
deploying it. Hopefully, in a similar vein, the CA/Browser Forum will
be able to focus our collaborative energies and resources towards the
important and challenging effort of ensuring that TLS is simple and
easy for site operators to deploy and update. For example, by
exploring ways to improve automation - potentially by even mandating
support - we might be able to more significantly help secure the
Internet, by ensuring communications remain confidential to the domain
in the URL, and that site operators can easily obtain certificates for
their domains.