Intent to deprecate: Insecure usage of powerful features

12202 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
to Jeffrey Yasskin, postf...@gmail.com, blink-dev
Given that premise, however, HTTPS doesn't solve the problem, it just
shunts it off to a party other than the browser vendor. In a
HTTPS-only world for html5 games, most developers will be forced to
rely on third parties to provide their encryption - CDNs like
cloudflare/cloudfront, hosting services like github or newgrounds,
etc. In that scenario there's no actual guarantee that the author is
who they say they are, or that the content has been vetted to ensure
it's not malicious, etc. All you've done is slightly raise the cost of
entry for malware while simultaneously erecting huge barriers between
independent developers and their users. We have numerous examples from
app stores like the iOS/Android markets, content hosting sites like
Newgrounds/Kongregate, where malicious parties steal a developer's
app, repackage it (sometimes with additional ads or malware), and put
it back up on hosting sites. HTTPS will do nothing to prevent this
either - to an end user this repackaged content will appear
'legitimate' so if it is considered reasonable to *remove*
prompting/security restrictions on Fullscreen (for example) just
because the content is SSL signed I think that is a huge step
backward.

I particularly object to creating more barriers for independent
developers. The past year has demonstrated that vulnerable minorities
authoring games & multimedia content - not to mention using the
internet in general - are active targets for harassment and violence
that is perpetuated using internet technologies to get personal
information: Required personal information on whois (thankfully
registrars are willing to mask information now), social engineering
against service providers, etc. My understanding is that there is no
way to acquire a valid SSL certificate without providing personal
identity information, since browser vendors helpfully destroyed the
ability to use self-signed certificates. This creates another point of
vulnerability for people authoring HTML5 multimedia content because
another random party has access to their personal information and is
likely to disclose it to hostile parties. I have the necessary time &
resources to acquire a SSL certificate, and have done so in the past,
but I know from those experiences that this is not something it is
reasonable to expect of all people who want to author HTML5 content.
In particular I'm not even sure how someone from a third-world or
restrictive country would go about legally acquiring a valid SSL
certificate. Is it easy for them to do that, or are there plans to
address that? If these security mechanisms disproportionately harm
people outside of the privileged west I think that would be highly
regrettable.

-kg

postf...@gmail.com

unread,
Feb 27, 2015, 5:33:54 PM2/27/15
to blin...@chromium.org, postf...@gmail.com


On Friday, February 27, 2015 at 9:38:50 PM UTC+1, Jeffrey Yasskin wrote:
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?"

Good point. 

So if I understood well, the main concern with the current solution - big annoying warning about entering fullscreen mode - is simply that some people wouldn't care enough about it or would not recognize it as highly suspicious if e.g. it was followed by fake bank site with fake credentials mimicking browser chrome UI credentials (green https + padlock icon).

Then maybe a new better solution could be to make somehow more obvious that fullscreen prompt followed by sensitive site is suspicious. 

It could be simply something like changing fullscreen warning into modal dialog that would show: "you are entering potentially insecure page" if originating URL wasn't HTTPS. Maybe adding red border vs green border and/or no padlock vs padlock icon on that fullscreen dialog for HTTP vs HTTPS origin.

Also instead of fading fullscreen dialog on just timeout (current solution), condition fadeout on at least some user interaction (mouse move, touch, keypress) plus timeout to ensure user always has chance to see concurrently fullscreen dialog overlayed on fullscreen content.

These relatively simple UI changes should make phishing attack much harder to pull off.

Or even something like small permanent overlay in fullscreen mode originating from HTTP (e.g. small broken padlock icon) would be much more preferable to outright disabling of fullscreen mode from HTTP. 

Users would then only have to be careful to never see that overlay while on some sensitive site (it couldn't be overwritten by phishing page because it would be rendered by browser as last). This would be similar to how users currently must pay attention to green padlock area in the upper left side of URL bar (which is the only protection there is against phishing from regular browser UI; for people who don't know they should pay attention to that area, this whole proposal doesn't make any difference anyways).

Such permanent overlay would protect even against more sophisticated attacks which would first try to show some non-sensitive sites in that fake fullscreen browser UI, with only getting to sensitive sites later on.

Please bear in mind - the more convoluted the attack, the easier is to detect it for user - attackers get deeper into "uncanny valley" where they have to emulate more and more of browser functionality in their fake UI. 

Even today fake UI already trivially fails to replicate true browser UI: it's impossible for attacker to replicate any user customizations of browser UI + OS theming (like bookmarks/extension buttons/themes/search engine widget status/Windows Aero transparency background color).

In any case, even if exact suggestions I just wrote were silly / had some obvious flaws, it would be preferable to first stear discussion into examining UI/UX solutions, before concluding this category of security issues have to be resolved only by baking strong restrictions into web standards.

virtu...@gmail.com

unread,
Feb 28, 2015, 5:53:01 AM2/28/15
to blin...@chromium.org
+1 for Klaus
This would be a very very bad idea for all panoramic and online vr producers. Also for their clients and users.
I guess it is google 'april fools'...

Tuur

Kevin Chadwick

unread,
Feb 28, 2015, 11:14:42 AM2/28/15
to Joel Weinberger, blink-dev, dev-se...@lists.mozilla.org
On Thu, 26 Feb 2015 23:25:43 +0000
Joel Weinberger wrote:

> 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.

Seems reasonable, though I think dos and amplification (100x
demonstrated in the past) through ssl is ignored in the TLS speed
concerns.

In the long term and depending on the depth of features that are
moved to requiring https then it may make it more difficult to keep
serving http despite https servers being saturated.

Joel Weinberger

unread,
Mar 1, 2015, 8:01:45 PM3/1/15
to Kevin Chadwick, blink-dev, dev-se...@lists.mozilla.org
Hi everyone. A couple of clarifications and thoughts.
  • As mentioned before, there is no timeline for this deprecation. That's one of the things that we're trying to figure out. We certainly will consider the "ease of use" of SSL in the timeline. But in the meanwhile, check out some of the references given earlier (e.g. sslmate, letsencrypt.org, etc.).
  • 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.
  • As mentioned before, localhost is already considered a "secure context", which should help as development. Additionally, we intend to build a flag that will temporarily disable the secure origin requirement for features for a specific origin. Thus, for testing, this should give a lot of flexibility.
  • I love the idea of restricting persistence of these permissions before outright deprecation. I do not believe we've done this previously, but it's certainly something we've discussed.
Keep the comments, thoughts, and ideas coming. Thanks!
--Joel

Jeffrey Yasskin

unread,
Mar 1, 2015, 9:37:28 PM3/1/15
to Joel Weinberger, dev-se...@lists.mozilla.org, blink-dev, Kevin Chadwick

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.

Jeffrey

oli...@omattos.com

unread,
Mar 2, 2015, 4:55:35 PM3/2/15
to blin...@chromium.org, j...@chromium.org, dev-se...@lists.mozilla.org, ma1l...@yahoo.co.uk, jyas...@google.com
How about "HTTP origins can't persist any permission grant.".

That way every feature still works.   Network attackers can still do bad stuff, but it won't persist.  It also provides an SSL upgrade incentive.

The permission grant dialogue for insecure origins could be reworded to say "Do you want to give *the internet* access to your camera?"

Now users are informed that potentially more than just the website showing can access the camera.

Joel Weinberger

unread,
Mar 3, 2015, 6:10:56 PM3/3/15
to oli...@omattos.com, blin...@chromium.org, dev-se...@lists.mozilla.org, ma1l...@yahoo.co.uk, jyas...@google.com
I certainly agree that this would be a great start/halfway point, but it doesn't really address the fundamental issue, which is that if a user trusts an origin, they'll grant the permission. And even if the permission isn't persistent, they'll still be granting the permission to any man-in-the-middle.
--Joel

seddo...@gmail.com

unread,
Mar 5, 2015, 12:15:50 AM3/5/15
to blin...@chromium.org
As a core developer on Modernizr I'm wondering how feature detection will be effected by these changes? If I do a check for the fullscreen api on a http site will it return false? Would it inform me through throwing an exception that this feature is available but requires https?

Philip Jägenstedt

unread,
Mar 5, 2015, 1:59:06 AM3/5/15
to seddo...@gmail.com, blink-dev
This is speculation at this point, but I expect that
Document.fullscreenEnabled would return false in this situation, so
that it could be detected synchronously and without actually trying to
enter fullscreen.

It would be quite bad if any APIs which get restricted to secure
origins will only fail after trying to use the API and in a way which
is indistinguishable to some pre-existing failure, so that's
definitely something to keep in mind.

Philip

On Thu, Mar 5, 2015 at 12:15 PM, <seddo...@gmail.com> wrote:
> As a core developer on Modernizr I'm wondering how feature detection will be effected by these changes? If I do a check for the fullscreen api on a http site will it return false? Would it inform me through throwing an exception that this feature is available but requires https?
>

Anne van Kesteren

unread,
Mar 5, 2015, 2:03:39 AM3/5/15
to Philip Jägenstedt, Ryan Seddon, blink-dev
On Thu, Mar 5, 2015 at 7:59 AM, Philip Jägenstedt <phi...@opera.com> wrote:
> It would be quite bad if any APIs which get restricted to secure
> origins will only fail after trying to use the API and in a way which
> is indistinguishable to some pre-existing failure, so that's
> definitely something to keep in mind.

Why exactly? It's not like there's an alternative other than moving to TLS.


--
https://annevankesteren.nl/

Philip Jägenstedt

unread,
Mar 5, 2015, 2:32:14 AM3/5/15
to Anne van Kesteren, Ryan Seddon, blink-dev
I imagine that there are libraries that would want to work on both
secure an insecure origins in the presumably long and somewhat bumpy
transition period. If the thing that requires a secure origin is just
a nice-to-have, like say fullscreen mode or "take picture and insert"
for a rich text editor, it's nice to be able to hide that bit of UI if
you know that it isn't going to work.

It's a safe bet that many Web developers will be unhappy with any of
the suggested changes, and making the behavior impossible to feature
detect would make it more difficult for them.

(Just guessing, I'm not an actual Web developer.)

Philip

Brandon Jones

unread,
Mar 5, 2015, 2:33:35 PM3/5/15
to Philip Jägenstedt, Anne van Kesteren, Ryan Seddon, blink-dev
On Wed, Mar 4, 2015 at 11:32 PM Philip Jägenstedt <phi...@opera.com> wrote:
If the thing that requires a secure origin is just
a nice-to-have, like say fullscreen mode

I imagine that if you ask developers at YouTube, Netflix, Vimeo, or Twitch they would vigorously disagree with the characterization of fullscreen as "nice to have". Same with games or presentation software. Let's be sure to not minimize the importance of some of the features we're talking about walling off.
 
(Just guessing, I'm not an actual Web developer.)

I don't intend this as a personal knock, but I think many web developers are greatly concerned by these kind of statements in a discussion like this. It gives the impression that an out-of-touch native developer is imposing arbitrary limitations on a class of content they don't understand. I feel this isn't accurate in your case, but these are the types of quotes that people love to take out of context.

In any case, I want to make sure that we have a really firm grasp on how developers are actually using these features before we make moves to limit them.

--Brandon

Philip Jägenstedt

unread,
Mar 5, 2015, 10:53:29 PM3/5/15
to Brandon Jones, Anne van Kesteren, Ryan Seddon, blink-dev
On Fri, Mar 6, 2015 at 2:33 AM, Brandon Jones <baj...@google.com> wrote:
> On Wed, Mar 4, 2015 at 11:32 PM Philip Jägenstedt <phi...@opera.com> wrote:
>>
>> If the thing that requires a secure origin is just
>> a nice-to-have, like say fullscreen mode
>
> I imagine that if you ask developers at YouTube, Netflix, Vimeo, or Twitch
> they would vigorously disagree with the characterization of fullscreen as
> "nice to have". Same with games or presentation software. Let's be sure to
> not minimize the importance of some of the features we're talking about
> walling off.

I grouped that poorly. By 'a nice-to-have, like say fullscreen mode or
"take picture and insert"
for a rich text editor' I meant both features in the context of a rich
text editor, where removing those features from the UI would still
leave you with something worth using.

But on second thought, when the feature isn't a nice-to-have but the
central purpose, it's equally helpful to know up-front that it's not
going to work, at least for a library that could end up used in any
context. It's a solved problem for Fullscreen
(document.fullscreenEnabled) but I haven't looked at the other
features.

>> (Just guessing, I'm not an actual Web developer.)
>
>
> I don't intend this as a personal knock, but I think many web developers are
> greatly concerned by these kind of statements in a discussion like this. It
> gives the impression that an out-of-touch native developer is imposing
> arbitrary limitations on a class of content they don't understand. I feel
> this isn't accurate in your case, but these are the types of quotes that
> people love to take out of context.
>
> In any case, I want to make sure that we have a really firm grasp on how
> developers are actually using these features before we make moves to limit
> them.

Point taken, my remark could be seen as gleeful ignorance rather than
an honest admittance that I could be wrong.

Philip

Joel Weinberger

unread,
Mar 6, 2015, 12:15:54 AM3/6/15
to Philip Jägenstedt, Brandon Jones, Anne van Kesteren, Ryan Seddon, blink-dev
My assumption has been that a feature would simply be rejected as if it had been denied. I don't think I see why this would be problematic, either. If the idea is that a site has an HTTPS version but only wants to serve it if feature X can only be used on HTTPS, I don't really see a problem in requiring that the application simply serve HTTPS all the time. Philip, can you clarify why it's important to have feature detection in these cases?

Anne, what does navigator.serviceWorker.register() do if called from an HTTPS page?
--Joel

Philip Jägenstedt

unread,
Mar 6, 2015, 1:11:07 AM3/6/15
to Joel Weinberger, Brandon Jones, Anne van Kesteren, Ryan Seddon, blink-dev
Joel, consider the "take picture and insert" feature for a rich text editor that can be included as a library on any site. getUserMedia() is the async API with which you would implement this. Would there be a way to know while building the UI that the feature is never going to work (if we're on an insecure origin) to either remove or disable the button?

Admittedly I'm speculating on what library authors would want, and the discussion is premature until we're about to introduce a restriction for some specific API.

Philip

Katelyn Gadd

unread,
Mar 6, 2015, 1:17:55 AM3/6/15
to Philip Jägenstedt, Joel Weinberger, Brandon Jones, Anne van Kesteren, Ryan Seddon, blink-dev
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.

In some cases the solution will be for the user to replace 'http:'
with 'https:' but they don't have any easy way to know that. Some
websites don't have a secure version in which case the developer will
need to update the site, but if the feedback is poor there will be
little reason for a typical user to realize that they need to complain
to the developer, and the developer might not realize that they need
to update their website to conform to these new standards. The fact
that these changes probably won't be rolled out with equal timing in
different browsers could easily lead to end users assuming the browser
they're using is broken.

I think changes to existing shipped APIs in wide use like fullscreen
need a lot of careful thought applied in that area if you don't want
to have a painful years-long evangelism just to get existing apps and
samples and tutorials working again. Even once that evangelism work is
done, outdated information out there will probably continue to mislead
newbie developers.

So given this, I want to echo Philip's statement here: It needs to be
possible to detect that these features are unavailable in a given
context, and perhaps possible to get a clear explanation of why that
you can present to the end-user or respond to (for example by
redirecting to https.)

Mike West

unread,
Mar 6, 2015, 2:01:52 AM3/6/15
to Joel Weinberger, k...@luminance.org, Philip Jägenstedt, Brandon Jones, Anne van Kesteren, Ryan Seddon, blink-dev
On Fri, Mar 6, 2015 at 7:24 AM, Joel Weinberger <j...@chromium.org> wrote:
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.

I believe most APIs we're looking at follow a request-based model, giving us an opportunity to reject the request. Developers (should) already be handling error cases. Fullscreen, for instance, has a number of failure conditions (step 3 of https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen). We're more or less talking about adding one more condition over time.

To the larger point regarding feature detection, I can think of three ways to do this:

1. Add an attribute to the global object exposing whether or not the browser considers it a privileged context, which would allow libraries like Modernizr to summarize support in a particular context.

2. Extend the forthcoming permissions API (https://w3c.github.io/permissions/) to include the permissions we care about in this context, which would allow pages to query for permission before executing code.

3. Remove the relevant APIs when they're not available. I suspect this would break pages, as I doubt anyone is writing `if (navigator.geolocation) { ... }`, but it's an option.

Are there other options folks would find palatable?

-mike

Anne van Kesteren

unread,
Mar 6, 2015, 3:15:05 AM3/6/15
to Joel Weinberger, Philip Jägenstedt, Brandon Jones, Ryan Seddon, blink-dev
On Fri, Mar 6, 2015 at 6:15 AM, Joel Weinberger <j...@chromium.org> wrote:
> Anne, what does navigator.serviceWorker.register() do if called from an
> HTTPS page?

slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#service-worker-postmessage
you get a promise rejected with a DOMException whose name is
"SecurityError".

I think Philip's point about existing APIs requiring some kind of
feature detection to ease transition makes sense though. On the other
hand, if the numbers for these APIs are low anyway, as has been
suggested for some (e.g. geolocation), it might be more effort than
it's worth.


--
https://annevankesteren.nl/

Anne van Kesteren

unread,
Mar 6, 2015, 3:19:07 AM3/6/15
to Mike West, Joel Weinberger, Katelyn Gadd, Philip Jägenstedt, Brandon Jones, Ryan Seddon, blink-dev
On Fri, Mar 6, 2015 at 8:01 AM, Mike West <mk...@chromium.org> wrote:
> 2. Extend the forthcoming permissions API
> (https://w3c.github.io/permissions/) to include the permissions we care
> about in this context, which would allow pages to query for permission
> before executing code.

Yeah, perhaps something like Permissions.available() so you can
feature detect whether or not to include certain UI. On the other
hand, if the end game is going to be TLS, libraries should simply tell
their embedders that. It's not entirely clear to me that making it
easier to write non-TLS application UI is a worthwhile investment.


--
https://annevankesteren.nl/

MSI Team

unread,
Mar 21, 2015, 12:58:14 PM3/21/15
to securi...@chromium.org, blin...@chromium.org

So, to that point, we'd love to hear what the community thinks.

Those should indeed be secured. 

Ryan Sleevi

unread,
Mar 22, 2015, 3:55:23 AM3/22/15
to MSI Team, blink-dev
Removing security-dev to BCC, to reduce cross-posting.

Joel

unread,
Apr 30, 2015, 1:44:17 PM4/30/15
to blin...@chromium.org
Hi everyone. I've created https://codereview.chromium.org/1115913002/ to add a deprecation warning to the discussed APIs (except for EME, which is being handled separately). I would love to get the thoughts of the API owners to confirm that this looks good to them. Thanks!
--Joel

Philip Rogers

unread,
Apr 30, 2015, 1:56:20 PM4/30/15
to Joel, blink-dev
LGTM, this is good to go.

Brandon Jones

unread,
Apr 30, 2015, 3:11:37 PM4/30/15
to Philip Rogers, Joel, 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 testing?
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 content?

Kenneth Russell

unread,
Apr 30, 2015, 3:23:06 PM4/30/15
to Brandon Jones, Philip Rogers, Joel, blink-dev
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.

-Ken

Joel Weinberger

unread,
Apr 30, 2015, 4:18:20 PM4/30/15
to Kenneth Russell, Brandon Jones, Philip Rogers, blink-dev
Thanks for the additional comments! I've inline some thoughts and response below.
--Joel

On Thu, Apr 30, 2015 at 12:23 PM Kenneth Russell <k...@chromium.org> wrote:
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
We have. http://feross.org/html5-fullscreen-api-attack is the canonical demo of this (obviously, not an actual attack site).
show up for that feature as well as getUserMedia and geolocation are
It's not just about phishing, but also about MiTM where you abuse a site that already has the permission. Without HTTPs, a passive attaker can sniff your traffic and steal your location (or your video, or your audio, etc). Fullscreen, as discussed earlier, is not subject to this passive attack, of course, which is why it is likely to be the last to be moved to HTTPS.
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
Why is it infeasible? We should make it feasible, and we (the Chrome Security team) would very much like to know about specific cases that are making it impossible or just plain difficult in the long tail to get certs. If it's just about cost, please see below.
believe that this effort is misguided and will drive users away from
browsers based on Blink.

-Ken


On Thu, Apr 30, 2015 at 12:11 PM, 'Brandon Jones' via blink-dev
<blin...@chromium.org> wrote:
> 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
> testing?
Yes. localhost is already treated as a secure origin, so that doesn't cause a deprecation warning. Additionally, just today, there's a CL out that will allow for a command-line whitelisting of insecure origins that should be treated as secure, so developers can test on any domain (https://codereview.chromium.org/1072933006/).
> 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.
The consensus is that we'll deprecate based on usage. Part of the patch is, for example, adding use counters for fullscreen over insecure channels. Additionally, we're looking at Rappor (https://www.chromium.org/developers/design-documents/rappor) to better understand the usage numbers, rather than just raw numbers.
> 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.
There are various efforts to do so (https://letsencrypt.org/ is the major one I'm aware of, not to mention https://www.startssl.com/ and https://www.cloudflare.com/ which already offer free certs).

However, 0 cost across has never been a requirement, and I don't expect it to be. Servers are generally not free, either, but they're a prerequisite for running a web application. Low cost is obviously important, but I don't see 'free across the board' as a prereq. If it is, then we should start a thread on that.
> 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
> content?
I'm not sure I understand the question. The proposal is that, eventually, developers will not be able to use these features without SSL, other than for development. The broad goal is to make SSL easy and accessible everywhere, and that's certainly something Google has many projects working on.