Security wrappers and whatnot

[Boris Zbarsky]

I was talking to bholley today, and he raised the question of how we
plan, in our proposed dom.js+binarydata setup, to do things like
XrayWrapper.

The answer to that probably depends at least in part on how we recognize
"our" DOM objects.

-Boris

[Niko Matsakis]

What precisely is an XrayWrapper?


Niko

[Boris Zbarsky]

It's a JS proxy that wraps a DOM object and provides and "unadulterated"
view of it. That is, it ignores any custom properties that got defined
on the object by the web page and only sees the properties that should
be there per the IDL.

These are necessary any time extension code or browser code operates on
a content JS object.

-Boris

[Niko Matsakis]

On 3/28/12 11:57 AM, Boris Zbarsky wrote:
> It's a JS proxy that wraps a DOM object and provides and
> "unadulterated" view of it. That is, it ignores any custom properties
> that got defined on the object by the web page and only sees the
> properties that should be there per the IDL.
>
> These are necessary any time extension code or browser code operates
> on a content JS object.

I don't see any particular difficulty in implementing a similar proxy
scheme, so long as the only access to this proxy is from the "JS" task.
It seems like this proxy would just access the "JS version" of the DOM's
data (i.e., the writable version), filtering out data it doesn't want to
present as normal.


Niko

[Boris Zbarsky]

On 3/28/12 12:23 PM, Niko Matsakis wrote:
> I don't see any particular difficulty in implementing a similar proxy
> scheme, so long as the only access to this proxy is from the "JS" task.

That would be the case, yes.

> It seems like this proxy would just access the "JS version" of the DOM's
> data (i.e., the writable version), filtering out data it doesn't want to
> present as normal.

Hmm. We really don't want to write the DOM impl twice, is the point...

-Boris

[Niko Matsakis]

On 3/28/12 11:01 PM, Boris Zbarsky wrote:
>
>> It seems like this proxy would just access the "JS version" of the DOM's
>> data (i.e., the writable version), filtering out data it doesn't want to
>> present as normal.
>

> Hmm. We really don't want to write the DOM impl twice, is the point...

Ah, I see. These seem like a classic candidate for auto-generation to
me. What do we do today?


Niko

[Boris Zbarsky]

What we do today is that the proxy knows how to get the real JSNatives
for the relevant properties without going through any objects exposed to
page JS, and makes direct calls into those JSNatives.

The hard part in the dom.js setup is getting one's hands on the
unadulterated code for making the actual change...

-Boris