Re: CSP3: DOM API Strawman

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