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

On Fri, Oct 19, 2012 at 9:08 AM, Feross Aboukhadijeh <feross@feross.org>wrote:

> "Apple has also indicated of not liking confirm prompts of any kind
> whatsoever"
>
> To reiterate: for 90% (probably more) of fullscreen use cases, there would
> be no confirmation prompt at all. Only when the developer specifically
> requests keyboard access would there need to be a prompt. Thus, developers
> of video website and video slideshow tools can avoid requesting keyboard
> access and need not get any prompt at all if Apple so chooses. A prompt
> should only be necessary for games or complex fullscreen web apps with lots
> of shortcuts. Since the user only needs to confirm this one time (the
> browser can remember their choice), this burden seems minimal. The cost of
> restricting all keyboard input for convenience or for an idealogical
> aversion to dialogs is very high. We'd basically making the open web
> useless for fullscreen games. What's the point of the pointerlock
> specification then?
>
If you cannot convince Apple to go along with the "prompt when full input
required" it doesn't matter.


> Also, we're defining a spec for the open web here, right? I don't think
> that worrying about what one vendor may or may not implement is useful. The
> spec should reflect what we want the open web platform to look like. A
> fullscreen mode that is secure against phishing yet supports keyboard input
> for games and other complex web apps is pretty important for the web. Can
> we make the spec reflect this?
>
The reason why one vendor matters in this is:

#1
$('<button>Fullscreen</button>').appendTo('#mycontainer').click(function(){
requestFullScreenWithInputs(); }
  a) Unknown if that button mutates to a "break my app button"
  b) In presence of possibility of a button becoming a "break my app
button" we cannot offer that button
  c) That button would have to be hidden behind an educational dialog for
the user that it is possible that after pressing the button nothing works,
and that it's not our fault.


#2 if(!$.browser.safari){ ... } or if($.browser.chrome || $.browser.firefox
|| etc.){ ... }
  a) If a vendor changes his mind against input, a button may mutate to a
"break my app" button
  b) If a vendor changes his mind for input, users won't get the feature
  c) Ties fullscreen buttons to a flawed assumption, will likely lead to
broken fullscreen apps for decades after a vendor changed his mind.

That is why it is important that we can figure that out beforehand. Since I
see zero chance to lock all vendors into one set of restrictions and UX.
And since that is so, again I re-iterate the method from a developers
perspective should be:

Step #1: Query the availability of a *capability* (not just keyboard
because vendors might not support other inputs as well)
Step #2: Decide if you can offer a fullscreen button with the capabilities
you just queried, if yes, place a fullscreen button in your app
Step #3: Upon the user pressing that button, request fullscreen with the
capability you know you can get

Again I re-iterate, keyboard is not the only concern here. You have to
consider other inputs as well since vendors might choose to restrict those
as well.
Again I re-iterate, the standard is unlikely to lock one vendor into one
set of restrictions/UX
Again I re-iterate, since that is so we need a solution that will hold up
to a shifting restrictions landscape and allow app developers to
confidently use that feature without fear if it will break their app.
Again I re-iterate, we cannot have a "break my app button" in our apps.