- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Thu, 7 Oct 2010 11:03:18 +0300
- To: ext Rich Tibbett <rich.tibbett@gmail.com>
- Cc: "public-device-apis@w3.org WG" <public-device-apis@w3.org>, Rich Tibbett <richt@opera.com>, "Oksanen Ilkka (Nokia-MS/Espoo)" <Ilkka.Oksanen@nokia.com>, "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>
Hi, On 6.10.2010, at 21.32, ext Rich Tibbett wrote: > On Wed, Oct 6, 2010 at 7:38 PM, Anssi Kostiainen <anssi.kostiainen@nokia.com> wrote: > Hi, > > On 4.10.2010, at 13.57, ext Rich Tibbett wrote: > > > I have added a section to the Contacts API spec entitled 'API Invocation > > via DOM Events' + an example of its usage. It is included informatively > > and might be worth a read: > > > > http://dev.w3.org/2009/dap/contacts/Overview.html#api-invocation-via-dom-events > > Thanks. A concrete proposal is a good way to start mulling this one. Before going full steam ahead with the approach I'd like to make sure we won't increase the attack surface too much. > > Rather than taking clickjacking as the jumping off point perhaps focusing on preventing/managing 'synthesized click events' is the way to go here. > > I'd like to solve the more general problem of clickjacking but short of rewiring the whole web platform I worry it's not going to lead to any actionable outcomes for the DAP WG. It's a serious issue but probably not one suited for tackling in this group. I may, of course, stand corrected on this. Primarily I'm the most concerned about the potentially increased attack surface DAP may introduce, and secondarily about solving the general problem spanning across the web platform. Regardless, IMHO we should understand these exploits in more detail in order to be able to do informed design decisions. I'd also like to understand the role of synthesized clicks better. > Instead, I believe the answer lies in enforcing the DOM Level 3 Events specification behaviour around "user-initiated activation triggers" and "trusted" events: > > http://www.w3.org/TR/DOM-Level-3-Events/#trusted-events > > I certainly see a few areas on these topics that we could address in our own spec...but more on that later when I have a proposal. I'm happy to review the proposal. Clickjacking attacks use iframes to hijack user's session. How about simply preventing API invocation via DOM events within an iframe? Would that be too drastic a measure? If we allow that, the UI, including the contact picker (because the infobar is then omitted), should make it very obvious that the origin is different from that of the top-level browsing context origin, as per: http://www.w3.org/2009/dap/wiki/ApiCheckList This is quite similar to the Geolocation case, discussed in Google's privacy WS paper: http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-24.pdf More pondering on the UI and security and privacy considerations: Currently the Contacts S&P says "The user interface must include the document base URL" whereas the Geolocation says "the document origin". I see that the document base URL (http://example.org/foobar/#baz) typically contains more information than the origin (http://example.org) and in theory allows a more informed decision to be made. However, I'm not sure how well users actually understand the difference and if the lengthier document base URL actually obscures the (more important?) origin part. The document base URL can also change during the lifetime of the Document (fragment identifier, pushState()) which may make it less useful compared to origin. [By looking at the Chrome's address bar, the origin is highlighted while the rest is dimmed. Perhaps there has been some studies behind this design decision. I'm not sure how (if at all) this kind of implementation details should be reflected in the spec, although at the same time I can see them being extremely useful advice to implementers of user agents.] -Anssi
Received on Thursday, 7 October 2010 08:04:28 UTC