Debugging Cookie for Attribution Reporting API Not Recognized

[hengtang]

Hello privacy sandbox team, we are currently exploring the Attribution Reporting API with debugging reports.

Despite confirming the cookie's presence in the response header, we observed that the debugging keys could not be registered. Upon further investigation, we identified a potential cause related to the case sensitivity of the HttpOnly attribute. Specifically, our responses contain the attribute as HTTPOnly instead of HttpOnly, which seems to lead to the debugging cookie being ignored by the browser, since it's not considered as a HttpOnly cookie.

Our current web framework does not offer the flexibility to alter the case of the HttpOnly attribute easily, posing a significant barrier to utilizing the debugging feature of the Attribution Reporting API effectively.

Questions

1. Can you help confirm if the case sensitivity in the HttpOnly attribute is the reason for the debugging key being ignored?
2. Are there any recommended workarounds or solutions for this issue?

[apasel422]

Thanks for the report. In the future, please consider filing implementation questions like this in https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support.

That said, according to at least one specification reference and seemingly-relevant Chromium unit test that I found, the HttpOnly attribute should be compared case-insensitively, so I would be surprised if that's why it isn't being set properly.

[apasel422]

I was able to confirm locally that HTTPOnly (case as written) resulted in the cookie being set as expected, so something else must be going on here.

@hengtang Would you mind pasting the exact Set-Cookie header value here as text (not an image)?

[hengtang]

@apasel422 Thank you very much for your prompt and insightful response! I appreciate your guidance on where to direct future implementation questions and your efforts to investigate the issue quickly.

As requested, here's the exact Set-Cookie header value and corresponding response cookie info under Network tab in developer tools:

Set-Cookie: ar_debug=1; Max-Age=2629746; Expires=Mon, 15 Apr 2024 11:41:48 GMT; Secure; HTTPOnly

I've ensured that the header matches the specifications. However, I'm still encountering the issue where the cookie isn't being recognized. Specifically, when I check chrome://attribution-internals/, it shows Debug Cookie Set: false. In the Network tab, the cookie is also shown as not HttpOnly, leading me to suspect that the issue might indeed be related to the HTTPOnly attribute.

I'm wondering if there might be other factors at play here that I haven't considered. Any further insights or suggestions you might have would be greatly appreciated.

Thank you once again for your assistance.

[apasel422]

@hengtang Thanks for the details. Using the exact string you provided, HttpOnly is being set when I test locally, so I'm not sure what's going on.

Could you try deleting the ar_debug cookie for the origin in question, so we can ensure we're starting with a fresh state, and then try to register again?

Please also provide the browser version you're using and, if possible, a link to the test page you're using so I can try to reproduce the problem locally.

[apasel422]

Also, are you using fetch to access the registration endpoint? If so, can you try to set credentials: "include", per https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#optional-transitional-debugging-reports?

[apasel422]

@hengtang Just following up on this.

[hengtang]

@apasel422 Hope you're doing well. First off, my apologies for the delayed response. I've been away dealing with some personal matters this week and am just catching up.

Thanks a lot for your input and the suggestion to clear cookies. I've tried that approach, but unfortunately, it hasn't resolved the issue for either fetch calls or the click-through conversions from window.open. I'm planning to update my browser and try clearing the cookies again to see if that makes a difference.

On the topic of fetch calls, I noticed you've recommended switching to XHR requests as a workaround for our other issue(privacysandbox/privacy-sandbox-dev-support#243). In this context, should we also apply a setting similar to credentials: "include"? I'm assuming setting xhr.withCredentials = true; might be the equivalent, but I wanted to double-check with you to be sure.

Thanks again for all your help and advice. Looking forward to your thoughts on this.

[apasel422]

First off, my apologies for the delayed response.

No worries.

I'm planning to update my browser

If you can provide the browser version you're using, that would help with debugging.

I noticed you've recommended switching to XHR requests as a workaround

I didn't recommend switching. See https://github.com/privacysandbox/privacy-sandbox-dev-support/issues/243#issuecomment-1988363527 in particular.

[hengtang]

@apasel422 Thanks for the quick reply!

If you can provide the browser version you're using, that would help with debugging.

Version 122.0.6261.69 (Official Build) (x86_64)

I didn't recommend switching. See https://github.com/privacysandbox/privacy-sandbox-dev-support/issues/243#issuecomment-1988363527 in particular.

Sorry for my earlier misunderstanding regarding the switch to XHR. It seems I misinterpreted the discussion in the issue. Thank you for directing me to the correct comment for clarification.

[apasel422]

@hengtang

1. Do you have a link to a page that is exhibiting the issue so I can try it for myself?
2. Have you had any luck with my suggestion in https://github.com/WICG/attribution-reporting-api/issues/1195#issuecomment-2001981476 ?

[hengtang]

@apasel422 Thanks for looking into this. Please let me know if you need further information.

1. You may reproduce this through the main feed page mentioned: https://github.com/privacysandbox/privacy-sandbox-dev-support/issues/243#issuecomment-2002278004. Any Promoted contents that leads to a new page should trigger a navigation source registration.
2. Sorry I haven't tried the specific solution for fetch since it requires production change from our FE team. However, I did get a chance to clear my cookies and update my browsers. With both change, I'm able to see the cookie now recognized as HttpOnly, however it is still showing Debug Cookie Set: false for me. And it is the same for both navigation and event sources.

[apasel422]

1. You may reproduce this through the main feed page mentioned: Attribution Reporting Error on chrome privacysandbox/privacy-sandbox-dev-support#243 (comment). Any Promoted contents that leads to a new page should trigger a navigation source registration.

Unfortunately I'm not seeing any attribution requests from that page.

2. With both change, I'm able to see the cookie now recognized as HttpOnly, however it is still showing Debug Cookie Set: false for me.

CC @linnan-github. Could you offer some guidance here?

[hengtang]

Unfortunately I'm not seeing any attribution requests from that page.

Can you please try refreshing the feed to find something like below and click on Learn more? Those should trigger the navigation registration requests. The requests should be made to https://px.ads.linkedin.com/attribution_source. Please let me know if that still doesn't work.

[linnan-github]

@hengtang Per https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#optional-transitional-debugging-reports, the SameSite attribute (default value Lax) of the ar_debug cookie should be set to None, which I don't see in the Set-Cookie string you shared. Could you please try setting the attribute explicitly and see whether it works? Thanks.

[apasel422]

@hengtang Did https://github.com/WICG/attribution-reporting-api/issues/1195#issuecomment-2018709555 resolve this issue for you?

[apasel422]

Feel free to reopen if this is still an issue.

[hengtang]

@apasel422 Thanks for following up on this. We run into some blockers but finally deployed the change last Friday and confirmed that they fix our issues. Thank you and @linnan-github very much for your time and effort on this!