Is Browser-Fingerprinting legal when I transfer/ store only the hash of user related attributes? Is the following pseudo code, being executed within the browser, compatible with GDPR? sha256(fonts + useragent + plugins + ..) Notice: It doesnt store the actual attributes on the server, only the hash of these is transferred, so that the server cant conclude what the real values were.
It doesn’t make you exempt from the GDPR if that’s what you’re asking The hash you produce is linked to one (or a small number) of computers and it therefore serves as an ID number. Because that ID number is linked to the owner of the computer it is personal information and if you are collecting it, you must comply with the requirements of the GDPR - valid legal reason, deletion when no longer required, deletion on request, data security etc.
From ACRO's Subject access - further guidance web page: Why do I need to supply proof of ID? We need to be confident that we provide your personal data to the correct person, which is why we ensure we have sufficient proof of identity before we disclose any information. It also helps us to ensure we make a correct match on the PNC. As for this proof of ID (personal data) provided when submitting a Subject Access Request, ACRO's Privacy policy states: We gather information about site usage to help the development and improvement of services to the public, and to protect the integrity of our systems from malicious users. At the moment this information consists of: Statistical information obtained using Google Analytics. No information collected can be used to identify individual users. For more details about how this affects your privacy please visit the Google Analytics Privacy Centre. If you don’t want to send information to Google Analytics, an Opt-out Browser Add-on is also available or you can configure your browser to let you to choose which, if any, cookies are allowed to be created. Information obtained by our content management system to examine what people are searching for, what they find and occasions where no results are returned. Information collected can’t be used to identify individual users. Information provided by users through online forms; it's held in our UK-based secure data centres and is retained in line with the Data Protection Act 2018, the General Data Protection Regulation (EU) 2016/679, and our retention policies. However, I have not been able to locate publicly available copies of the retention policies referred to in the emboldened text.
Yes. Art 13 requires you to provide “the identity and the contact details of the controller”. You are the data controller. Your name and address are necessary to establish your identity. Using AdSense means you're offering an internet society service commercially. In that case, there's also probably some EU fair competition directive that was implemented in your countries national law and will provide equivalent requirements. For example, my country Germany has a far-reaching Impressumspflicht. Not sure if this is the most relevant EU law, but Art 22 of Directive 2006/123 requires that your country passed laws to ensure that you make available “the name of the provider, his legal status and form, the geographic address at which he is established and details enabling him to be contacted rapidly and communicated with directly and, as the case may be, by electronic means”. I think you would be in scope of this directive since you're acting commercially. This legally mandated self-doxxing is unfortunate for private bloggers, but it's also essential for making it possible to enforce data subject rights: if you were to violate someone's privacy rights, how could they sue you if they don't know where to serve you with a lawsuit? However, all things are a balancing act. These requirements are not intended to limit freedom of expression. If you're just trying to communicate something to the public without jeopardizing your anonymity, then paradoxically social media services can be more attractive.
Yes, it triggers the GDPR obligations Considerations: Can you surely identify those residing in Europe? In that case you should ask them to sign up again and confirm the consent. A lot of mailing lists are doing just that. Did they previously give consent and you can document it? If so, then you can argue that you have the required consent. Do you have business in Europe? If not then I don't think they would bother to go after you. You could just walk away from the fine. What other personal informastion are you storing? If you know who reside in Europe then you already have more info than just the email. The email address itself wouldn't be much of a documentation issue, SAR or Portability task.
The GDPR does not prescribe how information should be pseudonymized and does not even define the term properly. Yet, pseudonymization is suggested as an safety measure in various places, so that pseudonymization should be implemented wherever appropriate. The most useful guidance the GDPR gives is by contrasting pseudonymization with anonymization, where it says that pseudonymized data is still personal data because the data subjects can be identified using additional information (see Recital 26 GDPR). In contrast, re-identification is not reasonably likely for truly anonymized data. A common technique for pseudonymization is to replace identifying information with a pseudonym, for example replacing a name with a random numeric ID. However, this can only be considered pseudonymous if the mapping between the ID and the real value is not available to whoever uses this data. Replacing individual fields in a data set might not be sufficient for pseudonymization because apparently non-sensitive fields could still enable indirect identification. This requires careful analysis taking into account the entire context of the data, so it isn't possible to say whether merely removing names + email addresses achieves pseudonymization or anonymization. What you are doing is redacting parts of sensitive data. I think this is a pretty weak pseudonymization method since it still leaks partial information about the true value, and leaks information about the length of the redacted value. It is possible to argue that this is OK (e.g. if you can show that you have multiple similar redactions so that you achieve a level of k-anonymity). But by default, such partial redactions are likely to be unsafe. Completely removing the sensitive data is much safer. The “Article 29 Working Party”, a pre-GDPR EU body, has published an opinion on anonymization techniques in 2014 (PDF). It does not account for the GDPR's specific phrasing, but provides an overview of pseudonymization and anonymization techniques and puts them into context of European data protection law. It considers how such guarantees guard against attacks such as singling out data subjects, linking multiple records of the same individual, and making inferences about the data subject. In this guidance, pseudonymization techniques that are suggested include encrypting or hashing the sensitive data. However, the guidance warns that such techniques do not provide strong protection against singling out or linking records of the data subject. A bit earlier, the UK ICO had published guidance on personal data, including on the matter of anonymization and pseudonymization (PDF) with some good examples. For determining whether a data set has been successfully anonymized (or pseudonymized), they suggest a motivated intruder test: could someone without specialist knowledge or skills re-identify the data subject? In your example, such a person should not be able to infer that a record about Stxxx Axxdxrxn is about a Steve Anderson. In my opinion, your pseudonymization approach would fail the motivated intruder test unless you have multiple records that could all be about Steve Anderson (compare k-anonymity).
The GDPR doesn't generally distinguish public from non-public personal data. If you have a good reason to contact the professor, do send them an email. GDPR does not prevent this. If you're sending this email for “purely personal or household purposes”, then GDPR doesn't apply anyway. There are rules in the ePrivacy Directive against unsolicited emails, but these specifically relate to emails for direct marketing purposes. A company is not allowed to send out spam marketing, regardless of whether they obtained the email address from a public data source. Companies can send email marketing to their own existing customers, or to people who have given consent. Consent is defined in a fairly restrictive way (as a specific, informed, freely given, and unambiguous indication of the data subject's wishes), so that mere publication of an email address cannot be interpreted as consent to receive marketing from a particular company.
The GDPR does not mandate specific features, but that any processing is lawful and transparent etc. So what would be the purpose of storing a revision history? Once that is clear you can work out an appropriate legal basis (e.g. a legitimate interest) and then figure out which data subject rights apply. For example, let's assume that there is a security interest in keeping a revision history, so that (a) mistaken edits can be rolled back, and (b) the user can be notified of possibly unauthorized changes. This would be a legitimate interest primarily of the account holder, secondarily of you as the system operator. Of course, such security requirements have to be proportional, but I'd see that as given when there's a payment method on file. You are required to apply appropriate safety measures and to apply the data minimization principle. E.g. is it necessary to store this revision history for all eternity? No, one or two months will likely be sufficient. Who should have access to this data? If the purpose is to defend against unauthorized access, it could make sense to only give out this data on request, and otherwise only make it available to support and security staff. Now we can discuss how this interfaces with rectification or deletion. That the user is able to rectify their data themselves is very good. However, that doesn't imply a prohibition on keeping a revision history: the revision history indicates what data was stored at what point in time, and is by definition correct. This assumes that you are not using the revision history for any other purposes. When the legal basis is a legitimate interest, a request for erasure has to be preceded by (or implies) an objection (opt-out) to further processing. The objection must weighed against the legitimate interest: the objection can be denied when there are overriding grounds to continue processing. This might be the case for a security purpose: if someone with unauthorized access can just erase their traces, the purpose cannot be achieved. But perhaps the user could opt out when they create their account? Or opt-out later, but with some delay to still achieve the security purpose at the time of opt-out? In any case, erasure is required when the data is no longer necessary for its purpose – this ties back to picking an appropriate retention period, as discussed above. So it's not really possible to provide a general answer, and it really depends on the specific purpose you are trying to achieve.
If you process any personal data, you do need to provide notice to the data subjects per Art 13 or Art 14 GDPR. Personal data is any information relating to a (directly or indirectly) identifiable natural person. It seems you are processing personal data including as addresses, PayPal accounts, and IBANs. Thus you're in scope of the GDPR. The GDPR does have an exception when data is processed for “purely personal or household purposes”, but that very likely does not apply to you. The German Datenschutzkonferenz (DSK), a cooperation of the German supervisory authorities, has published a handout on information obligations, listing which information has to be provided in a privacy notice: https://datenschutzkonferenz-online.de/media/kp/dsk_kpnr_10.pdf Such a privacy notice can be fairly short if you're don't doing anything special, in particular if you only use the data as necessary to fulfil the sale contract and then as legally required (e.g. for keeping financial records). There are privacy notice generators that can help with the boilerplate, but be aware that some are significantly outdated, and that in any case you have to fill in the information about your concrete processing activities. You have guessed correctly that you will need to inform your customers about your data retention periods. Your privacy notice will get more complicated if you also want to use this data in other ways, for example for marketing purposes. That would also require you to think about appropriate legal bases (e.g. legitimate interests, or consent).