Intent to deprecate: Insecure usage of powerful features

[Joel Weinberger]

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]

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]

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]

(+www...@w3.org to bcc)

[npd...@berkeley.edu]

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]

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]

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]

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]

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]

My concerns over the policy would indeed rapidly diminish as the costs of deploying HTTPS (monetary and mental) approach zero.

[Glenn Adams]

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

[1] https://w3c.github.io/webappsec/specs/powerfulfeatures/#feature-requires-privilege

[2] https://w3c.github.io/webappsec/specs/powerfulfeatures/#threat-models

[3] http://www.dlna.org/dlna-for-industry/guidelines

 

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

[Philip Jägenstedt]

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]

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]

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]

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]

Will this also affect flash/unity full screen? Or only HTML5 full screen?

[karthi...@gmail.com]

I am not happy with this, unlocking browser features with SSL. First make SSL free and easy to setup.

[karthi...@gmail.com]

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]

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]

+1 Scott, I'm not seeing it, would love to see the rationale and argue against them.

[plue...@googlemail.com]

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]

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:

http://mattdesl.github.io/impressionist-3d/

http://auduno.github.io/clmtrackr/examples/facesubstitution.html

http://a-way-to-go.com/

http://christmasexperiments.com/

http://elevr.com/webvr-experiments/

[katsuomi....@gmail.com]

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]

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]

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]

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:

http://mattdesl.github.io/impressionist-3d/

http://auduno.github.io/clmtrackr/examples/facesubstitution.html

http://a-way-to-go.com/

http://christmasexperiments.com/

http://elevr.com/webvr-experiments/

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

https://mattdesl.github.io/impressionist-3d/

https://auduno.github.io/clmtrackr/examples/facesubstitution.html

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]

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:

http://d8d913s460fub.cloudfront.net/krpanocloud/webvr/index.html?v=119pr1

Please rethink this decision!

Not everyone needs or wants https!

Klaus

[PhistucK]

You mean -

https://d8d913s460fub.cloudfront.net/krpanocloud/webvr/index.html?v=119pr1

:)

☆PhistucK

[ma...@krpano.com]

But not everyone has (or wants) a https capable server! ;-)

[postf...@gmail.com]

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:

https://github.com/mrdoob/three.js/wiki/How-to-run-things-locally

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:

https://twitter.com/mrdoob/status/568485386869190656

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]

+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]

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]

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]

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]

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]

+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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

Those should indeed be secured. 

[Ryan Sleevi]

Removing security-dev to BCC, to reduce cross-posting.

[Joel]

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]

LGTM, this is good to go.

[Brandon Jones]

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]

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]

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.

[Joel Weinberger]

Also, in timely news, Mozilla announced their intent to depreciate HTTP, including a similar intent to deprecate powerful features: https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
-Joel

[Yoav Weiss]

On Fri, May 1, 2015 at 1:44 AM, Joel Weinberger <j...@chromium.org> wrote:

Also, in timely news, Mozilla announced their intent to depreciate HTTP, including a similar intent to deprecate powerful features: https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
-Joel

They're not talking about deprecating powerful features, but about deprecating *all* new features.

IMO that is not the way to go, since it'd just slow down adoption of new features while applying very little pressure on the business folks that make these decisions. Henri Sivonen made an interesting suggestion on that thread, to limit persistency of cookies on HTTP. That approach can apply pressure at the right places.

[Joel Weinberger]

On Thu, Apr 30, 2015 at 10:09 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Fri, May 1, 2015 at 1:44 AM, Joel Weinberger <j...@chromium.org> wrote:

Also, in timely news, Mozilla announced their intent to depreciate HTTP, including a similar intent to deprecate powerful features: https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
-Joel

They're not talking about deprecating powerful features, but about deprecating *all* new features.

Yes, my mistake. I meant that they're intending to deprecate old powerful features (in their parlence "features that pose risk to security and privacy", their step 2), which is similar to what we've proposed on this thread.

[Brandon Jones]

On Thu, Apr 30, 2015 at 1:18 PM Joel Weinberger <j...@chromium.org> wrote:

http://feross.org/html5-fullscreen-api-attack is the canonical demo of this (obviously, not an actual attack site).

Thanks for the demo, it is an interesting proof of concept. I'm not sure I understand how forcing that site to be HTTPS changes the mechanics of the attack in any way, though. Could you clarify?

--Brandon

[PhistucK]

If a man in the middle responds with their content for bankofamerica.com (the HTTP one), the full screen notice will say "bankofamerica.com", but that cannot happen with HTTPS.

☆PhistucK

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

[pya...@gmail.com]

On Friday, May 1, 2015 at 10:30:41 PM UTC+2, PhistucK wrote:

If a man in the middle responds with their content for bankofamerica.com (the HTTP one), the full screen notice will say "bankofamerica.com", but that cannot happen with HTTPS.

That's not specific to fullscreen. If a middle man responds with their content for bankofamerica.com (HTTP) they don't require fullscreen to spoof you. So surely that can't be a valid reason to coerce fullscreen off for non HTTPS.

[PhistucK]

The difference is that the user can see that something is different (not HTTPS, no green lock, no "Bank of America" token in the address bar) without the full screen spoof. Obviously, the user should be alert for that, but it is arguably easier to deceive a user in full screen than without.

☆PhistucK

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

[Florian Bösch]

I'm just wondering what I'll tell my clients when they come to me "hey your fullscreen button broke, can you fix it?" and I go like: "Yeah sure, you'll just need to use HTTPS, and up to date OpenSSL, which your server probably doesn't support, so if you could please be so kind as to get a brand spanking new VPS to fix the button?". And they would probably go like "wut?", and then I'll probably have to remove the button. And I guess, that'll be "mission acomplished" then right?

[Joel Weinberger]

The MiTM thatbim more worried about is in the case that I've already granted fullscreen to an HTTP site, say nytimes.com. Then when a MiTM creates this fullscreen attack, there will be only the short, temporary warning, rather than an Allow/Blcok option.

[Florian Bösch]

If somebody is already impersonating the nytimes.com, to gain your password for instance, then they don't require fullscreen. I don't see how fullscreen is made any more secure by HTTPs, and I don't see how HTTP is made any less secure by the presence of fullscreen.

[Florian Bösch]

I have polled a client of mine which has a small web property that contains a WebGL widget which does include a fullscreen button.

Here is what I wrote that client:

I'd like to inform you that it's likely that the fullscreen button will break in google chrome and firefox in the forseeable future (mid 2015-2016). For security reasons browsers want to disable fullscreen if you are not serving the website over HTTPS.
Starting mid 2015 a new SSL Certificate Authority will offer free certificates (https://letsencrypt.org/)
Do you think you could host your site over HTTPS to prevent the fullscreen button breaking? If required, I could also remove the fullscreen button.

The clients response below:

I appreciate the heads up.  
Redesigning our site to use HTTPS is probably possible but I currently do not have time and resources to undertake that task.
Would it be possible to let me know when you get the information that the first production Chrome or Firefox is released?  At that time I can certainly disable the fullscreen function myself as this is real easy to do in your .js file.

I quote this conversion because precisely this scenario is what is going to play out across countless web properties once fullscreen and other features are put behind HTTPS.

The practice will be that fullscreen and any other feature that is so mandated behind HTTPS, can just not be used anymore. Existing deployments will break, and they cannot be fixed. Future uses of these features will be impossible in many cases. Often for sites which do not handle any sensitive information, promotional pages, advertising, infographics, data visualization, games etc.

While your goals may be noble, and your causes justified, it isn't going to change that you will effectively retire these features from the web altogether.

Encouraging TLS deployment, providing better/free CAs, easing TLS configuration, those are all good things to do. Coercing site operators into useing TLS by denying them features is not a good thing to do. And the outcome will not be what you seek.

[Florian Bösch]

There is another issue that went perhaps completely ignored so far.

Any video sharing site will have problems with moving fullscreen behind HTTPS.

Youtube, Vimeo etc. allow people to embed the player into their pages. These sites also offer HTML5 video players, and the fullscreen functionality greatly benefits that usecase as it puts it on parity with flash.

However the fullscreen permission is pinned to the embeding site, not the originating iframe. And so anybody who embeds those video players would no longer be able to get access to fullscreen if the html5 video player is used. Meanwhile, flash does not have that problem. So it comes down to a choice of breaking millions of web-pages that embed the viewer and try to explain the people who do it that if they want the full html5 video functionality, that they have to serve their sites via HTTPS, or switch back to a flash player.

[PhistucK]

I imagine Flash based full screen will be restricted as well (or else it would not make sense).

☆PhistucK

[Yoav Weiss]

Specific to full-screen, wouldn't disabling the pinning be enough? That way, existing http based full screen would still work, but the user would have to authorize it every time, making sure it isn't abused without the user understanding that the current site is going full screen.

[Florian Bösch]

That's not up to the UA, that's Adobes business. I don't know their intentions, but I'd imagine they'd be very happy to leave a feature in place that gives them a distinct advantage over html5 video players.

On Sat, May 2, 2015 at 10:53 PM, PhistucK <phis...@gmail.com> wrote:

[PhistucK]

Frankly, I would not count on it.

While Adobe has some control, Google are in charge of the PPAPI support in Chrome and can limit Flash in any way they see fit.

Microsoft has a built in Flash on Windows 8 and later, I imagine their co-operation can involve restricting this feature.

However, I do not suppose Adobe will even refuse. Remember that they invest in HTML5 lately and Flash is seriously decreasing in popularity.

☆PhistucK

[Florian Bösch]

I get annoyed everytime I have to re-allow the youtube embedded player on another page again for fullscreen. That's just cementing that in place. Couldn't you pin to the originating iframe?

[Florian Bösch]

On Sat, May 2, 2015 at 11:03 PM, PhistucK <phis...@gmail.com> wrote:

However, I do not suppose Adobe will even refuse. Remember that they invest in HTML5 lately and Flash is seriously decreasing in popularity.

Flash is only decreasing in popularity because html5 has reached feature parity. But if suddenly that is not the case anymore, it's either:

1) explain users of the embed players to upgrade to HTTPS if they want the fullscreen button and accept that fullscreen will stop working for a very large portion of embedding sites.

2) revert back to the flash player which doesn't have that issue.

If you're faced with crippling your viewer or reverting to a technology that still does what you want, for a page-view driven business the decision is pretty simple.

[PhistucK]

Again, I do not think Adobe will fight Chrome and Firefox and allow Flash to go full screen in situations where HTML5 does not, since it is a security feature and frankly, it will just make them look bad and insecure.

☆PhistucK

[Florian Bösch]

Again, if you're faced with cripled functionality and millions of web pages that all need migrating to HTTPS or the video player don't work no longer, and your support hotlines run amok because your customers are complaining en-masse, all that goes out the window. Sharing sites will chose what works, and works more often than html5, and Adobe will serve its prime usecase best it can without ideology. I do think that when push comes to shove, Adobe will fight Chrome and Firefox if they decide to cripple their players.

[PhistucK]

You seem to think that the full screen feature is the most important thing in a video player. The video is the most important thing in a video player. And a lot of people do not even think about going full screen (perhaps technical people do it more, but my non-technical family members do not go full screen almost ever if I do not tell them to do it, or do it for them).

☆PhistucK

[thund...@illyriad.co.uk]

Geolocation and getUserMedia I can see it makes sense for.

Encrypted Media Extensions, the inclusion isn't for the user, or the hoster (as they would be the decider whether to use https) so I assume its for 3rd party media providers to trust the technology?

Device motion / orientation pretty esoteric; straight MitM script injection gives you any on page attack vectors; forcing https doesn't prevent bad actors for off page though I suppose it ties blame?

Fullscreen however seems unnecessary to include in this group:

> If a man in the middle responds with their content for bankofamerica.com (the HTTP one), the full screen notice will say "bankofamerica.com", but that cannot happen with HTTPS

You display bankofamerica.com (not-secure)

> The MiTM thatbim more worried about is in the case that I've already granted fullscreen to an HTTP site, say nytimes.com.

You don't allow grants to persist in HTTP

> The broad goal is to make SSL easy and accessible everywhere

Which is a noble goal, however this is far more aggressive and moving towards trying to make http undesirable everywhere

For users of these features to keep their pages working; they then have to keep their certificates always up to date, rather than just leaving a page up. Which includes being aware of entire CAs and every certificate they have ever issued being dropped (e.g. CNNIC), protocols and certificates that use them being deprecated (e.g. SHA-1-based signatures, non forward secrecy, and obsolete cipher suites). People are bad enough keeping old pages html up to date; hence the horrible garbling and twisting of the UA string; or the pain around css prefixes causing browser vendors to have to start accepting other browsers prefixes.

I understand there is a general desire for everything everywhere to be https and there are a lot of bad actors; whether government scale; isp (comcast injecting ads http://arstechnica.com/tech-policy/2014/09/08/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/) etc

But there is also a risk of weakening the trust in https. Outside the security community; custom domains are probably seen as far more important than https and even outweigh sites being broken to some people due to MitM injection or manipulation. While a lot of providers for cloud services allow https and/or allow custom domains; many either don't do both, or use the requirement as the marker higher costs.

Where do you see this going? For example say in the future every cloud provider accepts tls for custom domains (we aren't there yet), and I have a custom experiment on Google App engine, another on Heroku; a repo and some pages on Github, something on Azure and something else on Amazon; a merchandise shop on cafepress; a product line on shopify and "end of line" shop on ebay; a blog on wordpress; maybe also using a couple cdns; some legacy some current - all on custom domains. Do you generate a cert for all of them? Or are you passed the tipping point and don't want to renew and keep up to date that many certs? Just make a wildcard (which your CA hands over the keys to in a plain text email)? A start up in SF is doing something exciting, so you hand over your wildcard and keys to test it out...

Also you get unintended side effects from forcing the issue like gogo which doesn't want video streaming over its airplane wifi; but since a lot of traffic is now https it MitM all https to do packet inspection and prevent it http://www.tripwire.com/state-of-security/latest-security-news/heads-up-frequent-fliers-gogo-inflight-wifi-found-issuing-fake-ssl-certificates/

I'm all up for SSL everywhere; but lets see how things like https://letsencrypt.org/ work out first and how auto renewal fits into this picture; if other providers step up to offer similar services and what cross platform features are like.

Though looking at responses you could probably just take Fullscreen out of the set of features and most of the complaints would go away ;-)

And also hopefully pointer lock isn't in the group...

[Brandon Jones]

I've been mulling this over, and I'm still not sure I understand why restricting Fullscreen to HTTPS makes users safer. Phistuck mentioned that a concern was a supposedly "safe" domain showing as the requestor of the fullscreen privileged, However in the demonstrated attack linked earlier (http://feross.org/html5-fullscreen-api-attack) the domain that displays on the Fullscreen Allow popup is feross.org, not bankofamerica.com. Assuming the user isn't paying attention to the domain displayed on the dialog this attack is still just as effective with HTTPS as it is HTTP. In order to avoid that you would have to have the aforementioned Man-in-the-middle attack in place to inject your false UI into the page and have it show as if it's from the correct domain. I understand that to be a very legitimate concern.

But... If my banking site has been MitM-ed don't I have a bigger problem? In the same context the attacker could easily install a simple listener that monitors keypress events and relays them to a third party. That would be far more invisible/harmful to users, especially since it doesn't involve fullscreen animations, screen flickering, or permissions dialogs, not to mention removes the need to mock up the targets UI for your own fullscreen page. To that end, I question what attacker with MitM injection capabilities would ever bother with fullscreen when there are far easier ways to do their dirty work.

So while I agree that these types of attacks are dangerous hiding Fullscreen and similar functionality behind HTTPS feels like confiscating people's pocket knives as they enter a shooting range. Yes, they can't stab anyone anymore, but was that really the primary safety concern?

--Brandon

[gebacke...@gmail.com]

Very much against this. 

I don't see how requiring https for fullscreen is supposed to make things secure. With apparently free https certificates available and mozillas plans to get rid of http alltogether, any site may have a https certificate, including malificient sites. 

[Justin Novosad]

On Mon, May 4, 2015 at 5:56 PM, 'Brandon Jones' via blink-dev <blin...@chromium.org> wrote:

I've been mulling this over, and I'm still not sure I understand why restricting Fullscreen to HTTPS makes users safer. Phistuck mentioned that a concern was a supposedly "safe" domain showing as the requestor of the fullscreen privileged, However in the demonstrated attack linked earlier (http://feross.org/html5-fullscreen-api-attack) the domain that displays on the Fullscreen Allow popup is feross.org, not bankofamerica.com. Assuming the user isn't paying attention to the domain displayed on the dialog this attack is still just as effective with HTTPS as it is HTTP. In order to avoid that you would have to have the aforementioned Man-in-the-middle attack in place to inject your false UI into the page and have it show as if it's from the correct domain. I understand that to be a very legitimate concern.

I totally agree with that argument. Perhaps the solution to making fullscreen more secure is to improve the Fullscreen Allow pop-up. For example, the popup should indicate whether the page is using http or https, show the lock icon, etc. Right now it just shows the domain. Also, the popup should reappear on navigation events that go to a different domain or that switch between http and https. The pivotal element of the fullscreen attack is to show a false location bar, in order to trick the user into trusting the page. Security-aware users know to use the location bar to decide whether to trust a page, so perhaps it would make sense to make the fullscreen pop-up look more like a location bar.

[Brandon Jones]

On Tue, May 5, 2015 at 7:44 AM Justin Novosad <ju...@chromium.org> wrote:

I totally agree with that argument. Perhaps the solution to making fullscreen more secure is to improve the Fullscreen Allow pop-up. For example, the popup should indicate whether the page is using http or https, show the lock icon, etc. Right now it just shows the domain. Also, the popup should reappear on navigation events that go to a different domain or that switch between http and https. The pivotal element of the fullscreen attack is to show a false location bar, in order to trick the user into trusting the page. Security-aware users know to use the location bar to decide whether to trust a page, so perhaps it would make sense to make the fullscreen pop-up look more like a location bar.

These are suggestions I can get behind 100%! 

[Florian Bösch]

On another thread on this topic it was suggested that confirmation dialogs could go away completely in all cases (http and https) by designing the fullscreen effect more visibly. I think that would be a very worthwhile because that would take care of other UX issues as well (confirm dialog creep and ineffective permission pinning for fullscreenable iframes).

[Joel Weinberger]

Hi everyone. I've inlined a few more response below. Also, if anyone is at BlinkOn this week and wants to discuss this topic, please let me know! I'm around and happy to chat pretty much any time.

--Joel

On Tue, May 5, 2015 at 7:56 AM 'Brandon Jones' via blink-dev <blin...@chromium.org> wrote:

I've been mulling this over, and I'm still not sure I understand why restricting Fullscreen to HTTPS makes users safer. Phistuck mentioned that a concern was a supposedly "safe" domain showing as the requestor of the fullscreen privileged, However in the demonstrated attack linked earlier (http://feross.org/html5-fullscreen-api-attack) the domain that displays on the Fullscreen Allow popup is feross.org, not bankofamerica.com. Assuming the user isn't paying attention to the domain displayed on the dialog this attack is still just as effective with HTTPS as it is HTTP. In order to avoid that you would have to have the aforementioned Man-in-the-middle attack in place to inject your false UI into the page and have it show as if it's from the correct domain. I understand that to be a very legitimate concern.

But... If my banking site has been MitM-ed don't I have a bigger problem? In the same context the attacker could easily install a simple listener that monitors keypress events and relays them to a third party. That would be far more invisible/harmful to users, especially since it doesn't involve fullscreen animations, screen flickering, or permissions dialogs, not to mention removes the need to mock up the targets UI for your own fullscreen page. To that end, I question what attacker with MitM injection capabilities would ever bother with fullscreen when there are far easier ways to do their dirty work.

I think we've been misled by the 'banking site' example. Forget the banking site. Take the nytimes.com, which is pretty much just a content site, and one that requests fullscreen for a variety of reasons, and is only served over HTTP.

Now, when a user grants http://nytimes.com the fullscreen permission, they've set themselves up for a bad time. Per Brandon's comment, yes, it's true, a MiTM can setup a keylogger on nytimes.com, but really, that's not so bad, because nytimes.com is pretty much just a content consumption site. What is bad, is elevating that MiTM to effectively "control" every other origin.

Since the user has previously granted the nytimes.com fullscreen, a MiTM can start injecting content that waits for a navigation, for example. Once that navigation occurs, they can go fullscreen and replicate whatever browser chrome they want (a la the feross.org example shown earlier), thus tricking the user into interacting with their content, as if it was the browser.

So now the attacker has elevated what was merely an attack against the nytimes.com into an attack against all of Chrome. This is our primary concern.

[Florian Bösch]

On Wed, May 13, 2015 at 6:16 AM, Joel Weinberger <j...@chromium.org> wrote

So now the attacker has elevated what was merely an attack against the nytimes.com into an attack against all of Chrome. This is our primary concern.

This isn't made much worse by HTTP and sprinkling HTTPS like magic dust on it doesn't make it any much better. Anybody, good or bad, can use HTTPS. There's nothing whatsoever stopping anybody from setting up a HTTPS site and impersonating the browser shell. You might ask, well why would somebody grant a malicious site fullscreen? Well how do you know it's malicious? It could be nytimes.com got XSS'ed, or somebody set up a particular sting site like mymouthofmadnessclone.com or whatever.

HTTPS is not magic fairy dust. Fix your UX

[Florian Bösch]

I don't have statistics on this, I'm sure it could be found somewhere, but comparing attacks on sites and looking at XSS, MiTM and breaking in the server:

MiTM only provides control over some users of a site (the ones routing across your proxy/network), not all users of the site.

To gain control over the entire site somebody's got to break into the server. If they already broke into the server, they don't need MiTM.

XSS also grants control over the entire site, and if you have that, you don't need either MiTM or breaking into the server.

Due to being very much more effective, I'm pretty sure XSS and breaking into servers are much more prevalent than MiTMs. But you're not worried about XSS and breaking into servers?

[Jeffrey Yasskin]

On Tue, May 12, 2015 at 11:23 PM, Florian Bösch <pya...@gmail.com> wrote:
> I don't have statistics on this, I'm sure it could be found somewhere, but
> comparing attacks on sites and looking at XSS, MiTM and breaking in the
> server:
>
> MiTM only provides control over some users of a site (the ones routing
> across your proxy/network), not all users of the site.
>
> To gain control over the entire site somebody's got to break into the
> server. If they already broke into the server, they don't need MiTM.
>
> XSS also grants control over the entire site, and if you have that, you
> don't need either MiTM or breaking into the server.
>
> Due to being very much more effective, I'm pretty sure XSS and breaking into
> servers are much more prevalent than MiTMs. But you're not worried about XSS
> and breaking into servers?

The same groups working on HTTPS proposals are also working on CSP to
prevent XSS. It's not either/or.

[Florian Bösch]

On Wed, May 13, 2015 at 5:41 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

The same groups working on HTTPS proposals are also working on CSP to
prevent XSS. It's not either/or.

There's no way to prevent XSS other than disabling javascript altogether. But I assume the same group's also gonna fix any unpatched servers and bad/rooted webserver deployments, and monkey patch after every bad web programmer?

Stop breaking the web, stop breaking youtube, stop breaking vimeo, stop breaking virtually all WebGL content, stop breaking nytimes.com, fix your UX.

[Jeffrey Yasskin]

We'd need a more concrete UX than "designing the fullscreen effect
more visibly", and nobody's come up with a way to make it more
persistently visible that doesn't break other use cases. e.g. keeping
it visible after an initial period actually breaks the video and
gaming use cases.

(Youtube and vimeo are fine: they're both HTTPS.)

[Florian Bösch]

On Wed, May 13, 2015 at 6:37 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

We'd need a more concrete UX than "designing the fullscreen effect
more visibly", and nobody's come up with a way to make it more
persistently visible that doesn't break other use cases. e.g. keeping
it visible after an initial period actually breaks the video and
gaming use cases.

Persistent visibility obviously is the anathema to fullscreen (duh). But you could have a more obvious effect that persists for some time and get rid of the confirmation/permission/pinning altogether, which has the pleasant side effect of also taking care of some other UX issues like:

- embeds permission pinning (re-allow on every embedding site)

- permission dialog creep

 

(Youtube and vimeo are fine: they're both HTTPS.)

Sites embedding youtube may not be HTTPS. You break fullscreen for non-HTTPs, you're gonna break youtube embeds (at least the fullscreen button's gonna disappear). Which will trigger people to switch back to the flash player, which doesn't have this issue (and I don't buy adobe would voluntarily kneecap their most important use-case).

On any account, here's something to think about. You want people to build apps for the web platform? Stop kneecapping people trying to do so.

[Brandon Jones]

On Wed, May 13, 2015 at 9:38 AM Jeffrey Yasskin <jyas...@chromium.org> wrote:

(Youtube and vimeo are fine: they're both HTTPS.)

I hate to beat a skeletal horse, but this is really one of my bigger concerns: Youtube and vimeo are fine because they're huge and financially stable and have the infrastructure necessary to not worry about things like HTTPS traffic overhead or certificate cost. The issues with this change have never really been about them, or the New York Times, or other well established players. It's about the out-of-a-garage hacker that now has one more paywall to go through before they are allowed to "play with the big kids toys".

Beyond that, it's kind of frustrating that on one hand we are constantly talking about how to allow the web to better compete with native apps. One of the most frequently cited reasons why developers choose native over web is better access to hardware or OS features, and that's something that the Chrome team has collectively been working hard to address. It feels counterproductive to then restrict said features to only those developers that can afford to enable HTTPS, especially when there's no similar requirement on the native side (and native apps can be far, far scarier). It's just one more excuse for developers to lean towards native and neglect the web.

As I've said before I'm very much in favor of better security everywhere, but I also know that won't happen till it's effectively free, anonymous, and dead simple to deploy. (https://letsencrypt.org/ looks promising, but It's not here yet.) I feel our efforts would be better spent working towards those goals than taking away pre-existing features that developers have already been using for years and using them as a carrot to push HTTPS adoption.

--Brandon

[Katelyn Gadd]

In general this is a major undercurrent to the required-https
discussions on both the blink and mozilla lists: the community seems
happy to discount concerns of the minority (people with bad
connections, people reliant on caches, people without access to &
control over private servers that can have https configured, etc) in
favor of 'solutions' that bias towards stuff the 90% (youtube, vimeo,
github, etc) can trivially implement. These solutions are arguably a
step forward in terms of security by reducing risk, but they don't
actually solve any of the security problems we're grappling with here,
they just obfuscate them behind a permeable layer of protection.

HTTPS (as intended here, at least) is not authentication or content
verification, it's merely crypto as a means to prevent MITM and
passive snooping. Preventing MITM is a way to help prevent malicious
code from crossing the wire and entering the browser, but it's hardly
a solution there. Anti-snooping is a noble goal for the internet as a
whole but has nothing to do with webapps, really.

The challenges implicit in deploying HTTPS have a likely consequence
of pushing minority internet users to host their content on
third-party-controlled HTTPS servers, which actually *increases* the
attack surface because now all you have to do is compromise their
content on the third-party server - something many (most? all?) free
hosting services already do in order to monetize or simply out of
sheer incompetence.

Ultimately, as someone with extensive experience both as a web user &
developer (and experience on native platforms), I admire the ethos
here - promoting HTTPS, protecting users - but I don't see these moves
as positive in any regard. It appears to be a step forward in security
but I can't convince myself that anything will actually improve,
especially given the real price that will have to be paid to cope with
retroactive removal of HTML5 APIs for HTTP content.

Mozilla's compromise of only gating *new* platform features on HTTPS
is less odious in that it doesn't regress the state of apps on the
web, but i'm still not happy about it.

-kg

On 13 May 2015 at 10:05, 'Brandon Jones' via blink-dev

[Torne (Richard Coles)]

Native apps have typically *stronger* verification than HTTPS: code signing and trusted distribution channels with explicit user install gestures.

[Florian Bösch]

So that's what you want to transform the web to? A walled garden can only deploy website with permission system?

[Florian Bösch]

Is that why you push for SSL so so hard, regardless of the cost, impracticality and breakage? Because you want a central identification token you can whitelist? So you can become the arbiter of who's allowed to use "new features"? Is that the endgame of this whole push?

[Chris Palmer]

Everybody, let's all take a deep breath. Take another deep breath. Let's all calm our minds.

OK, now that we're calm, let's recall some core facts.

* On the web, we prioritize the needs of the various constituencies: """In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.""" http://www.w3.org/TR/html-design-principles/ So, the needs of the people who use the web sites/apps we develop should come first. Basic safety is among those needs. The convenience of site operators is certainly important, but secondary.

* HTTPS is computationally cheap. https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html """If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more.""" And that was written in 2010.

* If you want to run your web app on a custom domain, you already have to buy a domain name. That is a bit of a hurdle, but it is very low. And you need to remember to renew it, and configure DNS, and so on. Demonstrably, people are capable of this.

* If you want to run your web app over HTTPS, you do need to get a certificate signed by a known CA. That is a bit of a hurdle, but it is pretty low. And you need to remember to renew it, and configure your web server, and so on. Demonstrably, people are capable of this. (In some cases, DNS registrars are also CAs, e.g. https://www.gandi.net/ssl. That can make things easier.)

* Let's Encrypt will be nice. In the mean time, there are other easier-to-use and more-affordable certificate services, such as https://sslmate.com/ and https://certsimple.com/.

* Certificates, like DNS domains, cost a certain amount of money. I suspect that for most sites, the costs are dwarfed by the costs of developer time, developer equipment (laptops and workstations), server hardware, and bandwidth.

* HTTPS provides 3 basic safety features: web server authentication; data integrity; and data confidentiality. Just about any non-trivial web application should provide its users — and its operators! — at least 2 and probably all 3 of those features. (In fact, some need more than that.) Examples include: having some reason to believe the reader sees what the publisher intended to publish; not having the user interface destroyed by meddling intermediaries; monetizing the *right* ads for the *right* publisher; protecting payment instruments for paid content sites/retail sites; confidentiality of sensitive personal information like email, medical information, et c. et c.; some bare minimum notion of reader privacy. There are many more examples like this that demonstrate that when a site provides users basic safety, it also serves the site operator's interests.

* It is not computationally feasible/is an AI-hard problem to programmatically distinguish toy-app.com from doctor.com, or personal-blog.com from stock-trading.com. Therefore, user agents generally must (and should) assume the user's security requirements are higher than they may be.

* Many JavaScript APIs/web platform features give the JavaScript author increased control over the user's computer, and/or increased access to sensors in the user's computer. Thus, the user must trust the site operator more. The site operator should do the bare minimum to earn that trust. HTTPS is that bare minimum. (Usually, we would like to see much more than the bare minimum. But increased safety guarantees build on the HTTPS baseline.)

* The norm for mobile apps is that code is authenticated. HTTPS's web server authentication feature is the rough analogue of that for the web. Code signing is good for code authors and for users.

I hope that everyone can agree that the above bullet points are all plain statements of fact. If not, it is likely that we simply don't share enough ontology to even discuss the matter further.

I hope that from these plain facts, a reasonable person will conclude that HTTPS is, and should be, the norm for a powerful, useful, and (at least minimally) safe web. Surely, for new and powerful web platform capabilities, it is a reasonable requirement; for pre-existing powerful platform capabilities, we should consider requiring HTTPS for them (that is, we should have been requiring HTTPS all along).

Now, if people want to haggle over Full Screen in particular, sure — reasonable people may disagree on that. Perhaps we can come to some other solution for that particular capability. But keep in mind that, in general, computing platforms do not reliably offer a secure attention sequence (http://en.wikipedia.org/wiki/Secure_attention_key). This makes features like Full Screen and Pointer Lock somewhat risky. Now consider the fact that the web is sort of a platform-within-a-platform: this compounds the secure attention problem further. ("Sure, I'm at the true Windows login screen; but how can I be guaranteed to see the true web browser chrome?")

Finally, I hope we can all agree that the web's relative lack of centralization — its loosely-coupled nature — is a huge strength that we all want to preserve. At the same time, I hope we can all recognize that loose coupling creates certain engineering difficulties and imposes certain engineering trade-offs. I hope we can agree that it is generally better for site operators to take on some costs rather than externalize the costs to the (hopefully) many, many people using the site. After all, site operators have highly-technical people, some modicum of money, and the incentives to provide a good service.