- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 24 Nov 2015 08:57:24 -0800
- To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- Cc: François Daoust <fd@w3.org>, WebAppSec WG <public-webappsec@w3.org>, Mike West <mkwst@google.com>, "mark a. foltz" <mfoltz@google.com>
Thanks Anssi, I'm glad to see that I'm not the only one, and I look forward to seeing some progress on the CG work. I don't believe that it is appropriate to call the Presentation API complete until its prerequisites are stable. I can imagine some ways in which the protocol work could be completed without changing the API, but most of those require some ugly trade-offs. I'd encourage you to give the protocol work priority. I've learned that if you don't, it's easy to get an non-interoperating mess [1]. And you want to learn about API changes as early as possible. --Martin [1] Based on what I've seen, that point might have been reached already. But I'm always willing to be optimistic when starting new work. On 24 November 2015 at 05:06, Kostiainen, Anssi <anssi.kostiainen@intel.com> wrote: > [ +bcc public-secondscreen ] > > Hi Martin, > > Thanks for your comments. The Second Screen Working Group [1] received similar feedback during the TAG review of the spec. To address TAG's as well as your concern, discussions were started to recharter the Second Screen *Community* Group [2] with the following goals (from the work-in-progress CG charter [3]): > > [[ > > Specifically, the CG provides a venue for discussing and incubating early proposals that aim to: > > * define a base set of protocols that Presentation API implementers can refer to to implement the spec; > * improve interoperability between implementations, i.e. the possibility to associate a presentation controller with a presentation receiver even if they have not been implemented by the same user agent. > > ]] > > Mozilla has provided valuable input to these discussions. > > Thanks, > > -Anssi (Second Screen WG and CG chair) > > [1] http://www.w3.org/2014/secondscreen/ > [2] https://www.w3.org/community/webscreens/ > [3] https://webscreens.github.io/cg-charter/ > > >> On 23 Nov 2015, at 20:45, Martin Thomson <martin.thomson@gmail.com> wrote: >> >> 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 Tuesday, 24 November 2015 16:57:53 UTC