search

WICG / attribution-reporting-api

Attribution Reporting API
https://wicg.github.io/attribution-reporting-api/
Other
347 stars 162 forks source link

Create devtools protocol to fetch registered impressions and registered conversions #1207

Open cjzcpsyx opened 4 months ago

cjzcpsyx commented 4 months ago

Currently, the only way to inspect registered impressions or conversions will be through chrome://attribution-internal page. However, this page can be updated frequently and will not be stable enough to be used as programatic API to be used in testing. Is there a way to add devtool protocols to fetch all registered impressions and registered conversions?

apasel422 commented 4 months ago

Thanks for the request. Since this repository focuses on browser-independent behavior, I believe your request should be reframed in terms of WebDriver support (something we already have a minor integration with), rather than Chromium's DevTools and Attribution Reporting Internals UI, which are browser-specific and not covered by this repository or specification.

It would also help for you to list the specific information about registered/stored sources and reports that you'd like to have access to, and what other operations you'd like to be able to perform using WebDriver. For example, I suspect that you will want to be able to send pending reports immediately.

cjzcpsyx commented 2 months ago

Thanks, the fields we will need to get access to are:

For Impressions: source_event_id, status, source_origin, destination, report_to, source_type, priority, filter_data, aggregation_keys, debug_key, dedup_keys, reporting_origin, trigger_specs, max_event_level_reports, trigger_data_matching, event_level_epsilon, aggregatable_budget_consumed, debug_cookie_set, aggregatable_dedup_keys

For Conversions: event_level_status, aggregatable_status, destination, report_to, debug_key, filters, event_triggers, aggregatable_triggers, aggregatable_values, negated_filters, reporting_origin, registration_json

These are the existing fields we use for validation, let me know if these make sense to expose thru API

apasel422 commented 2 months ago

@cjzcpsyx Does that mean you don't need access to reports, only triggers?

cjzcpsyx commented 2 months ago

Yes, since reports are send to AdTech endpoint through report API. We are able to get from internal capture of the testing Adtech. We mainly only need a way to get Source+Trigger programatically. Since these two are kept by chrome only not shared to anywhere. So far the only place having the info is chrome://attribution-internals/

apasel422 commented 1 month ago

To elaborate on the complexities here:

  1. Exposing every single source-side and trigger-side field that you may be interested in places burdens on implementations in terms of retaining data that they may not otherwise need to. For sources in particular, I would ask why you need to inspect all of those fields, rather than test the API's behavior directly (i.e. using reports and debug reports) alongside something like a WebDriver API for flushing all pending reports immediately. Inspecting every single field will likely result in brittle tests, which if I understand correctly is the reason this issue was initially opened with respect to Chromium's internals UI. (Consider what happens if a backwards compatible field is added to the API in the future, but the WebDriver results include its default value explicitly; if you are doing something like exact dictionary matching, your tests will start failing; but maybe that's the point?) It is possible we could consider exposing fully defaulted source/trigger registrations like we do in the header validator today, rather than require WebDriver to be able to retrieve the equivalent fields for persisted sources, which do not need some of them. Then your tests could ensure that a given registration has the exact effective value you intended. We could also provide the result of each registration in terms of a precise error condition or success status.
  2. I don't want to prematurely design this API without accounting for proposals like Full Flexible Event-Level, which may interact with how reports are materialized in the browser in a way that is incompatible with the WebDriver integration.
  3. I would like to receive more feedback from other users about whether they are interested in WebDriver integration in general, and their specific use-cases and requests for it.