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