Changes to SameSite Cookie Behavior – A Call to Action for Web Developers
Everyone’s already moved onto using service workers to implement third party cookies. I know because we are using it in production.-edit-This is how we use it:We have two domains.Our main site `widget.com` and `widgetusercontent.com`.`widget.com` contains an iframe from `widgetusercontent.com`.We have a service that runs on `widgetusercontent.com/service` that is controlled by us, but it needs to be authenticated with a temporary credential (doesn't matter if it gets leaked) and cannot run on the same domain as `widget.com` since it also contains user generated content.We used to embed the URL `widgetusercontent.com/service?auth=$AUTH_COOKIE` on `widget.com` and have the `widgetusercontent.com/service` set the cookie, but this no longer works because this is third party cookie and has never worked on Safari.The solution is to load `widgetusercontent.com/service` as a blank page containing only a service worker. We ask this page to load `widgetusercontent.com/service/sw.js?auth=$AUTH_COOKIE`. The service we control returns a service worker with the auth cookie embedded in it, and is set to rewrite every request under `widgetusercontent.com/service/*` and inject the $AUTH_COOKIE into the request header.I came up with this myself but I assume others would have as well.I don't know if this'll work for tracking and other nefarious stuff ad networks use but this is a legitimate use case for us.Yes it works in Safari. Cookies don’t work but this does.