The SOP problem - Re: removing keygen from HTML

Henry Story <[email protected]> Wed, 8 Jun 2016 15:34:06 +0200
Newsgroups gmane.org.w3c.tag
Message-ID <[email protected]>
--Apple-Mail=_E2C8865E-4F08-4EB5-8394-2514636C6A6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 8 Jun 2016, at 14:32, Harry Halpin <[email protected]> wrote:
>=20
>=20
>=20
> On Tue, May 31, 2016 at 6:31 AM, Chaals McCathie Nevile =
<[email protected] <mailto:[email protected]>> wrote:
> On Tue, 31 May 2016 16:40:30 +0200, Harry Halpin <[email protected] =
<mailto:[email protected]>> wrote:
>=20
> On Tue, May 31, 2016 at 3:43 AM, Daniel Appelquist <[email protected] =
<mailto:[email protected]>> wrote:
>=20
> Hi Folks - the TAG (in the person of Travis) has written on this =
topic:
>=20
> https://w3ctag.github.io/client-certificates/#replacing-keygen =
<https://w3ctag.github.io/client-certificates/#replacing-keygen>
>=20
> As noted, it represents the rough consensus of the TAG on this issue.
>=20
> As I read that, in relation to the question facing the Web Platform =
group for the HTML spec:
>  1) It doesn't present any urgency to remove keygen, noting that there =
is not a replacement available now.
>=20
> The urgency is that <keygen> as it stands violates SOP and so user =
privacy (details here - =
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xa=
ck =
<https://groups.google.com/a/chromium.org/forum/#%21topic/blink-dev/pX5NbX=
0Xack> - although finger-printing avoidance is nearly impossible).

That thread is huge - 132 posts. Which parts of the argument are you =
referring to?

Perhaps it would be easier to start with the  TAG finding that =
summarises this thread=20

     http://w3ctag.github.io/client-certificates/

It has come, it seems to me, to the opposite conclusion that you have, =
regarding SOP.

In any case since you think that SOP is the problem, do you think you =
could describe=20
the problem concisely? That argument could then be added to the TAG =
finding, if it stands
up to scrutiny. Or perhaps it is already in the TAG finding? Can you =
point to the relevant=20
sections?

It seems that the way you think of SOP it is an architectural principle, =
of high enough
importance that it should override usage of most browsers for the past =
17 years. After
all browsers have some kind of keygen functionality until recently, =
including=20
Microsoft with an ActiveX component. If so it really should be something =
the TAG can
describe in a principled way, so as to avoid mistakes if there are any =
to be made again,
and also to put the discussion on a principled basis.

> However, given that TimBL and a few others on this list use <keygen> =
in their programming projects, it seems the polite thing to do is not to =
deprecate it until Web Authentication is ready by end of the year =
despite the security/privacy concerns. That should at least give TimBL =
and others time to update their code.=20

And what if TimBL and others using this were correct to use it, and you =
were actually misunderstanding
the issues? The only way we can work out how much you are right and how =
much Tim and others
are right, is if you clearly specify the problem with SOP, and we can =
understand the issue from first principles.

> =20
>  2) I don't know how rough that consensus is. Multiplying rough =
consensus by rough consensus can quickly get to "a minority opinion".
>=20
> One could argue to keep <keygen> enabled till when Web Authentication =
API
> is in browsers.
>=20
> Which would have a critical impact on our current question - should we =
remove it *now*?
>=20
> Given that Chrome has removed it and Mozilla has said they will remove =
it, it seems not to make much sense to keep it in the HTML spec.=20

You never know: they could change their mind.

But the problem with SOP is not limited to keygen. As I read you from =
posts in different lists
it actually extends to usage of client certificates across origins, =
which remains even if keygen
is removed. And the people removing keygen have not argued against =
client certifictes. Indeed
removing keygen does not remove client certificate functionality... I =
think in that very long
thread I saw a statement of Ryan Sleevi, who was pushing for removing =
keygen, that this
had no effect at all on client certificates. =20

I suppose you disagree with that. We'll know when you spell out the =
Single Origin Policy argument.



>=20
> Also, as <keygen> is currently non-interoperable and specified in only =
one browser
>=20
> As far as I can see it works in Safari as well. Is my simplistic =
testing giving a false positive, or does it work?
>=20
> Safari in my experience tends to policy not to comment on future work. =
Feel free to ask them. However, one browser probably does not mean it =
should stay in the HTML spec, particularly after Mozilla drops it. You =
can ask Mozilla for their timeline. =20
>=20
> On Tue, 31 May 2016 at 13:33 Eric Mill <[email protected] =
<mailto:[email protected]>> wrote:
>=20
> The original email said: "Since the TAG, or its members, appear to =
have
> opinions about our spec, we'd be grateful to hear them." It'd be most
> productive for this thread's discussion to at least be initiated by a
> member of the TAG.
>=20
> To be fair, I understand the nature of this mailing list, and while I =
addressed my comments prmiarily to the TAG I am grateful for others =
giving input too.
>=20
> Given that the TAG sometimes is not aware of all the work happening in =
W3C, it seemed to make sense to chime in with the Web Authentication =
timeline.=20

The point is to get clear on this SOP principles, or else this issue =
will keep re-appearing=20
and just polute any other standard you try to put forward and work on.

Henry

>=20
> cheers
>=20
> Chaals
>=20
>=20
> --=20
> Charles McCathie Nevile - web standards - CTO Office, Yandex
>  [email protected] <mailto:[email protected]> - - - Find more =
at http://yandex.com <http://yandex.com/>
>=20


--Apple-Mail=_E2C8865E-4F08-4EB5-8394-2514636C6A6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 8 Jun 2016, at 14:32, Harry Halpin &lt;<a =
href=3D"mailto:[email protected]" class=3D"">[email protected]</a>&gt;=
 wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D""><br class=3D""><div class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On Tue, May 31, 2016 at 6:31 AM, =
Chaals McCathie Nevile <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:[email protected]" target=3D"_blank" =
class=3D"">[email protected]</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span =
class=3D"">On Tue, 31 May 2016 16:40:30 +0200, Harry Halpin &lt;<a =
href=3D"mailto:[email protected]" target=3D"_blank" =
class=3D"">[email protected]</a>&gt; wrote:<br class=3D"">
<br class=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Tue, May 31, 2016 at 3:43 AM, Daniel Appelquist &lt;<a =
href=3D"mailto:[email protected]" target=3D"_blank" =
class=3D"">[email protected]</a>&gt; wrote:<br class=3D"">
<br class=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi Folks - the TAG (in the person of Travis) has written on this =
topic:<br class=3D"">
<br class=3D"">
<a href=3D"https://w3ctag.github.io/client-certificates/#replacing-keygen"=
 rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://w3ctag.github.io/client-certificates/#replacing-keygen<=
/a><br class=3D"">
<br class=3D"">
As noted, it represents the rough consensus of the TAG on this issue.<br =
class=3D"">
</blockquote></blockquote>
<br class=3D""></span>
As I read that, in relation to the question facing the Web Platform =
group for the HTML spec:<br class=3D"">
&nbsp;1) It doesn't present any urgency to remove keygen, noting that =
there is not a replacement available now.<br class=3D""></blockquote><div =
class=3D""><br class=3D""></div><div class=3D"">The urgency is that =
&lt;keygen&gt; as it stands violates SOP and so user privacy (details =
here - <a =
href=3D"https://groups.google.com/a/chromium.org/forum/#%21topic/blink-dev=
/pX5NbX0Xack" target=3D"_blank" =
class=3D"">https://groups.google.com/a/chromium.org/forum/#!topic/blink-de=
v/pX5NbX0Xack</a> - although finger-printing avoidance is nearly =
impossible). </div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>That thread is huge - 132 posts. Which parts of =
the argument are you referring to?</div><div><br =
class=3D""></div><div><div>Perhaps it would be easier to start with the =
&nbsp;TAG finding that summarises this thread&nbsp;</div><div><br =
class=3D""></div><div>&nbsp; &nbsp;&nbsp;&nbsp;<a =
href=3D"http://w3ctag.github.io/" =
class=3D"">http://w3ctag.github.io/</a>client-certificates/</div><div><br =
class=3D""></div><div>It has come, it seems to me, to the opposite =
conclusion that you have, regarding SOP.</div><div><br =
class=3D""></div><div>In any case since you think that SOP is the =
problem, do you think you could describe&nbsp;</div><div>the problem =
concisely? That argument could then be added to the TAG finding, if it =
stands</div><div>up to scrutiny. Or perhaps it is already in the TAG =
finding? Can you point to the =
relevant&nbsp;</div><div>sections?</div><div><br class=3D""></div><div>It =
seems that the way you think of SOP it is an architectural principle, of =
high enough</div><div>importance that it should override usage of most =
browsers for the past 17 years. After</div><div>all browsers have some =
kind of keygen functionality until recently, =
including&nbsp;</div><div>Microsoft with an ActiveX component. If so it =
really should be something the TAG can</div><div>describe in a =
principled way, so as to avoid mistakes if there are any to be made =
again,</div><div>and also to put the discussion on a principled =
basis.</div><div><br class=3D""></div></div><blockquote type=3D"cite" =
class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"">However, =
given that TimBL and a few others on this list use &lt;keygen&gt; in =
their programming projects, it seems the polite thing to do is not to =
deprecate it until Web Authentication is ready by end of the year =
despite the security/privacy concerns. That should at least give TimBL =
and others time to update their code. <br =
class=3D""></div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>And what if TimBL and others using this were =
correct to use it, and you were actually misunderstanding</div><div>the =
issues? The only way we can work out how much you are right and how much =
Tim and others</div><div>are right, is if you clearly specify the =
problem with SOP, and we can understand the issue from first =
principles.</div><div><br class=3D""></div><blockquote type=3D"cite" =
class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"">&nbsp;<br=
 class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&nbsp;2) I don't know how rough that consensus is. Multiplying rough =
consensus by rough consensus can quickly get to "a minority =
opinion".<span class=3D""><br class=3D"">
<br class=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
One could argue to keep &lt;keygen&gt; enabled till when Web =
Authentication API<br class=3D"">
is in browsers.<br class=3D"">
</blockquote>
<br class=3D""></span>
Which would have a critical impact on our current question - should we =
remove it *now*?<span class=3D""><br class=3D""></span></blockquote><div =
class=3D""><br class=3D""></div><div class=3D"">Given that Chrome has =
removed it and Mozilla has said they will remove it, it seems not to =
make much sense to keep it in the HTML spec. <br =
class=3D""></div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>You never know: they could change their =
mind.</div><div><br class=3D""></div><div>But the problem with SOP is =
not limited to keygen. As I read you from posts in different =
lists</div><div>it actually extends to usage of client certificates =
across origins, which remains even if keygen</div><div>is removed. And =
the people removing keygen have not argued against client certifictes. =
Indeed</div><div>removing keygen does not remove client certificate =
functionality... I think in that very long</div><div>thread I saw a =
statement of Ryan Sleevi, who was pushing for removing keygen, that =
this</div><div>had no effect at all on client certificates. =
&nbsp;</div><div><br class=3D""></div><div>I suppose you disagree with =
that. We'll know when you spell out the Single Origin Policy =
argument.</div><div><br class=3D""></div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><span class=3D""><br class=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, as &lt;keygen&gt; is currently non-interoperable and specified in =
only one browser<br class=3D"">
</blockquote>
<br class=3D""></span>
As far as I can see it works in Safari as well. Is my simplistic testing =
giving a false positive, or does it work?<span class=3D""><br =
class=3D""></span></blockquote><div class=3D""><br class=3D""></div><div =
class=3D"">Safari in my experience tends to policy not to comment on =
future work. Feel free to ask them. However, one browser probably does =
not mean it should stay in the HTML spec, particularly after Mozilla =
drops it. You can ask Mozilla for their timeline.&nbsp; <br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><span class=3D"">
<br class=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">
On Tue, 31 May 2016 at 13:33 Eric Mill &lt;<a =
href=3D"mailto:[email protected]" target=3D"_blank" =
class=3D"">[email protected]</a>&gt; wrote:<br class=3D"">
<br class=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The original email said: "Since the TAG, or its members, appear to =
have<br class=3D"">
opinions about our spec, we'd be grateful to hear them." It'd be most<br =
class=3D"">
productive for this thread's discussion to at least be initiated by a<br =
class=3D"">
member of the TAG.<br class=3D"">
</blockquote></blockquote></blockquote>
<br class=3D""></span>
To be fair, I understand the nature of this mailing list, and while I =
addressed my comments prmiarily to the TAG I am grateful for others =
giving input too.<br class=3D""></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">Given that the TAG sometimes is not =
aware of all the work happening in W3C, it seemed to make sense to chime =
in with the Web Authentication timeline. <br =
class=3D""></div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>The point is to get clear on this SOP principles, =
or else this issue will keep re-appearing&nbsp;</div><div>and just =
polute any other standard you try to put forward and work =
on.</div><div><br class=3D""></div><div>Henry</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">
<br class=3D"">
cheers<span class=3D""><font color=3D"#888888" class=3D""><br class=3D"">
<br class=3D"">
Chaals</font></span><div class=3D""><div class=3D"h5"><br class=3D"">
<br class=3D"">
-- <br class=3D"">
Charles McCathie Nevile - web standards - CTO Office, Yandex<br =
class=3D"">
&nbsp;<a href=3D"mailto:[email protected]" target=3D"_blank" =
class=3D"">[email protected]</a> - - - Find more at <a =
href=3D"http://yandex.com/" rel=3D"noreferrer" target=3D"_blank" =
class=3D"">http://yandex.com</a><br class=3D"">
</div></div></blockquote></div><br class=3D""></div></div>
</div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_E2C8865E-4F08-4EB5-8394-2514636C6A6A--