Not really cookie-less and it can be considered a regression compared to cookies because of JS, but something that can work is doing stats + anonymization clien

Not really cookie-less and it can be considered a regression compared to cookies because of JS, but something that can work is doing stats + anonymization client-side. You can store information client-side, without sending them over network, but randomly send digests back to your server. For instance you can store a counter of the times the user went to visit the website, and randomly with a 1% probability send that counter to your server. (It's better to make it random, because if you send every +=1 you would end up being able to track users). At my work, I do a lot of statistics of user usage, but I always work to do my best not to leak PII. I'm not a security or privacy researcher, so my work is probably not great but still, the way I do it I believe is largely private: - No unique ID sent, but a daily digest (some people send every single event to their statistics server, and thus need a unique ID to know how many time one person did one action. With a digest that already counts the actions there is no need) - bucketized persistent data: for example the available storage size of the device the app is running on. Sending precise value would make it easier to track digests from one day to the other and track users - For booleans, add some white noise (because 20 booleans is enough to identify someone) - For open-ended information (for instance the list of countries contacted by your SMS app), booleanize it (one boolean per country, cf previous line), and maybe keep a counter to know how many you didn't take into account to know whether you're still missing a lot. Yes overall doing it with no PII requires much more work, but then Big Tech (and smaller techs like Clearview) clearly showed that any PII can and WILL be used against their users. The best way to never leak user's data remains to never have them in the first place.