W3C home > Mailing lists > Public > public-web-security@w3.org > January 2017

Re: Presentation API in non secure contexts

From: Richard Barnes <rbarnes@mozilla.com>
Date: Mon, 23 Jan 2017 14:30:19 -0500
Message-ID: <CAOAcki_Rrvwu7oTpO7z=JwT+ss2_SVpZX+DVfOcg-32OM8DMRA@mail.gmail.com>
To: Francois Daoust <fd@w3.org>
Cc: WebAppSec WG <public-webappsec@w3.org>, public-web-security@w3.org, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "mark a. foltz" <mfoltz@google.com>
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

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

> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:41 UTC