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

Happy to do so, and working on the transition request now.  Is there an
updated CR draft I should point to; the one from the beginning of this
thread is still the July 19th copy?

On Tue, Aug 30, 2016 at 7:33 AM Mike West <mkwst@google.com> wrote:

> FWIW, Jake withdrew his objections (though I'd like to leave the "at risk"
> demarcation in case we find a way of tightening the restriction) in
> https://github.com/w3c/webappsec-secure-contexts/issues/42.
>
> I still feel like these questions are details that can be resolved during
> CR with implementation experience, and I'd suggest that the lack of
> objection on the list (along with positive TAG feedback, etc) is a
> reasonable indication of agreement.
>
> Chairs, would y'all be comfortable declaring consensus so that we can move
> ahead with a transition request to CR in time to argue about the
> dependencies at TPAC? :)
>
> -mike
>
> On Tue, Aug 2, 2016 at 8:51 PM, Mike West <mkwst@google.com> 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?
>>
>> -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
>>>>
>>>
>>
>