The SOP problem - Re: removing keygen from HTML

> On 8 Jun 2016, at 14:32, Harry Halpin <hhalpin@ibiblio.org> wrote:
> 
> 
> 
> On Tue, May 31, 2016 at 6:31 AM, Chaals McCathie Nevile <chaals@yandex-team.ru <mailto:chaals@yandex-team.ru>> wrote:
> On Tue, 31 May 2016 16:40:30 +0200, Harry Halpin <hhalpin@ibiblio.org <mailto:hhalpin@ibiblio.org>> wrote:
> 
> On Tue, May 31, 2016 at 3:43 AM, Daniel Appelquist <dan@torgo.com <mailto:dan@torgo.com>> wrote:
> 
> Hi Folks - the TAG (in the person of Travis) has written on this topic:
> 
> https://w3ctag.github.io/client-certificates/#replacing-keygen <https://w3ctag.github.io/client-certificates/#replacing-keygen>
> 
> As noted, it represents the rough consensus of the TAG on this issue.
> 
> 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.
> 
> 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/pX5NbX0Xack <https://groups.google.com/a/chromium.org/forum/#%21topic/blink-dev/pX5NbX0Xack> - 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 

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

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.

>  
>  2) I don't know how rough that consensus is. Multiplying rough consensus by rough consensus can quickly get to "a minority opinion".
> 
> One could argue to keep <keygen> enabled till when Web Authentication API
> is in browsers.
> 
> Which would have a critical impact on our current question - should we remove it *now*?
> 
> 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. 

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.  

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



> 
> Also, as <keygen> is currently non-interoperable and specified in only one browser
> 
> As far as I can see it works in Safari as well. Is my simplistic testing giving a false positive, or does it work?
> 
> 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.  
> 
> On Tue, 31 May 2016 at 13:33 Eric Mill <eric@konklone.com <mailto:eric@konklone.com>> wrote:
> 
> 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.
> 
> 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.
> 
> 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. 

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

Henry

> 
> cheers
> 
> Chaals
> 
> 
> -- 
> Charles McCathie Nevile - web standards - CTO Office, Yandex
>  chaals@yandex-team.ru <mailto:chaals@yandex-team.ru> - - - Find more at http://yandex.com <http://yandex.com/>
>