I use JS to record the amount of visitors (technically pageviews) that reached the end of an article on my blog to get a sense for completion rate. Surely that is not too much?
You can collect anything without limits as long as you don’t associate this data with identification data / profiles.
An amount of visitors isn’t creating any privacy concern. That would be another situation if you stored individual completion rates associated with, say, an IP or worse, an user account. You would still technically be able to do it but not without clear consent from the user.
MartijnHols is talking about using javascript, not cookies (or similar mechanisms). It is possible to use JS without cookies. If they're not using cookies, nor fingerprinting, nor storing PII, or anything else that breaks the spirit of the laws then it doesn't need a cookie banner, but under some jurisdictions you need disclosure about the potential data aggregation (even if it's just "increment a counter") to be in your privacy policy.
Collecting non-personalized aggregate data without any tracking mechanisms (cookies, fingerprinting, PII storage) is mostly fine in jurisdictions that implement GDPR and ePrivacy, as long as the usage also aligns with that (example: you also can't cheat and use AI or whatever to break privacy post-facto).
"Everything needs cookie banners" is a take as bad as "Nothing needs cookie banners".
> You can collect anything without limits as long as you don’t associate this data with identification data / profiles.
That's completely wrong, the whole article is about the issue of reading data from the visitors device and needing a cookie banner for that. So you can't "collect anything without limits" in fact you can't collect any data from the visitor device. Which leaves a very narrow option of counting without using things from the device.
> in fact you can't collect any data from the visitor device
But this is not true.
You can definitely collect and store all sorts of data (including PII) for legitimate purposes, and without a cookie banner. For example: collecting and storing data required to provide the service itself requested by customers, login data, collecting address for delivering a package, shopping cart persistence, language selection, some preferences, fraud detection, rate limiting, DDOS protection, JS polyfill application, logging, resolution optimization.
By the way, ePrivacy is not really about the data collection itself (this is more in the GDPR's wheelhouse), but rather about storage in the user's device, among other things.
For the legitimate purposes regulated by the ePrivacy Directive, the Matomo link in the article also mentions it, in the "When Consent Is Not Required" section. You posted a link to it yourself, here: https://news.ycombinator.com/item?id=42820474
Here's a demonstration of how cookie banners are redundant if you only have legitimate purpose: you can click "deny" and the website still works and performs collection and storage. "To still work" is legally required by the GDPR. For those cases, all you need is a Privacy Policy.
In fact it would be impossible to comply to both ePrivacy and GDPR at the same time if consent was required for legitimate purpose actions!
And of course: as long as you reuse any of this legitimately collected data for advertising or analytics, you need extra consent, but I assume this is clear.
The pendulum is swinging back but or 5+ years and arguably today still most people think collecting any data is too much. i.e They want total anonymity.
Personally I want a middle ground for Page View, returned visitors within ~30 days, but this isn't a popular view on HN.
Technically you need one, because you're using session storage for something that is not strictly necessary to make the page work. It's in the article.
An amount of visitors isn’t creating any privacy concern. That would be another situation if you stored individual completion rates associated with, say, an IP or worse, an user account. You would still technically be able to do it but not without clear consent from the user.