W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2015

Request for review of the Presentation API from a security perspective

From: Francois Daoust <fd@w3.org>
Date: Mon, 23 Nov 2015 18:22:06 +0100
To: <public-webappsec@w3.org>
Cc: "Mike West" <mkwst@google.com>, "'Kostiainen, Anssi'" <anssi.kostiainen@intel.com>, "mark a. foltz" <mfoltz@google.com>
Message-ID: <01d501d12613$7adc3120$70949360$@w3.org>
Hello WebAppSec WG,

The Second Screen Working Group is working on the Presentation API specification, which enables web content to access external presentation-type displays and use them for presenting web content:

  http://www.w3.org/TR/presentation-api/

The group would like to draw the attention of this group to this working draft and request a security review of the spec. This request was initially sent to the Web Security IG but Mike West suggested we rather got in touch with you.

The group evaluated the spec against the "Self-review questionnaire". See evaluation in:
  https://github.com/w3c/presentation-api/issues/45#issuecomment-100955052

The group has discussed this topic since the evaluation was made and had a lunch discussion with Mike in Sapporo, in particular, mainly around five axes:

1. Potential issues about the API being inherently cross-origin. There was a feeling that this was acceptable, since there is no way to push information to the other side if it does not want to consume it.
2. The need to require a secure context in all cases. The feeling here was that the overall risk is relatively low: there is permission involved, the API can do little harm to users. The fingerprinting issue related to the possibility to check whether a second screen is available could be mitigated by preventing it on non-secure contexts.
3. Mixed content rules for the API: here the group plans to add a requirement to the spec to prevent an existing receiving presentation running in a secure context from receiving input from a controller running in a non secure context.
4. The behavior of nested frames (i.e. when a nested frame wants to present content as typically needed when one embeds a media player). Mike mentioned an early proposal to delegate permissions to the nested context. In our case, there is no long-term permission and the group is actually considering not requesting any additional iframe attribute à la "allowfullscreen" for a nested frame to be able to call the API.
5. Security requirements for the messaging channel between secure origins. This touches upon the protocols used under the hoods, which are out of scope of the Second Screen Working Group.

See the summary of this discussion in [1].

Please let us know if you have further comments on these issues, or if you think there are other issues related to the API.

Thanks,
Francois Daoust, Staff Contact
Second Screen Presentation Working Group

[1] http://www.w3.org/2015/10/29-webscreens-minutes.html#item06
Received on Monday, 23 November 2015 17:22:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:16 UTC