We (Chrome Security) originally sent this out to various browser development mailing lists. See the original intent-to-deprecate email on blink-dev. This is based on the original idea to prefer secure origins for powerful new features.
This is a living document — as we learn more, we'll probably need to change this page.
We want to start applying the concepts in https://w3c.github.io/webappsec-secure-contexts/to features that have already shipped and which do not meet the (new, not present at the time) requirements. In particular, this approximately requires that powerful features only be accessible on "secure origins" (such as HTTPS) where the full ancestor chain is also secure.
We want to start by requiring secure origins for these existing features:
As with gradually marking HTTP as non-secure, we expect to gradually migrate these features to secure-only, based on thresholds of usage, starting with lowest usage and moving towards higher. We also expect to gradually indicate in the UX that the features are deprecated for non-secure origins.
The deprecation strategy for each of these features is not decided on and may very well differ from feature to feature. We don’t currently know what the thresholds will be, or how heavily used the features are on what kinds of origins. We are in the process of gathering data, and will report back when we have it. There are no firm plans at all at this time, other than eventual deprecation. We intend for this to stimulate a public discussion of the best way to approach this deprecation. So, to that point, we'd love to hear what the community thinks.
If a feature is powerful and not available on HTTP, and you are a developer that needs to keep testing a feature on a server that does not have a valid certificate, you have several options:
We are hoping to come up with better metheds for testing powerful features on insecure origins, and we'll be sure to update this page once we've developed them. Feel free to contribute ideas to email@example.com.