Is it allowed to store a user id to remember him, his settings, preferences and history, without asking for his permission?
Is there anyknowledge about that how that goes with privacy laws like GDPR or Californian privacy laws?
I'm mostly interested in mobile apps, but how do mobile and web differ in this aspect?
Maybe. European regulations (GDPR, ePrivacy) do not distinguish between web apps and mobile apps. For both, the core points are:
Processing of personal data needs a clear purpose and legal basis as specified by GDPR. That legal basis may be “consent”, but doesn't have to be. Other common legal bases include necessity for fulfilling a contract, or a legitimate interest.
Accessing or storing information on the users device needs consent, unless the access/storage is strictly necessary for a service explicitly requested by the user. While this part of the ePrivacy Directive is known as the “cookie law”, it is entirely technology-neutral, and applies to mobile apps as well. It doesn't matter here whether the information in question is personal data.
Unfortunately, there is some mismatch between these criteria, so it can happen that ePrivacy requires consent (because some storage is not strictly necessary), even though no consent would be required by GDPR.
But in your presented scenarios, it is likely that no consent would be necessary. In short, if storage is necessary for something that the user wants to do (whether indicated through explicit consent or more implicitly), you can do it.
Consider the case of settings/preferences, like a dark mode toggle that is stored client-side.
GDPR aspect: the dark mode preference is likely to be personal data, since it relates to the user. The purpose of storing this information is to respect the user's preferences across pages/sessions, leading to a less annoying user experience. Since this is entirely in line with the user's interests, it is likely that an Art 7(1)(b) necessity for fulfilling a contract with the user could be an appropriate legal basis (with the contract in question being the terms of service). Alternatively, it might be possible to argue that remembering this preference is in the user's own legitimate interest.
ePrivacy aspect: Client-side storage is not strictly necessary for providing a dark mode feature.
But once the user indicates a preference, it should be possible to argue that it is now strictly necessary to remember that preference by storing this preference on their device, for example with a cookie, or a settings database.
Caveat: ePrivacy also regulates later access to this information. So we can only use the dark mode preference to select dark/light mode, not to infer whether the user is a new or recurring user.
So for this scenario, it is quite possible to argue that we can store some information client-side without having to ask for consent.
What if we want to store the settings server-side instead? This would require us to still store some kind of client identifier or session ID client-side, so that the correct settings can be retrieved from the server. The analysis would generally remain unchanged, but the GDPR's data minimization principle would nudge us towards storing everything client-side instead – avoiding the need to generate a client identifier that could be abused for tracking/profiling. If the client identifier were used for tracking or analytics, that would not be strictly necessary and would require consent per ePrivacy.
However, user logged into a server already need a session ID or other stable ID. Then, storing user preferences server-side using this existing ID would probably not raise any ePrivacy issues, and would likely be fine from a GDPR perspective as well. In particular, server-side preference storage for logged-in users might be necessary to provide features such as cross-device settings sync, if that is part of the service being offered.
Where web apps and mobile apps differ is not so much the regulatory framework, but the degree of control the user has.
For web apps, users have strong ability to inspect what is stored and processed, and to control/modify the capabilities of the web app via privacy settings, plugins, and developer tools. Improper tracking is often made quite visible by blocking/filtering add-ons like uBlock Origin or browser-integrated features. This has led to an environment where many web apps have an imperfect but decent approach to compliance, for example by showing consent dialogues.
Similar pressure doesn't exist in the mobile space, where users cannot as easily inspect what an app is doing. Correspondingly, typical privacy practices are often far worse in the mobile space. Pressure to comply comes mainly from the operating system APIs (such as Apple's change to enforce consent on a technical level before an app can access the device's advertising ID), and through app store review guidelines.
That would depend on where you store it. There is a lot of information about me stored on my phone because I wanted to store it. For example my passport number, so I can fill out forms without having my passport in hand. If you store data on my phone and equally safe, you should be fine.
If you store data in an encrypted form on your server, so that I and only I can read it, that should also be fine.
If the data is accessible to you, or to a rogue employee who acts against your wishes, or to a clever hacker, then you have a problem.
Difference between mobile and web app: With a web app it's more likely that my data is stored on your server, and that you can access my data if I use the web app - a mobile app might store lots of things, but totally inaccessible to you. It's like saying that robbing a bank is illegal, whether you have a gun and a facemark or not, but people with guns and facemasks are more likely to be bank robbers.
