Re: [Beacon] Last Call comments re: privacy and editorial suggestions

On Tue, Jul 29, 2014 at 3:39 PM, Nicholas Doty <npdoty@w3.org> wrote:
> Hi Web Performance Working Group,
>
> I wanted to provide a few comments on the Beacon API during your Last Call review. The comments below were shared with and informed by discussions among the Privacy Interest Group, but please assume that any mistakes or misunderstandings are mine entirely.
>
> I'd be happy to talk further about these questions and comments if that would be useful for you all. And I know the Privacy Interest Group [1] folks have been interested in conversations with the Web Perf WG in the past and might provide further expertise.
>
> Thanks,
> Nick
>
> [1] http://www.w3.org/Privacy
>
>
> ## must honor headers?
>
>> User agents MUST honor the HTTP headers (including, in particular, redirects and HTTP cookie headers),
>
> This seems to be new in this version of the spec and I don't understand the reasoning behind it. Why MUST user agents honor all response headers? If (as I believe most user agents do) a user agent typically ignores Set-Cookie headers from different origins, is that user agent non-conformant with Beacon? This requirement seems unlikely to be followed, as it would introduce privacy risks.

Agreed. The language here should be improved.

> ## security considerations and CORS
>
> What are the security considerations of this document? Is there an origin-restriction on the POST URL?

No.

> Should one be recommended?

IMO no.

> Does making background POST requests to other origins including sending credentials provide an increased risk of CSRF attacks? (Maybe this risk is identical to the existing risk of submitting POST forms to other origins.)

The risks is identical to existing <form> posts as well as existing
cross-origin XMLHttpRequest usage.

> Are cross-origin POST requests with credentials necessary to satisfy the purpose of the Beacon specification?

It's always hard to talk in absolutes. But I'd say it's "highly
desirable" to allow cross-origin POSTs. And no downside.

> If not, why add the attack surface? I understand the group has already discussed using POST vs. GET, even though this is a request that may be repeated under error conditions. But use of POST also expands the methods attackers have for conducting CSRF attacks, since many server operations will require POST.

See above. There's no added attack surface.

> The CORS specification is listed in the References, but doesn't seem to be referred to in the text of the specification. Are user agents intended to follow the CORS cross-origin request model when making a beacon request to a different origin? If so, is preflight required because of the non-simple Beacon-Age header?

I think CORS is indirectly used by invoking the fetch spec. I guess
that means that we could remove the reference to the CORS spec
entirely. I don't feel strongly.

/ Jonas

Received on Tuesday, 29 July 2014 23:12:10 UTC