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

Re: [presentation-api] Authenticity of screen selection permission is problematic in insecure contexts

From: Anssi Kostiainen via GitHub <sysbot+gh@w3.org>
Date: Wed, 25 Jan 2017 09:46:49 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-275063423-1485337608-sysbot+gh@w3.org>
[Piggy-packing on this existing issue that provides the most recent 
context.]

In preparation for the Presentation API CR refresh #406, we explicitly
 asked the WebAppSec WG folks for feedback whether they see it as an 
issue that the Presentation API is not gated behind [SecureContext], 
see 
https://lists.w3.org/Archives/Public/public-webappsec/2017Jan/0031.html.
 In that thread (still developing) the general recommendation is that 
indeed new features should be exposed into secure context only.

Earlier, as part of the privacy and security review of the 
Presentation API documented in #45, we solicited feedback from the Web
 Security IG, PING, and Mike West (lunch at TPAC 2015), and at that 
time, [SecureContext] was not seen as a must requirement.

It appears new information has surfaced and the web security 
community's thinking has evolved since then, and we should consider 
re-evaluating that decision. We must understanding that might delay 
our CR refresh plans.

Comments, concerns? What are the key use cases that motivate the use 
in insecure contexts?

If we decide to require [SecureContext], there's reusable prose and 
guidance for editors at 
https://w3c.github.io/webappsec-secure-contexts/#new. Also major 
implementations seem to provide `isSecureContext()` or similar method 
that implements the checks defined in the Secure Contexts spec, so the
 required implementation effort would be reasonable.

-- 
GitHub Notification of comment by anssiko
Please view or discuss this issue at 
https://github.com/w3c/presentation-api/issues/380#issuecomment-275063423
 using your GitHub account
Received on Wednesday, 25 January 2017 09:46:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:19:02 UTC