The beauty of GDPR is that it clearly distinguishes between a "data processor" and a "data controller". Services such as cloud computing providers, including databases used to store data, are merely data processors. You, the contracting party, would be the data controller, held liable for anything that happens with the data.
On the other hand, you have a business relationship with your services provider, and you're free to hold them accountable to any claims in the contract. In my experience, however, any liability is capped to some meager amount in the default ToS.
To answer your question, you need to clarify what you'd be liable for. When you're the data controller, the answer to your question is almost always yes.
I've long been of the opinion that the GDPR was a misstep when the plaintext read of it put default apache logging into the legally-ambiguous space.
When you make basic bedrock ages-old web behavior illegal, the web's gonna win, not the law. In most places, anyway. Good luck fairly and successfully policing every single neophyte admin not knowing that the first software every tutorial suggests you use is now illegally-configured in Europe out of the box.
(The result is, of course, that the law ends up unfairly enforced, which could be considered worse depending on one's legal philosophy.)
The Apache logging can fall under legitimate interest for security/fraud prevention/debugging purposes, as long as it's kept for a reasonable duration (I keep mine for 3 months) and is not used for any other purpose such as marketing or analytics.
Is it not incumbent upon the admin to prove they didn't use the data for analytics? If so, that makes the data default-radioactive where before GDPR it was legally harmless.
And what is "analytics" exactly? If a one-person outfit happens to be skimming the logs and notices "Oh, neat, that's a lot of IP addresses from Germany," did they just do analytics?
> If a one-person outfit happens to be skimming the logs and notices "Oh, neat, that's a lot of IP addresses from Germany," did they just do analytics?
Yes.
However enforcement is intentionally discretionary and selective and hence sensitive / prone to political, protectionist and sentimental whims. Your 1 person outfit in Europe is less likely to suffer in actual court, or the court of public opinion, than a big bad American tech company will.
Maybe it's just personal preference, but I find "This criminalizes a very common behavior, but don't worry, prosecutors will use broad discretion while enforcing it and only enforce it on the right sort of people" to be very, very disquieting.
It's how you get war-on-drugs-level legal atrocities.
What I miss the most, and where the most damage to the net has been done so far, is in terms of whois. Without WHOIS it's become near impossible to contact people. Before you'd find an interesting domain, whois, email 'em up. Now that GDPR has made whois illegal, or a high enough legal risk that registrars are chosing to turn it off, there's no way to contact any arbitrary domain. It's made the web a lot more impersonal and corporate.
Eh, I never had much success with at least corporate whois email addresses even before they started being effectively removed (by registrars masking them, years before GDPR). Even addresses like postmaster@ which are mandated by the SMTP spec (RFC 5321 §4.5.1 and other places) don’t tend to work.
Making companies liable for the data they collect is a very good thing. Before GDPR logging everything was the default. Now, every business has to think about what data they collect, what purpose it serves, which parties the data is shared with, and when the data will be deleted.
GDPR, like any big new law, has plenty of weird unintended consequences. But it’s a major step forward for privacy and consumer data rights regardless.
Also there has been a huge amount of malicious compliance (though frankly it mostly doesn’t actually legally comply), deliberately muddying the waters and poisoning people’s impressions of GDPR and ePD. People have been convinced to blame GDPR rather than the businesses that have built themselves upon doing hostile and creepy stuff.
(Cookie banners are the most obvious example of this. The businesses say “our hands are tied, the EU told us to do this”, whereas in actual fact the EU more told them to stop doing the storing and collecting. And very few cookie banners and such actually comply, and they made them a much bigger deal than they should have legally. All up there was very clear intent to poison perception in many cases.)
I agree with all your observations. Enforcement actions will slowly nudge businesses into compliance, but this will easily take another decade. It takes a long time for the law to solidify in the courts.
If you're trying to regulate a bunch of bad actors, and you don't anticipate that they will try to game whatever regulations you come up with, you are not doing your job well.
Sure they should have and probably did expect that there would be bad actors. But should they have expected that pretty much all businesses and even individuals would rather make their users miserable than give up tracking them? Is people adding cookie banners for their personal blogs because they are that addicted to meaningless analytics something anyone would have expected?
Also, a lot of the problems are not bad actors finding ways around the law but straight up violating it. The most prominent example is the consent bannes that try to discourage the deny option in various ways. The lawmakers did anticipate that kind of maliciousness and made sure to disallow it. What is lacking is mostly enforcement, and that is not something the lawmakers control.
> Is people adding cookie banners for their personal blogs because they are that addicted to meaningless analytics something anyone would have expected?
Yes, emphatically. It's a one-time change for the admin that allows them to maintain the status quo, and they don't visit the site as often as users do.
They always were liable. But of course, people would have to show they were actually harmed in some way by being “tracked”. GDPR makes it illegal to collect data that doesn’t cause any demonstrable harm to anyone.
I don’t get it. Why not just set a 24-hour cookie scoped to the path, and every request without the cookie is logged as a “unique visit”.
That gives unique visits by device within a 24 hour period, per page, with no logging of any ID/IP whatsoever. You can pair this with signup counts or campaign codes to get conversion rate by channel, all without any nonsense “anonymized” user IDs.
ePrivacy Directive says you can’t store that cookie without consent (since it’s not in any way essential).
More generally: analytics mustn’t rely on storing anything on the user’s device for its functionality; that’s why people head in the direction of fingerprinting.
In the article they point out that anything that can be used to identify one click and link it to a subsequent click - in your example the cookie - is considered person hall data. This is because you may be able to de-anonymise a person from the pattern of their interactions.
The cookie is the same for all users. There is no value unique to each user. All that is logged is “a visit to this page occurred at X time” and if the request contained the cookie then it is marked “unique”. The cookie value is the same for everyone.
What should matter is what’s logged. Every request contains an IP that’s how the web works.
Back in 2012 the EU’s Article 29 Data Protection Working Party* published an rather readable opinion about the different cookie consent exemptions. Yes, first party analytics are not essential. The WP29 even proposed to exempt them in a hypothetical future privacy directive.
The WP29 is superseded by the European Data Protection Board and there seem to be proposals for an updated ePrivacy Regulation making their way through the system. Signals are mixed. The proposal by the commission from 2017 mentions the usefulness of analytics cookies as a possible exemption. The EDPB on the other hand gives the opinion that a future ePrivacy Regulation should not lower the level of protection offered by the current ePrivacy Directive and looks not kindly on possible exemptions, but describes an exemption for an audience measurement as “very limited privacy risk for the users”.
Interesting. Maybe there is a possibility in the future.
That would require you to now have all users opt-in to cookies on your site where they didn't have to do that before.
... because users absolutely love clicking through those annoying opt-in compliance boxes. So the admin now has the choice of no longer having that data or damaging UX.
The law seems pretty clearly bent on just not letting web admins collect that bedrock baby's-first-metric anymore for European users.
You can do basically this without cookies with daily random salt (which is not stored longterm) added to the ip + useragent hash mentioned in the article.
You can completely, at all, avoid storing PII for the purpose of estimating the number of unique visitors. The answer is to use HyperLogLog (see e.g. https://en.wikipedia.org/wiki/HyperLogLog or http://antirez.com/news/75) on a strong fingerprint of the user's device. In this case, only some small amount of aggregate data across all seen fingerprints is stored.
NB: this is completely irrelevant except as a mathematical curiosity, because GDPR prohibits any processing of PII (in this case - the fingerprint), not just storing it anywhere, without a legal basis.
> NB: this is completely irrelevant except as a mathematical curiosity, because GDPR prohibits any processing of PII (in this case - the fingerprint), not just storing it anywhere, without a legal basis.
Hmm, but using PII in anonymized form is allowed, right? But how do you anonymize PII without processing it?
Because that involves storing a cookie, which you're not allowed to do except as necessary to operate the site without first gaining consent.
I use Plausible, which works by hashing IP addresses. Honestly, I disagree with the analysis as given: the claim is that we're assigning a unique ID to each user, but it's really not doing that -- the ID changes, and more than one user may have the same ID.
GDPR is a balancing act, between the rights of the people involved and the desires of data controllers to have useful data. In practice, Plausible presents (at least to my mind) a solution to my legitimate interests with a privacy impact that's suitably minimal for the level of interest I have in the statistics I collect. A cookie is arguably less privacy-preserving, as it has better specificity.
I am a SWE (IANAL) with a post-grad degree in GDPR/DPO, and while I had only time for a cursory read, I must say it hits a lot of nails on the head! A breath of fresh air in times of so much GDPR misinformation.
From what I remember, the ePrivacy-GDPR cookie mismatch (consent as the only allowed legal basis for cookies) is due to ePrivacy being older than the GDPR and not intentional.
Article 5 (Principles) is always a good mention - just having a legal basis is not enough, you always need to respect these principles (such as lawfulness, fairness and transparency).
The dig at pseudonomyzation not being enough is great. It's a personal pet peeve of mine. Pseudonomized data is still personal data!
The GDPR does not prescribe how to anonymize data. It just says "as long as someone can identify a person, then it's personal data." For example, you might think that aggregating based on city is enough to anonymize, but my nephew was at one point the sole person living in a village - that would have directly identified him. Likewise, stripping the last octet of IP addresses might not be enough if I personally own a /24. It's all about context.
The biggest thing I personally learned, was that any solution claiming to be "GDPR proof" probably is not compliant.
This is one of my pet peeves of GDPR! Your nephew and IP Octet cases are very extreme edge cases that we shouldn't build policy around if there are major drawbacks to including them. It's bad there is ostensibly no compliant way to count anonymized unique users in Europe under the current framework.
I don't think there is any way to reliably count unique users without collecting an inappropriate level o f personal data. Even tracking unique devices requires significantly undermining privacy.
This simply isn't data companies should be allowed to collect without meaningful consent.
A half-baked idea I had while reading the article was to use bloom filters:
User visits the site. On the backend, check if their IP+UA is in the bloom filter or not. If not, increase the unique visitor counter and add them to the filter.
Perhaps the filter would need to be preseeded with dummy data to protect the privacy of the first few visitors.
This is effectively what the “GDPR compliant” providers mentioned in the article are already doing, namely, a one-way hash of the IP+UA. One of the points of the article is that this is non compliant, since you need to transmit the IP+UA to do this calculation to begin with.
But do they store individual IP+UA hashes, or do they mush them together in a bloom filter or a HyperLogLog data structure?
In the first case, it could be argued they still store personally identifiable information (for a limited time, but still). In the second case I think it would be harder to argue the probabilistic data structure with lots of hashes mushed together still constitute personally identifiable information.
> One of the points of the article is that this is non compliant, since you need to transmit the IP+UA to do this calculation to begin with.
IP + UA gets transmitted to the first-party server already. They already have it. The question becomes – is it OK to anonymize this PII we already received for one purpose (serving the web page), to use it for another purpose also (counting unique visitors).
> IP + UA gets transmitted to the first-party server already. They already have it. The question becomes – is it OK to anonymize this PII we already received for one purpose (serving the web page), to use it for another purpose also (counting unique visitors).
Maybe I'm missing your point, but in the situation we're talking about (so-called "GDPR compliant" analytics), if I set up one of these services on my website, the user's IP+UA are transmitted to a 3rd party, for the sole purpose of analytics including counting unique visitors. My understanding is that this is quite different in the eyes of the GDPR from the question you posed, and is almost always not going to be compliant.
I was thinking about the article author's case where they were looking at options for implementing unique user tracking for themselves, on their own server.
Author of the article here! (I tried to submit it but HN rejected it)
I started researching this last weekend, reading through the GDPR, the ePrivacy Directive, and tons of related court rulings (with the help of Google Translate). 2002/58/EC and EC 2016/679 is engrained into my brain now. I was so nervous releasing to the public, but I breathed a sign of relieve after reading your comment.
What I don't understand is how come nobody talks about Microsoft Clarity? I don't know anything about GDPR but I would think if anything violates GDPR, it would be a literal screen recording app that tracks your mouse movements and can show literally where you put your mouse and your moves on the screen.
And yet:
> Clarity is GDPR-compliant as a data controller. For more information, see the Microsoft Privacy Statement.
If you use clarity (you are the controller, ms the processor) you are responsible for obtaining the necessary consent from your users. That consent should make it clear to the user what behavioral data is collected.
(Commonly referred to as cookie banner).
I think there are a few incorrect logical leaps in here. An identification number is only regulated insofar as it can be used to "identify a natural person". The law is referring to something like driver's license # or customer ID number or username or etc (or, increasingly, an IP address).
Within the spirit of the law, it's okay to say "this is user 1, this is user 2, etc". Pseudo-anonymous data has been specifically called out several times as fine.
In that context, the author is really stretching to claim that any amount of "fingerprinting" is deanonymizing. But there's not a lot of evidence that a fingerprint, no matter how good of one, is in violation of GDPR until it can be tied to a natural* person*.
Author here - I've gotten this question a few times now so I'll update the article to better explain it, but "online identifiers" are considered personal data according to Article 4. Recital 30 states:
"Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers (...)"
From this, I think we can assume any id connected to a device (and thus user) that can be used re-identify it can be considered personal data, regardless of the time-frame, especially since it mentions "cookie identifiers."
> Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.
Just from the phrasing of this recital, it's pretty clear that "unique identifiers and other information received by the server" are not regulated here.
Furthermore:
Article 4.5:
> ‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person;
Again, without the use of additional information is key. Just because it can be de-anonymized doesn't mean that it is.
Recital 29:
> In order to create incentives to apply pseudonymisation when processing personal data, measures of pseudonymisation should, whilst allowing general analysis, be possible within the same controller when that controller has taken technical and organisational measures necessary to ensure, for the processing concerned, that this Regulation is implemented, and that additional information for attributing the personal data to a specific data subject is kept separately. 2The controller processing the personal data should indicate the authorised persons within the same controller.
I have spent a LOT of time with on our GDPR team. And while GDPR is horrendously complex, I don't think anyone on our legal team would support the assertion that GDPR is countermanding itself.
Also, notice the phrasing "whilst allowing general analysis" - completely separate from Legitimate Interest, GDPR allows for "general analysis" of pseudoanonymous data.
This article is incomplete without any mention of strong privacy techniques such as differential privacy.
There is a write-up by Cohen and Nissim [1] where they analyze the privacy statutes in the GDPR and derive a formal definition of privacy, which they call Privacy Singling Out, intended to match the text of the document.
They then show how PSO compares to other privacy definitions, and in particular that Differential Privacy implies PSO (and thus satisfies GDPR). Differential Privacy, in turn, is basically an entire field on its own, with entire textbooks [2] and workshops [3]. It also dominates many privacy-focused conferences, and has been used by US Census Bureau.
There are plenty of truly GDPR-compliant analytics one can do. It just takes some effort to understand how.
Not a lawyer, but sat in waaaay too many meeting with lawyers on this very subject as we built a GDPR framework for a past-employer.
It certainly means well but makes a number of jumps that are wrong or untested.
For example; some things flagged as personal data (like IP address) are not always considered personal data depending on how it is used. Like, logging IP addresses for the purpose of security is an extremely widespread practice and considered necessary.
Likewise, storing data on a personal device (like a cookie) is ok if it is necessary for the service to function (as opposed to unnecessary tracking data or non-critical information). Storing data that manages a session, log-in state, shopping cart, dark-mode preference, is ok)
If IP addresses are considered PII, we can basically shut down the internet. They are necessary to protect against spammers and attacks. Also, as you have mentioned, an IP address can _not_ be linked to a natural person, as you can't tell who it belongs to without context. For an ISP for example an IP address is linked to a customer, everyone else can only guess who it belongs to. You won't be able to get the exact location or tell how many people are in the household with just the IP address.
I'm ready to get downvoted by the "we don't want any analytics" crowd on HN.
"Die dynamische IP-Adresse stellt für einen Webseitenbetreiber ein personenbezogenes Datum dar, denn der Webseitenbetreiber verfügt abstrakt über rechtliche Mittel, die vernünftigerweise eingesetzt werden könnten, um mithilfe Dritter, und zwar der zuständigen Behörde und des Internetzugangsanbieters, die betreffende Person anhand der gespeicherten IP-Adressen bestimmen zu lassen (BGH, Urteil vom 16.05.2017 - VI ZR 135/13). Dabei reicht es aus, dass für die Beklagte die abstrakte Möglichkeit der Bestimmbarkeit der Personen hinter der IP-Adresse besteht. Darauf, ob die Beklagte oder X. die konkrete Möglichkeit hat, die IP-Adresse mit dem Kläger zu verknüpfen, kommt es nicht an." - "The dynamic IP address represents personal data for a website operator, because the website operator has abstract legal means that could reasonably be used to identify the person concerned using the stored IP to have addresses determined (Federal Court of Justice, judgment of May 16, 2017 - VI ZR 135/13). It is sufficient that the defendant has the abstract possibility of identifying the persons behind the IP address. Whether the defendant or X. has the specific opportunity to link the IP address to the plaintiff is irrelevant." (translated by google) (https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/ - Ruling by the Regional Court Munich)
As far as I understood, it all depends on your intention, not on the data itself. Yes, you can store someones email address if it's necessary to run your service. If you don't have a legal basis, you can't.
I think it's comparable to an id card number. This should be considered personal, because it's unique and links a user to a real person. You can't identify them in the real world, because you don't have access to a government database.
Reminder: I'm not a lawyer, so this isn't legal advice.
Alright, so no more DDoS protection or rate limiting. Do we need consent before a router or switch on the network can process traffic? Isn't the ISP violating the GDPR if they hand out information about a customer to third parties without consent? What about servers that have logs turned on (Apache) before GDPR went into effect?
I know the opinion of lawyers about IP addresses. But it's so far from reality that it would break the internet if strictly followed.
"Handling personal data
Personal data may not be processed, including its storage and transmission, without a legal basis (Article 6). These legal bases are not applicable to cookies.
Consent: The user has given clear consent for a specific purpose with an affirmative action.
Contractual obligation: ‘Contract’ in this case may include terms of service.
Legal obligation
Vital interests: Saving one’s life.
Public task
Legitimate interests"
This was in the article, having security logs probably counts as a legitimate interest. Also ISPs giving away your information without your consent and reason is violating the GDPR.
Reminder: I'm not a lawyer, so this isn't legal advice.
IP addresses aren’t being considered not personal data (expressed without the double negative: IP addresses are still personal data), they’re just being processed under the “legitimate interest” lawful basis when it comes to things like security.
Storing functional cookies: the article discussed this in the ePD section, look for “strictly required”.
The entire document (https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...) isn’t short: 54,000 words. But it’s very skimmable so that you can obviously skip quickly over the considerable majority as irrelevant to your situation, and generally pretty easy to read. The parts relevant to the typical developer or business person are actually only a few thousand words of chapters 1–4. I recommend just reading it if it might be relevant to your business, rather than relying on others’ writings about it.
Most of the lawyerly arguments come from people trying to justify bad stuff that they used to get away with but which is clearly contrary to the spirit and generally text of GDPR. (This is my uncharitable description.)
The EU should be blocked from the greater internet until they can fix their laws to be compatible with an open internet. The fact that it is illegal to link to third party sites is ridiculous. I much prefer an internet where sites can freely link to other sites and they can freely do analytics to improve their services. Having to get consent has made the web annoying to use because now every site needs to get your consent.
No it doesn’t. You’ve been conned. Look at what they’re trying to get your consent for, and you will find that you would almost always prefer that they not do it.
Ah, I take it you’re referring to the Google Fonts case, then? That’s completely different from linking to a third-party site: that’s loading resources from a third-party site. For a hyperlink, any fetching is user-initiated and you’re obviously not on the hook for that. (The one arguable exception is if you explicitly cause prefetch or prerender on, say, link hover. That would then obviously be on you, because you made it happen.)
> It does if they want to flow the law.
No, they can just not do it. Simplifying very slightly: they’re trying to get your consent precisely because they don’t have to do it, therefore they’re not allowed to without consent. I would also note that the sort of consent they solicit on public websites is practically always for storing stuff on your machine (ePD, from 2002) rather than for processing (GDPR, from 2016). But I lack energy to get further involved in this aspect; suffice it to say that their tracking is basically never in your interests at all, and routinely not even in their direct interests.
Which is what browsers can do for link tags. Some browser scan for links on pages and speculatively load them so that if you were to click on them it loads instantly. You as the website author can't prevent this functionality.
>No, they can just not do it
But they want to do it and may have business reasons to do it.
>their tracking is basically never in your interests at all
The tracking likely either improves the service based off analytics which is in my interest or it makes ads more relevant which makes the site more financially viable which is also in my interest if I am gaining value from that site.
> Some browser scan for links on pages and speculatively load them so that if you were to click on them it loads instantly.
Anything like that is user (the browser acting as their agent). You’re obviously not responsible for that. You didn’t ask it to do that automatically, unlike <link rel="stylesheet"> and <script> and the likes.
How is the link tag any different? It's also a link which is optional to access. One's user agent could choose not to request it. script tags are optional too.
Things like <link rel="stylesheet">, <script> and <img> are subresources: instructions to the browser to fetch and use the specified resource, so that the page can be rendered properly. As you say, the user agent can choose to ignore these instructions (and text-mode browsers will generally ignore all three of these subresource types), but the page will probably be materially compromised, and the developer placed the subresource there with the expectation that it will be loaded.
A hyperlink is a reference to another page altogether, that it’s up to the user to access if they choose to. It’s not a subresource.
> Having to get consent has made the web annoying to use because now every site needs to get your consent.
I don't understand why it wasn't immediately obvious to browser vendors that this was going to be how web developers responded to GDPR; and that the browser vendors could/should get ahead of this degradation of the quality of the web-browsing experience by giving the user a way to do GDPR consent at the browser-chrome level by e.g. ticking a box in the browser preferences that will set a request header. (It didn't work for Do Not Track, but Do Not Track is a "request" to a malicious adversary; while "I consent to cookies, so stop prompting me" isn't.)
I can only guess that browser vendors don't like GDPR, and so are avoiding implementing such a GDPR quality-of-life feature in order to ensure that users get just as annoyed by the cookie prompts as they should be, and eventually demand the law be changed.
Browser vendors seem to think it's perfectly fine to add a bunch of new "low-entropy" Client-Hint request headers. Where the difference between high- vs low-entropy seems to be literal: if the header is just one bit, then the browser vendors don't consider it to be a problem for deanonymization purposes.
As someone who prefers to focus on the product, post GDPR, here are some technologies which are just safer to not have, even on a non-ad-driven website, unless you like spending time arguing with lawyers and bureaucrats:
You can do a lot of analytics without touching personal data. Page view counts, countries people visit from (assuming it's low enough granularity (not personally identifiable) and you don't use a third party service), times people visit. All the juicy stuff, really.
You can use third-party resources if you self host them (like fonts, images, videos, ...).
Not sure about CDNs, but I don't think a global CDN that's GDPR compliant can exist.
85 comments
[ 6.5 ms ] story [ 125 ms ] threadOn the other hand, you have a business relationship with your services provider, and you're free to hold them accountable to any claims in the contract. In my experience, however, any liability is capped to some meager amount in the default ToS.
To answer your question, you need to clarify what you'd be liable for. When you're the data controller, the answer to your question is almost always yes.
When you make basic bedrock ages-old web behavior illegal, the web's gonna win, not the law. In most places, anyway. Good luck fairly and successfully policing every single neophyte admin not knowing that the first software every tutorial suggests you use is now illegally-configured in Europe out of the box.
(The result is, of course, that the law ends up unfairly enforced, which could be considered worse depending on one's legal philosophy.)
And what is "analytics" exactly? If a one-person outfit happens to be skimming the logs and notices "Oh, neat, that's a lot of IP addresses from Germany," did they just do analytics?
Yes.
However enforcement is intentionally discretionary and selective and hence sensitive / prone to political, protectionist and sentimental whims. Your 1 person outfit in Europe is less likely to suffer in actual court, or the court of public opinion, than a big bad American tech company will.
It's how you get war-on-drugs-level legal atrocities.
I don't consider it a loss that there's one less place my phone number and address is posted online.
GDPR, like any big new law, has plenty of weird unintended consequences. But it’s a major step forward for privacy and consumer data rights regardless.
(Cookie banners are the most obvious example of this. The businesses say “our hands are tied, the EU told us to do this”, whereas in actual fact the EU more told them to stop doing the storing and collecting. And very few cookie banners and such actually comply, and they made them a much bigger deal than they should have legally. All up there was very clear intent to poison perception in many cases.)
Also, a lot of the problems are not bad actors finding ways around the law but straight up violating it. The most prominent example is the consent bannes that try to discourage the deny option in various ways. The lawmakers did anticipate that kind of maliciousness and made sure to disallow it. What is lacking is mostly enforcement, and that is not something the lawmakers control.
Yes, emphatically. It's a one-time change for the admin that allows them to maintain the status quo, and they don't visit the site as often as users do.
That gives unique visits by device within a 24 hour period, per page, with no logging of any ID/IP whatsoever. You can pair this with signup counts or campaign codes to get conversion rate by channel, all without any nonsense “anonymized” user IDs.
More generally: analytics mustn’t rely on storing anything on the user’s device for its functionality; that’s why people head in the direction of fingerprinting.
What should matter is what’s logged. Every request contains an IP that’s how the web works.
https://ec.europa.eu/justice/article-29/documentation/opinio...
The WP29 is superseded by the European Data Protection Board and there seem to be proposals for an updated ePrivacy Regulation making their way through the system. Signals are mixed. The proposal by the commission from 2017 mentions the usefulness of analytics cookies as a possible exemption. The EDPB on the other hand gives the opinion that a future ePrivacy Regulation should not lower the level of protection offered by the current ePrivacy Directive and looks not kindly on possible exemptions, but describes an exemption for an audience measurement as “very limited privacy risk for the users”.
Interesting. Maybe there is a possibility in the future.
https://digital-strategy.ec.europa.eu/en/library/proposal-re...
https://edpb.europa.eu/sites/default/files/files/file1/edpb_...
... because users absolutely love clicking through those annoying opt-in compliance boxes. So the admin now has the choice of no longer having that data or damaging UX.
The law seems pretty clearly bent on just not letting web admins collect that bedrock baby's-first-metric anymore for European users.
In the cookie case, you can detect a returning visitor by the presence of the cookie, you do not need to assign an unique identifier.
In the hashing case, the hash of the IP and UA counts as PII, at least for the 24 hours while you still have the salt.
NB: this is completely irrelevant except as a mathematical curiosity, because GDPR prohibits any processing of PII (in this case - the fingerprint), not just storing it anywhere, without a legal basis.
Hmm, but using PII in anonymized form is allowed, right? But how do you anonymize PII without processing it?
I use Plausible, which works by hashing IP addresses. Honestly, I disagree with the analysis as given: the claim is that we're assigning a unique ID to each user, but it's really not doing that -- the ID changes, and more than one user may have the same ID.
GDPR is a balancing act, between the rights of the people involved and the desires of data controllers to have useful data. In practice, Plausible presents (at least to my mind) a solution to my legitimate interests with a privacy impact that's suitably minimal for the level of interest I have in the statistics I collect. A cookie is arguably less privacy-preserving, as it has better specificity.
From what I remember, the ePrivacy-GDPR cookie mismatch (consent as the only allowed legal basis for cookies) is due to ePrivacy being older than the GDPR and not intentional.
Article 5 (Principles) is always a good mention - just having a legal basis is not enough, you always need to respect these principles (such as lawfulness, fairness and transparency).
The dig at pseudonomyzation not being enough is great. It's a personal pet peeve of mine. Pseudonomized data is still personal data!
The GDPR does not prescribe how to anonymize data. It just says "as long as someone can identify a person, then it's personal data." For example, you might think that aggregating based on city is enough to anonymize, but my nephew was at one point the sole person living in a village - that would have directly identified him. Likewise, stripping the last octet of IP addresses might not be enough if I personally own a /24. It's all about context.
The biggest thing I personally learned, was that any solution claiming to be "GDPR proof" probably is not compliant.
This simply isn't data companies should be allowed to collect without meaningful consent.
User visits the site. On the backend, check if their IP+UA is in the bloom filter or not. If not, increase the unique visitor counter and add them to the filter.
Perhaps the filter would need to be preseeded with dummy data to protect the privacy of the first few visitors.
In the first case, it could be argued they still store personally identifiable information (for a limited time, but still). In the second case I think it would be harder to argue the probabilistic data structure with lots of hashes mushed together still constitute personally identifiable information.
> One of the points of the article is that this is non compliant, since you need to transmit the IP+UA to do this calculation to begin with.
IP + UA gets transmitted to the first-party server already. They already have it. The question becomes – is it OK to anonymize this PII we already received for one purpose (serving the web page), to use it for another purpose also (counting unique visitors).
Maybe I'm missing your point, but in the situation we're talking about (so-called "GDPR compliant" analytics), if I set up one of these services on my website, the user's IP+UA are transmitted to a 3rd party, for the sole purpose of analytics including counting unique visitors. My understanding is that this is quite different in the eyes of the GDPR from the question you posed, and is almost always not going to be compliant.
I started researching this last weekend, reading through the GDPR, the ePrivacy Directive, and tons of related court rulings (with the help of Google Translate). 2002/58/EC and EC 2016/679 is engrained into my brain now. I was so nervous releasing to the public, but I breathed a sign of relieve after reading your comment.
And yet:
> Clarity is GDPR-compliant as a data controller. For more information, see the Microsoft Privacy Statement.
https://learn.microsoft.com/en-us/clarity/faq
Is this true?
Although I am not sure why these would violate GDPR. Customer usage data is specifically exempt if it's anonymized.
Within the spirit of the law, it's okay to say "this is user 1, this is user 2, etc". Pseudo-anonymous data has been specifically called out several times as fine.
In that context, the author is really stretching to claim that any amount of "fingerprinting" is deanonymizing. But there's not a lot of evidence that a fingerprint, no matter how good of one, is in violation of GDPR until it can be tied to a natural* person*.
"Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers (...)"
From this, I think we can assume any id connected to a device (and thus user) that can be used re-identify it can be considered personal data, regardless of the time-frame, especially since it mentions "cookie identifiers."
> Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.
Just from the phrasing of this recital, it's pretty clear that "unique identifiers and other information received by the server" are not regulated here.
Furthermore:
Article 4.5:
> ‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person;
Again, without the use of additional information is key. Just because it can be de-anonymized doesn't mean that it is.
Recital 29:
> In order to create incentives to apply pseudonymisation when processing personal data, measures of pseudonymisation should, whilst allowing general analysis, be possible within the same controller when that controller has taken technical and organisational measures necessary to ensure, for the processing concerned, that this Regulation is implemented, and that additional information for attributing the personal data to a specific data subject is kept separately. 2The controller processing the personal data should indicate the authorised persons within the same controller.
I have spent a LOT of time with on our GDPR team. And while GDPR is horrendously complex, I don't think anyone on our legal team would support the assertion that GDPR is countermanding itself.
Also, notice the phrasing "whilst allowing general analysis" - completely separate from Legitimate Interest, GDPR allows for "general analysis" of pseudoanonymous data.
There is a write-up by Cohen and Nissim [1] where they analyze the privacy statutes in the GDPR and derive a formal definition of privacy, which they call Privacy Singling Out, intended to match the text of the document.
They then show how PSO compares to other privacy definitions, and in particular that Differential Privacy implies PSO (and thus satisfies GDPR). Differential Privacy, in turn, is basically an entire field on its own, with entire textbooks [2] and workshops [3]. It also dominates many privacy-focused conferences, and has been used by US Census Bureau.
There are plenty of truly GDPR-compliant analytics one can do. It just takes some effort to understand how.
[1] https://www.pnas.org/doi/10.1073/pnas.1914598117
[2] https://www.cis.upenn.edu/~aaroth/Papers/privacybook.pdf
[3] https://tpdp.journalprivacyconfidentiality.org/2022/
It certainly means well but makes a number of jumps that are wrong or untested.
For example; some things flagged as personal data (like IP address) are not always considered personal data depending on how it is used. Like, logging IP addresses for the purpose of security is an extremely widespread practice and considered necessary.
Likewise, storing data on a personal device (like a cookie) is ok if it is necessary for the service to function (as opposed to unnecessary tracking data or non-critical information). Storing data that manages a session, log-in state, shopping cart, dark-mode preference, is ok)
Thats just a sample.
This person should really consult a lawyer.
Reminder: I am not a lawyer.
If IP addresses are considered PII, we can basically shut down the internet. They are necessary to protect against spammers and attacks. Also, as you have mentioned, an IP address can _not_ be linked to a natural person, as you can't tell who it belongs to without context. For an ISP for example an IP address is linked to a customer, everyone else can only guess who it belongs to. You won't be able to get the exact location or tell how many people are in the household with just the IP address.
I'm ready to get downvoted by the "we don't want any analytics" crowd on HN.
"Die dynamische IP-Adresse stellt für einen Webseitenbetreiber ein personenbezogenes Datum dar, denn der Webseitenbetreiber verfügt abstrakt über rechtliche Mittel, die vernünftigerweise eingesetzt werden könnten, um mithilfe Dritter, und zwar der zuständigen Behörde und des Internetzugangsanbieters, die betreffende Person anhand der gespeicherten IP-Adressen bestimmen zu lassen (BGH, Urteil vom 16.05.2017 - VI ZR 135/13). Dabei reicht es aus, dass für die Beklagte die abstrakte Möglichkeit der Bestimmbarkeit der Personen hinter der IP-Adresse besteht. Darauf, ob die Beklagte oder X. die konkrete Möglichkeit hat, die IP-Adresse mit dem Kläger zu verknüpfen, kommt es nicht an." - "The dynamic IP address represents personal data for a website operator, because the website operator has abstract legal means that could reasonably be used to identify the person concerned using the stored IP to have addresses determined (Federal Court of Justice, judgment of May 16, 2017 - VI ZR 135/13). It is sufficient that the defendant has the abstract possibility of identifying the persons behind the IP address. Whether the defendant or X. has the specific opportunity to link the IP address to the plaintiff is irrelevant." (translated by google) (https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/ - Ruling by the Regional Court Munich) As far as I understood, it all depends on your intention, not on the data itself. Yes, you can store someones email address if it's necessary to run your service. If you don't have a legal basis, you can't.
I think it's comparable to an id card number. This should be considered personal, because it's unique and links a user to a real person. You can't identify them in the real world, because you don't have access to a government database.
Reminder: I'm not a lawyer, so this isn't legal advice.
I know the opinion of lawyers about IP addresses. But it's so far from reality that it would break the internet if strictly followed.
"Handling personal data Personal data may not be processed, including its storage and transmission, without a legal basis (Article 6). These legal bases are not applicable to cookies.
Consent: The user has given clear consent for a specific purpose with an affirmative action. Contractual obligation: ‘Contract’ in this case may include terms of service. Legal obligation Vital interests: Saving one’s life. Public task Legitimate interests"
This was in the article, having security logs probably counts as a legitimate interest. Also ISPs giving away your information without your consent and reason is violating the GDPR.
Reminder: I'm not a lawyer, so this isn't legal advice.
IP addresses aren’t being considered not personal data (expressed without the double negative: IP addresses are still personal data), they’re just being processed under the “legitimate interest” lawful basis when it comes to things like security.
Storing functional cookies: the article discussed this in the ePD section, look for “strictly required”.
I'm all for privacy but the EU really harmed SMEs that cannot afford expensive legal help.
The entire document (https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...) isn’t short: 54,000 words. But it’s very skimmable so that you can obviously skip quickly over the considerable majority as irrelevant to your situation, and generally pretty easy to read. The parts relevant to the typical developer or business person are actually only a few thousand words of chapters 1–4. I recommend just reading it if it might be relevant to your business, rather than relying on others’ writings about it.
Most of the lawyerly arguments come from people trying to justify bad stuff that they used to get away with but which is clearly contrary to the spirit and generally text of GDPR. (This is my uncharitable description.)
I'm not trying to justify bad stuff.
Even experts in the matter debate about it.
I've been reading about GDPR for weeks and am still not certain I have everything covered to launch my SaaS.
Especially Google is extremely GDPR unsafe. But also DigitalOcean is often not allowed.
But then Azure is an exception because of some legal mumbo jumbo microsoft convinced them off.
It’s not.
> now every site needs to get your consent
No it doesn’t. You’ve been conned. Look at what they’re trying to get your consent for, and you will find that you would almost always prefer that they not do it.
It is if you are linking to a site hosted in the US because if the browser preloads it you send your IP to a US server which is not allowed.
The referenced lawsuit used a <link> tag, but an <a> tag can result it a browser sending a request too.
>No it doesn’t
It does if they want to follow the law.
>and you will find that you would almost always prefer that they not do it
I don't mind companies having analytics using data they have collected from me.
> It does if they want to flow the law.
No, they can just not do it. Simplifying very slightly: they’re trying to get your consent precisely because they don’t have to do it, therefore they’re not allowed to without consent. I would also note that the sort of consent they solicit on public websites is practically always for storing stuff on your machine (ePD, from 2002) rather than for processing (GDPR, from 2016). But I lack energy to get further involved in this aspect; suffice it to say that their tracking is basically never in your interests at all, and routinely not even in their direct interests.
Which is what browsers can do for link tags. Some browser scan for links on pages and speculatively load them so that if you were to click on them it loads instantly. You as the website author can't prevent this functionality.
>No, they can just not do it
But they want to do it and may have business reasons to do it.
>their tracking is basically never in your interests at all
The tracking likely either improves the service based off analytics which is in my interest or it makes ads more relevant which makes the site more financially viable which is also in my interest if I am gaining value from that site.
Anything like that is user (the browser acting as their agent). You’re obviously not responsible for that. You didn’t ask it to do that automatically, unlike <link rel="stylesheet"> and <script> and the likes.
Things like <link rel="stylesheet">, <script> and <img> are subresources: instructions to the browser to fetch and use the specified resource, so that the page can be rendered properly. As you say, the user agent can choose to ignore these instructions (and text-mode browsers will generally ignore all three of these subresource types), but the page will probably be materially compromised, and the developer placed the subresource there with the expectation that it will be loaded.
A hyperlink is a reference to another page altogether, that it’s up to the user to access if they choose to. It’s not a subresource.
I don't understand why it wasn't immediately obvious to browser vendors that this was going to be how web developers responded to GDPR; and that the browser vendors could/should get ahead of this degradation of the quality of the web-browsing experience by giving the user a way to do GDPR consent at the browser-chrome level by e.g. ticking a box in the browser preferences that will set a request header. (It didn't work for Do Not Track, but Do Not Track is a "request" to a malicious adversary; while "I consent to cookies, so stop prompting me" isn't.)
I can only guess that browser vendors don't like GDPR, and so are avoiding implementing such a GDPR quality-of-life feature in order to ensure that users get just as annoyed by the cookie prompts as they should be, and eventually demand the law be changed.
1. Analytics
2. Third-party resources
3. CDNs
4. DDOS protection services
What else am I missing?
You can use third-party resources if you self host them (like fonts, images, videos, ...).
Not sure about CDNs, but I don't think a global CDN that's GDPR compliant can exist.