Re: [CSP] PING-- CSP vs. Fetch

According to
http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0012.html, we
landed on putting Ping in `form-action` and Beacon in `connect-src`.

I kinda don't care at all, really. :) If you're happier with it under
`connect-src`, I'll move it to `connect-src`.

-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 Sat, Nov 15, 2014 at 2:18 AM, Daniel Veditz <dveditz@mozilla.com> wrote:

> In the CSP Level 2 spec PING ("hyperlink auditing") shows up under
> form-action[1]. In Fetch it's listed as connect-src[2]. Both Fetch and
> CSP2 put sendBeacon() under connect-src.
>
> Since we want to integrate CSP and Fetch the two specs should agree.
>
> [1]
>
> https://w3c.github.io/webappsec/specs/content-security-policy/#directive-form-action
> [2] https://fetch.spec.whatwg.org/#requests
>
> I could make reasonably persuasive arguments for putting either feature
> under either directive, as well as why the two should be treated the
> same or why doing so is not important. If anything sendBeacon() seems
> more "form-ish" than <a ping>. In theory putting PING under form-action
> (which does not fall-back to default-src) seems to solve backwards
> compat problems of applying CSP2 to a CSP1 page. For Gecko, at least, <a
> ping> was directly controlled by default-src in our CSP1 implementation
> so if anything moving it to form-action could reduce restrictions on
> existing pages. We doubt we'd be breaking any pages if we put it under
> connect-src.
>
> Of the two existing specs I'd personally prefer going with the current
> state of the Fetch spec. "ping" will not make authors think of forms.
>
> -Dan Veditz
>
>