Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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


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)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: