On Tue, Jul 29, 2014 at 3:39 PM, Nicholas Doty <[email protected]> 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
