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
On Fri, Feb 27, 2015 at 7:48 PM, <postf...@gmail.com> wrote:[snip]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 warningThis may be the core of some misunderstanding. When a browser receives a page over HTTP, there is no originating URL since anyone on its network could have replaced the content. HTTPS makes the difference between "Do you trust foo.com to use your X?" and "Do you trust the folks sitting at your coffee shop, your ISP, several other network providers, and foo.com to use your X?"
On Mar 1, 2015 5:01 PM, "Joel Weinberger" <j...@chromium.org> wrote:
> The problem with fullscreen is not just privacy; it's very much about MitM attackers. If, for example, http://example.com has a legitimate use of fullscreen, and the user grants it, now *any* Man-in-the-Middle can silently use this fullscreen feature. They could inject a phishing attack, for example, Or, perhaps they could just abuse it for fullscreen ads. In any case, the concern isn't necessarily http://example.com, but an attacker.
Fullscreen, pointer lock, and keyboard lock have spoofing risks that multiply, the more of them you have enabled. It may make sense and be feasible to restrict combinations before restricting the individual features.
If the thing that requires a secure origin is just
a nice-to-have, like say fullscreen mode
(Just guessing, I'm not an actual Web developer.)
On Thu, Mar 5, 2015 at 10:17 PM Katelyn Gadd <k...@luminance.org> wrote:Given that fullscreen (just to pick one example) is out in the wild, I
think there will be significant UX issues if fullscreen API calls
suddenly start failing without any obvious reason. Most websites will
probably never be updated to communicate to the user that the problem
is the page being accessed from a non-secure origin.
If this is an issue, user agents can build UX elements that say "hey, this page tried to fullscreen, but it's on an insecure page, so we blocked it" (think the mixed-scripting shield in Chrome). I'm not saying that's something we will build, but it's something we can build, if necessary. It doesn't have to be application or site UX that alerts users.
So, to that point, we'd love to hear what the community thinks.
I'm sorry for not adding my voice to this discussion when it was
active, but I am also unhappy with the direction to make these
features HTTPS only. I've never seen a credible phishing attack from
full-screen content, and think that the visible warnings that already
show up for that feature as well as getUserMedia and geolocation are
sufficient to guard against attacks. There is a long tail of smaller
sites that use features like WebGL, WebVR, and camera input to deliver
really cool experiences, and it's infeasible for the site authors to
obtain SSL certificates. I am not an owner of one of these APIs but
believe that this effort is misguided and will drive users away from
browsers based on Blink.
On Thu, Apr 30, 2015 at 12:11 PM, 'Brandon Jones' via blink-dev
> It's gotten a bit difficult to parse out what decisions have been made from
> this thread, so can we recap what's being done to address the following
> items? I feel like a lot of the concerns voiced earlier in the thread
> haven't been clearly accounted for.
> 1) Are we committing to having a exemption from these new policies for local
> 2) What is strategy for pre-existing and widely used features? (Fullscreen,
> Device Motion, etc?) Joel's patch makes it sound like these will eventually
> be made HTTPS only, which I'm concerned will affect a long tail of content
> that utilizes the features but will never be updated.
> 3A) Is there a plan for getting setup of HTTPS to ~0 cost (in monetary,
> deployment, and privacy terms)? I recognize that this may not something that
> Google is capable of addressing single handedly.
> 3B) If not, what's being done to address concerns that these policies would
> exclude developers who, for whatever reason, are unable to host HTTPS