We recently received a question about how we’re implementing security UI for deprecating legacy versions of TLS, and we wanted to explain our experiment design for embedders who might encounter the code.
We have a longstanding problem of how to motivate site owners to fix security misconfigurations. On the one hand, direct outreach to site owners doesn’t disrupt end users, but isn’t very effective. On the other hand, Chrome UI like an error page can alert site owners that they need to urgently fix a problem, but it can be overly disruptive to users. We’re interested in understanding whether less disruptive Chrome UI, such as an omnibox warning, can motivate site owners to fix misconfigurations without frustrating users as much as an error page.
When rolling out the TLS 1.0/1.1 removal UI (in the first phase, a “Not Secure” chip in the omnibox for affected sites), we’ll have a small, randomly selected control group of sites that will be exempt from the UI treatment. This control group will be served via Chrome’s component updater. We’ll be measuring whether sites in the control group upgrade to support TLS >=1.2 slower than other sites, as well as how the UI affects end users’ behavior. To avoid user-visible race conditions when showing the UI, it will be disabled unless the component is loaded.
We expect that the results of this experiment will inform how we approach security-related deprecations in the future. Let us know if you have any questions!