- From: Richard Barnes <rbarnes@mozilla.com>
- Date: Mon, 23 Jan 2017 14:48:12 -0500
- 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>
- Message-ID: <CAOAcki9CyiUfff5eKRRnHt2-jj1OBWWj1S8RdX8-vFtcLQmNfA@mail.gmail.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