Re: Defining exotic objects in IDL, HTML, or both?

On Fri, Oct 16, 2015 at 8:12 PM, Bobby Holley <bholley@mozilla.com> wrote:
> On Fri, Oct 16, 2015 at 10:56 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>> E.g., that same-origin Location objects still need security checks was
>> not listed.
>
> That's a property of the Location object, not of the behavior of
> cross-origin objects.

I guess that is true, so we wouldn't want them to behave identical
under those circumstances? It's fine for the Location object to still
have "expandos", to have a prototype object of sorts, etc. And to be
clear, this is also not stipulated, cross-origin Location objects can
only come from WindowProxy, right?

Or does Chrome also consider the case where document.domain "revokes"
access and therefore document.location should return a cross-origin
Location object? (Whereas that would throw in Gecko because nothing on
document is whitelisted once it's in its security wrapper.)


>> And one of Adam's concerns was not wanting to deal with
>> non-ES5-stuff, whereas this depends heavily on proxies.
>
> I don't quite follow here. Are you saying that the only way to make this
> proposal work in an ES world is to use proxies/membranes? IIRC, Adam's basic
> position was to specify something that allowed Blink to continue its
> reference-rewriting under the hood.

Well the only way to explain it would be, yes. The proposal as-is
requires specifying exotic objects.


> The origin of the 'minting' concept was to be safe-by-default in case the
> spec missed a corner case. The idea is that the spec can offer the basic
> invariant that "No ES object from one origin should ever be exposed to
> another origin", and engines can assume that the spec will never require
> them to do that (which was important to Adam). This is less important than
> Gecko thanks to wrappes, so we ignore this under the hood. But the idea is
> that this should never be observable.

Hmm. One problem with the proposed design (assuming we're not defining
compartments in the specification) is that it overrides === which TC39
would not be happy with. Not having to do that would be preferable I
think. === works fine for Window since there's WindowProxy. It seems
like Location would need something similar.


>> (It does seem like we need multiple underlying objects to
>> deal with "expandos" properly.)
>
> There are no expandos on cross-origin objects. The thing that makes this
> tricky is the prototype chain of methods that you pull off of a cross-origin
> object.

Ah right, [[Set]] throws. But it wouldn't for a same-origin object
which is why you would want at least those to be distinct.


>> And does minting a new object
>> per-origin correctly deal with navigation, a case that is also not
>> covered?
>
> I am not aware of any problems that navigation might cause. Can you be more
> specific?

bz mentioned this. But I think what happened in his scenario was that
you'd get a reference to a WindowProxy that would end up referring to
a cross-origin Window object. So maybe that doesn't matter much.


-- 
https://annevankesteren.nl/

Received on Friday, 16 October 2015 19:58:34 UTC