[whatwg] HTML 5 : The Youtube response

[Maciej Stachowiak]

On Jun 30, 2010, at 6:47 PM, Shane Fagan wrote:

> 
>> #5 is a problem only if you care about phishing attacks...or indeed apps that have the gall to believe that you should be able to see nothing else when they are running.
>> 
> 
> We talked about this a week or two ago and the idea was to have a "allow
> full screen" element in the video tag that makes a control that can be
> used by the user to go full screen. The problem here is abuse but I
> think the browser vendors should make some safeguards if this is the
> route they take.

I don't think that is a useful design. First, it doesn't match the user experience that video hosting services want - they want a fullscreen control that matches their custom playback controls, and they want fullscreen mode to retain custom controls. This proposal fails on both counts. In WebKit, we have webkitEnterFullscren() and webkitExitFullscreen() which allow triggering fullscreen from custom controls, but which doesn't retain any custom controls once you go fullscreen. Even that, we are hearing, is not enough for content providers.

The security risks here are as follows:

1) Annoying the user by popping into fullscreen against their wishes.
2) OS simulacrum attacks, where the full-screen experience is used to simulate the whole OS, and then trick the user into typing in a password or other sensitive information.

I believe we can allow arbitrary content to go fullscreen, along the lines of what Robert O'Callahan has proposed on this list, if we impose sufficient restrictions to mitigate the above risks. In my opinion, the following measures would likely be sufficient:

A) Have a distinctive animated sequence when an element goes into full-screen mode. This helps the user understand what happened.
B) Limit the ability to go fullscreen to user gestures, much as many browsers limit pop-ups. This prevents shenanigans from happening while the user is away from the keyboard, and greatly limits the potential annoyance factor.
C) On systems with keyboard/mouse input, limit the keys that may be processed by fullscreen content to a small set, such as the set that Flash limits to in full-screen mode: <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5>.
D) On multitouch devices with an onscreen keyboard as the normal means of input, things are trickier, because it's possible for a dedicated attacker to simulate the keyboard. My best idea is make sure that a visually distinctive status indicator appears at the top of the screen even in full-screen mode, since that is the norm on such platforms.
E) Reserve one or more obvious key combinations to exiting fullscreen no matter what (Escape, perhaps Cmd+W/Ctrl+W).
F) Even on keyboard/mouse type systems, have some distinctive visual affordance which is either always present or appears on mouse moves, and which allows the user to exit full-screen mode.

I think these measures greatly mitigate risks (1) and (2) above, and open up highly valued functionality (full screen video) with a UI that users will enjoy, and customizability that video hosting sites will appreciate.

Note: I do not believe prompting the user, even if passively, is an effective security measure, and in particular I am not convinced it mitigates the risks that would be posed by full keyboard access.

Regards,
Maciej