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

Proprietary dependencies (was Re: Request for review of the Presentation API from a security perspective)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 23 Nov 2015 10:45:04 -0800
Message-ID: <CABkgnnX87RRVM4fq5j6o0qt1t59V+EaKVq3fu0z=hN3dgh-CWw@mail.gmail.com>
To: François Daoust <fd@w3.org>
Cc: WebAppSec WG <public-webappsec@w3.org>, Mike West <mkwst@google.com>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "mark a. foltz" <mfoltz@google.com>
I don't see any mention of any network security aspects of this API.
That's worrying.  Not as much from a security perspective - I'm sure a
proprietary interface can be implemented to the necessary level of
security as much as an open one could.  However, I don't like that
this is being developed with a reliance on proprietary technology.

The fact that I won't be able to use Browser from vendor X to talk to
Screen from vendor Y makes this a technology that could do more harm
than good to the open web.

Is there any goal of addressing this problem?  It's not like there
aren't a good number of options available to us that are
well-standardized.  I am aware of the Mozilla implementation and that
seems to be relying on RTCPeerConnection for at least part of the
underlying technology.

On 23 November 2015 at 09:22, Francois Daoust <fd@w3.org> wrote:
> 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 18:45:32 UTC

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