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

--001a114024bc3d2f4405391b350b
Content-Type: text/plain; charset=UTF-8

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 <[email protected]> wrote:

> <hat="individual"> I support this very much.
>
> On Tue, Jul 19, 2016 at 6:22 AM Mike West <[email protected]> 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
>>
>

--001a114024bc3d2f4405391b350b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Based on some discussion on GitHub, I&#39;ve added two new=
 &quot;at risk&quot; demarcations to the Secure Contexts spec:<div><br></di=
v><div>* In <a href=3D"https://github.com/w3c/webappsec-secure-contexts/iss=
ues/42">https://github.com/w3c/webappsec-secure-contexts/issues/42</a>,=C2=
=A0Jake has expressed some discomfort with the `opener` restriction on popu=
ps (that is, popups created from a non-secure context remain non-secure, ev=
en if delivered securely): recorded in the spec as=C2=A0<a href=3D"https://=
w3c.github.io/webappsec-secure-contexts/#issue-8ea95bab">https://w3c.github=
.io/webappsec-secure-contexts/#issue-8ea95bab</a>.=C2=A0I suspect that we&#=
39;ll be able to address Jake&#39;s concerns via changes to specs other tha=
n this one, but it&#39;s worth noting that there&#39;s not complete harmony=
 on the topic (nor, honestly, do we have pervasive implementation of that r=
estriction).</div><div><br></div><div>* In <a href=3D"https://github.com/w3=
c/webappsec-secure-contexts/issues/43">https://github.com/w3c/webappsec-sec=
ure-contexts/issues/43</a>,=C2=A0Erik suggested that the move to exclude `l=
ocalhost` was the wrong way to solve the problem, and that we should instea=
d treat it as &quot;secure&quot; if it resolves to a loopback address. Reco=
rded in the spec as=C2=A0<a href=3D"https://w3c.github.io/webappsec-secure-=
contexts/#issue-8ea95bab">https://w3c.github.io/webappsec-secure-contexts/#=
issue-8ea95bab</a>. Without some change in the way that agent&#39;s DNS res=
olvers handle these names, I&#39;m reluctant to change the spec, but perhap=
s pushing for that change is a reasonable thing to do.</div><div><br></div>=
<div>The regenerated document is up at=C2=A0<a href=3D"https://w3c.github.i=
o/webappsec-secure-contexts/">https://w3c.github.io/webappsec-secure-contex=
ts/</a> for review.</div><div><br></div><div>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=
.</div><div><br></div><div>What do y&#39;all think?</div><div class=3D"gmai=
l_extra"><br clear=3D"all"><div><div class=3D"gmail_signature" data-smartma=
il=3D"gmail_signature">-mike</div></div>
<br><div class=3D"gmail_quote">On Wed, Jul 20, 2016 at 11:18 PM, Brad Hill =
<span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blan=
k">[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">&lt;hat=3D&quot;individual&quot;&gt; I support this ver=
y much.</div><div class=3D"HOEnZb"><div class=3D"h5"><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr">On Tue, Jul 19, 2016 at 6:22 AM Mike West &lt;<a =
href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello, Web=
AppSec and TAG,<div><br></div><div><div>This is a call for consensus to tra=
nsition Secure Contexts to Candidate Recommendation with the document at:<b=
r></div><div><br></div><div><a href=3D"https://w3c.github.io/webappsec-secu=
re-contexts/CR.html" target=3D"_blank">https://w3c.github.io/webappsec-secu=
re-contexts/CR.html</a><br></div><div><br></div><div>Since the last time we=
 formally discussed this spec, we&#39;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 f=
rom the TAG and elsewhere (thanks to Anne and Domenic in particular).<br></=
div><div><br></div><div><span style=3D"font-size:12.8px">The core of the sp=
ecification is already used in a number of specifications to gate certain f=
eatures (like Service Workers) to contexts which offer guarantees about the=
ir usage, and browser vendors seem interested in implementing.</span></div>=
<div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"=
font-size:12.8px">One substantive change since the last time around is the =
sandbox behavior in=C2=A0<a href=3D"https://w3c.github.io/webappsec-secure-=
contexts/CR.html#monkey-patching-sandbox-flags" target=3D"_blank">https://w=
3c.github.io/webappsec-secure-contexts/CR.html#monkey-patching-sandbox-flag=
s</a>, which now defaults to forcing a sandboxed frame into &quot;non-secur=
e context&quot; status, and requires a new &#39;allow-secure-context&#39; t=
oken to allow the context to be treated as secure. It&#39;s not clear wheth=
er we can ship that change; it&#39;s marked as &quot;at risk&quot; pending =
gathering some metrics.</span></div><div><br></div><div>Note also that this=
 document references WHATWG documents in a few places where the W3C version=
 is out of date. I&#39;m sure we&#39;ll have some exciting conversations ab=
out those references:=C2=A0<a href=3D"https://w3c.github.io/webappsec-secur=
e-contexts/CR.html#index-defined-elsewhere" target=3D"_blank">https://w3c.g=
ithub.io/webappsec-secure-contexts/CR.html#index-defined-elsewhere</a> cont=
ains a complete list.</div><div><br></div><div>The deadline for this CfC is=
 in two weeks, on August 2nd. Feedback, both positive and negative is welco=
me, either directly to the list, or via some sort of clever emoji response =
to=C2=A0<a href=3D"https://github.com/w3c/webappsec-secure-contexts/issues/=
39" target=3D"_blank">https://github.com/w3c/webappsec-secure-contexts/issu=
es/39</a>.</div><div><br></div><div>Thanks!</div></div></div><div dir=3D"lt=
r"><div><div><br clear=3D"all"><div><div>-mike</div></div>
</div></div></div></blockquote></div>
</div></div></blockquote></div><br></div></div>

--001a114024bc3d2f4405391b350b--