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

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

--- Comment #29 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Boris Zbarsky from comment #28)
> > I don't understand why we'd Object.freeze if doing a [[usages_exposed]]
> 
> Actually, I just realized that we (Mozilla) do in fact want to Object.freeze
> here.  We're doing it now and will likely continue to do so for the
> foreseeable future.
> 
> The reason is to handle the case of security proxies that are supposed to
> provide an "unmodified" view of an object.  For types defined in Web IDL
> this is simple: the proxy knows what things are supposed to be on the
> prototype by default and makes sure to only expose those things on the
> object.  But for ES types like Array, that doesn't really work.  The proxy
> can guarantee that you get the right array object, but not that its contents
> haven't been messed with by the page.  Freezing the array, on the other
> hand, guarantees the latter property, allowing the proxy to work correctly.
> 

Boris,

As discussed in the F2F, can you provide any example of any other Web Platform
API that uses Freeze? Part of the objection here to freezing is about matching
developer expectations through consistency of the platform, rather than
implementor preference.

Absent some TAG push for it (ala Promises), my inclination is that freeze is
the wrong thing here precisely because it violates developers expectations
compared to other objects - the huge number of interfaces with "readonly
attributes" that fundamentally aren't readonly seems a prime example of this.

http://w3c.github.io/deviceorientation/spec-source-orientation.html#devicemotion
(readonly attributes in DeviceMotionEvent that aren't)
http://w3c.github.io/performance-timeline/#sec-PerformanceEntry-interface
(readonly attributes for name/entryType that aren't)
http://w3c.github.io/dom/#interface-event ( readonly attributes for type that
aren't)

Note that the reason I say that "they aren't" is that even though Web IDL
requires an error be thrown on mutation (
http://heycam.github.io/webidl/#dfn-read-only ), you can certainly mess with
the String.prototype.

I can see there's bikeshed elsewhere (e.g.
http://w3c.github.io/webappsec/specs/content-security-policy/#dom-securitypolicysourcelistdirective
/
http://w3c.github.io/webappsec/specs/content-security-policy/#dom-securitypolicy-directives
), but it's also inconsistently applied in other specs (for example,
http://w3c.github.io/webrtc-pc/#idl-def-RTCPeerConnectionIceEvent - 'candidate'
is a readonly attribute of type RTCIceCandidate, which itself is an interface
with non-readonly attributes)

My utmost goals are to
1) Match consistency with developers' expectations
2) Do the right thing

Yes, that's a nasty ordering, but I don't see how I can do otherwise, given
http://www.w3.org/TR/html-design-principles/#priority-of-constituencies ,
until/unless we make a coordinated effort to ensure "Do the right thing" also
"matches consistency with developers expectations"

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

Received on Saturday, 8 November 2014 02:55:56 UTC