Re: CfC: Transition "Secure Contexts" to CR; deadline August 2nd.

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?

-mike

On Wed, Jul 20, 2016 at 11:18 PM, Brad Hill <hillbrad@gmail.com> wrote:

> <hat="individual"> I support this very much.
>
> On Tue, Jul 19, 2016 at 6:22 AM Mike West <mkwst@google.com> wrote:
>
>> Hello, WebAppSec and TAG,
>>
>> This is a call for consensus to transition Secure Contexts to Candidate
>> Recommendation with the document at:
>>
>> https://w3c.github.io/webappsec-secure-contexts/CR.html
>>
>> 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.
>>
>> Thanks!
>>
>> -mike
>>
>