Hello, WebAppSec and TAG,
This is a call for consensus to transition Secure Contexts to Candidate Recommendation with the document at:
Since the last time we formally discussed this spec, we've cleaned up examples and algorithms based on some very helpful feedback from folks at Mozilla working on their implementation (thanks Boris and Jonathan!), as well as interested folks from the TAG and elsewhere (thanks to Anne and Domenic in particular).
The core of the specification is already used in a number of specifications to gate certain features (like Service Workers) to contexts which offer guarantees about their usage, and browser vendors seem interested in implementing.
One substantive change since the last time around is the sandbox behavior in https://w3c.github.io/webappsec-secure-contexts/CR.html#monkey-patching-sandbox-flags, which now defaults to forcing a sandboxed frame into "non-secure context" status, and requires a new 'allow-secure-context' token to allow the context to be treated as secure. It's not clear whether we can ship that change; it's marked as "at risk" pending gathering some metrics.
Note also that this document references WHATWG documents in a few places where the W3C version is out of date. I'm sure we'll have some exciting conversations about those references: https://w3c.github.io/webappsec-secure-contexts/CR.html#index-defined-elsewhere contains a complete list.
The deadline for this CfC is in two weeks, on August 2nd. Feedback, both positive and negative is welcome, either directly to the list, or via some sort of clever emoji response to https://github.com/w3c/webappsec-secure-contexts/issues/39.
<hat="individual"> I support this very much.
On Tue, Jul 19, 2016 at 6:22 AM Mike West <[hidden email]> wrote:
Based on some discussion on GitHub, I've added two new "at risk" demarcations to the Secure Contexts spec:
* In https://github.com/w3c/webappsec-secure-contexts/issues/42, Jake has expressed some discomfort with the `opener` restriction on popups (that is, popups created from a non-secure context remain non-secure, even if delivered securely): recorded in the spec as https://w3c.github.io/webappsec-secure-contexts/#issue-8ea95bab. I suspect that we'll be able to address Jake's concerns via changes to specs other than this one, but it's worth noting that there's not complete harmony on the topic (nor, honestly, do we have pervasive implementation of that restriction).
* In https://github.com/w3c/webappsec-secure-contexts/issues/43, Erik suggested that the move to exclude `localhost` was the wrong way to solve the problem, and that we should instead treat it as "secure" if it resolves to a loopback address. Recorded in the spec as https://w3c.github.io/webappsec-secure-contexts/#issue-8ea95bab. Without some change in the way that agent's DNS resolvers handle these names, I'm reluctant to change the spec, but perhaps pushing for that change is a reasonable thing to do.
The regenerated document is up at https://w3c.github.io/webappsec-secure-contexts/ for review.
These feel like small, detail questions that we can resolve during CR with the additional implementation experience it will bring. From my perspective, proceeding to CR makes sense.
What do y'all think?
On Wed, Jul 20, 2016 at 11:18 PM, Brad Hill <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|