My web app stores personal data about the user, but on the user's phone only (HTML5 Local Storage). The data is never touched by any server or database. I can't see the data. My server can't see the data. I do not store it anywhere outside of the user's phone. I do not send it anywhere.

I do offer to back up the user's personal data, but the data is then encrypted on the user's phone (using client-side JavaScript) before it's being sent to my server, and the encryption-key is stored on the user's phone only (end-to-end encryption). It's therefore impossible for me to decrypt the data since I don't have the encryption-key.

Does GDPR apply to me?

ADDED INFO: The purpose of storing this data is to help the user keep track of his or her personal diet and other health-related information. This is stored together with the user's first name, to enhance the user experience. I guess this could be considered identifiable information.

  • 7
    Frame Challenge: Why would you or your user store data that is never used with anyone?
    – Marcel
    Commented Dec 6, 2021 at 13:23
  • 7
    The purpose of storing this data is to help the user keep track of his or her personal diet and other health-related information. This is stored together with the user's first name, to enhance the user experience. I guess this could be considered identifiable information.
    – Chris
    Commented Dec 6, 2021 at 14:04
  • 2
    If you don't back up the key also I take it you're generating the key from some local password? If so, what if they forget it? There is no way to have a password reset. Commented Dec 7, 2021 at 0:19
  • 2
    I do not know the GDPR rules, but what about simply not backing up the name? (And anything else which could help identify the person--that's going to be stuff they already know and don't really need backed up.) Commented Dec 7, 2021 at 0:20
  • 2
    Writing this as a comment not an answer since I don't know how the law applies to it, but technically, as long as you're able to push software updates to the user's phone that are able to change the rules about how the data is handled (this includes having your application delivered as a website you control!), you are in control of the data, and thus in some sense should be responsible as a data controller. Commented Dec 7, 2021 at 19:19

2 Answers 2


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.
  • 1
    I cannot claim to be any sort of expert, but from my reading yes. There is no exception for encrypted data, and combined with the key it is PII. Remember it is not just the user, it is anyone with access to the key, which may be a hacker or thief of the phone, or a partner. As I say, I do not see what is gained by this backup.
    – User65535
    Commented Dec 6, 2021 at 14:56
  • 1
    @RedwolfPrograms No, having the key does not necessarily mean you have access to the data. You are assuming only the owner of the data has the key, but the key can be compromised just like anything else.
    – chepner
    Commented Dec 6, 2021 at 21:06
  • 3
    The encrypted PII stored on your server may be decrypted without actually knowing the key, if the user chooses a password that is weak enough to be brute-forced, or if a flaw is found in the encryption algorithm. Then it would be possible to get access to the user's PII without ever having access to their phone.
    – Geir
    Commented Dec 7, 2021 at 5:24
  • 7
    The technical issues about getting access to the encrypted data are irrelevant to the question. The GDPR does not have an exception for encrypted data so you cannot use it to avoid the GDPR.
    – User65535
    Commented Dec 7, 2021 at 10:20
  • 1
    @eis in a sensible system, the user doesn't choose the key directly; it's derived from what they choose. By basing the key on a password plus salt, encrypted through appropriate algorithms brute-forcing can be made slow
    – Chris H
    Commented Dec 7, 2021 at 13:53

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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .