WebIDL attribute reflection
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:
> 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
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! ;-)
More information about the es-discuss