Re: Spec for CryptoKey.algorithm and CryptoKey.usages doesn't really make sense

Domenic,

Sorry for the long mail; see the bit in the middle about getters 
returning the same value each time (modulo effectful sets/calls) and why 
that is or is not desirable.  That part could use input from you.

On 7/14/14, 2:06 PM, Ryan Sleevi wrote:
>     I mean, for the [[algorithm]] case it's talking about "converting
>     the interface" but there is no interface involved.
>
>
> It would help if you could clarify how you arrived at that, so that we
> can try to find language to clarify.

Well, what's stored in the [[algorithm]] internal slot is an IDL 
dictionary, right?

That's not the same thing as an interface...  I'm not sure how to make 
that clearer.

> 4. Let /algorithm/ be a new RsaHashedKeyAlgorithm

Right, which is a dictionary.

> When the /algorithm/ attribute of privateKey/publicKey is accessed,
> [[algorithm]] goes through the WebIDL conversion steps to convert a
> dictionary to an ES object.

Here's what the ED of the spec says right now:

   algorithm
       Reflects the [[algorithm]] internal slot, converting the
       interface contained within [[algorithm]] to an ECMAScript
       object, as defined by [WEBIDL].

Where in that is it made clear that 
http://heycam.github.io/webidl/#es-dictionary is what's getting invoked? 
  That's all I'm asking for here: that you s/interface/dictionary/ and 
ideally directly link to that link.  Even better would be fixing Web IDL 
to allow linking directly to the "An IDL dictionary value V is converted 
to an ECMAScript Object value" part, but that's not really under your 
control.

> In the same way that a DOMString getter returns new instances of the
> DOMString.

There is no such thing as "new instances of DOMString".  JS strings are 
values, not objects.  Two JS strings with the same string data are == 
and === to each other, and treated as the same thing by things like Set 
and Map.  So really, each get of a DOMString returns the _same_ JS 
string unless the actual string value changes.

> As for why you can't modify the resulting object

I think we're talking past each other.  Can you clearly explain what 
your mental model is here?  I'm happy to accept plain English, ES6 spec 
terms, whatever, as long as you clearly explain what behavior you 
_think_ these objects should have.

Right now nothing in the spec produces objects that "you can't modify".

> [[algorithm]] varies... depending on the type of algorithm. This seems
> like it's entirely up to the implementation to track the exact type, in
> as much as the individual sections for creating a CryptoKey detail the
> value stored within [[algorithm]] (e.g. generateKey, importKey, etc)

Sure.  The point is, it's always some dictionary inheriting from 
KeyAlgorithm, yes?

> Can you point to any explanation as to the "why"? I don't say so glibly,
> it's just that multiple people from different organizations have clearly
> different views on the "right" way to do things, and whether or not
> something is really "desired".

I'm going to pass this off to Domenic, because he's written this sort of 
thing up before and can probably just link you to it.  But the gist of 
it is that that's the behavior JS programmers expect from their objects, 
basically.

> For example, I could not find discussion that the rationale for not
> exposing dictionaries is because they create new objects

 From the horse's mouth, so to say: 
http://lists.w3.org/Archives/Public/public-script-coord/2012AprJun/0186.html

> and separately heard requests that it does create new objects (from non-Googlers, to be
> clear)

There's no issue with exposing an API that returns a new object each 
time.  It just needs to be a method, not an attribute.

> Since Web IDL declares read-only in terms of the absence of a setter
> (and a possible TypeError), it seems that B is the only option that
> matches Web IDL.

No, any of those options are fine in Web IDL.  You're confusing whether 
there is a setter on CryptoKey that would allow you to affect what sort 
of thing .algorithm involves (or which object it returns), and what the 
behavior of setting properties on the thing returned from .algorithm is. 
  We all agree CryptoKey should have no setter for this property.  We're 
disagreeing about what the getter should return.

>         As currently written, they store IDL objects
>
>     As currently defined, nothing says what they store.
>
> Please qualify. As with the above example of RSA-SSA, this is
> documented. If you feel it should be documented elsewhere as well, it
> would be good to note.

See above for where I think it should be documented.  But also, right 
now this is basically defined via "it stores whatever it stores".  And 
what's stored in the places that store to it is not "IDL objects" but 
"IDL dictionaries" and "IDL sequences" (for [[algorithm]] and [[usages]] 
respectively).

I do think it's important to say what sort of things are stored in here, 
instead of just saying "well, it has something, and what it has will 
depend on who sticks what in there", because that makes it much easier 
to check whether algorithms operating on the slot, which includes the 
things setting it, make sense.

>     ImageData is perfectly well defined.  Structured cloning of
>     ImageData explicitly creates a new one that has the same width and
>     height and then structured clones the Uint8ClampedArray.  Structured
>     cloning of Uint8ClampedArray is also clearly defined, so there is no
>     problem.
>
> No, it's really not, at least not by the same criteria you're holding
> Web Crypto to.

Which part of 
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data 
is not clear?  Just for reference, it says:

   If input is an object with a [[DataView]] internal slot

     Let output be a newly constructed object of the same class as
     input, with its [[DataView]] internal property present, its
     [[ViewedArrayBuffer]] internal property set to the value obtained
     from invoking the internal structured cloning algorithm recursively
     with the value of the internal property on input as the new "input"
     argument and memory as the new "memory" argument, and with the
     [[ByteLength]] and [[ByteOffset]] internal properties set to the
     same value as their counterparts on input.

If Web Crypto defined its structured cloning for the non-JS things it 
wants to structure clone at this level of detail, I wouldn't be 
complaining about it at all!  Note that the above depends on the 
definition of structured cloning for for an ArrayBuffer, but that too is 
defined pretty clearly.

> In this case, ImageData.width, .height, and .resolution are all
> read-only attributes. In the same way that CryptoKey.algorithm is
> read-only - although perhaps even less.
>
> That is, as far as I can tell, the .height attribute is created by a
> defineOwnProperty(P, descriptor{ [[value]]: V, [[Writable]]: true,
> [[Enumerable]]: true, [[Configurable]]: true}).

Ah, I see your concern.  So this _is_ one place where the HTML spec is 
less precise than it could be.  In this case, it's talking about the 
width and height internal slots, not actual JS-exposed properties of any 
sort.  You're correct that this could be made clearer, and it should be; 
we've learned a bit about spec writing since that text was written.

Nevertheless, even though these are not called out as internal 
properties, that is what they are.

> Now, we can argue that's not a reasonable read of the spec, or not the
> intent, and I agree. And however ImageData (and friends) solve this
> issue

They don't solve the issue of clearly distinguishing internal properties 
from JS-exposed properties.  They should be changed to do so.

> But it doesn't seem like there is a clear consensus yet on the answer to
> this?

I think there is.  Just needs editorial bandwidth.

> So, while I'm sure these comments are borne out of genuine frustration
> and real issues, it doesn't really help, and highlights what I mentioned
> above, which is that various specs are in various degrees of being 'in
> vogue', or that different people perceive different answers.

I don't think there's any disagreement on how ImageData should behave 
when cloned, if that's what you're saying.

> So naturally, on the Web Crypto side, it's equally frustrating that there's
> no "right way" to do this.

I think the right way to define structured cloning is as follows:

1)  Delegate to the generic algorithm for any values already covered by 
it (e.g. typed arrays, strings, plain objects, etc).

2)  Clearly define cloning behavior for any object that has a special 
set of internal slots.  This cloning behavior needs to define what to do 
for the value in each slot.

-Boris

Received on Monday, 14 July 2014 19:17:12 UTC