Programmatic way to specify attribution reports

[csharrison]

Opening this issue to consider a new API surface at attribution trigger time for the API that allows:

• Programmatic access to sensitive (i.e. cross site) data
• Flexibility to specify information in reports that is a function of both impression/source and conversion/trigger data

In practice this could look a lot like SPURFOWL reporting, in that there could be some environment to inspect sensitive data for use in the APIs. This could be useful for a number of applications, including Conversion Filters, specifying aggregation keys, etc.

Possible solution: new worklet

We could add a new execution environment (a worklet) that can read from both source and trigger context. This environment should look similar e.g. to FLEDGE on-device bidding JS.

Here is an example of how it could potentially work with an aggregate report (although we can also consider this for event-level reporting):

At attribution source time

Add a new attributionsourcecontext attribute that holds an arbitrary string.

<a
  attributionsourceeventid="..."
  attributeon="..."
  attributionreportto="..."
  attributionsourcecontext="campaign123"> ...</a>

At attribution trigger time

await document.attribution.worklet.addModule("https://reporter.com/convert.js");

document.attribution.triggerAttribution("https://reporter.com", 
  <contextStr>, "my-event-level-reporter", "my-aggregate-reporter");

Within the worklet (convert.js)

class AggregateAttributionReporter {

// Function that learns both the trigger context and the source context in one spot.
function processAggregate(context, attributionSourceContext) {
  // Allow some number of contributions to e.g. a fixed-domain histogram
  contributions = [
    {bucket: 34, value: 1},
    {bucket: 1003, value: 15},
  ]

  return {
    contributions: contributions,
    processing_origins: [
      {origin: "https://helper1.com"},
      {origin: "https://helper2.com"},
  }
}
}

// Bound classes will be invoked when an attribution triggered on this document is
// successfully attributed to a source whose reporting origin matches the worklet
// origin.
registerAggregateReport("my-aggregate-reporter", AggregateReporter);

We should be careful that these techniques cannot be used to regress the privacy of the API. This could be a powerful primitive to satisfy multiple use-cases, and provide a base on which to add more features.

[csharrison]

One potentially concerning aspect of this feature is regarding attribution triggers that happen as a page is navigated away from (e.g. form submission). If this is common, we may need to introduce some "keepalive" style worklet operation mode.

[csharrison]

We moved away from this solution for a few reasons:

• Complexity
• Privacy concerns
• Performance concerns

Instead, we designed a declarative system for filtering triggers and computing metadata.