W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

Re: CSP3: DOM API Strawman

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Wed, 5 Nov 2014 20:46:32 -0800
Message-ID: <CAPfop_0sBUhN9WbJP=BM1N1PPGmf9jna3CB=ZDXTK7g+OF=PyQ@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-webappsec@w3.org" <public-webappsec@w3.org>
I agree with the extensible web ideas, but I guess I am confused how
the proposed API helps solve the issues bought up by Alex and Yehuda?

For example, both use words that ask "how does it help implement new
rules without waiting for browsers/specs to evolve?" Can you provide
an example?

On 4 November 2014 12:16, Mike West <mkwst@google.com> wrote:
> 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
>> >
>
>
Received on Thursday, 6 November 2014 04:47:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC