Re: New Editor's Draft

On Aug 27, 2012, at 8:50 PM, Ryan Sleevi wrote:
> On Wed, Aug 22, 2012 at 2:33 PM, Arun Ranganathan <arun@mozilla.com> wrote:
>> On Aug 17, 2012, at 5:48 PM, Ryan Sleevi wrote:
>> 
>>> On Tue, Aug 14, 2012 at 9:32 AM, Vijay Bharadwaj
>>> <Vijay.Bharadwaj@microsoft.com> wrote:
>>>> I agree with Arun that we should support key neutering of some sort.
>>>> 
>>>> Keys are in fact significantly expensive objects to set up.


<snip />


>> 
>> [GCvsExpensiveResources] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16952#c2
>> [NOTransferable] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18611
>> 
> 
> Perhaps incorrectly, but I've been conceiving as Key objects as
> similar to object URIs. There are not the data in and of themselves,
> merely a promise to provide that data when needed (eg: for a Crypto
> Operation).


That seems a safe enough assumption, but just to clarify:

1. An object uri *today* is merely a string; we use the term "dereference" (for lack of a more robust term in all of HTML5) to describe how a Blob is "dereferenced" with the object uri.  

2. A Blob is a "snapshot" at a specific timestamp of a File object.  It's not the file itself.  I owe a work item to the WG to clarify this to WebApps [BlobSnapshot].

Could we be better served if the Key object in our API is conceptually closer to 2. than to 1.?  As you point out below, there's a variety of APIs, secure element semantics, etc., but what if Key is to [underlying key] just as Blob is to file reference?


> A Key object does not necessarily represent a handle to an
> underlying data store - I'm not sure that any object COULD reasonably
> guarantee such a behaviour, given the wide variance of APIs, smart
> cards, and secure element semantics regarding how many parallel keys
> they can have open at a time.
> 
> The closest the semantics of close seem to be akin to revokeObjectURL.
> However, I'm nervous comparing it to even that, since naturally one
> thinks of autoRevoke = true as part of the objectURLOptions, whereas
> I'm not sure if the same makes sense for Key objects. In particular,
> consider accessing common keys (whether window.crypto.keys or via some
> query mechanism). Unless there was a way to say "Don't auto-revoke
> THESE keys", you'd only be able to use them for a single operation,
> before you need to re-query/re-get the Key handle. Surely, that seems
> inefficient/wrong.

Well… you *could* have the conceptual equivalent of autoRevoke = false :)  

Either way, whether via autoRevoke semantics, or .close() semantics, the case for being able to make key access a no op (via the existing "in memory" objects) at some point hasn't been fully fleshed out.  Are we doing this for memory management, security, or both?  You make the case that whatever our Key object is, it's probably not terribly expensive.  Is it desirable to let it linger?


> 
> For persistent keys, the equivalent to revokeObjectURL would be the
> KeyStorage.removeKey method. It seems like that could/should be
> normatively spec'd to invalidate any references to that key (including
> any in-progress operations), trigger the CryptoOperations onerror
> handling, etc.
> 

Possible -- what's the default? :)


> For ephemeral keys, dropping the object should be sufficient -
> especially since the ephemeral keys don't live in window.crypto.keys
> (which only contains 'persistent' keys)
> 

"Dropping the object" = GC?


> As far as "spec smells" go, how does the above proposal smell to you, Arun?
> 


It has a pleasing bouquet of "possibly on the right path" to it :)

-- A*
[BlobSnapshot] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17746

Received on Tuesday, 28 August 2012 18:40:19 UTC