For a while CHIPS (Cookies Having Independent Partitioned State) has existed in browsers, which makes cookies set by embedded frame not accessible on other domains. This is part of the push to reduce third-party tracking.
It seems that recently Cloudflare has started setting its cf_clearance cookie from an embedded frame. Report: https://forums.zotero.org/discussion/127657/aps-export-returns-403-and-sandbox-cookie-securityerror-issue-15992705
This breaks saving on Chrome. Firefox works, mostly because we use content xhr for same-origin requests, but I also tested from the background page, and even though the DevTools network tab doesn't report sending the cf_clearance key, the request succeeds. If you copy the request as curl and try it in the terminal it fails though.
The primary problem is that XHR and Fetch doesn't have the fine-grained controls to elect to send or not send these cookies. Page fetch will send all cookies, including from partitions, by default. Service worker/background page fetch sends all cookies that belong to the domain too, but seems to not include partition cookies. All MV3 translation requests occur via the background page as translation runs in an offscreen page sandbox.
So the result is that cf_clearance which is set with a partitionKey is not sent on Chrome when fetching resources and that causes cloudflare bot detection to fail.
Currently only affects Chrome, but I wouldn't be surprised if this continues to cause issues on other platforms.
I've created a discussion about this in the Chrome Extension Dev since I'm not sure whether there's a defined intended behaviour, and a bug should be submitted.
In the meantime, we have ways to work around it, but they're brittle and hacky. We can override cookies, but only via DNR, which is not intended for this sort of thing. Moreover, it's not clear that we should be overriding all of our request cookies if we detect that some are set with partition keys. Finally, it's probably bad for performance, and browsers should deal with this in a sensible way.
For a while CHIPS (Cookies Having Independent Partitioned State) has existed in browsers, which makes cookies set by embedded frame not accessible on other domains. This is part of the push to reduce third-party tracking.
It seems that recently Cloudflare has started setting its cf_clearance cookie from an embedded frame. Report: https://forums.zotero.org/discussion/127657/aps-export-returns-403-and-sandbox-cookie-securityerror-issue-15992705
This breaks saving on Chrome. Firefox works, mostly because we use content xhr for same-origin requests, but I also tested from the background page, and even though the DevTools network tab doesn't report sending the cf_clearance key, the request succeeds. If you copy the request as curl and try it in the terminal it fails though.
The primary problem is that XHR and Fetch doesn't have the fine-grained controls to elect to send or not send these cookies. Page fetch will send all cookies, including from partitions, by default. Service worker/background page fetch sends all cookies that belong to the domain too, but seems to not include partition cookies. All MV3 translation requests occur via the background page as translation runs in an offscreen page sandbox.
So the result is that cf_clearance which is set with a partitionKey is not sent on Chrome when fetching resources and that causes cloudflare bot detection to fail.
Currently only affects Chrome, but I wouldn't be surprised if this continues to cause issues on other platforms.
I've created a discussion about this in the Chrome Extension Dev since I'm not sure whether there's a defined intended behaviour, and a bug should be submitted.
In the meantime, we have ways to work around it, but they're brittle and hacky. We can override cookies, but only via DNR, which is not intended for this sort of thing. Moreover, it's not clear that we should be overriding all of our request cookies if we detect that some are set with partition keys. Finally, it's probably bad for performance, and browsers should deal with this in a sensible way.