Re: Privacy considerations of persistent device keys / device IDs

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.

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

Received on Thursday, 8 November 2012 15:05:58 UTC