Down With Cookie Walls, Give Us the Web Privacy API!

Google, Facebook, other advertisers profile us and invade our privacy in all ways imaginable. Lawmakers are always behind, cookie walls and opt-out schemes don’t do much, except ruining the web. Is there a better way? How about a new, GDPR-enforced Web Privacy API? This article lays out a design for an alternative, in form of an RFC.

A few days ago Google announced that it's killing FLoC. The invasive tracking technology, announced in 2021, met with widespread opposition, is finally being dropped, but only to be replaced with the Topics API. This new proposal is technically different, but it still aims at the same goal: 

Build user tracking functionality straight into the web browser, to  facilitate data harvesting by advertisers.

The problem with the current situation is that websites won’t ever stop with these annoying privacy-related questions. Over and over again. Do you agree that we track you? Also while at work? How about in your bedroom? Could we have your liver too? Please agree, otherwise no kitten videos. And agree again on your phone, and again on your tablet. They have to ask for our consent, by law. It’s so bad that people start thinking that data privacy is something useless and extremely annoying. To hell with my privacy, I just want to browse! And this might be the end result:

After the initial outrage, I started thinking. Advertisers want a new API, and they are onto something. It’s just the wrong kind of API. Nothing that We the People need, rather something that The Investors ask for.

How about a different API? Instead of the website asking me, how about it silently asking my web browser? Asking through API, a Web Privacy API. Here’s how it could work:

• Users go to browser preferences where they make privacy choices.
• The user interface is provided by the browser, not by the website. It looks and works in the same way for every website.
• Users can edit global privacy preferences, then adjust them for specific websites. For example, users can deny identity tracking on all websites but allow it on their banking website and their favorite webshops.
• Websites use JavaScript and CSS to discover privacy choices applicable to them and adapt their functionality accordingly.
• Users can easily obtain a global overview of what, where, and when they agreed to, and amend these choices if needed

With this, browser popups and cookie walls are no longer needed. In fact, they can even be banned.

RFC: Implementation of Web Privacy API in Web Browsers

I’m not adept at writing RFCs since I haven’t written one yet, so please have mercy. I hope you like the idea. I’d be happy if you drop me a note of support on my LinkedIn account where I have published this tongue-in-cheek initiative.

The proposal below contains a draft of functionality, the user interfaces as well as JavaScript API and CSS API, which could be provided by the browsers in order to implement the above solution. I hope you like it!

Problem

Privacy laws such as the European GDPR require user consent to tracking, profiling, and targeted advertising. Browsers provide no functionality to support such legislation. Implementation is left entirely to website owners. They comply with these laws by implementing custom user interfaces where users can specify their preferences. These measures are disruptive, deceptive, and mostly inadequate. They impede user experience while providing little protection from harmful assaults on our privacy.

Support for data privacy choices should be integrated directly into a web browser. It would improve user experience, and provide relief to millions of website owners, who spend considerable resources to stay compliant. It would also mitigate harmful and deceptive practices, intended to force users to make choices that are beneficial only to advertisers.

Duration

1 April 2022, extended by t@waraksa.net by agreement.

Current State

Awaiting feedback.

Proposers

1. Tomasz Waraksa

Detail

Privacy laws such as the European GDPR require user consent to tracking, profiling, and targeted advertising. Browsers provide no functionality to support such legislation. Implementation is left entirely to website owners. They comply with these laws by implementing custom user interfaces where users can specify their preferences. Users are obliged to give consent to be allowed to use website functionality.

There is no persistent store for these preferences. Cookies are volatile. Clearing browser cache results in websites asking users again for consent.

There is no way to share privacy preferences between browsers and devices. The same website opened on a different browser or a different device again will ask the user for consent.

There is no way to review and amend privacy preferences in bulk. Users are unable to see where they agreed, when and to what.

There are few legal requirements about the design and behavior of these user interfaces. Users face a variety of user interfaces. Each one looks different, works differently, and it asks different questions.

This overwhelming experience results in users making choices that aren’t beneficial to them. Advertisers exploit this liberty at all times. They come up with deliberately opaque user interfaces. While fulfilling legal requirements, they force users into approving questionable privacy practices.

It is time to stop pretending that advertisers will care about user privacy. The decisions about privacy should be made only by users, and in a way, that’s clear, consistent, pleasant, and easy to understand for humans. Things should be made easier for us, and not for those who use and misuse our data.

The current opt-out model where everything is allowed unless explicitly denied is harmful. It leads to new deceptive practices, coming daily. We propose a more restrictive opt-in model. Under this model everything not explicitly approved is legally forbidden. This model would be much better at protecting user privacy.

Proposal

This proposal addresses the following problems:

• Lack of consistent user interface and legal language for privacy preferences
• Repetitive queries from multiple websites
• Lack of persistent storage for privacy preferences
• Lack of ability to review and amend privacy preferences
• Lack of means to enforce opt-in model on website owners

We propose adding the following functionality to browsers:

• Browsers provide the user interface for editing and viewing user privacy preferences.
• The user interface presents choices according to the privacy regulations applicable to the user. For example, users from the European Union will be given choices required by the EU GDPR directive.
• The choices made by users are made available programmatically to websites via Web Privacy API
• Websites can query privacy choices using Web Privacy API. Websites must do this automatically and without any further questions to the user.
• Websites are allowed to notify users about functionality that is unavailable due to current user choices.
• Websites must not take any measures to coerce or force users to change their minds, by unreasonable crippling of website functionality.

We propose to introduce a legal obligation on browser vendors to implement such functionality, and on the website, owners to apply this functionality, when collecting and processing any private data of users.

Privacy Choices Summary

The user can review the privacy choices applicable to the currently opened website, straight from the browser’s main window. There should be a button visible directly after opening the browser window, nearby the address bar.

The user can navigate to Privacy Preferences Editor from there, in order to change the current privacy choices.

Selection of Applicable Privacy Laws

When opening the privacy preferences for the first time, a user must be asked about the legal residence, to determine applicable privacy laws, for example:

The user must be allowed to leave without making any choice. This must be seen as if the user has never consented to share any private information with anybody yet. As a result, all API queries for privacy-related permissions will return denied status. This might impede the browsing experience. But it must remain a valid and easily available choice for those who prefer to prevent any kind of data collection and analysis.

The user must be allowed to easily change or clear information about their legal residence at any future moment:

Privacy Preferences Editor

The browser should have a new user interface for editing privacy preferences. This user interface could be either part of the browser preferences dialog or a separate dialog.

Users must be able to edit global privacy preferences that apply to all websites visited by the user. The presented choices are regulated by privacy law applicable to the user, as determined above. Users in different jurisdictions might be asked different kinds of questions.

The exact nature of these questions needs to be analyzed further, as per references below:

• https://gdpr-info.eu/
• https://www.legislation.gov.uk/ukpga/2018/12/contents/enacted
• https://oag.ca.gov/privacy/ccpa
• Other applicable privacy regulations

The UI Allows Customized Choices for Specific Websites

Users can make customized choices for specific domains and groups of domains. There should be a list of domains, available in the preferences editor. There, users can add domains, also using wildcards, and define for each one of them the exact same preferences as seen in global preferences. These custom preferences override any choices made in global preferences.

The UI Allows Overview of Privacy Preferences

By clicking the Review My Privacy Preferences button a human-readable text document should be compiled, which reveals in detail, where I agreed, to what, and when. The UI should allow quick withdrawal of consent, for example:

Preferences Must Be Persistent

The preferences are persistent, similar to other browser preferences. They cannot be cleared otherwise by the user navigating to the User Interface and changing them. Specifically, actions such as clearing browser cache should leave these preferences intact.

The preferences should be included in browser synchronization features. This way, consent given to one device applies automatically to another device.

Preferences Must Be Exportable and Importable

Users use multiple browsers and devices. To help them protect their privacy, browsers must support the import and export of Privacy Preferences. The export format for the preferences must be a public domain and must be enforced by law. Importing and exporting preferences between browsers of different vendors must be possible.

Web Privacy API

The website should be able to query user privacy preferences with JavaScript API and CSS API.

Privacy Jurisdictions

Before editing privacy preferences, users must select their jurisdiction. All supported jurisdictions are built into the browser, just like root certificate authorities are. They are updated by browser vendors as needed. Jurisdictions have globally unique identifiers, for example:

eu
uk
us-ca
us-ny
etc.

Privacy Laws

After selecting a jurisdiction, users must be informed about privacy laws applicable to them. All privacy laws within the supported jurisdictions are built into the browser. They are updated by browser vendors as needed:

eu-gdpr-2020
uk-gdpr-2021
etc.

Privacy Items

Those are the privacy choices to which users can give consent in Privacy Preferences. All currently applicable privacy items are built into the browser. They are updated by browser vendors as needed. Identifiers can be namespaced, to precisely define the domain or areas being allowed or denied, for example:

store-and-process.identifiers
store-and-process.personal-data
store-and-process.health-data
store-and-process.payment-data
marketing.email
marketing.phone
marketing.post
share.withinorganization
share.withthirdparties
etc.

JavaScript API

Web Privacy API is available through singleton WebPrivacy present on the window object. We propose the following API classes and methods:

WebPrivacy.isAvailable() : Boolean

The method returns true if the user has specified their applying privacy laws and edited privacy choices. After the clean installation of the browser, the function must return false. Until the user has edited the privacy preferences, the function must continue to return false.

WebPrivacy.isAllowed(identifier: String) : Boolean

The method returns true if the specified privacy item is allowed for the current website. If privacy item has been allowed or denied in website-specific preferences, this should take precedence over user choices made in global privacy preferences.

The method should throw an exception if an invalid identifier is specified.

If the user has never made any choice about the item, the method should always return false.

WebPrivacy.isDenied(identifier: String) : Boolean

The method returns false if the specified privacy item is not allowed for the current website. If privacy item has been allowed or denied in website-specific preferences, this should take precedence over user choices made in global privacy preferences.

The method should throw an exception if an invalid identifier is specified.

If the user has never made any choice about the item, the method should always return true.

WebPrivacy.openPreferences() : Promise<Boolean>

The method opens the Privacy Preferences user interface, where users can edit the preferences for the current website’s domain. The user can then navigate to the global preferences or preferences of other websites.

Similar to File Upload API, the method can be called exclusively in response to user interactions such as mouse clicks or keystrokes. The method cannot be called without user action, to prevent websites from intentionally disrupting the user experience.

The method returns a promise which resolves to true whenever the user saves changes to privacy preferences. Otherwise, the promise resolves to false.

WebPrivacy.getItems(includeNotApplicable: Boolean = false) : Array[WebPrivacyItem]

The method returns privacy items applicable under the user’s current privacy law. It only returns currently applicable items, unless told otherwise.

WebPrivacy.getCurrentJurisdiction() : WebPrivacyJurisdiction

The method returns information about the privacy jurisdiction selected by the user in Privacy Preferences. It returns undefined if no such choice has yet been made.

WebPrivacy.getCurrentPrivacyLaw() : WebPrivacyLaw

The method returns information about the currently applicable privacy law under the jurisdiction selected by the user in the Privacy Preferences. It returns undefined if no choice of the jurisdiction has yet been made.

type WebPrivacyJurisdictionIdentifier = 'eu'|'uk'|'us-ca'|'etc.'

class WebPrivacyJurisdiction {
  // Globally unique identifier
  id: WebPrivacyJurisdictionIdentifier

  // User-friendly name
  name: String

  // Detailed description of the jurisdiction
  description: String

  // True if jurisdiction is currently applicable
  isApplicable: Boolean
}

The class describes a privacy law jurisdiction.

type WebPrivacyLawIdentifier = 'eu-gdpr-2020'|'uk-gdpr-2021'|'etc.'

class WebPrivacyLaw {
  // Globally unique identifierid: WebPrivacyLawIdentifier
  // Identifier of jurisdiction under which the law applies
  jurisdictionId: WebPrivacyJurisdictionIdentifier
  // User-friendly name
  name: String
  // Detailed description of the law
  description: String
  // Indicates whether the law is currently applicable
  isApplicable: Boolean
}

The class defines a privacy law within the specified jurisdiction.

type WebPrivacyItemIdentifier = 'store-and-process.identifiers'|'store-and-process.personal-data'|'etc.'

class WebPrivacyItem {
  // Namespaced and globally unique identifier, as described above
  id: WebPrivacyItemIdentifier

  // Identifier of jurisdiction under which the privacy item applies
  jurisdictionId: WebPrivacyJurisdictionIdentifier

  // Identifier of law act in which the privacy item is defined
  lawId: WebPrivacyLawId

  // User-friendly name
  name: String

  // Detailed description of the privacy item
  description: String

  // Other references such as names of legal acts, URLs of legal documents etc.
  references: Array[String]

  // True if privacy item is currently applicable.
  // Privacy items can become not applicable because of law changes
  isApplicable: Boolean
}

The class defines a privacy item to which users can give consent.

CSS API

Information about user’s jurisdiction, applicable privacy law as well as allowing data collection practices are added as CSS classes to page <body> element.

The new classes should be prefixed with web-privacy__ prefix. The following classes are proposed:

.web-privacy__jurisdiction_<id>
.web-privacy__law_<id>
.web-privacy__<item>

Notice that privacy items are namespaced using dots. Since dot is not allowed in CSS class names, it is replaced here with a dash character.

For example, if a user residing in the EU has agreed to store personal identifiers and to marketing emails, the following classes would be present on page <body> element:

.web-privacy__jurisdiction_eu
.web-privacy__law_gdpr-2020
.web-privacy__store-and-process_identifiers
.web-privacy__marketing_email

Website creators can use these classes in the CSS stylesheets to modify the user interface according to users’ privacy choices.

Disclaimer

This article is not promoting any of the described products, services, or vendors.   We don't have any commercial interest or associations with them. We're not trying to suggest that these products or services are best for you, nor promising that your experience will be the same.  

In no event will we be liable for any loss or damage including without limitation,   indirect or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of, or in connection with, the use of this website and any information presented on it.  

Through this website, you are able to link to other websites which are not under our control. We have no control over the nature, content, and availability of those sites. The inclusion of any links does not necessarily imply a recommendation or endorse the views expressed within them.