Re: Presentation API in non secure contexts

To clarify the distinction I'm drawing here: The discussion below argues
that exposing this API to non-secure contexts would not create major risk.
At this point in the web, that's not sufficient.  I'm looking for an
affirmative reason that this API *needs* to be exposed to non-secure
contexts.


On Mon, Jan 23, 2017 at 12:06 PM, Richard Barnes <rbarnes@mozilla.com>
wrote:

> What is the rationale for why this API needs to be available to non-secure
> contexts?
>
> On Mon, Jan 23, 2017 at 12:00 PM, Francois Daoust <fd@w3.org> wrote:
>
>> Dear Web App Security WG,
>> [and Hello Web Security IG]
>>
>> The Presentation API allows an application to request display of web
>> content onto a second screen. While the Presentation API forbids mixed
>> content, it does not require a secure context. We discussed this point with
>> some of you back at TPAC 2015 in Sapporo, and raised it in our request for
>> review shortly afterwards:
>> https://lists.w3.org/Archives/Public/public-webappsec/2015Nov/0064.html
>>
>> The feeling was that the overall risk is relatively low: there is
>> permission involved and the API can do little harm to users.
>>
>> The Second Screen WG would like to confirm with you that this approach is
>> still acceptable. The group received feedback that the spec should require
>> secure contexts, especially because it prompts the user for permission. See
>> discussion starting at:
>> https://github.com/w3c/presentation-api/issues/362#issuecomment-262102686
>>
>> The security guidelines in the Presentation API were updated to highlight
>> the need to warn users about origins that are potentially non trustworthy:
>> https://w3c.github.io/presentation-api/#user-interface-guidelines
>> ... and in particular:
>> [[ Showing the origin that will be presented will help the user know if
>> that content is from an potentially trustworthy origin (e.g., https:), and
>> corresponds to a known or expected site. The user agent should specifically
>> indicate when the origin requesting presentation is not potentially
>> trustworthy. ]]
>>
>> As a side note, the Second Screen WG will soon re-publish another
>> Candidate Recommendation of the Presentation API. On the security front,
>> the only changes were to move the mixed content and sandboxing checks to
>> the `PresentationRequest` constructor instead of to individual methods of
>> the `PresentationRequest` object, to "fail early". We do not believe that
>> this should trigger another security review, but feedback is of course
>> always welcome!
>>
>> Thanks,
>> Francois,
>> Staff Contact, Second Screen WG.
>>
>>
>>
>

Received on Monday, 23 January 2017 19:30:53 UTC