W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 17 Oct 2012 01:43:38 -0700
Message-ID: <CA+c2ei_TL2FQn74EZ7XL8CgsdaECeYzgwzbS2LOpQSxDawg5-w@mail.gmail.com>
To: "Carr, Wayne" <wayne.carr@intel.com>
Cc: Vincent Scheib <scheib@google.com>, Maciej Stachowiak <mjs@apple.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Chris Pearce <cpearce@mozilla.com>, Florian Bösch <pyalot@gmail.com>, Anne van Kesteren <annevk@annevk.nl>
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 08:44:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:55 GMT