Mark S. Miller wrote:
On Mon, Oct 1, 2012 at 9:02 PM, Brendan Eich <bren...@mozilla.com
<mailto:bren...@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.
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
"~"-prefixing!
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: 15.2.4.2 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
sure....
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?
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
