> Counting unique users is achieved with a combination of relying on sessionStorage facilities, the browser's cache mechanism and inspecting the referrer. Using this technique considerably reduces the complexity and load on the server while improving data privacy at the cost of knowing less about users. We can't and don't want to be able to connect single page views to an user identity.
Also a very interesting approach. The difference to counter.dev is that counter.dev does not need any hashes or any unique ids at all, which saves complexity and avoids needing to explain why our specific way of using hashes or ids is privacy friendly. As we have none.
It can be done without cookies. I built a simple visitor stats module for my website package, based on the solution of Simple Analytics. They explained that they make a difference between unique and non-unique visitors by checking if the referrer is your own site. If so, it's not a unique visitor. Of course there are edge cases, but for my case it works more than good enough. I thought it was a brilliant solution from Simple Analytics and I figured I could build something like that myself. It was also fun and I learned a lot.
Tomato tomato. A httpsonly cookie (as a tracking cookie should be) is just as visible as localstorage. So sure, technically correct not a cookie but does the name matter when the result is identical.
"Hey, I got an idea how we get rid of those pesky cookie banners, let's drop the cookies, no.. wait.. hear me out. We store the id... in localstorage! Brilliant!" POWConfetti.
It's not cookies. It can't be used to track you across sites the way that a cookie can, as all the embedding site needs to do is ping the site the cookie is for, and it's done. How do multiple sites access the same localStorage?
I support this behavior, but I wish it allowed users to opt-out per domain or something. The current behavior breaks localStorage on HTML5 games on itch.io (for iPad users, mostly) and there’s no real workaround (other than asking users to disable the setting entirely—something I don’t want them to do). It’s not even possible to detect this case and warn users, so they just think the games are broken…
Cookies can't really track you across sites reliably these days either. And in just the next couple years it will be almost entirely disabled by default in all major browsers
Is that really how httpOnly cookies work though? That and cross-origin is supposed to solve that, but I might not be aware of the work-around you're referring to. Did a search that turned up nothing, do you have a source?
I can't try myself right now. But last time I checked it's not at all that easy. What am I missing?
It's not really a more technical explanation. I get how localstorage and cookies are different. But it's a technicality the user doesn't care about. The problem is third party cookies.
Self-hosted solutions where only the site I visit tracks me is not a problem even for me as a privacy extremist. But calling it "no cookies" and putting the id in localstorage is misleading or misunderstanding the problem people have with cookies in the first place.
Don't get me wrong I like the effort and was looking for something similar before just implementing my own solution with regular nginx logs. But this is a space where trust is important.
No? How do you identify a specific browser? What's in these values?
var id = document.currentScript.getAttribute("data-id");
new URLSearchParams({
id: id,
})
You send it to the server (so I assume it can be used to identify a specific device) and call it an id in the code. Can't wait to see how you are going to try to wrap it to tell me it's technically not an id but...
looking at the code that seems to be the id of the website not of the user. You might have multiple websites on one instance of Counter and you just need to let the server know on which one to record the view.
IIRC, GDPR doesn't really care about cookies, but about storing information on the user's machine. sessionStorage would still fall under this classification. So it doesn't really matter if they are different or not.
That said, it does seem like Counter does not use user ids.
Right, and being sessionStorage it's cleared on browser close, and the next time I visit I will be counted as another daily unique visitor right? Trivial to work around using localStorage (or why not just a cookie) and a timer. So sure, not an id but a visited/not visited flag.
I personally would rather have the pages I visit use a self-hosted solution gather everything I do, instead of a third-party getting little data from many sites I use. If this script is used across many sites it can be checked server-side against my IP to get my usage. I can never verify what logs they keep and for how long.
That's the problem people tend to care about, not the cookies themselves.
> Right, and being sessionStorage it's cleared on browser close, and the next time I visit I will be counted as another daily unique visitor right?
No! There are a few rudimentary mechanisms on top of each other if one of them fails as you described. The /track endpoint sets up http caching. So if sessionStorage fails, you still have that. Then there is also inspecting document.referrer. If it is the page you are already on, then it's definitely not a unique visit.
I get regular user feedbacks for all kind of stuff and unique visits being counted double was not reported once since now.
> (or why not just a cookie)
Because cookies are considered "bad". But technically basically just saving a boolean value on the cookie would not be worse from a privacy perspective than using sessionStorage for a boolean value.
> I personally would rather have the pages I visit use a self-hosted solution gather everything I do, instead of a third-party getting little data from many sites I use. If this script is used across many sites it can be checked server-side against my IP to get my usage. I can never verify what logs they keep and for how long.
That is a general problem with externally hosted services. You can audit the source code (https://github.com/ihucos/counter.dev) but there is not way to verify that my deployment is as stated. I heard a podcast once that web hosters could guarantee that a deployment is in a specific way and contains a specific code base revision. But such solutions unfortunately do not exist. If you really want to be sure self hosting is the way to go (but somewhat cumbersome)
