[Bug 26322] Definitions "algorithm" and "usages" properties of CryptoKey make no sense

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26322

--- Comment #23 from Mark Watson <watsonm@netflix.com> ---
(In reply to Ryan Sleevi from comment #22)
> (In reply to Mark Watson from comment #21)
> > It seems that my proposal in comment#11 would work after all, modified by
> > Boris's comment that the [[usages]] Array should be constructed from an IDL
> > sequence and that we should recursively freeze members of the [[algorithm]]
> > that are themselves objects.
> > 
> > Ryan's concerns were that creation of the objects or internal access to them
> > could have side-effects, but this is not the case if they are created from
> > IDL objects / sequences (respectively) and immediately frozen.
> > 
> > Any objections ?
> 
> To reiterate, I don't think your solution works. That is, having security
> checks gated on ES objects, versus internal objects, frozen or not.
> 
> The advice of the TAG, and our folks, was that if we're making internal
> decisions based on the state of the objects - and we are - then it shouldn't
> be exposed using ES objects.

Can you explain why, or point me at the advice ? Based on the discussion above,
reading from the objects has no visible effects. Or is that wrong ?

I certainly see the problem in the case of objects where the prototype may be
or may have been modified, since script functions on the prototype may be
called as a result of the access (if it is through accessor properties). But
that is not the case here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 22 October 2014 22:42:07 UTC