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

On Mon, Jul 14, 2014 at 1:21 PM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

>  (I cannot seem to post to the list, as I am not a working group member,
> FYI.)
>
>
>  I would not give up on 2 just yet. I agree that it is not obvious how
> this should be done, and that other specs aren't helping. But as a first
> stab, you could store [[algorithm]] and [[algorithm_exposed]] both as JS
> objects, and say that structured clone only clones [[algorithm]]. Even
> though [[algorithm]] is a JS object, it should be safe to touch from the
> spec at all times, since users never get access to it.
>
>
>  It's true that modifications to the global Object and Object prototype
> would affect it, but I don't think they could break anything, as long as
> the spec does nothing more than getting a predefined set of own-property
> values. (Getting *arbitrary* properties is dangerous, since that falls
> through to Object.prototype, but if the object is guaranteed to have an own
> .hash property as a result of the structured clone, then `var hash =
> obj.hash`, or its spec equivalent, should be safe.)
>
>
>  If you can let us know what general approach you think would be good, I
> at least am happy to
>

Considering that the whole point of [[algorithm]] is to make it easier for
the Web Crypto spec to define it's processing algorithms in terms of
invoking getters on [[algorithm]]. If [[algorithm]] contains a JS object, I
do not see how we can (safely) invoke the Getter at any point during a
promises' asynchronous execution in a way that is undetectable, which I
consider an essential property for the Promise code (and, more generally,
to the concept of the immutability of [[algorithm]] from the POV of script
authors)

That's why I don't see it being possible for [[algorithm]] to sanely hold a
JS object.