Please note that the main discussion for this is intended to be on the blin...@chromium.org mailing list (https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev). However, to alert relevant groups of the intent, we have bcc’d the following lists on this email:
We want to start applying the concepts in https://w3c.github.io/webappsec/specs/powerfulfeatures/ to features that have already shipped and which do not meet the (new, not present at the time) requirements. We want to start by requiring secure origins for these existing features:
- Device motion / orientation
As with gradually marking HTTP as non-secure (https://www.chromium.org/Home/chromium-security/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.
Joel Weinberger, Chrome Security
I should also mention that, generically, we believe all of these features fit under the "requires privileged context" definition as proposed in https://w3c.github.io/webappsec/specs/powerfulfeatures/#feature-requires-privilege. If you disagree, of course please make the case.
I note that Fullscreen it isn't in the Privileged Contexts list, but that's OK, I think these changes should be accepted into the respective specs, even if optional to implement. For example, the fullscreen element ready check would be the place for Fullscreen. Otherwise there's a chance that the point of failure (which could be observable) is different in different browsers.
What if a service streams video, which requires full screen feature? It takes quite a bit more compute power to pack it into encrypted connection, and what if the video is not of any value as a secure content. Why should people be forced to encrypt and decrypt spending extra power (battery, in case of portable devices) on it?
SSL does not guarantee the security de-facto.
Also, there is plenty of personal data that is being passed through a non-encrypted connection, which is way more valuable.
adding these restrictions is equivalent to telling developers that they must now pay to unlock features of the browser.
I did mention these concerns on Twitter and people proposed some possible solutions that would be much less onerous than fully restricting Fullscreen API to HTTPS only:- show originating URL on fullscreen warning