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

On 16/10/12 11:39, Maciej Stachowiak wrote:
>
> That's why I liked having a separate API to request fullscreen with 
> full alphanumeric keyboard access. This allows apps to determine if 
> fullscreen with keyboard is available on a given browser, and allows 
> browsers to set separate security policies for that case.

Would you implement keyboard access in fullscreen via this API if we 
spec'd it? Or are you looking for a way to for authors to determine if 
key input isn't supported in fullscreen mode?


> I think the spec should change back to having two distinct APIs, even 
> though Mozilla is not interested in making a distinction between the 
> two cases.

I'd say fullscreen video is the only fullscreen use case where page 
script shouldn't need key events dispatched to it. I'm sure some other 
fullscreen uses wouldn't want key events, but most non-trivial users of 
fullscreen would want keyboard shortcuts or input.

Anyway, I'm curious what the Chrome guys think.

Chrome's requestFullscreen implementation takes a parameter/flag 
Element.ALLOW_KEYBOARD_INPUT to denote whether key input should be 
allowed. I thought they ignored that and just always allowed key input 
fullscreen, but I see now that they do honour it.


Regards,
Chris P.



>
> Regards,
> Maciej
>
> On Oct 15, 2012, at 3:45 AM, Florian Bösch <pyalot@gmail.com 
> <mailto:pyalot@gmail.com>> wrote:
>
>> Ok, so here's my question. You have a webapp (that oh, happens to be 
>> a game, or a slideshow app, or a video player with controls, etc.) 
>> which needs keyboard/UI events access to work (come to think of it, 
>> can you honestly think of any sort of usecase that does work entirely 
>> without user intercation?). Anyways, so now this app needs to figure 
>> out if it's worth the bother to even display a fullscreen 
>> icon/request fullscren (see, after all, there woulnd't be a point if 
>> there's no keyboard/UI access).
>>
>> So how does an app do that? How do we figure out what the random 
>> behavior changes are that vendors add, that would break our app, that 
>> make it pointless to try to use the API on that vendors browser? Anyone?
>>
>> On Mon, Oct 15, 2012 at 12:32 PM, Maciej Stachowiak <mjs@apple.com 
>> <mailto:mjs@apple.com>> wrote:
>>
>>
>>     On Oct 14, 2012, at 3:54 PM, Chris Pearce <cpearce@mozilla.com
>>     <mailto:cpearce@mozilla.com>> wrote:
>>
>>     > On 14/10/12 00:49, Maciej Stachowiak wrote:
>>     >>
>>     >> Despite both of these defenses having drawbacks, I think it is
>>     wise for implementations to implement at least one of them. I
>>     think the spec should explicitly permit implementations to apply
>>     either or both of these limitations, and should discuss their
>>     pros and cons in the Security Considerations section.
>>     >
>>     >
>>     > I don't support making these mandatory, but they should
>>     certainly be added to the Security Considerations section; we
>>     considered them, and we may indeed re-consider them in future if
>>     it proves necessary.
>>     >
>>     > I support making the spec general enough that implementors can
>>     chose their security features based on their requirements; what's
>>     appropriate for a desktop browser may not be appropriate for a
>>     tablet, for example.
>>
>>     I agree with both of these comments (in case it wasn't clear). I
>>     suggest that these mechanisms should be permitted, not mandatory.
>>     Right now it is not entirely clear if either is permitted per spec.
>>
>>     Regards,
>>     Maciej
>>
>>
>