Re: CSP 1.1 DOM design

On Mon, Nov 5, 2012 at 7:40 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 11/5/12 1:08 PM, Alex Russell wrote:
>
>>     If you want to allow writing to these things sometimes but not
>>     others while making it look like normal ES semantics, things are a
>>     bit complicated because of strict mode.
>>
>> Why strict mode? I'm not sure that matters.
>>
>
> WebIDL lets you define an attribute as either writable or readonly.
>
> If it's readonly, attempts to set are ignored in non-strict mode and throw
> in strict mode.
>

I see, it's the defineProperty() behavior.


> If it's writable, attempts to set call an IDL setter, which is in theory
> language-independent and thus has no concept of strict mode.
>

It's possible to model this the other way: it calls a JS setter which may
throw or call an IDL setter. I don't know the implications for legacy there.


> Note that a pure-JS implementation would have the same problem, by the
> way; the only way I know of to implement something like this in JS is to
> have two prototypes, with the property having no setter on one and a setter
> on the other, and have your objects inherit from the right prototype.
>  Unless I'm missing something.


See the proxy thing below.


>  Cameron: my view here is that the document.securityPolicy would be
>> defined as a getter that returns a Proxy (in ES6 terms) and that the
>> proxy would enforce the read-only invariants. It would be proxying for a
>> "naive" SecurityPolicy object.
>>
>
> Wait.  Why would we want a proxy there instead of just an object?


To preserve the invariants...I suppose without the overhead of having to
define a brand new type since it's a one-off.


>  That seems like proxy-happiness at the expense of other things...  What
> does using a proxy instead of a separate interface for writable security
> policies buy you, exactly?  What it loses you is basic things like sane
> instanceof behavior, afaict.


I think that's a dated understanding of proxies. The current Direct Proxies
proposal applies instanceof to the target, which in my proposal would be a
regular SecurityPolicy object:

http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies


>      There is no way to return a JS array that points directly into the
>>     stored state of an object in WebIDL right now.  Again, because we
>>     want to allow implementing the DOM in a language other than JS while
>>     remaining sane.
>>
>> Sane for whom? ;-)
>>
>
> The implementor.  ;)


My sympathy is limited = )


>  The goal of language fidelity isn't some abstract notion.
>>
>
> Sure it is.  It means different things to different people.  A concrete
> notion would be an actual description of the behavior.


As I suggested before, the exercise here should be to write down the
behavior you want in JS and then transcribe it back to IDL. I'm
implementing a SecurityPolicy class right now and can post it for review
when it's done.


>  That said, WebIDL can do magic.
>>
>
> Within reason, sure.  There have been proposals that were shot down
> because they're no implementable in ES.
>
>
>  If it's doing magic, it should do magic
>> on behalf of JS users today, even when JS isn't sane enough to explain
>> it all.
>>
>
> Sure, as long as there's an actual spec, not handwaving.
>
> -Boris
>