Intent to deprecate: Insecure usage of powerful features

12319 views
Skip to first unread message

Joel Weinberger

unread,
Feb 26, 2015, 6:25:50 PM2/26/15
to blink-dev

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:

securi...@chromium.org

dev-se...@lists.mozilla.org

public-w...@w3.org

public-web-...@w3.org

public-de...@w3.org

public-ge...@w3.org

public-h...@w3.org 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 - EME - Fullscreen - Geolocation - getUserMedia 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.


Thanks,

Joel Weinberger, Chrome Security

Scott Graham

unread,
Feb 26, 2015, 6:34:05 PM2/26/15
to Joel Weinberger, blink-dev
Are there any background links on why device orientation and fullscreen are considered powerful? (not arguing they aren't, just for my own edification)

Glenn Adams

unread,
Feb 26, 2015, 6:48:24 PM2/26/15
to Scott Graham, Joel Weinberger, blink-dev
Same question about EME.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Joel Weinberger

unread,
Feb 26, 2015, 7:03:55 PM2/26/15
to blink-dev
(+www...@w3.org to bcc)

npd...@berkeley.edu

unread,
Feb 26, 2015, 7:10:39 PM2/26/15
to blin...@chromium.org
The Privileged Contexts draft suggests -- and I know the Geolocation WG, among other groups, has discussed -- prohibiting *persistence* of permissions for insecure origins as either a step towards deprecation or as the end level of limiting features in insecure origins. I believe the reasoning is that a user may be able to use the context of where they are when they grant a one-time geolocation permission and judge it as less-sensitive, where granting a persistent permission makes such reasoning almost impossible (since any future active attacker could at any time redirect to that origin and maliciously access the privileged API).

Does the Chrome Security team have any experience with restricting persistence of permission rather than preventing API calls altogether? Would you expect that to be a step in a deprecation plan?

Brandon Jones

unread,
Feb 26, 2015, 7:22:36 PM2/26/15
to Joel Weinberger, blink-dev
I'm pretty uncomfortable with the idea of requiring HTTPS for features like Fullscreen. Speaking from the perspective of the WebGL community this is a very popular feature for creating immersive experiences, and something that is often used in hobby projects and quick effects demonstrations. As much as I am fully in support of encouraging the web to use HTTPS adding these restrictions is equivalent to telling developers that they must now pay to unlock features of the browser. For a good number of developers that I interact with on a daily basis that's would be enough to make them abandon the feature entirely or, worse, switch to a browser that doesn't have such restrictions.

--Brandon

steve...@gmail.com

unread,
Feb 26, 2015, 7:59:07 PM2/26/15
to blin...@chromium.org, j...@chromium.org, baj...@google.com
Chromium should be supporting user generated SSL / HTTPS certificates instead of trusting a signing authority, that would alleviate your concerns on the cost of supporting https right?

Joel Weinberger

unread,
Feb 26, 2015, 8:43:27 PM2/26/15
to steve...@gmail.com, blin...@chromium.org, baj...@google.com
Thanks for the quick replies and questions, everyone.

For fullscreen, the concern is that it allows for extraordinarily powerful phishing attacks, thus granting the power over HTTP means that a man-in-the-middle can effectively take over all of your interactions with your machine (this is particularly powerful when matched with pointer lock). See http://feross.org/html5-fullscreen-api-attack/ for one of my favorite examples of this in action.

Device motion has some pretty serious privacy consequences, and similar to geolocation, passing that in the clear can reveal quite a bit of information. One of my favorites is reading passwords based on accelerometer data: https://sparrow.ece.cmu.edu/group/pub/owusu_ACCessory_hotmobile12.pdf (which a man-in-the-middle can pretty easily take advantage of).

Regarding EME, I refer to https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332, which I believe Glenn has seen before.

I completely agree with the sentiment of making HTTPS easier to deploy. This has been discussed in relation to Chrome's proposal to "Mark HTTP as Non-Secure" (http://www.chromium.org/Home/chromium-security/marking-http-as-non-secure). I point to the FAQ on that document regarding the difficulty of setting up HTTPS, as well as to say we do have a plan for developers to be able to run powerful features on insecure origins in for specific sites. (See https://crbug.com/441605, which, admittedly, someone needs to get implemented... me maybe?)
--Joel

Joel Weinberger

unread,
Feb 26, 2015, 8:45:44 PM2/26/15
to steve...@gmail.com, blin...@chromium.org, baj...@google.com
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.

Brandon Jones

unread,
Feb 26, 2015, 9:53:50 PM2/26/15
to Joel Weinberger, steve...@gmail.com, blin...@chromium.org
My concerns over the policy would indeed rapidly diminish as the costs of deploying HTTPS (monetary and mental) approach zero.

Glenn Adams

unread,
Feb 26, 2015, 9:59:43 PM2/26/15
to Joel Weinberger, steve...@gmail.com, blink-dev, baj...@google.com
On Thu, Feb 26, 2015 at 6:45 PM, Joel Weinberger <j...@chromium.org> wrote:
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 wonder if there is a general consensus that those features listed in [1] are subject to the threat models cited in [2]. For example, does EME actually expose "temporary or permanent identifiers" to an application? Does it do so in a way that is not already possible by existing non-EME features? For example, Navigator.userAgent may expose a client unique identifier, and indeed some user agents (e.g., DLNA RUI-H [3]) are required to transmit such an identifier in the User-Agent header in certain server/client contexts (without otherwise requiring use of HTTPS).

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Philip Jägenstedt

unread,
Feb 27, 2015, 4:38:31 AM2/27/15
to Joel Weinberger, blink-dev
Hi Joel,

It looks like there is no immediate plan to change any API or even emit console warnings, but gathering data and seriously considering these changes sounds good to me. A good first step would be to add use counters in all of the places where an API would fail on an insecure origin.

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.

That being said, this is certainly risky for both Web compat and the competitiveness of the Web platform. To use a bit of hyperbole, being the most secure platform doesn't matter if by being secure you drive developers to other platforms. But with more data and specific changes to discuss, we can consider each change on its own merits.

Good luck!

Philip

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Mike West

unread,
Feb 27, 2015, 4:57:15 AM2/27/15
to Philip Jägenstedt, Joel Weinberger, blink-dev
On Fri, Feb 27, 2015 at 10:38 AM, Philip Jägenstedt <phi...@opera.com> wrote:
A good first step would be to add use counters in all of the places where an API would fail on an insecure origin.

We have some of these counters already, but you're right: we should add more. For example, Geolocation is used insecurely on ~0.06% of instrumented page views (https://www.chromestatus.com/metrics/feature/timeline/popularity/562). My suspicion is that this is mostly Bing and Yandex maps, and that explicit deprecation and outreach can effectively communicate our intent to those developers.
 
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.

Do note that the spec a) is a work in progress, and b) attempts to outline the types of features which require privileged contexts in fairly broad strokes. It's not meant to be an exhaustive list of features, and I do expect that our understanding of the categorization will change over time.

That said, I though I had added something to the effect of http://mikewest.github.io/spec-questionnaire/security-privacy/#native-ui to the document. I'll make that change today, thanks for the suggestion.

-mike

Danil

unread,
Feb 27, 2015, 6:02:34 AM2/27/15
to blin...@chromium.org
What is going to be the protocol for development environment? Should one deal with ssl just to quickly test out the code?

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. If this is an attempt to increase amount of secure connections, it is a very inconvenient one. Why not keep giving bonus point for using it (like SEO higher ranking) rather than making pure HTTP not usable.

On Thursday, February 26, 2015 at 3:25:50 PM UTC-8, Joel Weinberger wrote:

Mike West

unread,
Feb 27, 2015, 6:25:06 AM2/27/15
to Danil, blink-dev
On Fri, Feb 27, 2015 at 12:02 PM, Danil <d...@choister.net> wrote:
What is going to be the protocol for development environment? Should one deal with ssl just to quickly test out the code?

The spec has carveouts for this use-case: See https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy and https://w3c.github.io/webappsec/specs/powerfulfeatures/#development-environments. I believe the intention for Chrome is to add an option to devtools to whitelist specific origins (for staging servers, etc). Would that address your concern?

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?

YouTube does this today. It's certainly not impossible to stream video over HTTPS, but I grant that it's likely more work. Long-term, I think media should absolutely be transmitted securely. Short-term, the proposal at https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0371.html may interest you.
 
SSL does not guarantee the security de-facto.

Certainly not, but encryption (and authentication) seems to be a minimum bar. We _know_ anything below that bar is insecure, so we should avoid them.
 
Also, there is plenty of personal data that is being passed through a non-encrypted connection, which is way more valuable.

That sounds like a problem we should solve. See https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure for example.

-mike

karthi...@gmail.com

unread,
Feb 27, 2015, 6:40:11 AM2/27/15
to blin...@chromium.org
Will this also affect flash/unity full screen? Or only HTML5 full screen?

karthi...@gmail.com

unread,
Feb 27, 2015, 11:08:57 AM2/27/15
to blin...@chromium.org
I am not happy with this, unlocking browser features with SSL. First make SSL free and easy to setup.

karthi...@gmail.com

unread,
Feb 27, 2015, 11:18:29 AM2/27/15
to blin...@chromium.org
Also we assume, using HTTPS - the website is legit. What if I use cloudflare DNS or github to host my malicious site, as shown in the examples above.

tpa...@gmail.com

unread,
Feb 27, 2015, 11:37:15 AM2/27/15
to blin...@chromium.org
I echo many concerns raised here already, mostly around the ease of setting up and deploying HTTPS (I've never used it) and especially during development. Having a site whitelist in developer mode, or maybe just whitelisting locahost by default, would have to be part of this otherwise many developers won't be able to handle it.

I also don't understand why Fullscreen and Device Orientation would be considered on par with getUserMedia and GeoLocation. The latter are obtaining potentially sensitive information from the user's computer; the former are just graphics and interaction features. Just because a feature is "powerful" doesn't mean it's fundamentally a security threat. So I'm questioning the premise here for a few of the features...



On Thursday, February 26, 2015 at 3:25:50 PM UTC-8, Joel Weinberger wrote:

tpa...@gmail.com

unread,
Feb 27, 2015, 11:37:49 AM2/27/15
to blin...@chromium.org, j...@chromium.org
+1 Scott, I'm not seeing it, would love to see the rationale and argue against them.

plue...@googlemail.com

unread,
Feb 27, 2015, 12:13:57 PM2/27/15
to blin...@chromium.org
Imo its the wrong order, before HTTP can be deprecated and confined for security reasons, there must be a sane alternative (easy deploy, no paywalls).
For now the current state of art is sufficient: HTTP with permission dialogs (allow fullscreen?), HTTPS with stored permission config.

dave...@gmail.com

unread,
Feb 27, 2015, 12:14:35 PM2/27/15
to blin...@chromium.org
I worry these changes will hamper creativity and innovation among hobbyists and independent developers. I cannot imagine jumping through hoops and SSL configurations just to get a small Canvas, WebGL or WebVR experiment off the ground. 

One of the most attractive aspects of web programming -- and one of the reasons the JavaScript creative/interactive community is currently booming with beginners and experts alike -- is the extremely low barrier to entry. Complex applications and rich artistic experiences utilizing device motion, webcam, geolocation, etc are easy to build, and even easier for others to open up and view. 

A few examples of projects and experiments that might be hampered with higher barriers and increased restrictions:

katsuomi....@gmail.com

unread,
Feb 27, 2015, 12:15:43 PM2/27/15
to blin...@chromium.org
adding these restrictions is equivalent to telling developers that they must now pay to unlock features of the browser.

 I totally agree with this. Please stop for some time.

k...@luminance.org

unread,
Feb 27, 2015, 12:16:11 PM2/27/15
to blin...@chromium.org, j...@chromium.org, baj...@google.com
I want to echo Brandon's POV here. I'm uncomfortable with locking an existing feature like Fullscreen behind HTTPS.

The Fullscreen API was already crippled to address phishing concerns - among other issues, games can't use the ESC key, which is problematic for ports and usability - most PC games use this key so now it has to be remapped for a browser port, and players are used to hitting ESC to open a menu or such and in HTML5 it just pops them out of fullscreen and does nothing, which is disorienting.

If Fullscreen's usability is further restricted, the HTTPS restriction needs to come along with functionality improvements, perhaps the ability to capture ESC - otherwise developers will simply resent this change and view it as arbitrary.

I should also point out that there are many popular services out there that host user-provided HTML5 content - game hosting services, html/js playgrounds, etc. All of these services will end up being HTTPS encrypted (if they aren't already) at which point it will be trivial to bypass this security mechanism and enter fullscreen mode by hosting your malicious content on one of these services.

If it were actually painless to set up HTTPS this would bother me less but in my experience there are still significant hurdles involved. I think developers will be upset by having it forced on them when the social and technological burdens associated with HTTPS have not been alleviated yet.

-kg

tpa...@gmail.com

unread,
Feb 27, 2015, 12:27:08 PM2/27/15
to blin...@chromium.org, j...@chromium.org, baj...@google.com, k...@luminance.org
Yes, we are talking about crippling things even more.

I am going to argue that, if web development and deployment becomes as onerous and mobile, but the end results aren't as good, browsers are doomed.

Security concerns may be valid for some of the features, but addressing them simply *MUST NOT* cripple usability. If it does, browsers are doomed and the independent developer and hobbyist developer classes are dead. Browser developers need to put a leash on their security teams, otherwise the web is in real danger of permissioning itself to death.

Daniel Cheng

unread,
Feb 27, 2015, 12:46:06 PM2/27/15
to dave...@gmail.com, blin...@chromium.org
On Fri, Feb 27, 2015 at 12:14 PM <dave...@gmail.com> wrote:
I worry these changes will hamper creativity and innovation among hobbyists and independent developers. I cannot imagine jumping through hoops and SSL configurations just to get a small Canvas, WebGL or WebVR experiment off the ground. 

One of the most attractive aspects of web programming -- and one of the reasons the JavaScript creative/interactive community is currently booming with beginners and experts alike -- is the extremely low barrier to entry. Complex applications and rich artistic experiences utilizing device motion, webcam, geolocation, etc are easy to build, and even easier for others to open up and view. 

A few examples of projects and experiments that might be hampered with higher barriers and increased restrictions:



I think you have a typo in your first two links. I believe they should be:


Of course, I'm sure you can find other examples that aren't currently served over HTTPS. However, there already exist easy ways to get content onto HTTPS, and with Let's Encrypt, this will become even easier.

Daniel

ma...@krpano.com

unread,
Feb 27, 2015, 1:35:19 PM2/27/15
to blin...@chromium.org
Sorry, but I think that's a horrible idea!!!
Especially the idea to block devicemotion and fullscreen!

E.g. in my case - many users of my software (krpano) are hosting their content (interactive panoramic images) on their own private pages, which are often not served via https.

Without devicemotion it wouldn't be possible anymore to use the gyroscope to pan inside a pano or to view the pano with a VR-headset. Without fullscreen VR wouldn't be possible too!

Here a VR example (for Android mobiles) where this limitation would be very bad - fullscreen and devicemotion support are a must there:

Please rethink this decision!
Not everyone needs or wants https!

Klaus

PhistucK

unread,
Feb 27, 2015, 1:38:42 PM2/27/15
to krpano, blink-dev

ma...@krpano.com

unread,
Feb 27, 2015, 1:41:34 PM2/27/15
to blin...@chromium.org
But not everyone has (or wants) a https capable server! ;-)

postf...@gmail.com

unread,
Feb 27, 2015, 1:48:47 PM2/27/15
to blin...@chromium.org
I share Brandon's concerns. I create WebGL applications myself and I'm familiar with what's going on in WebGL and WebVR communities.

I'm afraid restricting Fullscreen API to eventually work only with HTTPS enabled sites would have potentially strong negative effects on both WebGL and WebVR communities.

For illustration: even just CORS restrictions are pain (prohibiting use of images not originating at the same URL as webpage), and these are much weaker restrictions than what's being proposed here.

Same-origin restrictions are constant source of troubles when developping locally, especially for people new to web development (in three.js community there is a lot of those, maybe even a majority). For three.js we created these instructions:


Yet, even with those instructions easily available (and in collective consciousness of three.js community), something as terrible as recommending always running Chrome with "--disable-web-security" flag made it into a printed book:


With requiring HTTPS such "barrier to entry" would be even higher (presumably also motivating to similarly drastic "workarounds"). 

Despite all the good intentions, getting HTTPS up and running is unfortunately still a messy affair (e.g. I'm not aware of a single individual person in WebGL community who would already run their site on HTTPS, myself included).

The practical effect of those proposed changes would be that only companies and professionals (for which switching to HTTPS is trivial compared to other efforts & costs) would continue to create "full-power" WebGL applications, applications that are in the same category as native applications (e.g. fullscreen games with pointer lock). 

Hobbyists / tinkerers / beginners / students / kids / anybody who just wants to quickly try something would simply avoid using fullscreen and instead be locked into browser tabs.

Now, for WebGL, that would be sad, but still somehow survivable. For WebVR unfortunately it would be deadly. You absolutely do need fullscreen access to make virtual reality work.

Also let's not forget we already do have in place security measures against fullscreen phishing attacks: there is big unmissable warning when going into fullscreen.

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
- make fullscreen warning always a modal dialog (Firefox already does that)

tpa...@gmail.com

unread,
Feb 27, 2015, 1:54:45 PM2/27/15
to blin...@chromium.org, ma...@krpano.com
+1 Klaus

I have a modest proposal: a single security prompt when visiting a new site, triggered by the first "powerful" feature. This brings up an opt-in dialog e.g.:

Allow This Site To

(bunch of check boxes with sensible defaults)

Use Your Camera
Use Your Location
Go Fullscreen
Track Your Device's Orientation (why in god's name is this a security issue?!?)

The contents of this dialog could be generated based on a specific site's needs, so that for example, if the site don't use the camera, that checkbox wouldn't appear. The developer would put it all in an app security manifest, kind of like developing a Facebook or Twitter app. This is MUCH easier than setting up HTTPS. I don't buy the argument that HTTPS deployment is going to get easier. It's always going to be a pile of crap for devs to deal with, it's just the nature of the beast.

Maybe someone from the Chromium team can float this idea to the powers-that-be?

Let's get real people. The elephant in the room is that browser usability is going down the toilet with all this security stuff, and more of the same will only make it worse. (I think an appropriate metaphor would be "death by a thousand cuts.") Not to mention that it has all the impediments for indie developers deploying.

Please throw us normal human web devs a bone here...

dave...@gmail.com

unread,
Feb 27, 2015, 2:02:34 PM2/27/15
to blin...@chromium.org, dave...@gmail.com
Daniel -
Some of the hoops involved with GitHub pages HTTPS:

- updating all blogs/readmes/etc to refer to correct URL
- adding in a JS hack to redirect `window.location.protocol` to HTTPS
- using canonical href in <link> for SEO
- using CloudFlare or another free SSL configuration for custom domains
- additional configurations when the app is moved from gh-pages to a private host

The barrier to entry seems higher for no real gain. And it seems like a determined attacker could also use HTTPS for phishing/etc (correct me if I'm wrong).

Not sure what "Let's Encrypt" is, but it sounds like another tool to get things working (and thus another barrier to entry).

Jeffrey Yasskin

unread,
Feb 27, 2015, 3:38:50 PM2/27/15
to postf...@gmail.com, blink-dev
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 warning

This 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?"

Katelyn Gadd

unread,
Feb 27, 2015, 4:14:32 PM2/27/15