- From: Wendy Seltzer <wseltzer@w3.org>
- Date: Tue, 29 Jul 2014 12:04:53 -0400
- To: Christine Runnegar <runnegar@isoc.org>, Nicholas Doty <npdoty@w3.org>
- CC: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Hi Christine and PING, Are you planning to submit these today? Good discussion in Toronto! A few additional thoughts: On 07/14/2014 09:00 PM, Christine Runnegar wrote: > Thank you sharing these preliminary notes Nick. > > The deadline for review is 29 July 2014. > > As this falls before our next PING call, we will need to finalise our input via this email list before sending it on to the Web Performance WG. > > Has anyone else had an opportunity to review this draft specification (http://www.w3.org/TR/beacon/)? > > Christine and Tara > > On 13 Jul 2014, at 7:01 am, Nicholas Doty <npdoty@w3.org> wrote: > >> Hi public-privacy, >> >> I mentioned on the last teleconference that I had started to read over the Beacon document, which is currently at Last Call status in the Web Performance Working Group, and might have relevant privacy/security questions for us to comment on. The notes below are very rough and early notes, so please forgive my ignorance and brevity. Nonetheless, I would certainly welcome your thoughts; expertise with CSRF attacks or the CORS specifications would be most useful in analyzing the security implications. >> >> Thanks, >> Nick >> >> >> In brief, I believe Beacon is a tool to enable sites to request that the browser asynchronously POST some analytics data collected while on the site after the page has unloaded. I would recommend that the spec include a "Privacy Considerations" discussion that addresses these issues. In addition, should the sending of beacon data be capable of being disabled by the user (independent of disabling all JS)? Is there a recommendation for how this data is handled when a user has toggled Private Browsing/Incognito mode? (Alternatively, sites now sometimes delay unloading the page in order to send back click information and the like.) >> >> ## 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? >> >> ## security considerations and CORS >> >> What are the security considerations of this document? 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.) Are cross-origin POST requests with credentials necessary to satisfy the purpose of the Beacon specification? If not, why add the 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? >> Is there an origin-restriction on the POST URL? Should one be recommended? (That may be hidden in the Fetch or URL dependency...) >> ## editorial comments >> >> Some requirements are placed on "the User Agent" and others on "user agents"; consistency would be better. >> >> Sections 1 and 4.1 (both Introductions) seem duplicative. In both cases, this sentence is first: >>> The Beacon specification defines an interface that web developers can use to asynchronously transfer small HTTP data from the User Agent to a web server. >> >> Nothing in the specification limits the size of the data sent. In fact, analytics data aggregated over an entire session (since unloading seems like the primary use case) might be quite large. >> >> I think it would be more correct to refer to transferring data via HTTP rather than "HTTP data". >> >> Web developers already have interfaces for asynchronously transferrring data via HTTP. For example, XMLHttpRequest, as you note. Perhaps a better summary would be: "This specification defines an interface that web developers can use to asynchronously transfer data from the user agent to a web server during or after the unloading of a page." > > Thanks! --Wendy > -- Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office) Policy Counsel and Domain Lead, World Wide Web Consortium (W3C) http://wendy.seltzer.org/ +1.617.863.0613 (mobile)
Received on Tuesday, 29 July 2014 16:04:57 UTC