> > 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.
Another option (for low-res videos on desktop) might be to use lower screen resolution when in full screen — text and UI elements displayed by attacker will look noticeably different. -- regards, Kornel
