Closed linnan-github closed 2 weeks ago
I'm not sure that omitting the Attribution-Reporting-Eligible
header is the right option, as opposed to including it but setting it to the empty string, as the absence of that header in some contexts still corresponds to the request being trigger-eligible. So it might be beneficial to tell the reporting origin that it is eligible for nothing, as opposed to letting it assume it can still register triggers.
But it depends on whether we consider the presence/absence/value of these headers to be a fingerprinting surface.
Sending all GREASED values would signal "nothing" without sending nothing, though wouldn't address fingerprinting concern.
Sending all GREASED values would signal "nothing" without sending nothing, though wouldn't address fingerprinting concern.
Yes, the header would still be subject to greasing.
So it might be beneficial to tell the reporting origin that it is eligible for nothing, as opposed to letting it assume it can still register triggers.
But it depends on whether we consider the presence/absence/value of these headers to be a fingerprinting surface.
Agreed that it may be beneficial in this aspect to distinguish these two cases. As for the fingerprinting, I think it's already true for requests with Attribution-Reporting-Support
header, so should be fine, at least not regression.
Currently when there is none attribution support (neither web nor os), the
Attribution-Reporting-Eligible
header may still be sent andAttribution-Reporting-Support
header is also sent as empty. We may consider omitting both to reduce bandwidth and a better indicator that the request is not eligible for Attribution Reporting.