W3C home > Mailing lists > Public > public-webcrypto@w3.org > November 2012

Re: Privacy considerations of persistent device keys / device IDs

From: Ryan Sleevi <sleevi@google.com>
Date: Thu, 8 Nov 2012 06:15:10 -0800
Message-ID: <CACvaWvb4-_nTX_U-s9RJymL70Z-=ht+jSsaepcV50Q9XL+8VUQ@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Seetharama Rao Durbha <S.Durbha@cablelabs.com>, David Dahl <ddahl@mozilla.com>, public-webcrypto <public-webcrypto@w3.org>, Arun Ranganathan <arun@mozilla.com>, Harry Halpin <hhalpin@w3.org>
On Wed, Nov 7, 2012 at 6:23 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> 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.

Mark, the language I described is similar to that of IndexedDB, Web
Storage, and Geolocation. If a user wishes to revoke access to an
origin, then it MUST NOT continue to be available to an origin after
that fact.

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

And is consistent with
http://dev.w3.org/geo/api/spec-source.html#security "User agents must
acquire permission through a user interface"

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

And I never said it was. But we're talking about a feature that you
see as vital for this group to adopt and support, and so it's only
appropriate to consider the full implications of what is being
requested by those supporting it.

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

Before we even engage in that, let's first have the discussion about
whether or not this group is even going to support it.

I'm fully aware that Netflix, from the beginning, has said this
feature is needed for their use case. I'm not aware of any committment
that every feature necessary for Netflix must be delivered by this WG,
or that it must be delivered in the first version of the API.

It's been abundantly clear that other members in this WG have use
cases and features that are not addressed, so I do not feel in any way
that there is some manifest requirement to address all of these use
cases.

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

You mischaracterize the previous support. KeyStorage was not intended
to be the "pre-provisioned key support" API. It was meant to address
the Key Storage requirements that we have. That it was usable for
pre-provisioned keys was a side-behaviour, but not the motivating
factor of the API proposal.

You're presuming that pre-provisioned keys are (and have been) always
accepted as a MUST DELIVER since the API. I suspect fundamentally this
goes back to the chartering discussions - I interpreted the charter to
not be requiring it (in particular, the out-of-scope comment regarding
device-specific behaviours), and you interpreted it as to be requiring
it.

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

Uncategorically, I do not believe the WG has agreed that your use case
is a "MUST SOLVE" for the first deliverable.

Thus, the objection to removal, while noted, is not reason to keep a bad API in.

Further, proposals to add an API to support your use case MUST first
be based on a decision as to whether or not the WG is willing to
support that use case, and, if so, whether or not the technical and
privacy considerations are sufficiently addressable.

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

Here's the proper way to handle this discussion:

1) Remove the KeyStorage API [Done]
2) The WG reaches consensus that device IDs are something that MUST be
delivered in the first API
  - If the WG does not agree that this blocks LC, then we can
separately discuss roadmap or separate document.

**only if the WG decides to support this**
3) If Device IDs are supported, what are the necessary technical,
security, and privacy properties
  - See previous thread regarding minimum suggested technical concerns
(async/non-blocking, locking behaviour, read-only vs read-write,
attributes, etc)
  - That such work will not affect our chartered timeline regarding
compatible implementations and last call
  - That such work will be compatible with our already acknowledged
and desired secondary features regarding certificates, multiple key
storage mechanisms (which I would argue this is), and discovery of
pre-existing keys
4) A proposal is made that meets these requirements
5) Review and discuss the API, for any technical or privacy concerns
that may exist with the proposal
6) The text is incorporated in the spec

You're effectively asking every member to be prepared to have this
spec blocked by a formal objection on privacy/scope grounds. That's a
reasonably big request, regardless of how essential it is perceived. I
certainly do not view it as a forgone conclusion that the first
version of the spec must incorporate this.
Received on Thursday, 8 November 2012 14:15:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:14 UTC