API support for auditing / monitoring calls

[csharrison]

Problem

The API currently requires a large amount of coordination to handle multiple ad-tech's registering impressions, especially when those impressions will be bundled and attributed together as one group at measureConversion time.

In the Sept 11 PATCG call, we discussed the need to support auditing in general to allow advertisers (and publishers to some extent) to better understand

• If ad-tech are misbehaving
• If ad-tech are making error in configuring the API

Some mistakes that we discussed were setting of histogram indices, priority, and other data which could affect attribution (e.g. future data to feed into worklet-based attribution).

Strawman API: monitoringEndpoints

Note: this is just a strawman to get a sense for what is possible here. The goal is to ensure that no impression is ever used for attribution if it does not property set the correct monitoring endpoints.

We can add a parameter to AttributionImpressionOptions to log the API call params to a set of distinct monitoringEndPoints:

navigator.attribution.saveImpression({
  ...
  monitoringEndpoints: ["https://auditor1.example/path", "https://auditor2.example/path"]
});

Upon receipt of the monitoring endpoints, the browser would immediately send a CORS request to the endpoints, where the payload would be some serialization of the exact call to saveImpression, possibly with some additional information like client wall clock time. This alone does not solve the problem, since a misbehaving intermediary site could neglect to set the correct monitoringEndpoints. However, we can fix this using filtering at conversion time to ensure we only consider events that properly added to the audit log.

const selectionDetails = {
  ...
  // Only include impressions which set at least one endpoint below.
  monitoringEndpoints: ["https://auditor1.example/path"]
};
const measurement = await navigator.attribution.measureConversion({
  ...
  ...selectionDetails,
});

A few notes:

• This uses the term monitoring rather than reporting to distinguish that the collector may be a different entity than the one processing conversion reports
• We need to support multiple auditors to gracefully handle migrations without data loss.
• In theory we could support more expressive filtering logic (i.e. force double logging), but I've intentionally punted on this. Unless extremely necessary we should punt more complexity to the worklet-based approaches discussed in Support for flexible filtering / attribution functionality #204 .
• Given that the data emitted is not cross-site, there should be no privacy concerns here

We can also consider how publishers / advertisers can automatically add monitoring endpoints to calls made on their sites (so e.g. publishers also get an audit log by default). This seems possible in theory either by auto-magically adding a monitoring endpoint to the call, or failing calls which don't have the endpoints prescribed by the top-level page. TBD on actual API surface.

cc @bmayd @AramZS @jaylett

[jaylett-annalect]

I haven't been following some of the other discussions closely, but I'm curious as to why exposing a timestamped exposure event doesn't have privacy implications. (Even without client wall clock time, if the browser immediately sends a CORS request, that provides an effective timestamp.) I haven't come up with a concise example that definitely causes problems, but even just getting match values against IP addresses (unless the browser MUST mask the device IP address, this could be passed on from auditor to brand) feels ... vulnerable (maybe via DOM scraping publisher account information). Is this a real concern?

[martinthomson]

I believe that the operating theory is that this auditing is functionally equivalent to a site writing a wrapper around the API calls that takes the options and sends them to a given URL. From that perspective, there is no new capability enabled, so no new privacy leak.

The requests would need to follow standard fetch rules, which could mean there are pretty significant performance implications (removing preflight seems difficult if the request goes cross-origin). We can probably use keepalive to allow the request to complete when the page disappears. And then we need to work out what the CSP treatment is if the API is invoked using HTTP headers. Overall though, the general shape of this doesn't need to give sites new information, just different packaging for convenience.

[jaylett-annalect]

It's functionally equivalent, but that isn't privacy equivalent - a site deciding to send data to a third party is different to one third party (brand or its adtech) identifying that another (auditor) should be sent that data. Or would there be something not only for publishers to augment the auditors list with their own choice, but for them to constrain it as well? I'm assuming that the .saveImpression() call would be from a fairly low level of the ad delivery onion, above the creative itself but below things like safety wrappers. (Of course that could limit what information is available to exploit, with IFRAME boundaries and no avoidance approaches in play.)

[csharrison]

It's functionally equivalent, but that isn't privacy equivalent - a site deciding to send data to a third party is different to one third party (brand or its adtech) identifying that another (auditor) should be sent that data. Or would there be something not only for publishers to augment the auditors list with their own choice, but for them to constrain it as well? I'm assuming that the .saveImpression() call would be from a fairly low level of the ad delivery onion, above the creative itself but below things like safety wrappers. (Of course that could limit what information is available to exploit, with IFRAME boundaries and no avoidance approaches in play.)

It is a good question who should be able to add to or constrain this list, and it is certainly privacy-relevant. When I said it was "privacy-safe" I mean it exposes no additional cross-site tracking vectors and therefore exposes nothing more than what could be exposed already w/ API wrappers.

What you wrote is still true, we should be thoughtful about who can add / constrain this list. In the original proposal the incentives are aligned so that no one uses auditors the advertiser does not actually want, since there is a filtering step meaning if you try to use a non-blessed auditor, your API call will be basically a no-op.

[jaylett]

I'm more worried about advertisers choosing an auditor that the publisher doesn't want than a call being set up to use an auditor that the advertiser isn't interested in. It'd be helpful I think to map out what we're worried about and what we aren't with some precision (so that for instance it's clear who the 'you' is in "your API call").

[martinthomson]

If we can’t stop someone from initiating a fetch, there isn’t much point in preventing this. There is a reason to include this still: otherwise there is no way to achieve the same when using HTTP