Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

Brendan Eich brendan at
Mon Oct 1 21:55:00 PDT 2012

Mark S. Miller wrote:
> On Mon, Oct 1, 2012 at 9:02 PM, Brendan Eich <brendan at 
> <mailto:brendan at>> wrote:
>     Mark S. Miller wrote:
> [...]
>         Relaxing this requirement would still technically be a
>         breaking change from ES5 so we need to be cautious. But I bet
>         we can get away with it if we do it by ES6. By ES7 it will
>         probably be too late.
>     I doubt it'll be too late. In part I am skeptical because I do not
>     believe any engine actually prevents host objects from spoofing
>     the 13 class names listed above. Anyone know of an engine that does?
> host objects are part of the TCB. There's no enforcement needed; an 
> engine running a malicious host object is already toast. What's 
> required is that host objects not do this, not that engines prevent 
> them from doing so.

Agreed, but that's not consistent with the "~"-prefixing.

>     Words on paper still carry force but they do not necessarily have
>     prompt effects, or any effects. It depends on the people reading
>     them and implementing, and trying to follow the rules. Those
>     people are much more likely to audit their (closed, per release,
>     typically) set of host objects and fix any spoofers.
> I think we're agreeing but for one thing. The force of a normative 
> specification is that violations can be added to test262, so that they 
> stand out like a sore thumb, putting pressure on the violator to fix 
> it. We already did this successfully with one host object violation.

Agreed again.

>         If a host function satisfies *all* the observable requirements
>         of a native one, then it is simply misclassified. It *is* a
>         host-provided *native* function and should have a [[Class]] of
>         "Function".
>     [[NativeBrand]] -- but then there's no spoofing issue.
>     The anti-spoofing defense in ES5 was advisory.
> It was most certainly not. It was and is normative.

Apologies, I misspoke -- "advisory" was my attempt to say that prose in 
Clause 15 intro asserted something to secure by auditing -- not by 

Perhaps normative-audit-based vs. normative-runtime-check-based? Argh.

>     Now we have a tiny bit of "~"-prefixing mandatory specification,
>     but predicated on (still using the old terms) "native" vs. "host"
>     object classes, the [[NativeBrand]] test for the former and
>     @@toStringTag for the latter (with "~"-prefixing for the 13
>     names). I think this is the wrong direction.
> Agreed. I think the "~" thing is terrible.

Good to discuss it, then.

>         (Allen, thank you for getting us away from this awful "host"
>         and "native" terminology!)
>     Are "ordinary" and "exotic" any better or worse? A rose by any
>     name would smell as sweet, a host-rose as sour.
> It's hard to do worse than "native" and "host", but I don't like 
> "ordinary" and "exotic" either. Time for more bikeshedding ;).

Best if we can get the differences down to what a Proxy can do!

>     But the @@toStringTag idea is a win. Why not use it uniformly, tag
>     all the natives and use advisory language to require that only
>     implementation(s) of objects that satisfy, e.g., the function
>     contract, can use "Function"?
> Again, if it satisfies the function contract, then it *is* a function, 
> so even by ES5's normative requirements, it should have [[Class]] 
> "Function".
> I don't understand the contract-obeying spoofing scenario you have in 
> mind.

See the latest draft: Object.prototype.toString does that 
"~"-prefixing only for a host object trying to tag itself as a 
"Function". If such a host object existed (let's say the implementation 
had good reason not to use a native function, perhaps due to some legacy 
DLL extension mechanism compatibility) and the host object indeed 
satisfied the function object contract, ES6 as drafted would prefix a 
big ugly "~" on "Function"!

Seems like a problem, in theory. Of course I am contriving the "host 
object emulating a native function" case -- or am I? IE with COM? Not so 

>     And I'm really asking whether, should we fail to agree on a less
>     mandatory and hacky solution than "~"-prefixing, we will end up
>     needing to enlarge the blacklist from 13 names to more.
> I don't think so but I'm not sure. Do we have a consolidated list of 
> the new builtin contracts, so that we can look at these on a case by 
> case basis?

We have a spec, it's about as good as one can hope for right now, and 
getting better for ES6.

Did you have a more detailed or differently-formulated spec than ES6 
draft, clauses 13 and 15, select parts?

>     Don't you have to use tag-testing on DOM objects in SES?
> Not when Caja is used together with SES. With Caja+SES, only Domado 
> ever gets direct access to a DOM object. All other code only gets 
> Domado-created wrappers. Domado itself is careful never to confuse 
> itself about when it is dealing with a DOM object vs something else. 
> To pull this off, Domado does brand its own wrappers so it can 
> recognize them when they're presented as arguments.

Cool. Using a WeakMap in latest browsers?

> To date, the only use of SES without the rest of Caja has been outside 
> the browser, where there are no DOM objects.

Ok, well how about SyntaxError, EvalError, and the other *Error names 
not in the drafted blacklist?


More information about the es-discuss mailing list