- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 19 Dec 2012 23:08:08 -0800
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Chris Pearce <cpearce@mozilla.com>, Florian Bösch <pyalot@gmail.com>, Wayne Carr <wayne.carr@intel.com>, public-webapps WG <public-webapps@w3.org>, Feross Aboukhadijeh <feross@feross.org>, Jonas Sicking <jonas@sicking.cc>
On Dec 18, 2012, at 6:44 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak <mjs@apple.com> wrote: >> Based on all this, I continue to think that requesting keyboard access >> should involve separate API, so that it can be feature-detected and given >> different security treatment by vendors as desired. This is what Flash does, >> and they have the most experience dealing with the security implications of >> fullscreen on the Web. > > Gecko and Chrome have indicated they do not desire this distinction. > You have indicated your desire to maybe enable keyboard access in the > future, but you do not have a thought out UI. Given this is the data > we are working with it seems unwise to change direction at this point. > > The specification is modeled after Gecko and Chrome and very much > intents to have keyboard access working. As per usual, everything that > is not restricted is expected to work. That seems like a bad basis to make a decision about a security issue. > > I am willing to add some wording to the security section to make the > risks of keyboard access more clear. Does anyone have some suggested > wording? What would be the point? Web developers can't protect themselves from phishing attacks by other sites, and as you state the spec currently does not allow UAs to limit keyboard access. So who is the audience for such as security considerations warning? End users? At minimum, I'd like the spec to explicitly allow not providing full keyboard access, as requested in my original message on this thread: >> 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. As you point out, the spec does not currently allow this behavior. Are you rejecting this request? If so, why? Safari has had this behavior since forever and is unlikely to change in the foreseeable future, so it seems pointless to disallow it. And given this difference in UA behavior, it seems useful to let web developers feature-detect the difference in behavior somehow. Regards, Maciej
Received on Thursday, 20 December 2012 07:08:38 UTC