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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
