Re: Privacy considerations of persistent device keys / device IDs

On Nov 8, 2012, at 6:15 AM, 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]

No, you do not have agreement of the group to do that. Please, let's not get into HTML-WG-style revert requests. You need consensus to make changes and you clearly do not have it.

As was clarified at the meeting and on email, we've agreed that you should propose the text to use IndexedDB etc. for key storage. If that text *also* removes support for pre-provisioned keys - a totally orthogonal issue - we'll object to it.

You may not have considered the pre-provisioned key aspect important to KeyStorage - you may think it was a "side-behaviour" - but I had a different opinion. It was exactly because KeyStorage supports pre-provisioned keys that we did not make any other proposal. It can happen in standardization that people support things for different reasons. You don't get to decide which reason is more "valid".

> 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

This is a little backwards: how could the WG make a "MUST be supported" decision without understanding the necessary technical security and privacy properties ?

The WG should certainly take a "we'll work on this" decision, but I would argue that given the complete lack opposition to pre-provisioned keys from the first workshop until just last week, we did that long ago.

Now we should do the work, which is why we've been making proposals.

If the privacy aspects turn out to be an issue for LC, then we take a decision on whether to keep working on those and delay LC, or drop the feature.

>  - See previous thread regarding minimum suggested technical concerns
> (async/non-blocking, locking behaviour, read-only vs read-write,
> attributes, etc)

Yep, and now you've raised these I'm happy to make a proposal.

>  - That such work will not affect our chartered timeline regarding
> compatible implementations and last call

We can't predict the future and this is true for all features. I don't see why a different standard (perfect knowledge in advance) should apply to this feature than to any others. You're just trying to establish insurmountable barriers here.

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

No, I'm asking that we continue to work on a feature which we've been working on from the start and which is in the FPWD. It's very strange that, out of nowhere, you propose that we throw this out and start from scratch. You say it's because of privacy issues, but also you say we should not discuss those privacy issues until we've made some set-in-stone decision that this is of MUST HAVE, WILL DELAY LAST CALL importance. I'm not proposing that. This feature is like any other and can be removed if insurmountable issues come up in discussion.

> 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 don't view it as a foregone conclusion that the first version of the spec must incorporate *anything* that is currently there. We are near the beginning of the process, so anything can change.

…Mark

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