One of GftW's goals is to
Protect privacy by creating alternatives for web monetization that are not dependent on collecting users’ data, for example, platforms that don’t require consumers to share data with content creators or submit their browsing history to collection by the monetization platform.
While monetization can provide alternatives to collecting user data, it doesn’t eliminate privacy concerns altogether, and developers might still be tempted to collect user data.
If, like many GftW applicants, you're developing a web application, you might have wondered what you can do to protect the users of your application. There is some excellent guidance to be found in the Privacy by Design approach.
The first principle of Privacy by Design is "Proactive not Reactive; Preventative not Remedial".
- When you design in privacy from the beginning, you anticipate and prevent privacy invasions before they happen, rather than waiting for an incident that you then have to scramble to resolve. This also reflects the reality that it can be much harder to change an already-deployed system to make it more privacy-preserving. It is far easier to instead design your system from the start to protect your users.
The second principle of Privacy by Design is “Privacy as the Default”. Let’s look at some concrete ways to achieve that:
- Minimize the data you collect and retain:
- Try to avoid collecting email addresses and phone numbers. Those can be used to link data, and if you have a data breach, an attacker can use them to link your user’s data to data from other databases.
- If you need user accounts, consider a model where you tell users that if they lose their password, they can just create a new account. By doing so, you remove the need for password resets or other "backup authentication", which may mean you don't need to retain an email address or phone number.
- When you must collect data, delete it as soon as possible. Think of this as deleting data "just in case" you have a data breach, rather than keeping it around "just in case" you find a use for it later.
- Minimize how long you keep log files - try to keep them for a day at most. If you can’t delete logs completely after a day, at least wipe all IP addresses from them.
- Trust the server less.
- In “Building a privacy-preserving architecture with less server trust”, Anike Arni gives an example of creating a backup authentication scheme with recovery codes sent to an email address. Rather than keep the email address on file, they use it immediately to send a long-lived recovery code then immediately delete the address. That way if they have a data breach, the attacker can not learn users’ email addresses.
- Degrade gracefully.
- Design your system to work - or mostly work - if users don't provide some data.
Two other Privacy by Design principles are “Visibility and transparency – keep it open” and “Respect for user privacy – keep it user-centric”. To that end:
- Give users control.
- If you're keeping data, give people a way to download it and, most importantly, give them a way to delete it.
- Design a system that lets you delete all copies of a user's data, even those on your backups.
Give thought to the above as early as possible in the design of your application. You can find more in Privacy by Design and the excellent case study mentioned above.
Those who aren’t (just) building web applications and whose projects may affect the Web ecosystem or other layers of the networking stack may also be interested in:
Top comments (0)