Should I blur personally identifiable information on Facebook screen recording for YouTube? (Global question: EU, US, etc) I'm recording a video for YouTube where I show how browser extension works while surfing through different Facebook Groups, Business Pages, Personal Profiles, etc. Should I blur surnames and photos of people who meet on the screen? According to this article: https://gdpr.eu/eu-gdpr-personal-data/ photos are also considered personally identifiable information: Video, audio, numerical, graphical, and photographic data can all contain personal data. ... Methods of identification that are not present today could be developed in the future, which means that data stored for long durations must be continuously reviewed to make sure it cannot be combined with new technology that would allow for indirect identification. So it's possible to find people if I show their avatars (using Neural Networks, Google Images, or other services). So It seems that even avatars should be blurred. But should I blur personally identifiable information? Especially considering that people on Facebook made it public and do not hide it. Thanks!
There are multiple issues with what you are trying to do, including issues with copyright, personality rights, and data protection. You are trying to use other people's content and likeness for your advertisement. Unless you are certain that you can do this in your relevant jurisdictions, without their consent, this sounds like a very bad idea. At least under GDPR, “but they made it public” is not an excuse. Personal data is personal data regardless of how you acquire it. The GDPR also has a very broad concept of identifiability that goes beyond direct identifiers or PII. If you want to use other people's personal data, you need a legal basis, and must provide them notice about your processing. Consent (informed opt-in) is one legal basis, legitimate interest (opt-out) another. You are suggesting to avoid this by blurring PII, but you may also have to blur other content that is indirectly identifiable. Real anonymization that meets the GDPR's definition is a really hard problem. In some cases, a legitimate interest is able to avoid such problems. E.g. if I make a video with commentary about a Tweet, it would likely be OK to show surrounding personal data like the responses including the identities of the various accounts, to the degree that this is relevant to the commentary and/or necessary for proper attribution. However, that commentary likely has strong protections under freedom of expression. At least from an European viewpoint, a tutorial, demo, or advertisement would not have a freedom of expression argument that would shift a GDPR legitimate interest balancing test in your favour. Instead of blurring almost everything in your video or working on GDPR compliance, content licenses, and release forms, you should consider a different solution: create dummy content just for your videos. You can use your own content, and maybe add a dummy profile.
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.
You are right that a visitor of a website does not expect to be tracked upon opening the website. But when using Google Analytics configured in the way explained in my other post, the visitor is not tracked. At least not in a way which violates the GDPR. You worry about the cookies. I also found this article which also does and suggests to either: change the _ga cookie to a session cookie, so it will be removed when the browser is closed. To do this, set the Cookie Expiration variable in your Google Analytics Settings to 0. completely disable cookies. (GA does not require cookies). To do this, set the storage field to none: ga('create', 'UA-XXXXX-Y', { 'storage': 'none' }); If you do not disable cookies, cookies can be used for tracking, which is more general defined in the GDPR as profiling. Profiling is defined in Art. 4 GDPR as: ‘profiling’ means any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person’s performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements; Art. 22(1) GDPR disallows profiling. Therefore in the settings menu from Google Analytics you have to disable data sharing and data collection. So data will only be used for the analytics function. But because you have configured to Anonymize your visitors IP Address, the part of the IP address used for this, is no longer considered personal data. This is because approx. 250 other users share the same part of the ip address which is stored, so data is not distinguishable between those 250 users. The anonymisation used by google is currently considered good enough. At least by the Dutch DPA. This might change if someone proves it is not good enough anonymized. Note that I am not a lawyer either, but I have read from multiple experts that analytics can be a "legitimate interest", the same way marketing can be a legitimate interest. This way configured the privacy impact is considered very low. It is also very important to note that a DPA consideres GA Google Analytics compliant. Even if a court would not agree in the future, you are acting in good faith if you follow those instructions, so you will probably not be fined. The DPA does currently not suggest to change the _ga cookie to a session cookie, or disable cookies completely. Note that the GDPR does not require doing anything to make it technical impossible to track someone. If a website has access to the data to track someone, but "promises" not to do that, that is fine. And rules regarding the usage of cookies in general, is not part of the GDPR, but (currently) part of the ePrivacy Directive. Only the way to ask for consent for storing cookies is defined in the GDPR.
Copyright The photographer, not the subject(s) own the copyright in the picture. So, unless this was a selfie, you have no rights in the picture. Privacy If the photo was taken in circumstances where a reasonable person would expect privacy, then revealing it to others might be a tort of privacy breach. In most common law jurisdictions this area of the law is undeveloped. However, if the photo was taken from a public place (even if you were in a private place), or with your permission, this doesn’t apply. Intimate images In some jurisdictions, the distribution of intimate images without the permission of the subject is a crime. Intimate does not include a photo that is merely embarrassing. Bullying This is probably bullying behaviour but bullying per se is generally not illegal. It might be illegal if the bullying is motivated by a protected characteristic (race, age, gender, sexuality etc.) but that usually requires a context - employment, public accommodation etc. it might also be illegal hate speech even outside such an institutional framework. Similarly, within an institutional context like a workplace or school there might be policies around bullying; these might have the force of law but are probably quasi-contractural matters. However, a private person doing it because they don’t like you and want to humiliate or embarrass you is probably not doing anything illegal.
BAD idea It is one thing to upload the phonebook and associated pictures for use of the owner of the phonebook. It isn't a fair use of the phonebook pictures - and you might not have a license anyway, as some people associate photos with numbers that they don't have a license to associate with anyway. But what if instead of a photo of the person, the first photo someone associated with the person is a photo of something like... crack cocaine, a photo of someone in a very compromising situation, just genitals, or some other thing that is just as tasteless or possibly criminal to share? In that case, your company is possibly committing defamation, and in case sharing or possessing of the image itself is illegal, your company is now the actor and liable. Depending on the content of the picture, distribution of pornographic material (possibly even underage material of that sort) could be up that alley just as much as hate speech through symbols, usage of banned symbols (such as swastikas in Gernamy) and many many others.
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).
You must get opt-in affirmative consent to process personal data, including tracking people's use of your site or providing targeted advertising. The banner on StackExchange is likely in violation of the GDPR. Do not copy it. It does not have an explicit opt-in, only an opt out which is onerous (leave the site, then manually go in and delete any cookies they set, which may be hard to identify if they are from 3rd parties). The sites you mention that have a gateway are a more correct implementation. Consent must be acquired before processing of data begins, and it must be explicit.
It follows from case law from the ECJ, e.g. C‑70/10 (28 January 2010) and C-582/14 (19 October 2016), that IP-addresses are personal data. Since my interpretation of the case law differs from the interpretation offered by @Greendrake, I'll go into the relevant case law in a bit more detail than I did in my initial answer. TL;DR: Yes, IP-addresses in server logs are personal data and you need to declare IP-address logging in your privacy policy. As I said, we need to examine the case law I mentioned in the introduction to find out whether IP-addresses are personal data. The first of those are ECJ C-70/10. In this, the court concludes that all IP-addresses are "protected personal data": It is common ground, first, that the injunction requiring installation of the contested filtering system would involve a systematic analysis of all content and the collection and identification of users’ IP addresses from which unlawful content on the network is sent. Those addresses are protected personal data because they allow those users to be precisely identified. (my emphasis) Then, in 2016, the ECJ ruled in a more narrow case ECJ C‑582/14 specifically ruling on dynamic IP-addresses: The court goes through a number of deliberations, then concludes: Having regard to all the foregoing considerations, the answer to the first question is that Article 2(a) of Directive 95/46 must be interpreted as meaning that a dynamic IP address registered by an online media services provider when a person accesses a website that the provider makes accessible to the public constitutes personal data within the meaning of that provision, in relation to that provider, where the latter has the legal means which enable it to identify the data subject with additional data which the internet service provider has about that person. It is very clear from this text that the court does not challenge or invalidate ECJ C-70/10 on static IP-addresses. The court is very careful, in its ruling to point out its ruling is specifically about dynamic IP-addresses. So the ruling of ECJ C-70/10 still stands for static IP-addresses, these are always protected personal data. I believe this case law is summarized in Recital 30 of the GDPR. This recital lists the identifiers that may make natural persons identifiable: 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. (my emphasis). Since it follows from case law that static IP-addresses always makes the data subject identifiable, and dynamic IP-addresses may make the data subject identifiable, I will conclude, based on jurisprudence alone, that: Unless you are able to filter your logs to exclude static IP-addresses. I think you must consider IP-addresses protected personal data under the GDPR. However, in ECJ C‑582/14, the ruling about dynamic IP-addresses hinges on the controller having legal means to identify the data subject by connecting the IP address to some other data. The court seems to think that getting access to ISP logs is the only means of doing that. This is wrong. In 2015, the Norwegian computer scientist Einar Otto Stangvik identified 78 Norwegians who seem to have downloaded abuse material starting only with their IP-addresses. Stangvik did this while working as a consultant for Norway's larges newspaper VG. I know Stangvik and I am familiar with the methods he used. I've tried them myself, and they work. Stangvik did not have access to ISP logs, he did not do anything illagal, and the 78 natural persons identified only by means of their IP-address, combined with other data the Stangvik had legal access to. I will not go into details, I will just say this: If you know how to do this, getting to the natural person when you know the IP-address is not difficult or labour-consuming. To return to the question: It also follows from the GDPR that logging of IP-addresses falls under its definition of "processing". Your privacy policy should list all personal data personal data that is collected by yourself and third parties ("processors" in the terminology of the GDPR) that you rely on. Your hosting company is such a third party, and you need to declare the logging of IP-addresses in your privacy policy.