Re: Privacy considerations of persistent device keys / device IDs

On Nov 8, 2012, at 7:05 AM, Harry Halpin wrote:

> On 11/08/2012 03:15 PM, Ryan Sleevi wrote:
>> 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.
> 
> I'm going to add that we are going to have to have a formal privacy review of this spec, and this will definitely come up and unless some effort is taken to address user authorization and privacy, then a formal objection would be likely.

Agreed, I've said from the beginning that the privacy aspects need to be addressed.

> 
> I think handling this, as Ryan points out, in a similar fashion to other WGs, is necessary. Mark, I believe the ball is in your court if you feel the API is not defined.

As far as pre-provisioned keys are concerned, we had support for that in the FPWD through KeyStorage and so we didn't make a separate proposal. I'm more than happy to discuss replacing that with something better, but the API is there right now and should be replaced rather than unilaterally removed.

> However, the "guid" proposal you outlined earlier at TPAC is a step in this direction, so its in general good to get these issues out early rather than wait for them at the last minute.

The unique identifier aspect is separate and builds on top of the basic support for pre-provisioned keys.

…Mark

> 
> 
>

Received on Thursday, 8 November 2012 15:42:36 UTC