Deprecating Powerful Features on Insecure Origins

Proposal

As browser users manage more and more of their day-to-day lives online, we (Chrome Security) believe they should reasonably expect that browsing and interacting with the web is secure and protects their sensitive information across their entire browsing experience. Protecting users’ privacy and security requires connecting to secure origins wherever possible. Practically speaking, this means restricting features to HTTPS in lieu of HTTP, especially for powerful web platform features.

While strong progress has been made in increasing HTTPS adoption on the web over the past several years, there are still millions of sites that do not support secure connections over HTTPS, which means that support for HTTP isn’t going away in the foreseeable future. As long as a significant portion of browsing the web can only happen over HTTP, it’s important that we take steps to protect and inform users whenever we cannot guarantee that their connections are secure.

Continuing from our past efforts to restrict new features to secure origins, we are taking further steps on our path of deprecating powerful features on insecure origins in order to mitigate the most privacy- and security-sensitive risks of using HTTP in Chrome. To guide our efforts going forward, we have created the following principles, which we will use to prioritize future work in this area:

• Better inform users when making trust decisions about sites over insecure connections Over time, Chrome users are making an increasingly large amount of trust decisions when interacting with websites, whether by granting permissions for powerful web features, submitting personal information to a website, or downloading executable code. However, when the connection to a website is unauthenticated and unencrypted, these trust decisions aren’t bound to the intended site in a meaningful way. When Chrome presents users with such a trust decision, we plan on ramping up warnings to users when these features are being used over connections to insecure origins.

• Limit the ability for sites to circumvent security policies over insecure connections The same-origin-policy (SOP) is an important security policy that limits a website’s ability to interact with resources from other origins. Several powerful web platform features (such as postMessage and CORS) allow for websites to exempt domains from this policy to provide a more feature-rich experience. Our goal for future versions of Chrome to gradually limit the ability for insecure origins to be expressed in policy exceptions like these.

• Change how, and for how long, Chrome stores site content provided over insecure connections When browsing to a site over HTTP today, Chrome will both cache site content for future use as well as providing access to persistent local storage. When this content is provided over insecure and unauthenticated connections, the value of this persistent storage is significantly reduced and we are exploring ways to limit the duration this content will persist on user devices between visits to insecure origins.

Powerful Features restricted to Secure Origins

A (non-exhaustive) list of powerful features we have already restricted to secure origins includes:

• Geolocation
• Device motion / orientation
• EME
• getUserMedia
• AppCache
• Notifications

Testing Powerful Features

If you are a developer that needs to keep testing a site using a powerful feature that has been restricted to secure origins, this article provides helpful instructions for a variety of options for local development, including testing on http://localhost where possible, creating and using self-signed certificates, as well as creating, installing, and managing self-signed CAs to issue testing and development certificates.

In addition to this guidance, there are some Chrome and Android-specific tips that can help when developing and testing features restricted to secure origins:

1. You can use chrome://flags/#unsafely-treat-insecure-origin-as-secure to run Chrome, or use the --unsafely-treat-insecure-origin-as-secure="http://example.com" flag (replacing "example.com" with the origin you actually want to test), which will treat that origin as secure for this session. Note that on Android and ChromeOS the command-line flag requires having a device with root access/dev mode.

2. On a local network, you can test on your Android device using port forwarding to access a remote host as localhost.

We continue to invest in improved methods for testing powerful features on insecure origins, and we'll update this page once we've developed them. Feel free to contribute ideas to security-dev@chromium.org.