Support Additional Redirects beside 302

[i-bansal]

Currently, to support registration on Android attribution Reporting API, Chrome will call registerWebSource with a list of attributionSourceURI and each URI’s registration on Android Attribution Reporting API can return a list of redirects. However, as per Android attribution reporting API documentation, it does not respect Attribution-Reporting-Redirects if the source is registered via registerWebSource preventing additional ad techs from registration if they are not part of the 302 redirect chain.

However, the above flow for web->app is different from app->app flow supported via Android Attribution Reporting API where AdTechs can also provide a list of redirects via “Attribution-Reporting-Redirects” response header for additional registrations and not go via 302 route. This will create a discrepancy in data available to additional AdTechs (B1/C1) for ads registered via registerWebSource as compared to registerSource. We request that Chrome should fix this behavior to be on parity with the Android Attribution reporting API

Possible Options:

• Chrome can add an additional header in the source registration response as part of which AdTechs can provide an additional list of redirects for which Chrome will call registerWebSource to Android attribution reporting API to support source registration. This way Chrome can validate the permissions on the website before invoking the registerWebSource.

• Chrome may pass the permissions policy for attribution-reporting via registerWebSource which possibly enables Android to support Attribution-Reporting-Redirects.