4 ms·

Nice write-up. I am a bit concerned with the part about fingerprinting. It sounds so easy to make that it made me realize that everyone must be doing it. I am

Nice write-up. I am a bit concerned with the part about fingerprinting. It sounds so easy to make that it made me realize that everyone must be doing it. I am not sure if the use-case here is to track people that delete their cookies or if the author found it easier than using simple UUID stored in cookies.

Fredej 5y ago
One part he mentions is that avoiding tracking cookies means avoiding the "I consent to tracking cookies" popup. > However, GA has grown exceedingly complicated, installs cookies (thus requiring the utterly annoying cookie warning in the EU)
- dindresto 5y ago
  Fingerprinting for this purpose requires user consent in the same way a tracking cookie would. Admittedly, fingerprinting is harder to prove from the user side.
  - Semaphor 5y ago
    AT least in this case, there’s a blog post pointing out how it violates GDPR ;)
rozenmd 5y ago
The fingerprinting part is to avoid double counting and using cookies - most analytics and feature flag services have something equivalent to: hash(salt + ip_address + user_agent + some_other_unique_characteristics) for analytics you could rotate the salt daily if you're only concerned about daily unique visitors
- jmmv 5y ago
  Precisely. To be honest, the fingerprinting part was a very late addition and... I don't like it. The original version used a uuid plus a cookie, but "aaah, cookies!" so I looked for an alternative. Which sounds worse than the simple cookie approach. One thing I'd like to do is try something like what you said server-side and compare how closely a hash of those properties matches the "accuracy" of fingerprinting. I'm only looking for something of reasonable precision during short periods of time (to avoid obvious double-counting) so if that tracked reasonably enough, it'd be a very interesting alternative.
  - GordonS 5y ago
    What about a time-limited fingerprint, built with a seed that rotates daily? That way, you can only track any given visitor for max 24 hours, which often would mean tracking them across a single "visit". I'm pretty privacy conscious, but personally would be absolutely OK with this.

Fredej 5y ago

One part he mentions is that avoiding tracking cookies means avoiding the "I consent to tracking cookies" popup. > However, GA has grown exceedingly complicated, installs cookies (thus requiring the utterly annoying cookie warning in the EU)

dindresto 5y ago
Fingerprinting for this purpose requires user consent in the same way a tracking cookie would. Admittedly, fingerprinting is harder to prove from the user side.
- Semaphor 5y ago
  AT least in this case, there’s a blog post pointing out how it violates GDPR ;)

rozenmd 5y ago

The fingerprinting part is to avoid double counting and using cookies - most analytics and feature flag services have something equivalent to: hash(salt + ip_address + user_agent + some_other_unique_characteristics) for analytics you could rotate the salt daily if you're only concerned about daily unique visitors

jmmv 5y ago
Precisely. To be honest, the fingerprinting part was a very late addition and... I don't like it. The original version used a uuid plus a cookie, but "aaah, cookies!" so I looked for an alternative. Which sounds worse than the simple cookie approach. One thing I'd like to do is try something like what you said server-side and compare how closely a hash of those properties matches the "accuracy" of fingerprinting. I'm only looking for something of reasonable precision during short periods of time (to avoid obvious double-counting) so if that tracked reasonably enough, it'd be a very interesting alternative.
- GordonS 5y ago
  What about a time-limited fingerprint, built with a seed that rotates daily? That way, you can only track any given visitor for max 24 hours, which often would mean tracking them across a single "visit". I'm pretty privacy conscious, but personally would be absolutely OK with this.