Consider omitting Attribution Reporting request headers when there is none attribution support

[linnan-github]

Currently when there is none attribution support (neither web nor os), the Attribution-Reporting-Eligible header may still be sent and Attribution-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.

[apasel422]

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.

[dmdabbs]

Sending all GREASED values would signal "nothing" without sending nothing, though wouldn't address fingerprinting concern.

[apasel422]

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.

[linnan-github]

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.