Live data from Hacker News

Do cookie-free analytics need cookie banners?

jfagerberg.me

81–88 of 88 posts

Re: Do cookie-free analytics need cookie banners?

#81

I disagree with the author's assessment: - There is no way the browser can be instructed to not send the browser agent. Moreso it could be argued that this is needed for making the site work (legitimate interest). Though yes, if it's an extra call to an external URL I would say this is problematic - As mentioned by the Plausible opinion, it is not being stored. It is also not an unique identifier As an addendum, when…

> Moreso it could be argued that this is needed for making the site work (legitimate interest).

If you process the UA to "make the site work" then yes. One example for that would be a site that has the purpose of showing the visitor their user agent string (like "what is my IP?" sites do for your IP). Another might be to provide a different view for mobile devices though that has largely been solved with responsive design.

If you process the UA to fingerprint visitors to "improve the experience" by showing them ads or performing usage analytics over time to see what works and what doesn't, that's different. Arguably analytics can have a legal basis other than consent but that doesn't give you a carte blanche for what data you can use and how.

> it is not being stored

That doesn't really matter as long as it is PII as processing PII still requires a legal basis even if you don't store it. Collecting, processing, storing and sharing all require a legal basis even if that basis might be trivial.

Re: Do cookie-free analytics need cookie banners?

#82
post #48

Earlier quoted context omitted.

The ePD is intended to be replaced by the ePR but the ePD has already been implemented in several countries so it's a good abstraction of those implementations if you don't want to look at the specifics of each one individually. > Some states like Germany didn't change any laws at all regarding the EPD. This is false. Germany implemented the ePD[0] by replacing the TKG with the TDDDG in 2021. You may have missed this…

> Germany implemented the ePD[0] by replacing the TKG with the TDDDG in 2021. At that point, the GDPR was already in force. The GDPR is mostly a superset of the ePD, so I don't think the TDDDG lead to substantial changes.

That's again false. It is also nonsense.

The original ePD was issued in 2002 and implemented by Germany in an update to the TKG in 2004 (and in an update to the UWG if you want to be pedantic). This precedes the GDPR by 12 years.

The GDPR is not a superset of the ePD. The GDPR did however lead to the recasting of the ePD in directive 2018/1972/EU (to clarify some ambiguities/conflicts created by the GDPR), which is what in turn led to the creation of the TTDSG which implemented the recast ePD and replaced parts of the TKG and TMG. The TTDSG in turn was renamed to the TDDDG when the DDG replaced the TMG due to the EU Digital Services Act.

So my statement that the TDDDG implemented the ePD was not entirely correct as the full story is a bit more complicated: the ePD was implemented in the TKG in 2004, the TTDSG implemented the recast ePD in 2021, the TTDSG was renamed to TDDDG in 2024. Also the TKG itself still exists, however parts of it were moved into the TTDSG/TDDDG.

But saying that the ePD did not lead to any changes in German law is wrong for both the original ePD and the recast ePD. Saying that the GDPR is a superset of the ePD is also wrong because if this were true, the ePD could have simply been replaced instead of having to be recast. And saying that the TDDDG didn't lead to substantial changes is only technical correct when referring to the renaming of the TTDSG to the TDDDG (which, again, was due to the EU DSA, not the EU GDPR nor ePD) but is, again, wrong when referring to the underlying TTDSG.

Here's a fairly comprehensible German language article about some of the changes in the TTDSG:

https://cms.law/de/deu/publication/das-neue-ttdsg-ist-in-kra...

Of course "substantial changes" is subjective but that's different from what you originally claimed about Germany "not changing laws at all", which I've hopefully demonstrated isn't true by any means.

Re: Do cookie-free analytics need cookie banners?

#83
post #47

Earlier quoted context omitted.

An address is already PII, whether you pseudonymize it with apartment numbers or not. Also I think in practice the bigger concern with IPs is that the IP itself is PII at the time you collect it, so you're always processing PII even if the hash or other such "anonymized" data you store may end up not technically being PII if there's no way to correlate it to an actual person after the fact (which wouldn't be the case…

> An address is already PII, whether you pseudonymize it with apartment numbers or not. The full address is PII. But a street level address isn't necessarily, if it points to an appt block. The problem with the mail boxes is that you're leaking that a "Mr. Smith" is living at that address. Now with Mr. Smith this is not such a big problem but if you're looking for "Mr. LessUnique" then it is

If you're arguing that landlords should have to get written consent to post a tenant's name on the mail boxes and door bell, then I agree. If we're talking about tenants doing it themselves, then there's no privacy issue unless someone else collects that information and uses it for other purposes.

Re: Do cookie-free analytics need cookie banners?

#84
post #78
post #34

Earlier quoted context omitted.

Most of these "cookie free" analytics vendors keep talking about how cleverly they have anonymised the data, but this article finally gets it right: That does not matter for cookie popups. Anonymisation is only relevant to GDPR, but you still need cookie banners under the ePrivacy directive.

> you still need cookie banners under the ePrivacy directive Only if you store data in the browsing (using cookies, localStorage, or any other technical means), no?

The article claims that loading JavaScript that sends back information comes under the ePDs definition of accessing stored data:

> So sending out JavaScript code that instructs the terminal equipment to send back information is… accessing the information.

Re: Do cookie-free analytics need cookie banners?

#86
post #2

If they're doing fingerprinting then they're clearly collecting too much data. If they need javascript to collect their metrics, they're clearly collecting too much data.

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?

>Surely that is not too much?

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.

Re: Do cookie-free analytics need cookie banners?

#87
post #68
post #50

I’m so tired of the popups. YOY DON’T NEED A POPUP TO USE COOKIES! Just stop tracking people across sites and you’re good. Cookies, localstorage or fingerprinting makes no difference. The distinction is whether you track users or not. You are allowed to use cookies to your heart’s content, as long as the cookie is necessary for the functionality of your site, like a session id, or a shopping cart id. > [You must] Rec…

For my mom‘s small business, I actually tried to craft something compliant by hand (because I can). It’s surprisingly hard to get it right! Like, don’t load external scripts unless consent has been given, reflect that in the interface, and allow to withdraw consent. For example, there’s a maps embed showing the store address. But that’s can only be displayed if you actually consent to the prompt! So that means you’ll…

The easy solution is to just not load external scripts. Done.

Re: Do cookie-free analytics need cookie banners?

#88
post #82

Earlier quoted context omitted.

> Germany implemented the ePD[0] by replacing the TKG with the TDDDG in 2021. At that point, the GDPR was already in force. The GDPR is mostly a superset of the ePD, so I don't think the TDDDG lead to substantial changes.

That's again false. It is also nonsense. The original ePD was issued in 2002 and implemented by Germany in an update to the TKG in 2004 (and in an update to the UWG if you want to be pedantic). This precedes the GDPR by 12 years. The GDPR is not a superset of the ePD. The GDPR did however lead to the recasting of the ePD in directive 2018/1972/EU (to clarify some ambiguities/conflicts created by the GDPR), which is w…

Aren't these details are mostly irrelevant? Can you name one additional requirement introduced with TTDSG or TDDDG which wasn't covered by the GDPR already?
Post reply on HN