indication for OS source as attribution action takes place at the advertiser site

[roistaboola]

As an attribution action takes place at the advertiser web page, these header are being sent by chrome browser:
Attribution-Reporting-Eligible: trigger
Attribution-Reporting-Support: os, web

However these headers do not indicate if the source had been OS (android SDK) and thus the action target server receiving those
headers cannot indicate whether it should respond with an app-to-web attribution OS header
(Attribution-Reporting-Register-OS-Trigger).

Please provide an indication the click source is OS by either a new header or new header value.

reference: https://developer.android.com/design-for-safety/privacy-sandbox/attribution-app-to-web

[apasel422]

Thanks for the request.

The source, if any, that the trigger is ultimately attributed to is unknown at the time of trigger registration, so there's no way the browser can provide the information you're asking for in a request header.

Additionally, even if the browser did know the source in question, it could not use that information to dynamically choose between processing the web trigger or the OS trigger because doing so would leak whether such a source existed for the unchosen platform, which would violate the API's privacy model.

That said, an OS trigger can only be attributed to an OS source, and a web trigger can only be attributed to a web source. If you want to be able to register using either platform (independent of whether a corresponding source actually exists), you can have a response like

Attribution-Reporting-Register-Trigger: ...
Attribution-Reporting-Register-OS-Trigger: ...
Attribution-Reporting-Info: preferred-platform=<platform>

where <platform> is either os or web. However, the registration used is solely based on the preferred-platform value and the browser's support, and does not dynamically depend on the attributed source (which, again, is unknown by the browser at this point in the attribution flow).

If you must be able to know ahead of time which type of registration to perform, you could use two reporting origins, e.g. https://web.example and https://os.example, and use only web registrations on the former and only OS registrations on the latter. In other words, you could segregate your registrations based on platform.

If I'm misunderstanding your request, feel free to clarify.

[apasel422]

@roistaboola Just following up on this.

[roistaboola]

Hi @apasel422 Thanks for getting back on this one.
Have tries responding with the 3 header as suggested, however it did not produce the result hopped for.

Here are the tested scenarios:

#1:
Responding with following headers,
the chrome://attribution-insternals/ 'OS Registration' tab did not present the OS trigger:

Attribution-Reporting-Register-Os-Trigger: "https://trc.taboola.com/attribution-reporting/attribution_trigger?sdk_atw=yes"

Attribution-Reporting-Register-Trigger: {
"event_trigger_data" = (
{
"trigger_data" = 1;
}
);
}

Attribution-Reporting-Info: preferred-platform=os

#2:
Responding with these headers, the chrome://attribution-insternals/ 'OS Registration' tab did not contain the OS trigger::
Attribution-Reporting-Register-Os-Trigger: "https://trc.taboola.com/attribution-reporting/attribution_trigger?sdk_atw=yes"
Attribution-Reporting-Info: preferred-platform=web

#3:
Responding with these headers, the chrome://attribution-insternals/ 'OS Registration' tab did contain the OS trigger::

Attribution-Reporting-Register-Os-Trigger: "https://trc.taboola.com/attribution-reporting/attribution_trigger?sdk_atw=yes"
Attribution-Reporting-Info: preferred-platform=os

#4:
Responding with these headers, the chrome://attribution-insternals/ 'OS Registration' tab did contain the OS trigger::
Attribution-Reporting-Register-Os-Trigger: "https://trc.taboola.com/attribution-reporting/attribution_trigger?sdk_atw=yes"

@apasel422 am I missing anything here ?
Is there another headers settings that provides for both OS & Web source registration ?

Thanks !

[apasel422]

What browser version are you using? For Chrome, preferred-platform is available starting in M124.

Also, your Attribution-Reporting-Register-Trigger header in (1) is not valid, though I'm not sure that matters for the purposes of this issue.

[roistaboola]

Hi @apasel422
chrome version is 124.0.6367.54

Thanks for noticing. I've corrected the Attribution-Reporting-Register-Trigger header, repeated test #1 having preferred-platform=os and run test #5 having preferred-platform=web ::

test #1:
Responding with following headers,
the chrome://attribution-insternals/ 'OS Registration' tab did present the OS trigger:

Attribution-Reporting-Register-Os-Trigger: "https://trc.taboola.com/attribution-reporting/attribution_trigger?sdk_atw=yes"
Attribution-Reporting-Register-Trigger: {"event_trigger_data":[{"trigger_data":"1"}]}
Attribution-Reporting-Info: preferred-platform=os

test #5:
Responding with following headers,
the chrome://attribution-insternals/ 'OS Registration' tab did not present the OS trigger:
Attribution-Reporting-Register-Os-Trigger: "https://trc.taboola.com/attribution-reporting/attribution_trigger?sdk_atw=yes"
Attribution-Reporting-Register-Trigger: {"event_trigger_data":[{"trigger_data":"1"}]}
Attribution-Reporting-Info: preferred-platform=web

As it goes, it is still required to identify if is OS or Web at handling the action and returning the 'preferred-platform' value.

Is there a response headers pattern that provides for both OS & Web registration ?

Thanks.

[apasel422]

test 5:
Responding with following headers,
the chrome://attribution-insternals/ 'OS Registration' tab did not present the OS trigger:

This is expected, as preferred-platform=web tells the browser to not even bother inspecting the Attribution-Reporting-OS-Trigger header.

Is there a response headers pattern that provides for both OS & Web registration ?

No, a single response can register using web or OS, but not both.

Could you elaborate on why you need to register both?

[roistaboola]

This is the app-to-web case, a user may click an ad at the SDK app, or can click an ad at a web site.
either way, the user gets to the advertiser web page (chrome) where the conversion action takes place.
as the click (source) might have been generated at either platform, the response should apply for both.

[apasel422]

This is the app-to-web case, a user may click an ad at the SDK app, or can click an ad at a web site. either way, the user gets to the advertiser web page (chrome) where the conversion action takes place. as the click (source) might have been generated at either platform, the response should apply for both.

Can you distinguish the two platforms using something in the URL? For example, on web you could have:

<img attributionsrc="https://x.example/register-trigger?platform=web">

and in an app you could have

<img attributionsrc="https://x.example/register-trigger?platform=os">

and then vary your response based on the platform query parameter.

[apasel422]

@roistaboola Just following up on this.

[roistaboola]

Hi, we hopped an indication could be fetched based on the source inventory that is available at the OS & web and have it reported at the action request. can that be considered ?

[apasel422]

Hi, we hopped an indication could be fetched based on the source inventory that is available at the OS & web and have it reported at the action request. can that be considered ?

Per #1240 (comment), this would violate the API's privacy model.

[apasel422]

Another option here would be to try to register both a web trigger and an OS trigger using a self-redirect, i.e.

Attribution-Reporting-Register-Trigger: ...
Location: /register-os-trigger

followed by

Attribution-Reporting-Register-OS-Trigger: ...

[roistaboola]

Thanks technically this might work, however we are not using redirection for the web trigger, and not sure we would like to redirect, we will look into whether the request itself can indicate the headers that need to be returned.
can close this ticket. thanks