Re: CSP3: DOM API Strawman

http://extensiblewebmanifesto.org/

http://yehudakatz.com/2013/05/24/an-extensible-approach-to-browser-security-policy/

http://infrequently.org/2013/05/use-case-zero/

:)

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Tue, Nov 4, 2014 at 8:50 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> Is there a discussion or design document about what sort of problems
> the DOM API is trying to solve? For example, as a CSP user, I would
> love to be able to modify the policy. This doesn't seem to address
> that right now. What it does address is "will this request succeed";
> but given the ViolationEvent Interface, isn't that really easy to
> check -- just try to make the request and see if the violation event
> is thrown?
>
> --dev
>
> On 3 November 2014 11:46, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > On 11/3/14, 8:59 AM, Mike West wrote:
> >>
> >> It would be good to be able to walk through the
> >> list with a `forEach` in order to determine whether a specific Request
> >> or Node matched an item in the list.
> >
> >
> > Sure, but matchesNode is only exposed on two of these interfaces, right?
> > And matchesURL on the third one?  And then have nothing else in common.
> >
> > I think having a common ancestor is fine, but a union type would be fine
> in
> > this case too.  If there were a common method, of course, the common
> > ancestor interface would definitely be what we want.
> >
> > -Boris
> >
>