W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2016

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

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 30 Aug 2016 17:24:48 +0000
Message-ID: <CAEeYn8icJ1PiP2B9Fb2yFq__aKHfBw_0bT8J7Esyfq9ZqYoRKQ@mail.gmail.com>
To: Mike West <mkwst@google.com>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>, Jake Archibald <jakearchibald@google.com>, Erik Nygren <erik+w3@nygren.org>
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
Received on Tuesday, 30 August 2016 17:25:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:57 UTC