Is Facebook&#39;s new cookie banner GDPR compliant? Today I visited Facebook from a Google search to find the following cookie banner at the top of the page: To personalize content, tailor and measure ads, and provide a safer experience, we use cookies. By tapping on the site, you agree to our use of cookies on and off Facebook. Learn more, including about controls: Cookies Policy. From what I understand the GDPR doesn't allow such implicit consent and also there needs to be a prominent way to opt out of this data collection. Has Facebook found a loophole to this requirement or is this approach illegal under the GDPR?
I'd say it's definitely illegal. Here's what the cookie notice says on Facebook at the time of writing this answer: By clicking on or navigating the site, you agree to allow us to collect information on and off Facebook through cookies. And here's what the GDPR define consent: ‘consent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her; Also consider this, by the way: When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract. Facebook's notice is a small blue bar at the top of its blue header, and you might not even notice it (at least on a desktop computer where I'm seeing it). I see no way to easily deny consent, for example there is no button saying "I don't accept". All you can do is click on the link to their cookie policy, and still that policy does not present a clear and easy way to deny consent in all different cases, it looks pretty complicated (among other things, it depends on whether you have a Facebook account or not). So denying consent looks pretty difficult, if at all possible. On the other hand, to give consent, you'd only have to click on any link. I tried this. I opened my browser in private/incognito mode, so it should not use any previous cookies. On Google, I searched for "facebook John Doe". Clicked on a result bringing me to a Facebook page with a list of profiles of people named John Doe. The cookie bar appears at the top, but let's pretend I did not notice it. Then I click on a profile, supposing I'm interested in a certain John Doe, and... I land on John Doe's profile on Facebook, now without the cookie notice! What happened is I gave consent by clicking on any link, that is, clicking on John Doe. I can't see any way this "consent" could ever be considered "freely given, specific, informed and unambiguous indication of the data subject's wishes". Why is Facebook not compliant? Well, they probably couldn't be compliant even if they wanted to, unless they wanted to go out of business. Lately I've been wondering what the purpose of Google Analytics would be if users were always given the option to freely refuse consent. Virtually every user would always be clicking on "I don't accept", every time everywhere, so lots of business models would be totally disrupted. By the way, as of now, the cookie bar of this community (stackexchange) does not comply with GDPR either. To tell you the truth, I'm afraid very few websites have a GDPR compliant cookie notice.
No. That is spelled out pretty clear in Article 11. In fact, if you want follow accepted data minimisation principles (and you should), you should not log anything about cookies at your or a third party's website.
Enforcement against non-EU entities is difficult, and especially digital services would be impossible to shut down. Ultimately, enforcement would depend on judicial assistance between the relevant EU member state and the jurisdictions where the data controller is established or has relevant assets. Your case involves physical goods and other regulations though, so that (some amount of) compliance by the data controller is necessary in order to have continued access to the EU single market. Which instruments for enforcement of fines are available depends on the EU member state, but could e.g. involve confiscation of products or payments. A non-EU B2B service provider would also have economic incentives to comply as EU data controllers cannot share personal data unless an adequate level of protection is ensured. In reality, it is fairly unlikely that non-EU data controllers will get fined anytime soon because data protection authorities tend to prioritize more clear cut cases, and tend to stay within their jurisdiction. Of course, non-EU data controllers are usually required to register an EU representative precisely to subject them to a particular authorities' jurisdiction, but a non-compliant controller is unlikely to do that. A note on the GDPR's territorial scope: it is far less extraterritorial than some people believe. Per GDPR Art 3(2) the regulation applies to non-EU data controllers, (a) to the extent of their processing activities that relate to offering of goods and services (also unpaid services) to data subjects in the EU, or (b) when they monitor/track behaviour of data subjects as far as the behaviour takes place in the EU. For example, a B2C company would have to comply with the GDPR regarding how they handle shipping addresses of their EU customers. The EDPB has issued in-depth analysis as part of their guidelines 3/2018 on the territorial scope. However, the ECJ has found that some of the GDPR's effects are confined to the EU. For example, Google has to hide some results from EU searches in order to comply with the GDPR's Right to Erasure, but cannot currently be forced to hide the results from non-EU searches.
The GDPR roughly applies in the following scenarios: Art 3(1): you have an establishment in Europe Art 3(2): you do not have an european establishment, but Art 3(2)(a): offer goods or services to persons in Europe Art 3(2)(b): monitor the behaviour of people who are in Europe (where Europe means EU/EEA/UK as appropriate). Art 3(1) does not seem to apply for you. Art 3(2)(a) does not apply, since you're not actively targeting people in Europe. At the point in time where you are offering the app to users, those users are in the US. Art 3(2)(b) could apply if you collect some kind of tracking data, in particular (but not limited to) location data. But if you temporarily shut down collection of new data for personalisation while the user is in Europe, that's probably going to be reasonably safe. It might not be necessary to disable ad personalisation if that personalisation is based on data collected outside of Europe. In practice, unless your app is specifically targeted at travellers, no one will care about what your app does outside of the US. For detailed guidelines on the territorial scope of the GDPR, consider reading EDPB guidelines 3/2018 (PDF). The document contains some relevant examples, but since it's official guidance they won't explicitly say that GDPR won't apply in a scenario like yours. The closest is Example 8: An Australian company offers a mobile news and video content service, based on users’ preferences and interest. Users can receive daily or weekly updates. The service is offered exclusively to users located in Australia, who must provide an Australian phone number when subscribing. An Australian subscriber of the service travels to Germany on holiday and continues using the service. Although the Australian subscriber will be using the service while in the EU, the service is not ‘targeting’ individuals in the Union, but targets only individuals in Australia, and so the processing of personal data by the Australian company does not fall within the scope of the GDPR. Also relevant is Example 10, which says that app downloads in the EU might not be subject to GDPR: A U.S. citizen is travelling through Europe during his holidays. While in Europe, he downloads and uses a news app that is offered by a U.S. company. The app is exclusively directed at the U.S. market, evident by the app terms of use and the indication of US Dollar as the sole currency available for payment. The collection of the U.S. tourist's personal data via the app by the U.S. company is not subject to the GDPR.
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.
The GDPR gives controllers a lot of latitude. They must decide on the correct course of action taking into account the possible risks to data subjects. Specifically, no notification of the authority is necessary if “the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.” In your scenario 1, you suggest that there is no breach because there is no evidence that the data was improperly accessed. This analysis is faulty: the controller is aware that the data was not properly secured, and cannot rule out that the data was improperly accessed. I would argue this fits the description of a “breach of security leading to the accidental or unlawful … unauthorised disclosure of … personal data” (compare the definition of a data breach in Art 4(12)). Thus, a data breach has happened. The question whether the supervisory authority has to be notified of that breach is more debatable. The controller must assess the likelihood of risks to the data subjects. Here, they can perhaps argue that the risk of disclosure is low. However, the nature of the breached data would also be relevant. If in doubt, the controller should make the notification. The goal of the GDPR is not to punish unlucky companies that suffer a breach, but to protect personal data. Thus, fixing mistakes and cooperating with the supervisory authorities is likely the best approach for most companies. In your second scenario, the data is sensitive – its disclosure has a high risk for data subjects. However, the risk of someone intercepting this data is debatable. Does the risk of interception balance out the sensitivity of the data? That's the data controller's call, but I don't think so. A notification would seem appropriate here. As a technical remark, simply offering HTTPS is not sufficient to prevent MitM attacks – users must be forced to use encrypted connections. If a controller sees MitM as a risk, they are required by Art 24 to take appropriate technical measures. Here HSTS and HSTS preload would prevent the connections from being downgraded to HTTP. Instead of offering insecure connections, the site would become inaccessible. A complementary strategy is to not serve content over HTTP, but have the HTTP server only issue a permanent redirect to the HTTPS URL.
The GDPR applies to such sites if they offer services in the EU/EEA. If they clearly wanted to avoid being subject to the GDPR, they should block visitors from the EEA. For the GDPR, only location matters. Other concerns like residence or citizenship are generally irrelevant. Personal data does not turn non-personal just because it was public. So the GDPR still applies when the data was collected from public sources. However, the data controller (who determines the purpose of processing) often has to balance your rights and interests against other interests (e.g. when using legitimate interest as a legal basis for some processing). For the purpose of publicly displaying your data, only showing data that was already public anyway makes it easier to argue that this is fine. But when the GDPR applies, you have data subject rights. Relevant rights include: a right to access, to see all the data they have about you a right to rectification, to correct wrong data they hold about you a right to restriction, effectively an opt-out a right to erasure (also known as the right to be forgotten) These rights apply both against the website and against Google Search (arguably, both are doing the exact same thing). Google correctly points out that they can't remove information from the Web, but they can hide information from search results. If you feel that your requests have not been resolved correctly, you can issue a complaint with your country's data protection authority. In theory you can also sue them. In practice, GDPR enforcement against overseas data controllers can be quite difficult and has not yet happened.
The intention of the GDPR is to minimize the amount of personally identifiable information (PII) you store. So the GDPR never tells you that you have to log certain events. The simplest way to make sure you comply with the GDPR is to simply not store any PII at all. But that might of course conflict with legitimate business interests and with other legal obligations you might have. So when you do store PII, then the GDPR regulates under which conditions you are allowed to store PII, for how long and what you are allowed to do with that PII. So when you receive a GDPR request from a customer to see their data, then you can say that you only have that one timestamp of their registration, because you didn't log their subsequent logins (assuming this is the truth). I hope your privacy policy says that you store all that PII on registration and that you have some good arguments why storing that information is a &quot;legitimate interest&quot; of your organization.