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

A function to query the capabilities obtainable after entering fullscreen
would also work from an application developers point of view:

navigator.fullscreenCapability.keyboard -> true/false
navigator.fullscreenCapability.mouse -> true/false
navigator.fullscreenCapability.ui -> true/false
navigator.fullscreenCapability.pointerlock -> true/false
navigator.fullscreenCapability.keyboardlock -> true/false
navigator.fullscreenCapability.gamepads -> true/false
navigator.fullscreenCapability.touch -> true/false
navigator.fullscreenCapability.penTablet -> true/false
etc.

So app developers will know not to show a fullscreen button when they know
that a user pressing that button would break their app.

On Tue, Oct 16, 2012 at 12:39 AM, Maciej Stachowiak <mjs@apple.com> 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. 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.
>
> Regards,
> Maciej
>
> On Oct 15, 2012, at 3:45 AM, Florian Bösch <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> wrote:
>
>>
>> On Oct 14, 2012, at 3:54 PM, Chris Pearce <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
>>
>>
>
>