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

On 7/14/14, 4:03 PM, Domenic Denicola wrote:
> 1. Lock down the objects. This only works if they are truly immutable (not just readonly), but from a brief glance at the spec, that appears to be the case? In that case, you can store a frozen object in the internal slot, which is tamper-proof against consumers, and just return that same frozen object every time, while also consulting it internally.

This is doable, but you have to be very careful.  For example, if this 
object can ever have properties not be set, you have to make sure to 
either create it with a null prototype or make sure all your operations 
on it don't consult the proto chain (e.g. getOwnPropertyDescriptor 
instead of "in" checks no [[Get]] ever, and so forth).

> This strategy seems a bit overcomplicated because WebIDL only supports getters, leading to [[algorithm]] + [[algorithm_exposed]] + algorithm getter.

For what it's worth, with Gecko's extensions to WebIDL this would be 
implemented as:

   [Constant, Cached] readonly attribute object algorithm;

(and the only reason it's "object" is because it's polymorphic in the 
type of dictionary it returns; if it only returned one kind in this 
special [Cached] case Gecko would let you use a dictionary type).  That 
moves the "exposed" internal slot effectively into the binding layer, 
out of the prose...

That sort of thing hasn't been adopted for IDL in general yet, sadly, so 
it's a bit more complicated to do right now.  :(

> In normal JS usage you would probably just do [[algorithm]] + an exposed algorithm data property.)

Indeed.  We should seriously think about adding data properties to IDL 
at some point, but that doesn't help us for now.

> 3. Bulletproof your spec algorithms against mutations to the object

This is not workable in this case, because the internal object, or its 
clone, needs to be accessed from other threads or other processes.  Thus 
we need to either have it be completely immutable or define points at 
which we take snapshots of it to pass to the async processing or 
something.  Having it be completely immutable is much saner and less 
likely to lead to weird races in both the spec and implementations.

> since I really think we have run up against a place where the path of least resistance in WebIDL (a bunch of algorithm classes) is a very bad path.

I would be interested in your take on 
<http://lists.w3.org/Archives/Public/public-script-coord/2014JanMar/0201.html> 
(and note that in this case some of the dictionary members are 
themselves KeyAlgorithm instances or other objects, so the comparison is 
not completely misplaced).

-Boris

Received on Monday, 14 July 2014 22:41:23 UTC