You're probably a data controller, but you have taken pretty good steps to limit your compliance obligations.
Personal data is any information relating to an identifiable person. You are a data controller if you participate in determining the purposes and means of processing.
The provider of a website is typically a data controller for any data that is processed via that website, even if the processing is handled entirely client-side.
The relevant case law in this instance is the Fashion ID case. A company included a Facebook “Like” button on their website. Loading this embedded button caused transmission of personal data such as IP addresses to third parties (here: Facebook). The company argued that it wasn't the controller e.g. because this processing happened in the user's browser, not on the company's servers. The European Court of Justice found that the company was a joint controller for the data collected and shared by loading the Facebook button, even though the company did not itself process the data. But by embedding the Facebook button, it participated in determining purposes and means of processing.
For your service, this means that you should determine for which processing activities you are participating in the determination of purposes and means.
The core purpose of your app seems to be diet tracking, and this data doesn't leave the user's device. It may be possible to make an argument that you're not a controller because you didn't participate in determining this purpose, which every user does for themselves. I'd be uncomfortable making that argument, but it depends on the details.
By providing the web app, you are definitely doing some processing activities such as serving the assets, and you are clearly a data controller for these activities (even if you outsourced them). You would also clearly be a data controller for things that your webapp does that aren't explicitly triggered by the user, such as collecting analytics, sending crash reports, or embedding third party resources.
You are offering encrypted backups. These encrypted blobs are still information that relates to an identifiable person (even though you might not have the means to identify the person from the blobs). Thus, storage is processing of personal data and you are the controller for this processing activity.
The UK ICO has also published a checklist to determine whether you are a controller. Only with regards to the core purpose of your webapp, I think the relevant questions would have to be answered as follows:
- YES – We decided to collect or process the personal data.
- You decided to offer a webapp for these purposes.
- YES – We decided what the purpose or outcome of the processing was to be.
- You decided that the purpose of processing is diet tracking.
- YES – We decided what personal data should be collected.
- You designed the software to collect certain kinds of data, and not collect others.
- UNCLEAR – We decided which individuals to collect personal data about.
- The software collects data from users, but users can decide for themselves whether to use the software.
- UNCLEAR – We obtain a commercial gain or other benefit from the processing, except for any payment for services from another controller.
- Depends on how you offer your service.
- UNCLEAR – We are processing the personal data as a result of a contract between us and the data subject.
- Depends on how you offer your service. But if users have to accept terms of service before they can create an account, that could indicate that a contract exists.
- NO – The data subjects are our employees.
- NO – We make decisions about the individuals concerned as part of or as a result of the processing.
- For example, a decision in this sense would be to set insurance premiums based on the data entered into the software.
- NO – We exercise professional judgement in the processing of the personal data.
- Unless perhaps the software provides nutritional guidance based on the data entered into the software. Are you a doctor or other health professional?
- YES – We have a direct relationship with the data subjects.
- You are not a sub-sub-contractor, and are directly offering the web app to users.
- YES – We have complete autonomy as to how the personal data is processed.
- No one is instructing you which features the app should provide.
- MAYBE – We have appointed the processors to process the personal data on our behalf.
- Processors on your behalf might be web hosters or CDNs for your purpose of serving the webapp. But it doesn't seem like you have delegated tasks relating to the functionality of the webapp itself.
Given these considerations, GDPR will apply to you if you also fall under the GDPR's territorial scope: if you live in the EU/EEA/UK, or if you target people in the EU/EEA/UK with your service.
Doing stuff client-side and using encryption is still a great approach because this is a good starting point for ensuring the security of processing as required by Art 32 GDPR. And if you can legitimately argue that you are not the controller for certain processing activities, this reduces your compliance obligations.
Further reading:
Which set of guidelines applies (EDPB or ICO) depends on where you want to offer your service. The linked EDPB guidelines were published after the UK's Exit Day and are not directly relevant in the UK, but the Fashion ID judgement is relevant for interpreting both the UK and EU GDPR.
