WebIDL attribute reflection

Brendan Eich brendan at mozilla.com
Sat Dec 29 13:03:29 PST 2012


David Bruant wrote:
> Boris, what initially triggered my questioning of the inherited 
> accessor setting is in this message: 
> https://mail.mozilla.org/pipermail/es-discuss/2012-December/027435.html
> Mostly concerns about a mix of API "securability" and convenience. I 
> "demonstrate" that if every attribute is an inherited accessor, then, 
> it's possible to secure the environment, but it can be at the expense 
> of API usability up to asking people to tweak their code (which is an 
> anti-goal when trying to secure your code from, say, an advertiser's 
> code)

Can you give an example?

Ads loaded via cross-site script src= need defense at a lower depth, 
without any code changes, by giving them a distinct trust label from the 
including page's label. I proposed this at AppSecUSA (while jetlagged 
from travel from London through Austin to NYC on the eve of Hurricane 
Sandy :-P). More to say when there is time, but the idea is to let the 
VM distinguish ad code from page code and let CSP enforce finer-grained 
policies via membranes (in-process, no inversion of control flow -- see 
Alex Russell's question if the Q&A made the video).

> Le 28/12/2012 22:18, Boris Zbarsky a écrit :
>> On 12/28/12 12:31 PM, Boris Zbarsky wrote:
>>> When we have gets through a proxy down in the 20-30 cycle range on
>>> modern hardware, I'm happy to talk about proxies performance-wise.  ;)
>>
>> One other note.  I'm somewhat sympathetic to the argument that the 
>> spec could describe things as proxies while actual implementations 
>> then implement them however the heck they want under the hood.
> I was half-clumpsy (I mentioned "An ES6 proxy-based implementation" by 
> mistake), but it was what I was asking for. That's what I tried to 
> express when I wrote "Using ES6 proxies semantics to explain own data 
> properties in WebIDL would..."
> From the beginning, I wanted to have a spec/semantics discussion. 
> Implementations are free to do whatever they want as long as the 
> observable behavior is conformant.

That's all true of any spec: semantics deal in observables, all else is 
open to radical re-implementation and optimization.

If I understand the rest of your post, you propose that WebIDL-based DOM 
specs could use a direct proxy with a certain handler sub-spec, 
unobservably, to create the same observable semantics that native C++ 
DOM implementations present? That is interesting. We'd need to work out 
the details. Go! ;-)

/be



More information about the es-discuss mailing list