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

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

--- Comment #32 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Boris Zbarsky from comment #30)

> We'll continue to ship this with frozen arrays until we figure out a way to
> make them mutable that doesn't introduce security bugs from our point of
> view, I guess.  We have some ideas for how to maybe make it work, but no ETA
> on when we might be able to do it, so given the choice between not shipping
> webcrypto at all and shipping with frozen arrays here, frozen arrays it is.

I'm definitely concerned here to understand what "security bugs" you see?

>From the discussion at the F2F, the proposed resolution was to embody in the
spec (via internal slots) what UAs do today for most web APIs (DOM being a
special case in so many ways).

That is, there is a 'canonical' internal slot that contains the true value
(e.g. what is used for all security checks), that is never exposed to callers.
There is a 'cached' slot that contains the external value, which is exposed to
callers, and follows all the normal "You can mess with this object in weird
ways if you're weird" that things like WebRTC demonstrate, but without
affecting the internal state/security checks.

Yes, it means that an object may 'lie' to an user, even if it doesn't affect
the internal operation. However, an object can be made to lie many ways
(Prototypes being the canonical way, even for Built-ins), and it seems like
it's one of those things that is expected of the platform, even if it's "weird
and smelly".

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

Received on Saturday, 8 November 2014 03:09:56 UTC