Re: Exposing constructors of readonly interfaces to web authors

I must take a moment a pedantic point:

    LargeRandomNumber() !== LargeRandomNumber()

is true with high probability, since a large, genuinely random number is
unguessable.

    {} !== {}

is true on actual hardware, still only with high probability, since
hardware may have undetected errors. Given that the random numbers above
were truly random and large enough, the probability of an undetected
hardware failure is even larger than the probability of an innocent numeric
coincidence.

However, the latter expression is necessarily true within the programming
language's formalism. This makes it unforgeable.

The most salient difference between the two is that unguessable secrets can
be leaked over bit-only channels. Object references cannot. In memory-safe
languages, covert channels can only transmit bits, not object references.
Access to a secret is knowledge limited. Access to an object reference is
not.




On Fri, Jun 27, 2014 at 6:39 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> From: annevankesteren@gmail.com [mailto:annevankesteren@gmail.com] On
> Behalf Of Anne van Kesteren
>
> > The way Domenic explained this the last time around was that certain
> constructors would accept an ID of sorts as argument that only the UA would
> know about.
>
> > Given that explanation, I don't see the problem throwing for these
> constructors, just like we throw for
>
> >> new Navigator
> >> new Window
>
> To be clear, here is the code you would have to write to explain this in
> JavaScript:
>
> ```js
> var unguessableSecret = generateSecret();
>
> class DOMRectReadOnly {
>   constructor(x, y, width, height, secret) {
>     if (secret !== unguessableSecret) {
>       throw new TypeError("Only UAs can construct DOMRectReadOnlys!");
>     }
>     ....
>   }
>
>   get x() { ... }
>   ...
> }
> ```
>
> But this is just silly in the case of DOMRectReadOnly and friends. There
> is no magic data, like a browser-internal representation of a window or
> navigator, or of a crypto algorithm (see
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#dfn-CryptoKey-slot-handle),
> which cannot be used by a user. You are instead just artificially limiting
> users for no good reason, by not giving them the unguessable secret.
>
> This has no benefits, since it does not enable implementations to do
> anything special with e.g. object layout or tying it to special object
> pointers. It has only downsides.
>
> From: Dirk Schulze [mailto:dschulze@adobe.com]
>
> > My concern is that we expose functionality that might not be used by
> authors (creating a readonly object that even the creator can not modify).
>
> Why is the DOM creating a readonly object that even the DOM cannot modify?
> Or is the DOM somehow able to modify these objects? I notice that despite
> there being no setter for x, y, width, and height, the spec says things like
>
> "The x attribute, on setting, must set the x coordinate to the new value."
>
> Since you can't set a readonly attribute, this is just a bug in the spec
> as it stands.
>
> The question is whether the intention was to allow the DOM to modify the
> object, in which case they would do so via mutable internal slots that the
> x, y, width, and height public getters return the value of, or whether the
> intention was for these objects to be immutable after creation. (Again, for
> an excellent example of this, see WebCrypto, e.g.
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#cryptokey-interface-members
> where the getters are specified.)
>



-- 
    Cheers,
    --MarkM