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)
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.