Re: Privacy considerations of persistent device keys / device IDs

On Nov 7, 2012, at 5:18 PM, Ryan Sleevi wrote:

> On Wed, Nov 7, 2012 at 4:10 PM, Seetharama Rao Durbha
> <S.Durbha@cablelabs.com> wrote:
>> On 11/7/12 4:43 PM, "Ryan Sleevi" <sleevi@google.com> wrote:
>> 
>> 
>> I appreciate you pointing out that "pre-provisioned device key" is
>> effectively identical (regarding security and tracking concerns) to a
>> "device serial number", since it may help participants better
>> understand the real privacy risks being proposed here.
>> 
>> [1] http://www.theverge.com/2012/3/25/2900787/apple-rejects-UDID-apps
>> [2]
>> http://www.businessinsider.com/everything-we-know-about-ifa-and-tracking-in-apples-ios-6-2012-10
>> 
>> 
>> I think a certain perspective is being lost here.
>> Firstly, device finger-printing is already being used - by third-party
>> cookies that users do not even know about, and by DRM clients that
>> necessarily have to finger-print the device (flash cookies !!), among
>> others. So, I do not understand why there is so much talk about privacy –
>> particularly when the requirement is that the user grant permission to use
>> that key. Mark is right – it is a user's choice. It is a necessary
>> information for the service to be provided.
>> 
>> Mark is also right that privacy is a business issue, not a technology issue.
>> 
>> 
> 
> To be clear as to what's been proposed, and in particular to provide
> context for those following along:
> 
> 1) A persistent user identifier
>  - http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/0056.html
> - "If a user wishes to grant a particular origin access to their
> "device serial number", in return for enhanced services, they should
> be allowed to."

Please add "origin-specific".

> 
> 2) That cannot be revoked or have access revoked
>  - http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/0054.html
> - "TVs don't do this today, so I'm not sure how or why a W3C
> specification would cause them to do that in future."

I've been very clear that access should be controlled by the users. You are quoting me out of context. My statement above was in reaction to your suggestion that the pre-provisioned key MUST be removed in conjunction with certain other common, less drastic, user actions. I think users would be user if this actions bricked their TV.

> 
> 3) That access to these keys MAY be allowed without explicit user consent
>  - http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/0013.html
> - Consent is only a SHOULD

That's stronger than the privacy sections of the storage specifications you cite. They have only a MAY for user authorization

>  - http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/0034.html
> - "If it is reasonable, from an API definition and implementation
> perspective, for pre-provisoned origin-specific Key objects to appear
> 'automatically' in IndexedDB or whatever other storage API is
> available, then this is fine."

So ? This doesn't say "without user consent".

>  - http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/0038.html
> - "However, the user authorization of keys that come embedded in the
> device (at manufacturing time or delivered through a trusted means –
> out of scope) should be handled in a user-friendly way. Best case
> scenario is, the user is NOT asked for permission on such devices
> (user has no clue what a 'key' is and what this identifier is, and
> what they are authorizing). Rather the browser can rely on a
> configuration file present on the device."
> 

That was not my text.

> 
> Certainly, user agent implementers can go implement device IDs and
> device serial numbers in their user agents without any form of W3C
> blessing or standardization. I imagine some already are. But I don't
> think the calls based on the importance of standardization of this
> feature should preempt or obviate the discussion of privacy and
> whether or not this is even a desirable feature for the open web, nor
> do I think it should monopolize our discussions and work on other
> issues.

So, let's have a rationale discussion about the actual privacy issues then. So far you have just mis-characterized what is proposed and asserted that it is "user-hostile".

> 
> This is fundamentally the issue being put forward to the WG to vote on
> during our next telecon - whether or not to adopt such functionality
> and features.

Actually, what we are going to vote on is whether to specify how unique identifiers associated with pre-provisioned keys are exposed in the API

It is only subsequent to the identifier discussion that you have proposed removing pre-provisioned keys altogether.

> It's being proposed that we add this support to the
> spec, and therefore MUST define it (implicitly encouraging it), and,
> based on the replies here and in similar threads, MAY have some sort
> of conversation of privacy retroactively.

I'm not sure who is making that proposal.

What I'm proposing is that we don't remove something which has been in the spec for a while and that we do have a discussion of the privacy issues (and I've been consistent about that). It's you who is suggesting we don't have a discussion, but instead simply remove the feature.

> 
> If the privacy concerns are too great, it's not clear what will
> happen. Based on the opposition towards removing KeyStorage because it
> would incidentally make such device IDs harder, I fear that the
> mandate to support the feature (if that is where the vote goes) will
> trump the privacy concerns.  I think that's a bad precedent for
> privacy and puts the cart before the horse.
> 

It's hard to have a discussion about the privacy implications of some unspecified implementation-specific magic. We should have a clear API defined, with detailed privacy considerations, that we can circulate for wider review.

We have a mechanism that can be used to expose pre-provisioned keys in the draft. I proposed some privacy text, but I'm quite happy to take the feedback that this is not sufficient and make a new proposal.

…Mark

Received on Thursday, 8 November 2012 02:24:22 UTC