Do I need to worry about GDPR, CCPA, CalOPPA, if collecting anonymous usage for a non-commercial, no-ads app? I am developing a free, non-commercial Android App that does not use Ads or in anyway attempt to share their information with a third-party. However, I would like to include both Google Analytics and Firebase Crash Reporting which will collect anonymous data on app usage and report any issues with the app if it crashes. The information is only being collected for myself and is not intended to include any personally identifying information like names, emails, phone numbers, etc. It may include some unintended hints at a rough location. I should add, both Google Analytics and Firebase Crash Reporting are opt-in and are not enabled until and when the user checks a box and saves it. The app is fully functional without it enabled. I am trying to generate a private policy for it using a service that generates a privacy template based on a questionnaire. Certain answers to that questionnaire also increase the price of retrieving that policy. It is asking me whether I want to include wording for GDPR, CalOPPA, and CCPA, and I am not sure if or which of those I actually need. I suspect I'll need to include GDPR, but I'm not completely sure. The last two both cover California and it's not clear to me how they would apply for a non-commercial, no-ads free app. What's the simplest way to make sure my app has an appropriate privacy policy?
The CCPA is in many ways similar to the GDPR. It applies to firms that profess the personal data of California citizens, just as the GDPR applies to firms that process the data of EU residents. If you expect to have any significant number of users from California you will probably we wise to comply. Fortunately, most of the needed steps to comply with the CCPA will also be needed to comply with the GDPR, there should be little additional effort needed. Even a site that hosts no ads and sells no information must still do some things to comply. The California Online Privacy Protection Act of 2003 (CalOPPA) primarily requires that a site include a clear privacy policy, and there there be an easily found link to such a policy from a sites main or home page. According to the Wikipedia article linked above: Neither the web server nor the company that created the website has to be in California in order to be under the scope of the law. The website only has to be accessible by California residents. The law apparently does not contain any enforcement provisions of its own. The Wikipedia article states that: CalOPPA is expected to be enforced through California's Unfair Competition Law (UCL), which prohibits unlawful, unfair, or fraudulent business acts or practices. UCL may be enforced for violations of CalOPPA by government officials seeking civil penalties or equitable relief, or by private parties seeking private claims. Thus CalOPPA is not really a Data Protection law like the GDPR or the CCPA. Rather it requires disclosure of privacy practices, whatever they may be. See Also &quot;Making your Privacy Practices Public&quot; by KD Harris.
Among other things, GDPR regulates what you may do with the data within your systems. You can use it for the contracted purpose, or in accordance to law, or with informed and revokable consent, or for some other enumerated purposes. Even with consent, you have to take security measures to avoid the misuse of the data. Remember the software shrink-wrap licenses? &quot;By opening the package, you agree to the terms inside.&quot; GDPR makes the equivalent in the cloud world impossible. You have to document exactly what you do with the data, and for any use that is not necessary to perform the service the customer can opt out. In the scenario you describe, it is possible that you are not the data controller under GDPR but the data processor, and that you have a duty to keep the data from separate controllers apart. And delete any batch at the end of contract. If you want to do this professionally, you need to consult a lawyer for your specific plans.
This depends on the context – GDPR rarely restricts the use of specific kinds of data (see Art 9) but instead regulates the processing of this data, and the purposes for which it is processed. Personal data is any information relating to an identifiable person (Art 4(1)). So to show that some information is not personal data, you must show either that it doesn't relate to the identifiable person, or that it's not possible to identify the person. Whether a person is identifiable depends on the means of identification that are reasonably likely to be used, taking into account the cost and effort of these means (Recital 26). This recital also mentions that singling out a person is a kind of identification. If you have lots of birthdays so that there are no unique birthdays, or if the birthdays are stored without contextual information that would allow identification, this can indicate that it's not personal data. Some examples to illustrate my views: Scenario 1: you are collecting statistical data in a shopping mall and are collecting birthdays from passer-bys, without any additional information. This information is anonymous and not personal data, since you have no reasonable means to identify the persons. Scenario 2: in an office, there's a publicly visible calendar on the wall with the birthdays of all staff members. However, the calendar doesn't say whose birthday it is. This information is likely personal data, since it's reasonably possible to infer the correct person based on contextual information. At least HR would also have the birthday for all staff members on file, so that the company clearly has the means to identify anyone. (This doesn't mean such a public calendar is illegal, just that there must be a legal basis.) It is more difficult to determine whether information also relates to an identifiable person, i.e. whether this information is about that person. This depends not just on what the information is, but how the information is used. AFAIK there has yet to be EU-wide guidance by the EDBP, but the ICO has listed some hints. I think that a birthday of an identifiable person will almost always relate to that person.
It's really your client that should be asking these questions. Writing the app is perfectly legal. So you can enter a contract with that client to write the app and deliver it to them, ready to be put on the Google Play store or the App Store (entering a contract needs to be done carefully, obviously). I'd make 100 million percent sure that the contract states clearly that you have zero responsibility if the app is rejected or removed for non-technical reasons, and that the legality of actually selling and running the app is also not your responsibility. The reason is that I very much suspect that running the app might be illegal, and that the chances of getting it permanently on one of the stores are rather slim. And solving those problems is outside of what a software developer can competently do.
Any processing of personal data needs a legal basis, for example necessity for some contract or legitimate interest. If no other legal basis allows the processing, you need to acquire consent. Consent must be freely given. If something is gated behind consent without that consent being really necessary, this might coerce users and they would not be able to consent freely. The GDPR does not have a hard ban on this, but it explicitly calls out that this case must be considered when determining whether consent is valid. So what your company is trying to do is in a dark grey area. Not necessarily wrong, but likely so. Consent could be made free if users have an actual choice. For example, some online newspaper sites had success with a “pay or consent” wall. (Success in the sense that some data protection authorities allowed this). In your case, this could mean that users either consent to extra data collection, or that they buy some reasonably priced premium mode. But none of this is for you to decide. You can voice your doubts that the software would be compliant. You could also ask if the Data Protection Impact Assessment document for this proposed processing is available (creating such an assessment is likely mandatory in this case). But in the end, it is the company's obligation to be compliant, and this responsibility is largely shouldered by the company's data protection officer (to whom you can turn with further questions).
No. While UK data controllers must register with the ICO, they only have to provide general contact details. The ICO does not provide a public registry of data controllers. Outside of the UK, there is no requirement to register with the Supervisory Authority unless a DPO is appointed. Per Art 13 GDPR, every privacy notice must disclose the contact details of the controller, and of their DPO (if applicable). The GDPR does not require controllers to have a specific email address for data subject requests. Controllers have to fulfill the request regardless of the channel through with the request is made, so that normal channels for support or contact should be appropriate. The ICO writes in its guidance to controllers on the right to access requests: Are there any formal requirements? No. The UK GDPR does not set out formal requirements for a valid request. Therefore, an individual can make a SAR verbally or in writing, including by social media. They can make it to any part of your organisation and they do not have to direct it to a specific person or contact point. Of course, if a controller does not make contact details available or otherwise refuses to accept a valid data subject request, you can ask the ICO for assistance.
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.
Modern websites use large amounts of Javascript scripts. These are small programs that are run on your machine. By accessing the website you implicitly give permission for this to occur. (Aside: I'm not aware of any case law on exactly what this implicit authorisation covers. CFAA case law on "authorised access" suggests that this is going to be complicated if it ever becomes an issue). Javascript is supposed to be run within a limited framework which allows the website to control the rendering of the website and track how you use it. So they can track your mouse clicks when the browser window has "focus", but not clicks you make when accessing something else. Like all software, the Javascript programs and the web browser "interpreter" that runs them can contain bugs. Javascript has to work on lots of browsers, so its not surprising when things don't always work properly. Coming on to the CFAA, criminal penalties only apply to intentional access. 5 (c) intentionally accesses a protected computer without authorization, and as a result of such conduct, causes damage and loss. So if a website runs Javascript on your computer with the intention of crashing it, that is a crime. However if the crash is inadvertent due to ordinary programming errors then it isn't. In this case it is almost certainly innocent. To prove otherwise you would need to study the code they are sending in detail to see if it is doing something strange and unreasonable.