We have a webb app that is usually used on our own domain, but in some cases we want to include the app in an iframe on a site with a different domain.
This works well when only using the app on the "native" domain, or when only using the app through the iframe. But when the user starts to mix usage iOS safari will start identify our cookies as tracking cookies and block them. Browser extensions like Privacy Badger will do the same.
To authenticate our app (app.com) in the iframe the top level window (client.com) will redirect to app.com where authenticate the request and set the cookies. App.com then redirects back to client.com which in turn loads app.com in an iframe. By doing this we get around the issue of setting cookies in an iframe, this works well.
But we're doing something that makes it look like we're tracking the user across sessions, which we don't have a need to do.
The cookies we set today without an expiry is:
- Server-side we use
hapijswithcrumbfor csrf token. - Socket.io
iocookie https://socket.io/docs/server-api/ - A cookie containing a path
- A cookie containing an ID
The session cookies have a short expiry but is maybe the one cookie that looks most like a tracking cookie. Since we use a third party auth service we can't set it as sameSite.
How can I start to identify what it is we do that the tracking blockers object to?
Is any/all cookies identified as a tracking cookies?