Re: Rethinking KeyStorage

On Wed, Nov 7, 2012 at 6:05 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Nov 7, 2012, at 3:43 PM, Ryan Sleevi wrote:
>
>> Given the number of concerns - both technical and legal - that exist
>> with "device serial numbers" - eg: [1] [2] - I think it's reasonable
>> to raise concerns about whether the W3C should be encouraging (or
>> standardizing) the development of web applications and services that
>> rely on such features.
>
> You're welcome to raise that question in the appropriate forum (I'm not sure it's this one). Please tell me if you do so that I can respond. We had a similar debate when considering whether to begin work on the Encrypted Media Extensions in the HTML group, though I don't see much of a parallel in the subject matter here. W3C is certainly entitled, as an organization, to decide that the web platform should not support a particular set of commercial services. I for one would welcome a clear answer.

You've asked this WG to adopt this feature. It's reasonable to expect
that, minimally, the discussion needs to happen in this forum, and
more broadly, by engaging W3C members focused on privacy.

>
>>
>> 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.
>
> Just to be clear, we're talking about origin-specific keys/identifiers here, but yes the distinction between a key vs identifier is not important when considering the privacy implications.
>
>>
>> [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 have no argument with the content of these articles. [1] points out the evils of an origin-independent, non-user-controllable device identifier. I completely agree.
>
> [2] explains how Apple are migrating from that to something more transparent, putting users in control. That's a step forward and I'm proposing essentially the same thing. It's not clear if Apple's IFA is origin-specific. but that is another improvement, in my view.
>
> You can certainly conclude from these and other articles on this topic that transparency and user control are important. I agree, Indeed, by "standardizing" a common approach for all iOS apps, Apple can give users a common settings panel to exercise this control. That's an improvement over every app doing their own implementation-specific opaque-to-users thing.
>
> I don't think you can conclude from the articles that such identities are universally evil (as you seem to). A web in which ad targeting was impossible would be a pale reflection of what we have today: some people actually click on those ads and thereby pay the salaries of many people developing new and innovative applications. Including, perhaps, some people on this list ;-)
>
> Please note, though, that my proposals are targeted at keys that are pre-provisioned for specific origins, not a general capability to provide such keys to any origin (though someone could certainly build that).
>
> …Mark
>
>

Mark,

Origin-specific / same origin policy are not a magic,
privacy-preserving feature. The Web security model is very different
than what is available to native applications - mobile or desktop.

The very real risk exists that even if only a single origin is ever
granted access to this device ID/key, by virtue of being an online
service, a hostile third-party web site may be able to compromise and
coerce the 'safe' origin to disclose that identifier. Or, of course,
the "safe" origin may collaborate with other origins to track users.
So it's absolutely reasonable to ask whether - within the web platform
- such features should exist and whether they can even safely exist.

I've stated my preferences before - which is that I would prefer this
sort of API and discussion be moved into a separate document, with a
separate discussion regarding the security considerations and access
restrictions. For example, this sort of tracking feature may, *if
accepted as a deliverable*, be better if constrained wholly to SysApps
rather than even allowing web apps to have access. Of course, I've
also stated elsewhere that I don't feel this feature is required to be
specified by our charter.

Received on Thursday, 8 November 2012 15:06:00 UTC