Re: Rethinking KeyStorage

On Wed, Nov 7, 2012 at 3:16 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Nov 7, 2012, at 2:58 PM, Ryan Sleevi wrote:
>
>> It seems like the crux of your argument is "If we standardize it,
>> people can then be aware of how bad it is for user privacy",
>
> No, if we standardize it, people can be aware of it, it's pros and cons, and of how to control their own privacy.

If you note in the specs I references, it's very clear even within
that text that specs should be trying not to introduce new overloaded
concepts regarding privacy - hence, the comparison with and the
expectation that the API will behave in a similar fashion to cookies,
which users have been rightfully conditioned to be suspicious of.

It's not at all reasonable to expect users to understand the full
implications of the security tradeoffs here, let alone to bury the
considerations within a spec that few end-users will read.

>
> You are making big value judgements here. It's not a bad thing if users are empowered to trade personal information for services, if they so wish. It's a bad thing if some group presumes to dictate to users that they shall not do this (and consequently shall not have access to as many services).

It's not a value judgement to be concerned about user privacy - it's
an active concern of at least two W3C working groups -
http://www.w3.org/Privacy/ and
http://www.w3.org/2011/tracking-protection/

Any new features, particularly those that involve such significant
privacy tradeoffs (even more than existing web technologies such as
cookies, local storage, or indexed DB), really do deserve careful
scrutiny.

>
>> while the
>> argument that I'm presenting is that "If we standardize it, we are
>> explicitly recommending it" (see, for example, the name of W3C specs -
>> Recommendations).
>
> Again, no. If we standardize it we are recommending that "if you do this, do it this way". In the example of Netflix, our decision to require strong device authentication is a business decision which is unlikely to be influenced by anything the W3C says. Again, it's a benefit to users (vs the status quo) if TV manufacturers and others approached this requirement in a standard way.

If looking to standardize tracking technologies, it may be that the
W3C is not the best place, as I think a number of member organizations
(particularly those who participate in the Advisory Committee who will
have to review this spec) really are concerned about the privacy
implications and concerns of new features - hence the aforementioned
work goups.

I really don't want to see a situation where otherwise tremendously
useful work ends up getting blocked by an Formal Objection in LC/CR
over an optional feature, and I think the privacy concerns being
glossed over or actively dismissed are a real reason for concern of
that happening.

>
>> Leaving it unspecified is no more nor less
>> problematic than the fact that <embed> as a giant black hole, while
>> specifying it, even as a "may", is a clear and direct signal that
>> implementors "SHOULD" or "MAY" consider hostile-to-user-privacy
>> features, which is a real reversal of course in terms of the W3C's and
>> user agents' concerns for user privacy.
>
> No doubt that there needs to be discussion, but users need to be empowered to understand and control private information, not dictated to as to what services they can use on the web.
>
> Also, I really think you are overstating the problem. We are entirely within the same-origin policy here. 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. Or are you just saying that the web should not support services like Netflix and similar ?
>
> …Mark
>

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.

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

Received on Wednesday, 7 November 2012 23:45:34 UTC