Change Details

Set up two websites on different registrable domains, and test what cross-domain cookie mechanics are enabled by RWS. The things we want to check: * Can you read/write third-party cookies on the server side without user interaction (in a cross-domain AJAX request or invisible pixel)? * Can you read/write third-party cookies on the client side without user interaction? Can this be made 100% unobtrusive to the user? (Presumably that would require an invisible iframe.) Can the parent web page react to the process finishing? (Esp. in the scenario when something goes wrong - is there something similar to a failure handler in an AJAX request, or something that can be done with a timer?) There are two possible approaches (`requestStorageAccess`, which is cross-browser and could be used to build a workflow that works on non-RWS-supporting browsers by falling back to a permission prompt; and `requestStorageAccessFor` which is more powerful and probably the only way to use AJAX requests, but Chrome-only), we should check both. Note that there are two ways to register a domain in RWS (primary/associated and service), with some notable [[https://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md#browser-behavior|differences]] in behavior. For background on the Related Website Sets spec (previously called First-Party Sets), see {T345589}. See [[https://developers.google.com/privacy-sandbox/3pcd/related-website-sets-integration#how_to_test_locally|Chrome docs]] on how to set custom RWS settings in a browser. This might require registering some throwaway domains, because of the .well-known requirements. We should also check whether disabling exemption heuristics makes a difference (see docs for [[https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md#testing-instructions|Chrome]]), to make sure we aren't attributing something to RWS that's actually only possible due to temporary heuristics.

Set up two websites on different registrable domains, and test what cross-domain cookie mechanics are enabled by RWS. The things we want to check: * Can you read/write third-party cookies on the server side without user interaction (in a cross-domain AJAX request or invisible pixel)? * Can you read/write third-party cookies on the client side without user interaction? Can this be made 100% unobtrusive to the user? (Presumably that would require an invisible iframe.) Can the parent web page react to the process finishing? (Esp. in the scenario when something goes wrong - is there something similar to a failure handler in an AJAX request, or something that can be done with a timer?) * {T360104} could be folded into this (it's essentially the same thing, just without calling the Storage Access API, and always doing user interaction). There are two possible approaches (`requestStorageAccess`, which is cross-browser and could be used to build a workflow that works on non-RWS-supporting browsers by falling back to a permission prompt; and `requestStorageAccessFor` which is more powerful and probably the only way to use AJAX requests, but Chrome-only), we should check both. Note that there are two ways to register a domain in RWS (primary/associated and service), with some notable [[https://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md#browser-behavior|differences]] in behavior. For background on the Related Website Sets spec (previously called First-Party Sets), see {T345589}. See [[https://developers.google.com/privacy-sandbox/3pcd/related-website-sets-integration#how_to_test_locally|Chrome docs]] on how to set custom RWS settings in a browser. This might require registering some throwaway domains, because of the .well-known requirements. We should also check whether disabling exemption heuristics makes a difference (see docs for [[https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md#testing-instructions|Chrome]]), to make sure we aren't attributing something to RWS that's actually only possible due to temporary heuristics. Webkit has some [[https://webkit.org/blog/11545/updates-to-the-storage-access-api/#:~:text=How%20To%20Use%20the%20Storage%20Access%20API|extra rules]] for using the Storage Access API, and a [[https://www.simoahava.com/privacy/itp-debug-mode-in-safari/|debug mode]] to help understand what's going on.

Set up two websites on different registrable domains, and test what cross-domain cookie mechanics are enabled by RWS. The things we want to check: * Can you read/write third-party cookies on the server side without user interaction (in a cross-domain AJAX request or invisible pixel)? * Can you read/write third-party cookies on the client side without user interaction? Can this be made 100% unobtrusive to the user? (Presumably that would require an invisible iframe.) Can the parent web page react to the process finishing? (Esp. in the scenario when something goes wrong - is there something similar to a failure handler in an AJAX request, or something that can be done with a timer?) * {T360104} could be folded into this (it's essentially the same thing, just without calling the Storage Access API, and always doing user interaction). There are two possible approaches (`requestStorageAccess`, which is cross-browser and could be used to build a workflow that works on non-RWS-supporting browsers by falling back to a permission prompt; and `requestStorageAccessFor` which is more powerful and probably the only way to use AJAX requests, but Chrome-only), we should check both. Note that there are two ways to register a domain in RWS (primary/associated and service), with some notable [[https://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md#browser-behavior|differences]] in behavior. For background on the Related Website Sets spec (previously called First-Party Sets), see {T345589}. See [[https://developers.google.com/privacy-sandbox/3pcd/related-website-sets-integration#how_to_test_locally|Chrome docs]] on how to set custom RWS settings in a browser. This might require registering some throwaway domains, because of the .well-known requirements. We should also check whether disabling exemption heuristics makes a difference (see docs for [[https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md#testing-instructions|Chrome]]), to make sure we aren't attributing something to RWS that's actually only possible due to temporary heuristics. Webkit has some [[https://webkit.org/blog/11545/updates-to-the-storage-access-api/#:~:text=How%20To%20Use%20the%20Storage%20Access%20API|extra rules]] for using the Storage Access API, and a [[https://www.simoahava.com/privacy/itp-debug-mode-in-safari/|debug mode]] to help understand what's going on.