Almost every application has a privacy setting of some kind, and it might not have anything to do with the legal basis of processing. Frankly, almost none of the users of your application cares about that. They care if the setting works, gives them good choices and that those choices are understandable, and that the setting is actually available.

That said, I’m going to tackle setting surfaces, as in all the discussion about privacy settings and controls, since this aspect is essentially untouched.

The underlying guideline is this: All settings and controls must be available from all platforms and surfaces on which they are relevant. A surface is a particular place where a user may interact with your product or system. For example, your website is a surface. If you have a mobile app, that application is a surface. A platform is a particular group of computing devices that may run the same computing applications. Windows laptop computers are a platform, as are Android phones and Apple iPads. In some cases, the distinctions between different software releases also become relevant: Android Jellybean devices may not be able to run all the same applications as Android Oreo devices.

Some settings and controls are not relevant on certain surfaces. If a mobile app offers a “poetry of the day” recommendation that is not available from desktop computers, then any settings to control that recommendation (e.g., to turn it off or limit it to particular topics) do not need to be available on desktop computers.

If a particular setting affects the behavior of a product or system on a certain surface, that setting is relevant. If there is an email client with an option to add a signature block at the end of each email, for example, that setting should be available from every surface where a user may send an email.

So far, so obvious. 

Where this gets tricky is that not every application can perform every action from every platform. Let’s say that I can post poetry to a particular website. I may also have a poetry electronic book that shows me poetry from that website. If the poetry book literally cannot accept any input (i.e., it picks poetry to display randomly and does not have page turn buttons), then there is no mechanism to operate any settings or controls. But if there is the ability to send back input, then the settings — which languages of poetry should be displayed — should be available.

If a particular setting or control is available on a particular platform, it should, under all circumstances, remain available on that platform. Note that I specified platform here, not surface.

When people delete an app, they may think that they’ve deleted their account. If that’s true, and your app has removed no data from the device, no problem. If that’s not true, then you effectively have two choices.

The simplest choice is to assume any device that hasn’t contacted your server within a specified period of time has had the application deleted and delete all that data from your servers accordingly. For data your servers are caching for the user for computational purposes, this is an excellent option.

The more complicated choice is not to delete data when the user disappears for a while. For example, if the user has asked you to back up their photos, they may become exceedingly upset if your server tosses out their baby photos just because it took a while to be able to afford a new phone after their old phone took a tumble. In that case, your service must take the more complicated option: ensuring that all relevant privacy controls and settings are always available from all platforms on which your application might have been used.

Ensuring availability on all these platforms requires maintaining a lowest-common-denominator access mechanism, one that will work even if a user cannot upgrade their device or install an application.

Users cannot upgrade their devices past a certain point for many reasons. One that all devices are eventually subject to is that limited storage means certain upgrades simply don’t fit on the device, let alone any additional applications. Certain mobile phone carriers simply do not distribute operating system upgrades (even security upgrades!) to all devices they sell. Upgrade limitations apply to applications, as well, both directly and indirectly; a particular device may not have room to store a larger upgraded app, or it may not have the new software necessary for the upgraded app to run (e.g., a new version of the operating system).

Almost every computing device with the ability to give some input that was built over the last two decades has a web browser built in. So, on most devices, including mobile devices, like phones and tablets, this means a mobile-friendly webpage that functions on old, low-memory, slow devices with minimal use of bandwidth.

It may not be pretty, but availability trumps prettiness every day.

Photo by Rodion Kutsaev on Unsplash