Legal aspects of Firebase Crashlytics SDK Let's say we have a mobile app, where every user is associated with app-generated unique user id (ex. 57d2ef8b391277001aad7784). Having the uuid itself that's not possible to identify a user. Having the uuid and access to the app backend infrastructure that becomes possible (by querying users by uuid). During sign-up to our service every user accepts Privacy Policy and allows us to store personal information on our backend infrastructure. What're legal aspects of usage Crashlytics.setUserIdentifier method in such case? Is it safe to use considering GDPR changes? I believe the answer depends on the jurisdiction user belongs to. I'd like to find a rock-solid legal answer at least for the US, the EU (GDPR), and Russia (152-FL).
[I'm not so well-versed on US and Russian law, thus I will limit my answer to EU law.] Your specific use of a user identifier, as I understood from your question, can be classified as personal data, so in your case, the GDPR seems to apply. This means that you need to have a) legitimate purposes to process that personal data (e.g. crash reporting) and b) a legal justification for each purpose of processing: it could be based on consent or another legitimate purpose (inc. your own legitimate interests). Consent might not be the best option for you, but it's up to you to decide. In any case, you need to assess the risks to the data subjects (your users) before you decide. How likely is it that you will get breached, and what potential harm will that cause to your users? These are some guidelines; my recommendation is that you read the law and the guidelines by the Article 29 Working Group and European Data Protection Board, or hire some good experts on this. There is no easy answer, or one size fits all solution. The GDPR isn't so hard to understand or implement, but it does require some change in mindset. With the new law, processing personal data carries a higher risk of penalties, so you should do it only when it's absolutely necessary, and with respect to the rights of your users.
are there any GDPR considerations that must be in place when an EU company stores personal information from citizens outside of the EU? Absolutely. The territorial scope of the GDPR is specified at Article 3: Article 3 Territorial scope This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not. This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to: (a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or (b) the monitoring of their behaviour as far as their behaviour takes place within the Union. This Regulation applies to the processing of personal data by a controller not established in the Union, but in a place where Member State law applies by virtue of public international law. As specified in point 1, the regulation applies to controllers and processors located in the EU. There is no exemption of personal data based on the data subject's nationality or location. In fact, GDPR Recitals 2 and 14 explicitly mention that nationality or residence shall not be a factor: The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data. […]
I'm pretty sure that under GDPR, you can indeed request them to send all data they have on you. If it's a complex request, they may charge you something like £10. If they have a lot of data on you, they may list the categories of data they have and ask you to pick one, rather than them having to collect and send everything. They should respond within one month, but iirc in the UK implementation, they can inform you (within that month) that they will respond within three months instead. For the rest, I only know current Dutch law. GDPR is not that different from what we already had (in general terms) and in many cases it even extends it. Under our law (WBP), you can also request a correction of the data in case it is incorrect, or deletion if they no longer need it for the purpose for which it was collected and stored. I don't really know how that works out in practice though, as Facebook can of course claim that "being able to connect you to your friends when you sign up for WhatsApp or Facebook with that number" is a legitimate purpose (in their eyes). They might also not have your full name and therefore not be able to connect your data to your request. Or, perhaps, they have only your full name (and there are probably more people with your name), so they'll have a hard time verifying that it's really your data which they would be handing over or deleting. The company is required to verify your identity before acting on your request. How they implement that is up to them. Under Dutch law, if I remember correctly, any data that can be connected to your person by any party is personally identifiable information (PII). While Facebook might not be able to find who's behind a phone number, your carrier most certainly can. Therefore, the data falls under PII protection laws and they will have to implement a way to verify you and get you your data. Finally, whether your local laws apply to Facebook, I don't know exactly. There's lots of information on this though, so you should be able to find it. Generally, countries say that if something happened within their territory (e.g. you signed up for WhatsApp while in the UK), their law applies. Companies, I've read, will instead try to claim that their main office is in SomeCountry and therefore SomeCountry's laws apply. But I'm pretty sure you'll be able to find a Facebook office somewhere where GDPR applies, so that's probably fine. While not an exact answer and while I am not sure about everything, I hope this gave you some pointers to go on!
The point of privacy laws is to set basic standards that apply to everyone, whether or not they have a privacy policy. A privacy policy that is inconsistent with privacy laws cannot be enforced. Breaches of privacy law can be punished even if the conduct is permitted by a privacy policy. Article 7 of the GDPR illustrates this by making special provision for the nature of &quot;consent&quot; to the processing of personal data. Consent must be freely given, and a &quot;written declaration&quot; as to consent, like the acceptance of a privacy policy, &quot;shall not be binding&quot; to the extent that it infringes the GDPR. The $5 billion penalty obtained by the FTC in United States v. Facebook, Inc (19-cv-2184) demonstrates that privacy laws can have a practical impact when a service provider &quot;subvert[s] users’ privacy choices to serve its own business interests.&quot; Facebook was penalised even though its users agreed to Facebook sharing &quot;information about the App User and the App User’s Facebook Friends&quot; with third-party developers. Whether a service provider has breached privacy law is a complex, fact-specific question, but if the service is &quot;pretty much part of people's lives,&quot; that will generally affect both the application of privacy law and the likelihood of an investigation by the regulators.
That GDPR Disclaimer is no protection in some jurisdictions: the applicable laws to that situation in germany for example don't care about the GDPR: Cold calling, mailing, or e-mailing private people to advertise services all is handled by the same law: Without the consent it is expressly illegal under §7 of the law against unfair competition (Gesetz gegen unlauteren Wettbewerb UWG) and such cases are rather Slam-Dunk if the origin can be made out. The punishment can be a 300.000 € fine. The fact that to email someone you need their e-mail address and that e-mail addresses and private addresses are by default considered personally identifiable information is making it worse for the advertizer: Without either an exception (there is none available to cold-emailing) or special allowance of the person the data belongs to, you violate §4 of the federal data protection law (Bundesdatenschutzgesetzes BDSG) just by handling their e-mail address. That's a separate crime from the UWG one, adding up to another 300.000 € fine under §43 BDSG - or even up to 2 years in prison under §44 BDSG! Oh, and if the email does not contain a proper sender's address, that's another chance for a huge fine under the UWG... So, GDPR is your least trouble, if you violate the marketing laws of a country, or their own data privacy laws. A disclaimer means nothing as the act of sending the mail, even to an unintended addressee, is what is illegal and the law as written does not give a damn about 'I didn't want to advertise to that person' when in fact you sent them unwanted advertisements. Oh, and the very repository you suggest? It would violate the very same §4 BDSG and be illegal for processing private data if it was not actively asked to do that by the end user. As a result, that database is useless: It does kick back all people not in its database. Its database is incomplete because only few people give their address to that database as people not aware of the database never add their data on their own. So it regularly violates §4 BDSG with every German citizen's e-mail address it gets and kicks back, and claiming those addresses would be OK, it throws the company trying to check the database under the bus because they rely on data that is impossible to be reliable. tl;dr Don't do cold-(e)-mail marketing. You throw yourself into boiling oil with a lit torch in hand. further reading Other laws banning such behavior I had listed here, and I quote myself: The US has the CAN-SPAM-Act, which illegalizes sending unsocialised advertisements. You may NOT send a mail if any of the following is true: it has no opt-out the email was gained by 'harvesting' contains a header not matching the text contains less than one sentence the adressee does not have any relation to you In fact, you are liable for a 5-digit fine per infringing e-mail in the US. The FTC itself suggests to never buy e-mail lists - as E-mail harvesting or generating any possible e-mail adress itself is illegal.
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.
The critical part is the nature of the relationship between you, the website provider, and the provider of the material you embed. If the embed-provider acts as your data processor, then things are generally fine. The GDPR does not really distinguish between personal data processing activities that you perform yourself versus activities that you've outsourced to third parties. However, you would remain responsible for compliance. This also means that per Art 28 GDPR, you will need a contract with that embed-provider (sometimes called a “Data Processing Agreement”, DPA). This contract stipulates that the processor will only use the personal data as instructed by you, but not for their own purposes. With the Google Fonts case, it must be highlighted that Google does not act as a processor for this service. Google does not offer a DPA that covers the Fonts CDN. While Google promises that it doesn't use the personal data collected in this context in any nefarious way, there are zero contractual guarantees for website providers. So we have to consider the scenario when the embed-provider is an independent data controller. We as the website provider have no control over what the embed-provider does with the collected data, our control only extends to whether or not we cause the website to disclose data to that third party. But this is still processing as personal data (see also the CJEU Fashion ID case), and we need a legal basis for this data sharing. In the Google Fonts case, the court in Munich found that there was no legal basis for using Google's CDN. There was no consent, no contractual necessity, and no necessity for a legitimate interest. After all, these fonts could all be self-hosted. (Technical remark: and given how modern browsers enforce cache isolation and provide HTTP/2, serving fonts from your main domain is probably faster anyway). Consent management services will typically act as your data processor. You don't need a legal basis for “sharing” data with them, because the processing remains under your control. As far as the GDPR is concerned, loading a script from your processor's servers is equivalent to loading a script from your own servers (which you're probably hosting via a another data processor anyway). Sometimes, the necessary data processing agreement is already part of the standard terms of service, sometimes it's a separate document that has to be signed. Figuring this out is your responsibility as the data controller, before deploying the service. Art 6 GDPR doesn't say that you always need consent. It says that you need a legal basis, for which paragraph 1 enumerates six choices. For a lot of use cases, a “legitimate interest” will be appropriate, though it requires a balancing test. Sometimes, other laws mandate that you use a particular legal basis. For example, the ePrivacy Directive says that you must get GDPR-consent when accessing or storing information on the user's device (such as cookies), unless that access/storage is strictly necessary to provide a service explicitly requested by the user.
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.