Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we built a GDPR-compliant website analytics platform without using cookies

usefathom.com

Post reply on HN
Print view View original

91–100 of 129 posts

Re: How we built a GDPR-compliant website analytics platform without using cookies

#91

Post by unilynx »

Why all the trouble with hashes - can't you just do it on the client and not having to store any data at all?

"For tracking unique page views"

  if(!sessionStorage[location.href]) {
    sessionStorage[location.href]=1;
    navigator.sendBeacon("/unique-pagehit?" + encodeURIComponent(location.href));
  }
"For tracking unique site views"

  if(!sessionStorage["Hi!"]) {
    sessionStorage["Hi!"]=1;    
    navigator.sendBeacon("/unique-sitehit");
  }
"For tracking previous requests"

I'm not sure I fully understand what is being measured (is it session-only?). For the duration someone watched a page, you can use sendBeacon in onBeforeUnload. To detect a bounce, set a Math.random() in a session variable, send it at the start of the page, and have every page load send the previously stored random variable. Then count the unique random keys you received on the server - those are the bounces.

I know, in practice you'll need to trim sessionStorage, sanitize URLs, use something less-colliding than Math.random, dealing with new tabs, some polyfills and other robustness, etc... but I don't yet see why the tracking mentioned needs any user ids or hashing at all.

Re: How we built a GDPR-compliant website analytics platform without using cookies

#92

Post by JackWritesCode »

bashy wrote: post #29
mrweasel wrote: post #25

Couldn’t people just parse the log files from their webservers?

Definitely. Helps with people who disable JS as well. I've used this before https://goaccess.io

bashy from laracasts? Hey there! And I've heard the disabled JS piece before. How many people are disabling javascript?

Re: How we built a GDPR-compliant website analytics platform without using cookies

#93

Post by JackWritesCode »

unilynx wrote: post #91

Why all the trouble with hashes - can't you just do it on the client and not having to store any data at all? "For tracking unique page views" if(!sessionStorage[location.href]) { sessionStorage[location.href]=1; navigator.sendBeacon("/unique-pagehit?" + encodeURIComponent(location.href)); } "For tracking unique site views" if(!sessionStorage["Hi!"]) { sessionStorage["Hi!"]=1; navigator.sendBeacon("/unique-sitehit");…

Great idea but we can't use sessionStorage under PECR, which is why we made this move. Plus we got rid of anything being stored on the user's machine.

Re: How we built a GDPR-compliant website analytics platform without using cookies

#94

Post by nybble41 »

JackWritesCode wrote: post #89
vmlpvf wrote: post #88

The data is not anonymous. Anonymity is actually very hard to claim (read k-anonymity, differential privacy, etc). Nevertheless, the chances of identifying someone are probably pretty low, and it´s a good effort to make analytics more privacy friendly.

So it's practically anonymous. Nobody has enough computing power to brute it & the data is deleted, typically, in 30 minutes.

To de-anonymize the data you don't actually need to brute force the 256-bit hash. If the other pieces of data are known (salt, site, page, day of year) and you can make a shrewd guess at the user agent then you'd only need to brute force the 32-bit IP address().

() Assuming IPv4. Obviously IPv6 addresses would be much harder to brute force, but still easier than a 256-bit hash.

Re: How we built a GDPR-compliant website analytics platform without using cookies

#95

Post by JackWritesCode »

nybble41 wrote: post #94
JackWritesCode wrote: post #89

Earlier quoted context omitted.

So it's practically anonymous. Nobody has enough computing power to brute it & the data is deleted, typically, in 30 minutes.

To de-anonymize the data you don't actually need to brute force the 256-bit hash. If the other pieces of data are known (salt, site, page, day of year) and you can make a shrewd guess at the user agent then you'd only need to brute force the 32-bit IP address( ). ( ) Assuming IPv4. Obviously IPv6 addresses would be much harder to brute force, but still easier than a 256-bit hash.

I do take your point but when we get into this area, it becomes a big question of trust. Because if I gave you a hash, you would need to guess the 256 bit salt in addition to all the other possibilities.

I mean, hey, here's a hash: 26246226167b9f190d3a1ce726efe07ae18bbf0480a78d19390b9aaf13f25cb0

Imagine you just got hold of it through a data breach. I'll give you $1,000 if you can get it de-hashed before midnight Chicago time ;)

Re: How we built a GDPR-compliant website analytics platform without using cookies

#96

Post by draw_down »

unilynx wrote: post #91

Why all the trouble with hashes - can't you just do it on the client and not having to store any data at all? "For tracking unique page views" if(!sessionStorage[location.href]) { sessionStorage[location.href]=1; navigator.sendBeacon("/unique-pagehit?" + encodeURIComponent(location.href)); } "For tracking unique site views" if(!sessionStorage["Hi!"]) { sessionStorage["Hi!"]=1; navigator.sendBeacon("/unique-sitehit");…

> can't you just

This is how you know you're about to make a really good point. Heck, I could code this up in a weekend!!

Re: How we built a GDPR-compliant website analytics platform without using cookies

#97

Post by ricardobeat »

unilynx wrote: post #91

Why all the trouble with hashes - can't you just do it on the client and not having to store any data at all? "For tracking unique page views" if(!sessionStorage[location.href]) { sessionStorage[location.href]=1; navigator.sendBeacon("/unique-pagehit?" + encodeURIComponent(location.href)); } "For tracking unique site views" if(!sessionStorage["Hi!"]) { sessionStorage["Hi!"]=1; navigator.sendBeacon("/unique-sitehit");…

This client-based scheme would be totally vulnerable to spamming / general messing about. Doing it in the server requires an actual request, and should still allow them to filter out attempts at gaming the system.

Re: How we built a GDPR-compliant website analytics platform without using cookies

#98

Post by ricardobeat »

SCLeo wrote: post #73

Looking at their live demo ( https://stats.usefathom.com/#!p=1w&g=hour ), I can see a lot of traffic is coming from ycombinator. So... (I mean, I don't have a point here but I find it pretty interesting. xD)

That's exactly what they are selling - the ability to get relevant business metrics while preserving user privacy.

Re: How we built a GDPR-compliant website analytics platform without using cookies

#99

Post by gcbw2 »

This is still logging everything the GDPR says you can't without asking for consent, but you made your search convoluted (but not less efficient if you have all the pieces) to (suggest|lie?) that you need to break the hash and that's why you don't need consent.

None of the information you are using on the hash wouldn't be in the search query itself! ip, user agent, path, date, etc. So there is no way to reverse the hash. You just hash your search query and compare in O(1) time.

The only piece of information that realistically makes the hash slightly difficult to get is the random number refreshed every day. But either you store it (and i have no reason to believe you do not) or it make the brute force effort trivial as I only need to generate the hash with that variable now.

Re: How we built a GDPR-compliant website analytics platform without using cookies

#100

Post by nybble41 »

JackWritesCode wrote: post #95
nybble41 wrote: post #94

Earlier quoted context omitted.

To de-anonymize the data you don't actually need to brute force the 256-bit hash. If the other pieces of data are known (salt, site, page, day of year) and you can make a shrewd guess at the user agent then you'd only need to brute force the 32-bit IP address( ). ( ) Assuming IPv4. Obviously IPv6 addresses would be much harder to brute force, but still easier than a 256-bit hash.

I do take your point but when we get into this area, it becomes a big question of trust. Because if I gave you a hash, you would need to guess the 256 bit salt in addition to all the other possibilities. I mean, hey, here's a hash: 26246226167b9f190d3a1ce726efe07ae18bbf0480a78d19390b9aaf13f25cb0 Imagine you just got hold of it through a data breach. I'll give you $1,000 if you can get it de-hashed before midnight Chi…

It's true that you'd need to know the salt first, but the server does know the salt, and if you obtained the hash through a data breach then you probably obtained the current day's salt as well.
Post reply on HN