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

Re: Presentation API in non secure contexts

From: Richard Barnes <rbarnes@mozilla.com>
Date: Mon, 23 Jan 2017 14:48:12 -0500
Message-ID: <CAOAcki9CyiUfff5eKRRnHt2-jj1OBWWj1S8RdX8-vFtcLQmNfA@mail.gmail.com>
To: Thomas Love <tomlove@gmail.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>
I would hope so, otherwise why is anyone spending time on it?

On Mon, Jan 23, 2017 at 2:44 PM, Thomas Love <tomlove@gmail.com> wrote:

> 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 Monday, 23 January 2017 19:48:45 UTC

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