Re: keygen and client-certificates document available

On 4 Dec 2015, at 7:47 pm, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> On 1 December 2015 at 09:21, Travis Leithead
> <travis.leithead@microsoft.com> wrote:
>> Keygen and client certificates document:
>> http://w3ctag.github.io/client-certificates/
> 
> Does the TAG have consensus that <keygen> (and friends) is worth
> replacing?

Section 5 starts:
  "The keygen element should be replaced by a new API better suited for modern day application requirements."

By "and friends", do you mean client certificates? That would be a much broader discussion.


>  It seems like there are plenty of approaches that can
> support similar use cases, some of which have considerably more
> momentum (see Fido for instance).  Is anyone signed up to do work on
> this?

What do you mean by "work" in this case -- FIDO obviously has a number of people working on it (soon including folks from your fine employer, as I hear it).

Generally, the TAG shies away from advocating for adoption of particular proposals (outside the ones we generate ourselves, of course). That said, we're happy to expound upon the architectural implications of various things, and FIDO is on that list; see <https://github.com/w3ctag/spec-reviews/issues/97>. 


> The document is unclear on what recommendation it makes regarding
> <keygen>-and-co right now.  I could infer from all the activity that
> the subtext is a plea to retain the busted feature until a replacement
> is ready, but that's not clear to me from reading the document.

Please don't infer what the TAG thinks from what people other than TAG members say on the TAG mailing list. 

For that matter, be extremely careful about inferring what the TAG thinks from what TAG members say, unless they explicitly say it's a TAG position.


> I think that's a very important part of the statement.  If the TAG has
> consensus on this point, I'd like to hear that.

*nod*


> I'm disappointed that the TAG thinks that user permission is all that
> is needed to install a cross origin correlator.  I realize that this
> is a highly contentious aspect of <keygen>: very important to some,
> one of the worst aspects to others.  Either way, I don't think that
> there is any question you could sensibly ask a user that would
> convince me that the answer you got constituted informed consent.

Ah, "informed consent" again. 

I don't necessarily agree that you can't ask the question in a useful way; while it may be that people who genuinely don't care will click through, people who do care will take advantage of the opportunity. What's important is to have defaults that respect the user, and assure that we don't put users in situations where the services they want are held hostage until they give a permission (this can't be prevented, of course, but it shouldn't be encouraged by the design).

We seem to be getting better at that. 

What does concern me personally is the number of questions that can be asked; I think one of the key things we need to watch is the complexity of the mental model that people have for the Web. If you need to know 400 different ways that your privacy might be affected by how you use a browser, people tend to give up -- either on controlling their privacy or the Web. 

So, I'm sympathetic to the idea that even with permission, a cross-origin correlator might not be the right thing here. However, we haven't got to that, yet. 

Cheers,

--
Mark Nottingham   https://www.mnot.net/

Received on Saturday, 5 December 2015 23:44:53 UTC