W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

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

From: Florian Bösch <pyalot@gmail.com>
Date: Tue, 16 Oct 2012 00:50:01 +0200
Message-ID: <CAOK8ODj20vM0WA4Q8iHnsZ5Y+31Mm5Qt231bJ62YUK_WtpLDXQ@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Chris Pearce <cpearce@mozilla.com>, Anne van Kesteren <annevk@annevk.nl>, "Carr, Wayne" <wayne.carr@intel.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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

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
Received on Monday, 15 October 2012 22:50:28 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:49 UTC