W3C home > Mailing lists > Public > public-web-security@w3.org > November 2012

Re: CSP 1.1 DOM design

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 05 Nov 2012 14:40:12 -0500
Message-ID: <5098161C.2030508@mit.edu>
To: Alex Russell <slightlyoff@google.com>
CC: public-web-security@w3.org, Cameron McCormack <cam@mcc.id.au>
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.

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.

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.

> 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?  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.

>     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.  ;)

> 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.

> 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
Received on Monday, 5 November 2012 19:40:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 5 November 2012 19:40:44 GMT