- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 20 Dec 2012 12:35:12 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- 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 Thu, Dec 20, 2012 at 8:08 AM, Maciej Stachowiak <mjs@apple.com> wrote: > On Dec 18, 2012, at 6:44 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >> 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'm not sure I follow. How specifications are written has no influence on how decisions regarding them are made. >> 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? I think the specification should state that certain keys should be protected, such as the key used by the user agent to fully exit fullscreen. > 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. Allowing Safari's behavior is bad for a large number of use cases, such as games and presentations that need to respond to key input. > And given this difference in UA behavior, it seems useful to let web developers feature-detect the difference in behavior somehow. Does Safari implement the standardized API already? http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Document.idl suggests it is still prefixed. -- http://annevankesteren.nl/
Received on Thursday, 20 December 2012 11:35:39 UTC