Privacy considerations of persistent device keys / device IDs

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

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

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


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.

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

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.

Received on Thursday, 8 November 2012 01:19:04 UTC