
Google has revised its strategy (July 22nd, 2024) regarding the third-party cookie deprecation. Instead of enforcing tracking protection by blocking third-party cookies centrally, they will offer this as a choice to their users across all their web browsing.
To allow our users to enable tracking protection, the solutions discussed in the blog remain fully relevant. We have updated the blog accordingly and incorporate any new guidance from Google as it becomes available.
As you may already be aware, browser manufacturers are presenting users with a choice for tracking protection that disallows third-party cookies. A prominent example is Google Chrome’s plan to let “people make an informed choice that applies across their web browsing”. We are working to ensure that your SAP solutions continue to function with no or minimal potential change in user experience and your application code. The good news is that now is the perfect time to plan for any future changes you need to make.
In our fourth and last installment of our blog series dedicated to the third-party cookie phase-out, we’ll glance over the definitive solutions you can implement for your application if it is affected: Cookies Having Independent State (CHIPS) and Storage Access API (SSA).
Before even considering CHIPS or SAA, make sure that you test your solution for breakage first. See our dedicated step-by-step guide for more information: Preparing and Testing Your Solution for Third-Party Cookie Phase-Out.
At SAP, we recommend implementing Cookies Having Independent State (CHIPS) or Storage Access API (SAA). Which solution you should apply depends entirely on your scenario and the context of your application. Both solutions have pros but also limitations you should be aware of. We’ve listed them in our full guide dedicated to these solutions.
SAP has made changes to Approuter and SAP Authorization and Trust Management Service to make them ready for CHIPS and SAA out of the box. These components use a combination of CHIPS and SAA to negate the effects of third-party cookie blocking.
However, because third-party cookies are used in various ways, customers and partners must manually configure their application or extension if they are affected. The configuration must be done by the application owner. See our full guide for detailed steps.
If your application or extension uses these components and SAP cookies only, the configuration is sufficient to make your application or extension ready.
If your solution or extension uses either Approuter or SAP Authorization and Trust Management Service, and sets its own cookies, you must fully implement CHIPS or SAA. Our guide can help you decide what solution is the best for your scenario.
Below is a brief recap of how both solutions work.
Partitioning cookies allows an embedded application to access cookies in its own third-party context. This solution is mostly suitable if the cookies are used for information that is only relevant in their respective context, e.g session cookies, application state, caches, etc…
With cookie partitioning, a third-party service that sets a cookie when embedded in one top-level site cannot access that same cookie when the service is embedded in other top-level sites.
Storage Access API is a JavaScript API that allows iFrames to request storage access permissions when access would otherwise be denied by your browser settings. It also enables access to cookies in a third-party context the same way you would access them in a first-party context.
Both solutions might require additional configuration depending on your application scenario. Check our full dedicated guide for more information.
This is the final part of our blog series covering the third-party cookie deprecation:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
33 | |
15 | |
11 | |
8 | |
8 | |
7 | |
7 | |
7 | |
6 | |
5 |