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)
Comments
Hello worksonmine,
please see on my upper response a more technical elaboration on how it works. It is not the same as cookies.
Cheers
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.
counter.dev does not use any id at all for tracking.
No? How do you identify a specific browser? What's in these values?
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.
I don't see how unique visitors and no identifier are both possible. One of them is not true.
from what I can tell, it works like this:
- the script is loaded
- check if sessionStorage has the '_swa' item
- if no, then hit the /track endpoint (this I assume is to count unique visitors). Then set the '_swa' item.
- hit the /trackpage endpoint (this one just increases every time)
- On next page load, the _swa item will be set in the sessionStorage, so /track will not be hit again.
That's about it from what I can see.
I think the main point is that the server doesn't do any tracking itself, it just has a number that increases when you hit /track or /trackpage.
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.
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.
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.
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)
Thanks, I sometimes have troubles explaining how it works but this is it! That is basically how it works (There are some hidden extras though)