Re: Rethinking KeyStorage

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.

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.

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

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.

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.

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.

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.

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.
Indeed, the charter specifically spells out how to handle such
features - roadmapped for future work.

Received on Wednesday, 7 November 2012 22:13:12 UTC