It’s a secure cookie, set for for my app’s domain (Which is hosted on fly), with Lax same site policies.
I don’t have posthog libraries anywhere in my app bundle, so the only other thing that could set this would be fly, which injects other headers into the app on every request (on top the fact fly uses posthog for some thing apparently). I never catch the set cookie header doing it, but this does seem to be happening with html content being served with fly. After clearing the cookie, it shows up again a few days later during normal use of the hosted app.
Anyone else serving html pages off fly seeing this?
Just to be clear, we will never inject cookies or tracking data into customer apps. We do alter headers when routing through our proxy (eg X-Forwarded-*) and add (but never alter) Fly-* headers to assist with end-user debugging and tracing. We did run a self-hosted posthog instance ~2-3 years ago to stress test our then-new postgres product, but we abandoned it shortly after and have not used any posthog tracking since. So like you, we have no posthog code in production.
My guess is either a library is adding these without telling you, or 3rd party js served from your site is. But I’d need to see the domain to know for sure. Are you able to share that?
We did run a self-hosted posthog instance ~2-3 years ago to stress test our then-new postgres product, but we abandoned it shortly after and have not used any posthog tracking since. So like you, we have no posthog code in production.
Ah ok, thank you for clarifying.
My guess is either a library is adding these without telling you, or 3rd party js served from your site is.
The only external code running in the site context that I can think of is my 1Password and Wipr safari browser extensions.
But I’d need to see the domain to know for sure. Are you able to share that?
