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

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
>>>
>>
>