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

Mark S. Miller erights at
Mon Oct 1 21:26:12 PDT 2012

On Mon, Oct 1, 2012 at 9:02 PM, Brendan Eich <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.

> 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.

>> 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.

> 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.

>  (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 ;).

> 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.

>      I asked a question aimed more directly at you up-thread: why
>>     should *only* the above 12 or 13 names be subject to
>>     "~"-prepending when returned from an object that lacks
>>     [[NativeBrand]]? Are there not host objects in need of protection
>>     from class-spoofing?
>> In the ES5 timeframe, there were hard limits on how much cleanup of host
>> objects we could do before finalizing the spec. Given the constraints, I
>> think it's miraculous that we cleaned them up as much as we did. There is
>> one form of spoofing protection that we did enforce by these rules for host
>> objects, they cannot pretend to be native objects, and no native object can
>> pretend to be a host object.
> You guys did make some good moves, but that was then. I would like us to
> go farther, but not in the mandatory-classname-rewriting-**list direction.


> 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?

> 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

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

> /be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list