- From: Florian Bösch <pyalot@gmail.com>
- Date: Tue, 9 Oct 2012 12:09:34 +0200
- To: Charles McCathie Nevile <chaals@yandex-team.ru>
- Cc: bugzilla@jessica.w3.org, public-webapps@w3.org
- Message-ID: <CAOK8ODh340Wo0hkLHp8CMqBQ0NVyqZb9Uye2d9BuGgX=DbtCtw@mail.gmail.com>
On Tue, Oct 9, 2012 at 11:41 AM, Charles McCathie Nevile < chaals@yandex-team.ru> wrote: > On Tue, 09 Oct 2012 08:43:13 +0200, Florian Bösch <pyalot@gmail.com> > wrote: > > Cheer up everyone, we've got somebody dedicated to writing fullscreen >> exploits now :) http://feross.org/html5-**fullscreen-api-<http://feross.org/html5-fullscreen-api-> >> >attack/ >> >> Summary: Change blindness may make phishing attacks feasible (displaying >> a mock browser/page in fullscreen) >> >> Cause: Switch to fullscreen before user consent. >> Fix: Switch to fullscreen after user consent. >> Questions: >> - Is this a problem? >> > > The blog shows why it is a problem? It matches a very well-known class of > problem. So I would say "Yes, there is a problem here". > > > - Does the proposed fix address the problem? >> > > The question of "what gets tp go fullscreen" matters. Getting user consent > to go fullscreen, but then making something else the actual thing that > takes the screen, may not solve the problem because it still enables the > attack to be developed. I think the reasoning to allow for elements to be fullscreened is pretty solid (video players, webgl overlays etc.). If an element cannot be made fullscreen (where such functionality is desired as in video players, containers containing UI and webgl, game portals embedding iframes etc.) it just leads to developers emptying the <body> and replacing the style/content with what they want in there, which ends up with the same result just in a much more inconvenient and slow fashion. You ultimately cannot prevent the page showing something else entirely upon entering fullscreen, but you can make it much more tedious for legitimate uses by removing the element fullscreen functionality. To that end, there wouldn't be a point not to do the element fullscreen capability. The reasoning to allow for javascript polled fullscreen is also pretty solid. The use-case for element fullscreen is evident and desired. Absent any means to target what element, a fullscreen menu/shortcut won't be able to do it right. Short of actually removing JS polled fullscreen you cannot address the issue on the basis of "whenever something goes fullscreen it can be something else". Yet, the case for fullscreen altogether is also pretty evident. This would come down to a choice between having fullscreen and not having fullscreen at all, which I think, is not a choice anybody would be happy with. The fix proposed works on the principle that the message to enter fullscreen disconnects the immediate display of the phish (the change blindness) from the actual action with the expected result (clicking link) by layering a dialog/indefinite delay until clicked between a link and a display, thereby removing the "blindness" almost entirely (you have to look at the screen to click a confirmation dialog, upon clicking the dialog, the screen will change a lot). I would propose making this confirmation fairly obstrusive/centered (like in firefox, chrome uses a very easily ignored dialog). Ultimately you have to accept that if you want fullscreen, and if you asked the user, and the user clicked yes, then this is all you can do. The only other choice is not to do fullscreen which would in my opinion exceed the remit of a reasonable security measure by far. > - What is the reasoning to switch before user consent? >> > > It allows developers to control more of the experience (which they > generally want). Given the price in security for the user, I would say the > end is not justified. > I don't understand how it gives more control over the experience.
Received on Tuesday, 9 October 2012 10:10:03 UTC