RE: Defenses against phishing via the fullscreen api (was Re: full screen api)

Requiring that the user approve before a full screen UI is active to prevent mimicking a bank site in a browser isn't dictating what the UI looks like.

And it can be detectable to the web page - it can be the full screen notification doesn't happen until after the user has approved it.

There are different approaches today, but none of them prevent the user from interacting with the full screen app before they've approved it going full screen.

>-----Original Message-----
>From: Jonas Sicking [mailto:jonas@sicking.cc]
>Sent: Wednesday, October 17, 2012 1:44 AM
>To: Carr, Wayne
>Cc: Vincent Scheib; Maciej Stachowiak; public-webapps@w3.org; Chris Pearce;
>Florian Bösch; Anne van Kesteren
>Subject: Re: Defenses against phishing via the fullscreen api (was Re: full screen
>api)
>
>On Tue, Oct 16, 2012 at 4:48 PM, Carr, Wayne <wayne.carr@intel.com> wrote:
>>> Chrome supports Fullscreen with keyboard enabled. We use a
>>> notification that persists until a user notices and dismisses it. We
>>> may modify it in the future to make this more noticeable, e.g.
>>> dimming page contents similar to FireFox.
>>
>> It would be safer if this was not only dimmed, but was modal, so the
>> user could not interact with the rest of the full screen contents of
>> that page until they responded to the notification.  Then they
>> couldn’t accidentally interact with a full screen app masquerading as a browser.
>>
>> (Either that or don’t go full screen until the user responded to the
>> notification.)
>
>We have generally always left UI up to implementations. For several reasons:
>
>* If it's not detectable by the webpage, then it doesn't really matter from a web
>compat point of view, so no need to specify.
>* Leaving UI up to implementations means that implementations can experiment
>and improve over time.
>* Generally implementations have been reluctant to allow specifications to
>dictate UI. And since test suites can't test it anyway, they could simply ignore the
>spec and still pass test suites.
>* Many times when trying to specify UI, such as when HTTP required UI for POST,
>the result has been really bad.
>
>There were some efforts in a separate WG around trying to standardize security
>related UI in order to provide more reliable and secure UI.
>IIRC this was mostly around the secure-connection UIs (a.k.a. "the lock icon") in
>the URL bar.
>
>Of course, things like "are keys enabled while in fullscreen mode" is very
>noticeable to the page, so it makes sense to put in the spec. And of course we
>always need to ensure that the spec is implementable in a safe way using *some*
>UI strategy. But whether dimming should be done, when exactly to switch to
>fullscreen mode, and how fullscreen notifications work I think fall under "leave it
>up to implementations"
>rule.
>
>The fact that we have so many different strategies for how to handle the
>fullscreen UI in current implementations I think is a testament to that the current
>strategy works. Implementations are *very* concerned about security, you can
>bet that they will do their utmost to protect users and adjust UI as needed in
>order to do so. Thinking that we can do better and putting requirements in the
>spec will just have the opposite effect since it means that implementations can't
>do better than whatever we come up with.
>
>/ Jonas

Received on Wednesday, 17 October 2012 17:11:08 UTC