Consider adding ability to read Interest Groups in Shared Storage worklets

[Josh Karlin]

The idea proposed here is to allow read-only access to an origin's (e.g., buyer's) interest groups within a Shared Storage worklet. From the worklet, you could send out private aggregate reports (e.g., create histograms) based on the IGs you've created for the given user.

Use cases I could imagine include things like, understanding how many IGs your users have, how valuable they are, how often IGs might conflict, etc. It seems like something that would be useful to ad-tech to understand what's happening on device by looking at all of their IGs collectively.

Would this be useful to you? Please let me know if so.

Pseudocode example:

Advertiser page:

navigator.joinAdInterestGroup({owner:"a.com", name: "foo"});
navigator.joinAdInterestGroup({owner:"a.com", name: "bar"});

let worklet = await sharedStorage.createWorklet("https://a.com/worklet_metrics.js". {readsIGs: true});
worklet.run("processIgs");

worklet_metrics.js

class IGReporter {
  async run(data) {
    let igs = await sharedStorage.getIGs();

    // Record how many igs the user has.
    privateAggregation.contributeToHistogram({bucket: igs.length, value: 1});
   }
}
register('processIgs', IGReporter);

[Josh Karlin]

Also worth noting that you can already write to shared storage from any protected audience worklet, so you could accumulate your data in there to help generate more useful reports.

[David Dabbs]

getIGs() will return a list/array of the IG as available to generateBid()?

interestGroup:
The interest group object, as saved during joinAdInterestGroup() and perhaps updated via the updateURL.
priority and prioritySignalsOverrides are not included. They can be modified by generatedBid() calls, so could theoretically be
used to create a cross-site profile of a user accessible to generateBid() methods, otherwise.

[Josh Karlin]

| getIGs() will return a list/array of the IG as available to generateBid()?

Haven't explored the exact details yet, but there isn't a privacy reason to exclude things such as priority or updates.

[David Dabbs]

Yes, this would be a useful addition.

There are two types of IGs - "positive" and "negative." Consider some ability to include/filter the types.
Assuming "being a negative IG" continues to be "has a non-NULL additional_bid_key" that should be uncomplicated.

Some internal IG attributes not available to buyers' auction bidding and reporting scripts could be useful to measure, assuming their exposure for aggregated reporting is privacy safe.

exact_join_time
expiration
last_updated
next_update_after
storage_size
joining_origin
joining_url

Chrome provides a simple prior bidCount to generateBid, but it does appear to store an IG's bid counts by day,

[Eyal Segal]

Reading the IGs in a worklet would help us properly reporting IGs reach, as discussed in #1219 so we would really appreciate implementing it.