Re: Privacy considerations of persistent device keys / device IDs

On Nov 8, 2012, at 8:26 AM, Ryan Sleevi wrote:

>>> 1) Remove the KeyStorage API [Done]
>> 
>> No, you do not have agreement of the group to do that. Please, let's not get into HTML-WG-style revert requests. You need consensus to make changes and you clearly do not have it.
> 
> Mark,
> 
> Consensus was reached during the Face to Face, recorded in the
> minutes, and reflected in the ACTION assigned to the editors -
> http://www.w3.org/2012/webcrypto/track/actions/60 . That decision was
> recorded, so this is not some unilateral action being taken.

As you know I wasn't present for that discussion. But at the same meeting I raised the question of whether this decision was about using other storage mechanisms (which it certainly seems to be from the action) or whether it was also intended to remove support for pre-provisioned keys. I made it very clear I supported the former and would object to the latter.

Virginie confirmed to me directly that if you're text proposal came back removing pre-provisioned keys as well as addressing the storage issue, then that would be a problem. We discussed this between us also. 

So, yes, there was a decision, but no, it was not a decision to remove support for pre-provisioned keys and you're well aware you don't have consensus to do that.

> 
> Your point that removing KeyStorage prevents your particular use case
> is noted. You can certainly make a proposal to provide text that
> addresses your use case.

It's going to be pretty hard to work together if anyone, at any time, can find that support for a feature they need is arbitrarily removed from the specification as a side-effect of another discussion and they are then asked to re-propose the feature.

I'm happy to work on "better" support for pre-provisioned key storage, but as editor you don't just get to remove features you don't like without agreement from the group.

> 
> But we should not simply leave misleading or non-implemented text in
> place, simply because we don't (yet) have something better, let alone
> before we've agreed upon adding and addressing that feature.

So, again, there was no dissent regarding pre-provisioned origin-specific keys since they were first proposed at the first workshop, up until last week. So we are in a situation where you are proposing to remove an existing feature, not in a situation where I am newly proposing to introduce it.

You're welcome to make the case that some existing text is misleading and should be removed or replaced as a consequence. But you have to make that case and get agreement, not remove it by unilaterally because you feel it is deficient.

> 
> For ANY feature, and not just pre-provisioned key, if there are
> issues, it is BETTER to remove it from the spec and address it with
> follow-up proposals than to simply leave it in place "because it's
> easier" or "because it's convenient".

I think you have to make that argument on a case-by-case basis. In this case I disagree that the existing text has issues bad enough to warrant that approach. That doesn't mean I won't work on improving it.

…Mark

>

Received on Thursday, 8 November 2012 19:19:46 UTC