Cookie Law: do anonymized analytics require cookie consent? In recent years a lot of privacy-aware analytics solutions have started popping up. These generally work using a very similar principle (see e.g. Fathom's algorithm): Create a fingerprint of the user using a hash of some combination of their IP, User-Agent, possibly other personally-identifiable information (PII) and a rotating salt. For the purpose of this question, assume that this creates an identifier that cannot be reversed back into PII. Use this identifier to determine whether the user has visited before, by storing it in a database along with the most recently visited page and time of visit. Aggregate all analytics to such a degree that no individual user can be identified. This conveniently gets around the issue of storing PII, since all stored information is either strongly anonymized (and minimal) or aggregated. Some of these solutions advertise &quot;No need for cookie banners!&quot; (see e.g. Plausible's landing page), implying that the need for informed consent is bypassed by the anonymization. Is there any legal basis for this? For the purpose of this question, assume GDPR isn't relevant (since no PII is stored), and only compliance with the ePrivacy Directive is in question. From my own reading the simple act of accessing the PII information in the first place, regardless of later anonymization, requires consent. As put by Article 5(3) of the Directive Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. (emphasis mine) As argued in a 2014 opinion on fingerprinting this also covers manufacturer-stored information such as User-Agents. In a 2014 opinion on anonymization it was argued that anonymization is a post-processing step, requiring consent to get the relevant information in the first place. In my opinion this means that, even despite the strong anonymization, and despite no PII being stored, these privacy-aware analytics solutions still require a cookie banner (as much as I hate to say it). The reason I'm asking this question regardless is that the claims of &quot;no need for cookie banners&quot; appears to be based on legal advice, having been checked by a legal team. Having no experience with law, this makes me think that I am missing something; what am I misunderstanding that makes this usage exempt from the ePrivacy Directive consent requirements?
First of all, in a GDPR contest, the process described is not strong anonymization. It may be hard for an outsider to go from the stored record to any PII, it is much easier for an outsider to &quot;single out&quot; an individual. This means that given a known individual, one can determine whether that person is among those listed in the records, or can determine this to a significant degree of probability. For this only the algorithm and the rotating salts are needed, one need not break the hash. Note also that the GDPR specifies that if a person can be singled out with the assistance of the site operator the data is not considered anonymized. Thus this data needs a lawful basis under the GDPR, and the various other GDPR requirement all apply. However, even if the data were totally anonymized, and say just added to a count of users with this or that User Agent, the process of reading local data (including but not limited to cookies) itself requires informed consent, and so a cookie banner or other interaction with similar info under the e-Privacy directive (EPD). The EPD, being a directive and not a regulation, must be implemented by national laws, and the exact provisions in those laws may differ somewhat from country to country. But I believe that all of them require consent before any local data is read.
Since you are from Europe, GDPR applies to all your processing activities per Art 3(1) GDPR, regardless of where the users are located. If you would like to avoid GDPR compliance, you would have to manage your business from abroad so that you no longer have an European establishment, and would have to avoid offering your services to people who are in Europe. So let's assume that you have no European establishment. Then, GDPR can only apply per Art 3(2) to those processing activities that relate to offering goods or services to people who are in Europe. For determining this, IP-based geolocation is indeed common. Very likely, you do not need consent for this. GDPR does not require consent for everything, just a legal basis. There are six potential legal bases in Art 6(1), though the relevant ones are consent, necessity for performing a contract, legal obligations, and necessity for a legitimate interest. For things like security checks, it would be common to claim a legitimate interest. Complying with GDPR can hurt revenue. However, data subjects have a right to data protection, but you do not have a right to a particular business model. Similarly, paying taxes can &quot;hurt revenue&quot;, but it's not really optional. If your business model can't deal with GDPR compliance (or with taxes), it might not be a sound business model. In Europe, many newspapers have since moved from advertising-only to a consent-or-pay model. That is, the user is given a choice: You can read articles without tracking if you buy a subscription. You can access articles for free if you consent to tracking. The legality of this is hotly debated. In principle, such an approach can be compliant, but the details are problematic, for example that you can only buy subscriptions rather than individual articles, and that these subscriptions are often orders of magnitude more expensive than what would be earned through ads. But this might actually be easier to solve for a mobile application than for a website, due to the availability of in-app payment and micropayment infrastructure. In any case, GDPR limits how much you can &quot;encourage&quot; consent – per Art 7(4), you cannot make access to your service conditional on consent. There must be a way to use your app without consenting to anything, unless that consent is actually necessary for the app to work. For example, consenting to camera access is necessary for a QR code reader app to work. It is extremely unlikely that ads would be necessary in this sense. Users also must not suffer detriment for declining or withdrawing consent. From this, the EDPB has developed the concept of &quot;permissible incentive&quot; in their guidelines on consent. In this post, &quot;Europe&quot; means EU/EEA/UK as appropriate.
No. While UK data controllers must register with the ICO, they only have to provide general contact details. The ICO does not provide a public registry of data controllers. Outside of the UK, there is no requirement to register with the Supervisory Authority unless a DPO is appointed. Per Art 13 GDPR, every privacy notice must disclose the contact details of the controller, and of their DPO (if applicable). The GDPR does not require controllers to have a specific email address for data subject requests. Controllers have to fulfill the request regardless of the channel through with the request is made, so that normal channels for support or contact should be appropriate. The ICO writes in its guidance to controllers on the right to access requests: Are there any formal requirements? No. The UK GDPR does not set out formal requirements for a valid request. Therefore, an individual can make a SAR verbally or in writing, including by social media. They can make it to any part of your organisation and they do not have to direct it to a specific person or contact point. Of course, if a controller does not make contact details available or otherwise refuses to accept a valid data subject request, you can ask the ICO for assistance.
It may be legal or it may not For example, if any of the users are in the European Union, then the GDPR applies and the person storing the information is a data controller and has legal obligations. These include, having a legitimate reason for storing them, storing them only for as long as necessary for that reason, notifying the individuals that the data is being stored and why, deleting it upon a users request etc.
How to store consent According to the ICO, you need to store the following: Who consented the name of the individual, or other identifier (eg, online user name, session ID). When they consented a copy of a dated document, or online records that include a timestamp; or, for oral consent, a note of the time and date which was made at the time of the conversation. What they were told at the time A master copy of the document or data capture form containing the consent statement in use at that time, along with any separate privacy policy, including version numbers and dates matching the date consent was given. If consent was given orally, your records should include a copy of the script used at that time. How they consented For written consent, a copy of the relevant document or data capture form. If consent was given online, your records should include the data submitted as well as a timestamp to link it to the relevant version of the data capture form. If consent was given orally, you should keep a note of this made at the time of the conversation - it doesn’t need to be a full record of the conversation. Whether they have withdrawn consent And if so, when. Source (p33/34) Would a txt file of users who had consented be acceptable The ICO provides this example as unacceptable: You keep a spreadsheet with ‘consent provided’ against a customer’s name. Source (p34) This shows that a TXT file of usernames would not be acceptable, as there is not enough information stored What would be acceptable You would want a table that looks something like this | UserId | Date | PolicyRevision | Method | WithdrawalDate | How to verify this data has not been modified You could store a hash of the row on some form of blockchain, to prove that after the stated date the consent had not been modified, this would prevent having to store a copy of the user's ID on the blockchain. It would not prevent forging consent at the time you claim it was given, but short of having the user digitally sign the transaction with some key that you do not have access to, there would be no way to prevent this.
There are a number of misconceptions in this question. Firstly, the regulatory environment did not drastically change when the GDPR came into force in 2018. Previously, each EU member state had its own laws implementing the 95/46/EC Data Protection Directive. The GDPR harmonizes these laws, and replaces them with a single EU-wide law. However, the GDPR is largely identical with the DPD. In particular, both laws have the same definition of a controller. Secondly, the data controller is not a position to be designated, like a Data Protection Officer would be. A controller is whoever – alone or jointly with others – determines the purposes and means of processing of personal data. Whether someone can decide the purposes of processing is a matter of fact, not a matter of formalities. There can be more than one controller. Most likely, the institution hosting the research group is the controller. For individual researchers, the important aspect would be to demonstrate that they've fully complied with their institution's procedures at all times – that they acted as agents of the controller, not as controllers of their own. The institution might have a more difficult time mounting the defense if its technical and organizational measures were inadequate. For example, keeping an unattended server running for five years without security updates borders on gross negligence – so there should have been a procedure so that each system has a clear point of contact who is responsible for administrating the system. The controller should also have inventoried its systems and processing activities at the latest in preparation of GDPR, e.g. for an Art 30 record of processing activities. Your question suggests that no one could be at fault because no one did anything, but inaction and failure to fulfil responsibilities can also be a violation of law. If the institution wasn't convinced that this server was GDPR-compliant, the correct approach would have been to shut the server down, not to continue the processing of personal data. Of course, the controller may be able to demonstrate that this breach of GDPR was very minor, for example because the personal data was pseudonymized and because other technical measures (like firewalls) would have prevented unauthorized access.
Can a city request deletion of all personal data that uses a certain domain for logins? Well, they can, but they have no legal backing to make it happen. Their chances of succeeding are about as good as me requesting a Ferrari, a Yacht and a Mansion. I can make that request. People will laugh. I will not get it. I'm a little worried that I shouldn't allow certain domains to be used as logins in the first place, especially ones that might be school related You have no way to know who owns what email address. And it's none of your business. Your only interest should be in whether the address is owned by the person that is creating the account. You probably already do that by sending a confirmation link to the email address when people sign up. I'd like to have some idea for future reference if there's any case where the GDPR would require me to comply with such a request The only way you have to comply with such a request is if the owner can prove their identity. As far as I understood, the &quot;Finnish city&quot; was three degrees away from that. They could not provide any proof they are who they said they are, they could not provide a finite list of accounts they claimed to own and they could not even provide proof they own those accounts. They literally just wrote an email with zero legal meaning. I want to figure out the right way to reply to emails like this one The correct way to handle this is have a feature on your website where the account owner can delete their own account. GDPR compliant. Then you make a text template explaining how to use that feature and reply with that template to every request, no matter how stupid (like this case) they are. If they cannot identify themselves to you by proving they have access to their &quot;own&quot; email, they have no business wasting your time. Legally, they could provide you with a different method of identification. In case of a Finnish school, that would probably need to be power of attorney from all children's legal guardians and a specific way to identify the accounts that is consistent with the data given (for example if they entered their full name and address on your website). You would probably in your rights to demand a certified translation if it's all in Finnish. Apart from the fact that you as a private US citizen have no real means to check the validity of all that paperwork, personally, if I saw hundreds of pages of certified translated paperwork, I would probably just comply. Not sure it it were actually enough, but it certainly gets an A+ for effort to delete data from a private website. But a real lawyer might give better advice with a real case on their hands. Is deleting the data actually more of a legal liability than not deleting it in some cases? (People shouldn't be able to delete other people's accounts.) Indeed. You should not delete people's data because a random punk on the internet sent you an email. You need to identify who the request is from and if they are allowed to make such a request. Whether you have a legal duty to actually keep data, is up to you or your lawyer to find out. It depends on your data and laws. It is perfectly legal to make a website with a textfield that deletes any data you enter after a second. Destruction of data you own is only a problem if you break other laws with it. For example the IRS might not be amused if you destroyed invoices and other proof of taxable income. &quot;Some dude claimed I must in an email&quot; is not going to fly with them. That said, again, please, identify who you deal with, find out if their claim is valid. Don't do stuff because random internet punks write you an email. Because the next mail you get, will be from a Nigerian Prince. Please wisen up before opening that one. People on the internet, through stupidity or malice, might not have your best interests at heart. Don't believe random emails.
GDPR Article 4 paragraph 1 says: ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; Recital 26 says Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. ... The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. Recital 30 says: 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. An IP address hashed through a cryptographically secure one-way hash cannot reasonably be used to establish the original IP address, nor to geolocate, nor to directly identify the data subject. However if such addresses are stored in a database with a link to the subject's individual record, or to other data which identify the data subject, then they would clearly be personal information. The ICO's page on &quot;What is personal data&quot; says: ‘Online identifiers’ includes IP addresses and cookie identifiers which may be personal data. The page from GDPR.EU on &quot;Personal Data&quot; says: Any information that can lead to either the direct or indirect identification of an individual will likely be considered personal data under the GDPR. ... Any data that relate to an identifiable individual is personal data. The page on &quot;Personal Data&quot; from gdpr-info.eu says: Personal data are any information which are related to an identified or identifiable natural person. The data subjects are identifiable if they can be directly or indirectly identified, especially by reference to an identifier such as a name, an identification number, location data, an online identifier or one of several special characteristics, which expresses the physical, physiological, genetic, mental, commercial, cultural or social identity of these natural persons. In practice, these also include all data which are or can be assigned to a person in any kind of way. For example, the telephone, credit card or personnel number of a person, account data, number plate, appearance, customer number or address are all personal data. Since the definition includes “any information,” one must assume that the term “personal data” should be as broadly interpreted as possible. This is also suggested in case law of the European Court of Justice ... See also &quot;Can a dynamic IP address constitute personal data?&quot; If a hashed IP address is stored so that it can be related to a specific individual, it is personal data. as such, it would be subject to the GDPR. To store it one would need to identify a lawful basis under GDPR Article 6 This could be the Data subject's consent, or the Controller's legitimate interest. In either case the information should be included in the list of personal information collected (often in a privacy policy document), disclosed to the subject on request, adn deleted on request if possible. If that is done, such a use of a hashed IP, although personal information, would seem to be compliant. If a hashed IP is stored in such a way that it cannot be related to any particular user, then it would not constitute personal information, and no compliance issue would seem to exist. Limiting the retention time of a hashed IP is a good practice which would reduce any possible impact it might have.