Re: Rethinking KeyStorage

On Wed, Nov 7, 2012 at 2:47 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Nov 7, 2012, at 2:12 PM, Ryan Sleevi wrote:
>
>> On Wed, Nov 7, 2012 at 12:11 PM, Mark Watson <watsonm@netflix.com> wrote:
>>> Ryan,
>>>
>>> I will review the web storage stuff and make a proposal. As I said, the idea of using the structured clone algorithm to enable Key objects to be stored in existing web storage mechanisms seems like a good one to me.
>>>
>>> My concern is that it sounds like you are proposing complete removal of support for pre-provisioned keys from the specification. If that's what you want to propose, you should raise a straightforward ISSUE for that which we can discuss. It should not be a "side-effect" of this storage discussion. Agreement "to adopt the proposed storage semantics as a way to address [the] concerns [with KeyStorage]" does not equal agreement to remove support for pre-provisioned keys, as I clarified the next day at the f2f.
>>
>> You've repeatedly asserted that the pre-provisioned keys you imagine
>> being provided are not applicable to desktop user agents.
>
> No, I've said I don't expect the major desktop browser implementors to provide them, but you're welcome to do so.
>
>>
>> Our charter requires two independent implementations to advance
>> recommendation. If there are no implementations by that time, our work
>> cannot advance. Ergo, it is vitally important that the spec only
>> contains features that will be implemented within the time frame we've
>> established.
>
> We cannot say for sure what will or will not be implemented. Features which don't make the CR criteria can be removed in order for us to progress. Sure, features where there is no implementation interest would be a waste of time. That is not the case here.
>
>>
>> Ergo, I do object to adding support for pre-provisioned keys.
>>
>> If the working group feels that pre-provisioned keys are necessary to
>> support in the first version - which I do not - then a sound technical
>> proposal needs to be put forward. Further, it will require significant
>> discussion of what the privacy implications are, and how
>> implementations can manage it. Please consider and compare with
>> existing web storage APIs - such as
>> http://www.w3.org/TR/webstorage/#privacy and
>> http://www.w3.org/TR/IndexedDB/#privacy
>
> Sure. Last week is the first time anyone has raised any technical issues with pre-provisioned origin-specific keys (specifically the storage API issue). I'll work on addressing those.
>
> We have been clear from the start that the privacy issues need discussion (see below).
>
>>
>> I feel in particular that the use case being proposed by Netflix runs
>> counter to the user privacy protections built or being built into a
>> variety of devices - desktop and mobile - and thus requires careful
>> evaluation whether such use cases should be encouraged or blessed
>> within a W3C Spec.
>
> This seems to be an in principle objection to our business requirement for strong device authentication. W3C specifications are not the place to encourage, discourage, bless or damn legitimate business decisions.
>
> Privacy protection is about empowering users to *control* their privacy, not dictating to them what information they may or may not share (and consequently what services they may or may not use).
>
> What runs counter to that princple is punting privacy-sensitive functionality into opaque implementation-specific loopholes. We should be transparent and address the issue head-on.
>
>>
>> In particular, if the spec is to provide any statements about
>> pre-provisioned keys, it MUST make accommodations to recommend that
>> user agents clear all pre-provisioned keys when a user attempts to
>> clear persistent storage, including the removal of all persistent
>> identifiers.
>
> 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.

And this is reason for concern - see the many discussions regarding
privacy protections in other persistent storage APIs - such as the
aforementioned Web Storage and IndexedDB.

If it's clear that the only implementations of this feature are going
to implement it in a way that directly runs counter to the privacy
concerns that are baked into other web APIs, is this really a good
feature to recommend or support? I realize very much that "This is how
it works today", but you're talking about a very different threat
model for the web, and given the very real concerns about user privacy
that exist in a multitude of contexts, opening up such a can of worms
invariably requires extensive discussion and the cross-working-group
engagement to resolve and evaluate these privacy concerns.

Adding device-specific, persistent identifiers that can be used to
track users - whether for good (authentication) or bad (insert
favourite evil scenario here) - more or less runs counter to the
design goals of a number of APIs, and directly flies into the face of
the efforts to build privacy considerations into APIs.

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", 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). 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.

>
>>
>> I should note that these concerns - about the significant harm to
>> privacy that pre-provisioned keys may represent - are in addition to
>> the very real technical concerns raised previously.
>
> Quite the reverse: an open and transparent specification for how pre-provisioned keys work would be a significant improvement - from a privacy perspective - on the situation today (where this is completely obscure).
>
>>
>> I would encourage this work regarding pre-provisioned be pursued in
>> parallel to / in separation of the current primary spec, as a point of
>> maintaining the chartered timelines and charter requirements regarding
>> advancement, much as discussion of the high-level API (a similarly
>> complex discussion point) is being done. If they can be specified,
>> discussed, and implemented in a way that is consistent with the
>> charter requirements, I think it's reasonable to consider integration,
>> but I do not think "nice to have" features should be incorporated
>> simply by virtue of specification.
>
> It's not nice-to-have for us, at least.
>
>>
>> If that is not workable, we should be discussing rechartering, which I
>> do not believe would be a good thing, as also raised during the face
>> to face.
>>
>>>
>>> I'll say it again: pre-provisioned keys (specifically the symmetric origin-specific kind) were raised as a requirement at the very first workshop, are central to the very first use-case proposed for this API (which happens also to be the use-case with the most likelihood of early implementation) and we've been consistent in our position on this throughput this work. I'd strongly oppose removing them from the specification, if that was proposed.
>>>
>>> …Mark
>>
>> Support for the Korean use case and certificates was also raised from
>> the beginning, and has been central to the use cases proposed, and
>> which we've seen a variety of requests for. Yet it has not been
>> demanded yet that it be incorporated into the first version delivered.
>
> If there was a workable technical proposal, people prepared to do the specification work and a likelihood of implementation then it would be perfectly reasonable for that to be in the first version too. Indeed those are exactly the criteria for inclusion in the first version, IMO.
>
>> Indeed, the charter specifically spells out how to handle such
>> features - roadmapped for future work.
>>
>
> Again, I think "such features" are those without workable solutions and proponents prepared to do the work (specification and implementation). We are contribution-driven, after all.
>
> …Mark
>

Received on Wednesday, 7 November 2012 22:59:17 UTC