Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)
brendan at mozilla.com
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 mozilla.com
> <mailto:brendan at mozilla.com>> 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.
> 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
> [[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]]
> I don't understand the contract-obeying spoofing scenario you have in
See the latest draft: 126.96.36.199 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