Re: Rethinking KeyStorage

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.

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

On Nov 7, 2012, at 11:16 AM, Ryan Sleevi wrote:

> On Wed, Nov 7, 2012 at 10:37 AM, Mark Watson <watsonm@netflix.com> wrote:
>> 
>> On Nov 7, 2012, at 10:24 AM, Ryan Sleevi wrote:
>> 
>>>> I'm fine for KeyStorage to be removed on these grounds IF there is a better alternative that maintains functionality.
>>> 
>>> The onus when removing features that are demonstrably bad (see above)
>> 
>> If you want to remove KeyStorage just because it is "bad", you need to present the technical argument here, and then I would be happy to help make a counter-proposal that addresses those points.
>> 
>> Just stating that it's bad (or referring off to long discussions on a different albeit similar mechanism) and only offering a less functional alternative isn't going to work if you're trying to get my agreement.
> 
> Considering that it was merely presented within the spec as a
> strawman, and without sufficient or significant discussion within the
> WG, I do not feel that it should suddenly have a higher bar for
> removal than it did for addition.
> 
> If anything, your continued insistence that it cannot be removed only
> serves to discourage people from contributing to the group, since it
> runs the risk that unless the idea is perfect on the first attempt, it
> will be impossible to remove.
> 
> We should simply remove it from the spec, acknowledge it as an ongoing
> issue, and continue. If we cannot resolve the issue within the
> schedule afforded to this group, then we can take appropriate action -
> either blocking progress (and implementation) of the spec until a
> suitable alternative can be found, or accepting (as I propose) that
> features that cannot be universally agreed upon or implemented are not
> blocking for Candidate Recommendation.
> 
> While I came to neither praise nor bury web storage, the issues were
> presented during the face to face, were re-iterated and amplified
> within the WebApps WG. A simple survey of appropriate literature (let
> alone the many and varied discussions in WebApps)
> 
> - http://blog.mozilla.org/tglek/2012/02/22/psa-dom-local-storage-considered-harmful/
> - http://webreflection.blogspot.co.uk/2012/03/whats-localstorage-about.html
> - http://paul.kinlan.me/we-need-to-kill-off-the-localstorage-api/
> 
> A small selection of the issues:
> - Synchronous API
> - Poor / undefined locking behaviour
> - Poor eventing model
> - Poor performance
> - Poor / no querying support
> 
> Further, given the strong overlap between pre-provisioned keys and
> other forms of discovered keys, I believe it's very important that we
> have a single, unified, consistent interface for accessing keys that
> were not directly created by the origin.
> 
>> 
>>> should not be that a counter-proposal be provided. It should be
>>> removed. If there is a proposal that can address the needs and be
>>> agreed upon within the work group as something to incorporate (and
>>> that will be implemented - which is very much a criteria for this API
>>> as spelled out in the charter), then we can revisit.
>>> 
>>> However, bad features should be removed. Not kept simply because no
>>> one has proposed something better.
>> 
>> Is it the functionality that you think is bad, or just the API design ? Previously you said it was the design ...
>> 
>> Badly designed features should be replaced with better designed alternatives. Or, indeed, if better designed alternatives cannot be found, they should be removed. But you should not just skip the search for alternatives and go straight to removal.
> 
> That's not generally how these processes work. If the current idea is
> a poor API (and again, it's well acknowledged and was particularly
> re-iterated during TPAC in WebApps), it should be removed. If a member
> of this WG feels that there are outstanding issues not addressed in
> the spec, we should leave ISSUEs to indicate "more work needed here".
> 
> However, suggesting that we use a bad interface as the marker for
> there being an outstanding issue is a very poor signal, and
> effectively makes compatible or experimental implementations
> impossible.
> 
> These are already highlighted in ISSUE-31 -
> http://www.w3.org/2012/webcrypto/track/issues/31 - and were also
> discussed in greater detail in the WG regarding locking, indexing,
> iteration, and performance. So the issues are well-known at this
> point.
> 
>> 
>> Nevertheless, you need the agreement of the group and I'm suggesting that it'll be much easier to get that if you address the design issues without removing functionality.
>> 
>> …Mark
>> 
> 
> And during our face to face, it was agreed to adopt the proposed
> storage semantics as a way to address these concerns - which involved
> a re-presentation of the issues and how the new proposal addresses
> them - and with WebApps as a venue to further improve and iterate on
> these semantics.
>

Received on Wednesday, 7 November 2012 20:11:37 UTC