Are Facebook Pixel GDPR compliant? GDPR states that a data subject have the right to get a copy of the data about the subject the data controller has collected, and in some cases deletion of said data. If I understand correctly, this also includes data that are collected with an ID set in a cookie, like Facebook Pixel does. Do Facebook Pixel have any way of getting the data of a single user through a userID, and also a function for deleting this data? I know Google Analytics have a function for deleting the data of a userID, and was wondering if Facebook Pixel had a similar function. If this doesn't exist, then I can't believe that Facebook Pixel is GDPR compliant.
The Facebook Pixel analytics solution does not seem to support access or erasure for data subjects. While there are some GDPR compliance features, these focus on collecting consent prior to collecting data. The relationship between the pixel user and Facebook is also murky. For certain kinds of data, Facebook acts as the data processor only, and the user has all the responsibility as the data controller. For other kinds of data, Facebook and the Pixel user are joint controllers, and therefore jointly responsible. This lack of features doesn't necessarily mean that Facebook Pixel is in violation of the GDPR, since the GDPR Right to Erasure only applies under certain circumstances. However, it is really difficult to argue that a website or app that integrates Facebook Pixel would be compliant. It is also rather dubious that Facebook could be compliant themselves, since their pixels will also collect data about persons who are not Facebook members. While these problems are most apparent with the Facebook Pixel since it's explicitly intended for tracking, this problem also applies to any other embeds provided by Facebook, such as like buttons. This was the subject of the Fashion ID case, in which the ECJ determined (in 2019) that the site operator is a joint controller with regards to data collection on the website by the Facebook embed. This effectively means that third party embeds can only be loaded after the website visitor has given consent for sharing data with Facebook. The tracking of non-users by Facebook was seen as especially problematic in Belgium, where Facebook had been banned from collecting such data already in 2015 (which was upheld in 2018). Since this was pre-GDPR, FB is currently litigating whether Belgium can continue enforcing their ban. I expect that Belgium will prevail with their ban. While this has no immediate consequences for Pixel users, this would make it more likely that Pixel users could be sued or fined successfully. From an advertiser perspective, Facebook does have valuable data that make the integration of Facebook Pixel an attractive proposition. However, other analytics solutions are much easier to bring into compliance. This is ultimately a business decision: will the better understanding of your ad spend on Facebook outweigh the risk and effort of integrating the Pixel?
… would face and voice count as personal information under GDPR? Absolutely. Does person B have the right to erasure … No. The right to erasure only applies in certain circumstances. While the initial reason for collecting personal data was consent, once it has been incorporated into a film, the processor now has a legitimate interest in the data. The right to erasure does not apply when there is a legitimate interest.
The GDPR as such puts obligations on the Data Controller (DC), that is the person or firm or other entity who determines the purposes for which data is processed. The entity that hires the developer and operates the web site is responsible for compliance with the GDPR and other laws and regulations, such as the e-privacy directive and its implementing laws. However, it is highly likely that in commissioning a web site the DC would specify that it be designed to aid compliance with the GDPR and other relevant laws, and if the developer did not do that it might be a breach of contract. Indeed, even if GDPR-friendliness was not explicitly required by the contract between the developer and the DC, the implied warranties of merchantability and fitness for the purpose would probably apply. A designer who, knowing the site is to be hosted and operated within the EU, failed to design it to facilitate GDPR compliance might well be in violation of those warranties. But that would depend on the specifics of Italian law. But note that GDPR compliance is not a matter of web site design, but of the ongoing practices of the operation of the site. There are various ways to comply with the GDPR, no specific technology or design need be used. The DC must so operate the site as to comply. If the DC fails to do that, penalties could be imposed on the DC, not on the developer.
Either approach can be GDPR-compliant. An issue to consider is that you as a data controller relying on consent “shall be able to demonstrate that the data subject has consented to processing of his or her personal data” (Art 7(1)). This might be simpler if a record of the consent is linked to a user account. On the other hand, the GDPR's data minimization principle would suggest that decentral, offline approaches are preferable. So you do have some flexibility here, as long as you feel comfortable demonstrating that your approach is compliant when investigated by a supervisory authority. In many cases, consent is not an appropriate legal basis to start with. It is one of several options in Art 6(1) GDPR. If a data processing activity is necessary for fulfilling a contract with the data subject, then Art 6(1)(b) is more appropriate. If the processing is necessary for a legitimate interest, then Art 6(1)(f) would work – after conducting a balancing test. Art 6(1)(a) consent is appropriate when the processing activity is not necessary, or when a legitimate interest balancing test doesn't go in your favor, or in some cases when required by law. For example, consent is required when processing special categories of data (such as biometrics), or when accessing or storing information on the end user's device, beyond what is necessary for a service explicitly requested by the user (the “cookie law”, but much more general than cookies). Consent also has heightened compliance requirements compared to other legal bases. The data subject must be able to make a free decision, without any coercion. You must not use dark patterns. You must leave the data subject a real choice. You must not make access to your app conditional on giving unrelated consent (like providing access to a game only when the user gives consent for personalized ads). The data subject must be able to easily withdraw consent later, without suffering detriment for this. The EDPB has issued relevant guidelines that might be helpful here: EDPB guidelines 05/2020 on consent EDPB guidelines 2/2019 on Article 6(1)(b) in the context of online services (also relevant for apps) TL;DR: what is “necessary” for performance of a contract is an objective question, and should generally be considered from the data subject's perspective. It is not possible to circumvent consent requirements by putting unrelated processing purposes like “analytics” into a services' terms of service. The main purpose of this document is to serve as a rebuttal of Facebook's GDPR compliance strategy. But it's perfectly fine to avoid asking for consent for those processing purposes that are actually necessary for the user. I've noticed that you mentioned various Google services like Analytics and Firebase. To the degree that your use of these services implies an international transfer of personal data into the US, it might be impossible to be GDPR-compliant. Be wary of claims that you're only transferring “anonymous” data, as the GDPR has a fairly broad concept of identifiability.
GDPR &amp; EPD require user consent before storing a users personal information. Wrong. User consent is one of the ways that justify storing personal information, but there are others. You may check art.6 to see the several reasons that allow to store personal information. In this case, it seems reasonable to justify it under the paragraph f (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Of course, that means that the data has to be used for this purpose. Avoiding spammers and other banned users would be such a purpose, but you should ensure that you do not send those e-mail address commercial information or even a Christmas greeting. In any case, be careful with anything you store. If along with the e-mail you stored more info, this could be interpreted as excessive and beyond the scope of paragraph f. For example, imagine storing &quot;User wrote nazi statements&quot; explaining why the e-mail is banned; EU laws are very restrictive about storing information about political or religious beliefs.
Cookies are information stored on the end users device and require consent¹ per the ePrivacy directive, even if the cookies or similar technologies don't contain personal data. Conditions for consent are defined by the GDPR. This was also confirmed by the &quot;Planet49&quot; case. 1. consent is required unless the storage of or access to information on the end users device is either strictly necessary for a service explicitly requested by the user, or necessary for technical reasons. E.g. functional cookies like a shopping cart feature in a web shop are fine, as are cookies used solely for security purposes or technical features like TLS session resumption. It is however likely that this cookie does qualify as personal data in the sense of the GDPR. The cookie contains an ID that lets you single out/distinguish this user from all other users, even though that ID doesn't link the user to a real-world identity. It is also possible to argue that the cookie is entirely anonymous, but the safer approach is to treat it as personal data. Similarly, other features of the website necessarily involve the processing of personal data, such as processing the user's IP address, if only for the purpose of responding to their HTTP requests. The GDPR's criteria for valid consent are mainly about ensuring that the consent is a freely given unambiguous indication of the data subject's wishes. For example, consent can never be the default, it needs to be an opt-in. However, Art 7(1) GDPR says that the data controller has the burden of proof of showing that valid consent was given. The GDPR itself does not provide further guidance on what this means specifically. I would argue that it can be decomposed into two aspects: Showing that valid consent was given. The manner in which you ask for consent must enable a free choice, and must respect that &quot;no consent&quot; is the default. For example, you could archive screenshots of the cookie management flow to show that there is a free choice. You could archive the frontend software so that it can be demonstrated that the cookie is not set until consent is given. Showing that this user gave consent. There is a wide variety of opinions on how to do that. My personal opinion is that the existence of a cookie paired with a valid consent flow to set that cookie demonstrates that the cookie can only have been set in a valid manner. However, there are consent management solutions that provide additional insight, such as the user's entire history of giving and revoking consent. For example, the user's browser might generate a pseudonymous ID enabling that user's consent history to be stored on some server. Indeed, that would be personal data, and this would have to be disclosed transparently. It would not be valid to use the consent management information for other purposes, for example by using the consent management ID for analytics purposes. Storing the user's consent history is definitely appropriate if you have a concept of identity, such as for signed-in users. I have doubts whether this is also helpful on websites that don't have user accounts, and I have not heard of a case where the existence of such records made a difference. After all, such records can only be relevant if the user gave consent but later disputes this in a complaint with a DPA or in a lawsuit. Which approach to choose will depend on more specific guidance provided by your country's data protection authority, and on the risk balance appropriate for your business. After all, the purpose of such compliance work is not to be 100% safe from lawsuits, but to reduce risks from enforcement/litigation to acceptable levels. What is acceptable is ultimately a business decision. E.g. the only 100% safe way to do web analytics is to have no analytics at all, but that is not acceptable for most businesses.
Does GDPR apply if my web app stores personal data on the user's phone only? No. If you are not processing Personally Identifiable Information (PII) then the GDPR does not apply to you. This is what a web browser does when it asks to remember your username and password for this web site. You are providing a tool, the user is using that tool to process their own data. I do offer to back up the user's personal data At this point you are processing the users PII, and the GDPR does apply to you. Even though you do not have enough information to identify an individual, as it can be used with other information to identify an individual it is PII. From the ICO: Can we identify an individual indirectly from the information we have (together with other available information)? Even if you may need additional information to be able to identify someone, they may still be identifiable. That additional information may be information you already hold, or it may be information that you need to obtain from another source. When considering whether individuals can be identified, you may have to assess the means that could be used by an interested and sufficiently determined person.
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.