Spam avoidance mechanism

[dcreager]

In today's WebPerf WG call, @yoavweiss asked about how we can tell apart valid report uploads from fake ones. We should figure out how to prevent a spam problem like you get with (for instance) Google Analytics: right now, anyone can get the report upload instructions for a particular origin (just GET any page on that domain and look at the Report-To response header), and can then blast away uploading any number of bogus reports about that origin.

You could solve that right now by handing out custom upload URLs for different clients; the server receiving reports would verify that the URL that the report came in on matches what would've been handed out to the client uploading the report. We also briefly discussed adding this more directly as part of the spec proper — each endpoint group in a Report-To header, for instance, could include a nonce field, whose value is different for each client, and each report upload would include that nonce value as-is, so that the server could verify it. That would give you the same capability without having to add complexity to your DNS or URL routing configurations.

[juliatuttle]

I think a URL parameter would be the best of both worlds? I wouldn't expect it to make URL routing more complicated on most servers, and it wouldn't require a special case in the spec.

[dcreager]

I think you're right about a URL parameter. We should put some text into the spec with advice on how to handle this. I think the best we can do is to recommend constructing custom URLs for each pair of origin and client IP address. (Custom URL constructed by adding a nonce somewhere: subdomain, URL path, URL parameter, whatever is easiest for you to implement.)

That would still allow a spammer to upload fake reports, but they'd have to make a request for each origin that they want to spam, from the host that will generate and send the spam reports. They wouldn't be able to blast a huge pile of spam uploads for different origins and clients in one go.

@yoavweiss, you had raised this on the WG call. Do you have any other thoughts or concerns? Anything I'm missing?

[bluesmoon]

I wrote this when we released boomerang in 2010: https://soasta.github.io/boomerang/doc/howtos/howto-7.html

[bluesmoon]

It lists types of beacon abuse and their solutions based on what worked for us.

[yoavweiss]

I agree that a URL parameter based nonce would cover the use-case.
Might be useful to add a note to the spec indicating this is something people probably want to do when deploying this.

[igrigorik]

Might be useful to add a note to the spec indicating this is something people probably want to do when deploying this.

Sounds reasonable. If we go ahead with this, I'd suggest adding this as an appendix / non-normative section at the end of the spec — e.g. "deployment considerations" or some such.

[igrigorik]

Also, see: https://github.com/WICG/reporting/pull/61#pullrequestreview-93831522