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.<p>-edit-<p>This is how we use it:<p>We have two domains.<p>Our main site `widget.com` and `widgetusercontent.com`.<p>`widget.com` contains an iframe from `widgetusercontent.com`.<p>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.<p>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.<p>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.<p>I came up with this myself but I assume others would have as well.<p>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.<p>Yes it works in Safari. Cookies don’t work but this does.