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

Re: Presentation API in non secure contexts

From: Thomas Love <tomlove@gmail.com>
Date: Mon, 23 Jan 2017 21:44:49 +0200
Message-ID: <CAJCGDi9Kjhuz3T_q4CPO_g1bE-OKpeDETTScLcYniiGh31sAfQ@mail.gmail.com>
To: Richard Barnes <rbarnes@mozilla.com>
Cc: Francois Daoust <fd@w3.org>, WebAppSec WG <public-webappsec@w3.org>, public-web-security@w3.org, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "mark a. foltz" <mfoltz@google.com>
Is there an affirmative reason this API *needs* to exist?



On 23 January 2017 at 21:30, Richard Barnes <rbarnes@mozilla.com> wrote:

> 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#issuecomm
>>> ent-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 Friday, 27 January 2017 08:26:48 UTC

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