Web-Browsers and Web-Communities Should Do More For Consent

I explore what web-browser vendors and web-communities can do to make consent practices better online.
published:
by Harshvardhan J. Pandit
CCPA consent cookies GDPR GPC privacy UI/UX web-browser

This blog post is an extended version of a rejected proposal to the Conference on Privacy Engineering Practice and Respect 2021 (PEPR ’21). While I continue to think about the topic to refine my ideas, posting them on my website helps me achieve what I set out to do - communicate. If you are interested in this topic or general area, I invite you to join the W3C Community Group on Consent. If you are interested in machine-readable data privacy and semantics, I invite you to join the W3C Data Privacy Vocabularies and Controls Community Group (DPVCG).

  1. Legal Requirements and Stakeholders
  2. The impossibility of Web-Scale Legal Compliance
  3. Why Browsers?
  4. Solution#1 Creating consent management interfaces and APIs at the browser and device level
    1. notice+consent interface APIs to provide a dialogue at the browser-level
    2. management of given consent similar to how we can currently manage cookies
  5. Solution#2 Establishing Web standards for management of permissions (including consent)
    1. Follow existing accessibility guidelines
    2. HTML tags for declaring notice or choice or contents at more granular levels
    3. schema.org extensions that indicate information
    4. portable consent records
    5. Extend existing permissions standard for consent interactions and management
    6. Implement common UI/UX baselines for notice+consent models
  6. Solution#3 Tastier cookies: improving cookies and cookie management interfaces
  7. What Next?

You visit any website these days, and the first thing is being forced to interact with a poorly designed and aggressive 'consent dialogue' that is designed to manipulate you into giving away your consent (and data and privacy). In most cases, the websites utilise an external service to collect and manage consent on their behalf - termed Consent Management Providers (CMP) - that provide convenient solutions with promises of legal compliance and better revenue through ads. CMPs promise or rather claim to provide the freedom and flexibility to let websites configure how their consent dialogues look, and thereby look to escape legal culpability for their products. Websites on the other hand point to the use of CMPs as a way to raise their hands and say they're following whatever the 'best practice' is. Its a classic case of companies passing the buck with no one wanting to take responsibility but everyone wanting the revenue that comes from looking the other way.

Existing research has outlined how these practices are manipulative, intentional, by design, utilise dark patterns, violate legal requirements, do not respect user-choice, are not human-centric, and harm individuals in terms of eroding their privacy through surveillance and obfuscation. The common lay person doesn’t know this, doesn’t care about this, and doesn’t have time for this either. And this is where the consent experience counts on this passivity to get away with theft and claim it was under ‘given consent’.

The so called dark patterns induce a person to agree through manipulation and suggestions. Depending on how and where it is used, it may or may not be illegal - though it mostly seems to be. It is one thing to lure people to buy more things through design and advertisement, and completely another to trick them into sharing the most personal attributes of their person-hood without their conscious awareness. Proponents of the data industry claim to provide features such as personalisation of ads and better results in return. Their claims may or may not be true – the point is moot if the way they obtain the data is not transparent, non-consensual, and unaccountable.

Even given the benefit of the doubt, one can argue that the issue of consenting to so many choices and options is burdensome, and even more so when it is replicated across the entire web. One might be tempted to argue that if you accept it once, then you don’t have to worry about it any more. But it cannot be called ‘freely-given consent’ if the process of not wanting to accept it is itself unfair, burdensome, and leads to repetitive requests to agree on the contrary.

Although consent dialogues seem like an European phenomenon by virtue of GDPR, the global laws are starting to consolidate on the view that consent is required on websites for personal data collection. With time, it is expected more jurisdictions and laws follow suit in making this an explicit requirement – ergo, consent on the web is here to stay. So if my fellow humans from all places on the globe may not have seen a dialogue yet, I assure you, they will soon. The fact that there’s now an ISO/IEC standard describing notices and consent online serves to strengthen my point. The web, as we know of it, now features consent as an intrinsic part of its experience. And this is why we must act to improve it.

A lot of solutions exist and are emerging, such as the Global Privacy Controls (GPC) as an automated opt-out signal, or the use of ad-blockers to completely block the consent dialogue itself. The GPC is legally enforceable under the California Consumer Protection Act (CCPA), and its successor - the California Privacy Rights Act (CPRA) goes further in specifying restricting use of dark patterns. It is an elegant and simple to implement/detect solution based on a boolean browser signal to indicate the user's preference. But I have reservations on its use in the consent process and the 'gaps' it leaves in interpretation of user-agency enforceability under GDPR - which I've outlined in a blog post. While GPC does provide an solution, and is implemented by a browser vendor - Brave, its specification does nothing to improve the experience and management of consenting. While CMPs have indicated interest / assent to incorporating the GPC signalling into their products, the sheeple are yet again left at the hands of the wolves.

So I raise an important question: Why haven't the browser creators and the larger web community been doing anything to improve the situation of consent management on the Internet? In response, I outline 3 areas where we can improve things.

Since the asking for consent, and the necessity of taking a decision is a legal requirement (such as under GDPR or the ePrivacy Directive implementations) – it consequently should not just be waved away without scrutiny. Argument made about understanding the applicability and interpretation of the law are a process of society – we will always encounter situations the law may not have foreseen, or is ambiguous about, or is not applicable towards. Solutions to these always stretch in two directions – spirit of the law and the perceived impact on profit-making commercialised organisations (businesses).

In the case of consent, despite the outcries of several denouncing the impossibility of the GDPR, we must strive to move ahead and affirm that privacy is a fundamental right – even on the web. The other alternative is to accept that we are commodities of data that can be exploited without our control or knowledge, and whose impact on us cannot be defended against. Society must decide which side it wishes to go towards, but practicality states that for now we must have a balance between the two.

To do that needs an understanding of how things stand, and who is involved. On the one hand are we, common people, who give consent, who provide data – explicitly or implicitly, and who at the end of the day are impacted by its utilisation. On the other hand, there are industry-led groups such as Interactive Advertising Bureau (IAB) that establishes standards for data and consent collection, running auctions on data, and for advertisement provision – all based on the utility of the web. There are also large players – such as Quantcast or OneTrust who are affiliated with such ad networks and providers, who themselves provide solutions that dominate the consent experience on the web. And littered amongst them are the countless companies and services that utilise the solutions and frameworks developed by these to request consent, collect data, run and provide ads on the web. The famous of the large players often play multiple roles – Twitter, Facebook, Google, Amazon all act as data collectors, aggregators, participate in ad networks, buy data, sell advertisements.

Most people are aware of these, but not the behemoth data industry invisible behind the web-views of a browser. There have been reports produced and compiled over the malpractices of such industries, the potential for harm from such data sharing practices, and the unfathomable complexity of their own practices. At the same time, the consolidation of a vast number of resources – both monetary and through lobbying – means it is often very difficult to get these behemoths to course correct on their actions.

And at last are the Data Protection Authorities (DPA) – burdened with the responsibilities of issuing guidance, enforcing compliance, and saving our fundamental rights regarding data protection and privacy. Without going into the myriad of details, it is sufficient to say that the authorities have not had an ideal impact on the state of things. There have been far too many investigations going on for far too long without outcomes, there have been documented cases where budget has been deprived, accusations flung over non-action, and no results to be proud of 4 years down the line. Still, the authorities are the only ones vested with the powers to enforce compliance, clarify interpretations, and issue fines. It may be hip to compliant about the government – but only because we actually care for their proper functioning. So despite a slow start – the authorities are actually the best bet to help improve the condition of things, but are simply burdened from the scale of things.

The impossibility of Web-Scale Legal Compliance

According to my understanding of how DPAs work, investigating compliance of consent dialogue on one website involves a plethora of time and human resources – whereby I imagine someone sitting down and meticulously documenting every instance of how some design or feature is found non-compliant based on some specific provisions of the law. Now imagine doing this at web-scale. It is arguably impossible because: (1) there are far too many websites and services on the web; (2) the web changes too fast and things become obsolete and unavailable; and more importantly (3) the DPAs probably don’t have enough resources to do this.

A more common-sense approach towards legal compliance is to “make an example of” one case and hope everybody else gets scrambling to fall in line. Unfortunately, this hasn’t been the case so far. I’ve lost count of the number of times European DPAs have ‘issued guidance on consent’ hoping things would be better. The EU has helped to alleviate some of this work by providing tools to assist with the investigation process – but the area remains complex and difficult to establish. Researchers working on automated non-compliance detection have worked on approaches that analyse the existing services – but ultimately the DPA has to (manually) verify the situation and document it according to established procedures.

To add to the issue at hand, the web is heterogeneous and non-uniform. Every website, every page, every service can be and is different. This makes it further difficult to repeat the same procedures of investigating legal compliance over changing designs, data, practices, and processes. And then there are issues about the timeliness of things – how to document the state of things at a certain point in time. It is easy to say a webpage ‘looked’ like this on a certain date, but capturing the intricacies of user experience, parties and services involved, and the background processes is quite complicated. It is without question that to investigate all of these, the DPAs need technically adept and experienced investigators and support staff in addition to the legal expertise.

At the same time, the proponents and pall-bearers of the web – namely the standard bodies and web browsers – do not have any provision that can assist in this task. There is no standard for ‘consent’ as such, though there exists an established standard for annotating metadata into webpages (schema.org) and a standard for expressing digital rights (ODRL). There is no compulsion to utilise these currently, which means they cannot be relied upon in approaches. The web browser teams meanwhile have not implemented any feature or facility to assist either the consent dialogue providers or the end users in providing a interfaces for information presentation and interaction, recording an consent interaction, and transparency regarding website activities across the web.

Proposing adoption of exotic or novel technologies will not help if they are not universally adopted. However, they have their benefits in investigating a better state of things, and help move suggestions and practical applications in the right direction. We must, therefore, do both – investigate potential solutions that change the status-quo with a better version; and at the same time also work on potential solutions that detect issues and problems with the current situation. And these need to happen at web-scale – so there must be compelling reason to get everyone to adopt this in addition to legal compliance. A good solution must be its own proponent.

Why Browsers?

Browsers and Device-makers (though there is a big overlap between the two) are powerful gatekeepers of the Internet in that they define and thus control how individuals access the services and what features they can utilise. One of the challenges they face is the constant uphill battle of protecting their users against malicious actors and agents, such as by blocking phishing attempts or flagging websites as a security threat. They also actively try to protect their users through PETs such as tracking protection and limitations placed on surveilling and profiling measures - such as through cookies.

Compare our experience of browsing the web today with a few years or a decade back where we had incessant animations, popups, opening of new pages and windows, hijacking of links - it feels like at one point the web was wild. The browser makers were the ones to proactively solve this by implementing several layers of security techniques which got us to today's situation where I can browse without running into troubles (most of the time).

Within this context, it is inherent to assume that these providers actively care about privacy protection which goes beyond security (as evidenced by tracking protection), and that they have the means to dictate paradigms which signal responsible behaviour (such as blocking of third-party cookies or the privacy labels enforced on Apple App Stores). At the same time, the development of Internet and web standards and protocols (usually under the umbrella of W3C and WHATWG) defines most of the underlying interactions on the web. Their standards and implementations provide new avenues for interactions on webpages, and their APIs enable novel use of the browsers and devices as computing devices.

The only notable efforts we have seen so far are the Platform for Privacy Preferences (P3P) - which was panned for being too complex and infeasible to implement, the Do Not Track (DNT) initiative - which was refused to be accepted, and now its successor in the form of Global Privacy Controls (GPC) - which has the backing of California Consumer Protection Act (2018) to become a legally enforceable means of signalling opt-outs.

Within this experience, it is imperative to ask why has there been no pragmatic development on the experience of consenting on the Internet? Despite the near-ubiquitous nature of consent dialogues, and the incessant pop-ups that take forever to disagree, why has there been no standardised, or convenient solution been developed, or even attempted to be developed by any of organisations with the power and resources to do so?

Currently, the most we have in terms of dialogue management is the ability to define a <dialog> as an HTML element, and even that has inconsistent support across different browsers. For devices, there is a central permission management system (e.g. access to contacts), but nothing that the apps can reuse to request specific permissions with (i.e. a custom API to show notice and request permission). As a result, both websites and apps utilise their own designed and developed custom interfaces to request consent and permissions, often in an aggressive and manipulative fashion. Researchers have shown that these are not only in violation of legal requirements, but that in most cases they are not properly implemented and do not respect the individual's choices. See studies:

  1. Purposes in IAB Europe's TCF: which legal basis and how are they used by advertisers? by Célestin Matte et al., 2020;
  2. Do Cookie Banners Respect my Choice? by Celestin Matte et al., 2020;
  3. Are cookie banners indeed compliant with the law? Deciphering EU legal requirements on consent and technical means to verify compliance of cookie banners by Santos et al., 2020;
  4. Dark Patterns after the GDPR: Scraping Consent Pop-ups and Demonstrating their Influence by Nouwens et al., 2020;
  5. (Un)informed Consent: Studying GDPR Consent Notices in the Field by Utz et al., 2020;
  6. Dark Patterns and the Legal Requirements of Consent Banners: An Interaction Criticism Perspective by Santos et al., 2021;

Some observations of the current situation:

  1. A website with a consent dialogue implementation provides it either natively or utilises a third-party service.
  2. Every website therefore may have a different implementation of consent dialogue and its management.
  3. Where using a third party service, the websites do not control their dialogues - or rather that they depend on the CMP to provide the design and interface.
  4. Most of the CMPs utilise IAB TCF frameworks to get consent, and therefore provide mostly the same (at a broad level) information.
  5. Even otherwise, 'consent on the web' has some commonly evident use-cases, such as analytics and functional services.
  6. Once closed, a consent dialogue is difficult to find and interact with it again. CMPs may decide to show a floating icon on the side, provide a link in the footer - its a treasure hunt to withdraw consent.

By identifying the requirements for requesting such permissions (for consent) and the necessity of a mechanism to show the notice, it is possible to devise a consistent and well-implemented system (as an interface or through APIs) that can be readily reused by any website or app. This is similar to how currently we can manage microphone or camera permissions on a website - because there are underlying APIs to request access to such. The creation of such interfaces and APIs also encourages better transparency and accountability by providing the possibility of recording these transactions and interactions, and building assistive technologies to support individuals. More importantly, it forces transparency and accountability by giving a uniform access to the notice+consent model which could be exploited to several goals:

  1. Customise interface e.g. language, buttons, font formats, reuse native UI/UX dialogs and designs
  2. Record the interaction within the browser i.e. a record of consent saying this interaction took place. This is the core idea behind the Consent Receipt, and I'm working on a project that explores this: Privacy as Expected: Consent Gateway.
  3. The uniformity in interface and information allows additional functionality in the form of extensions or plugins, e.g. to help the user make a choice, or highlight a particularly risky dialog or sensitive information, or provide more information or features about a concept, or even a simple privacy rating for a given website or its requested consent choices - similar to a security rating extension.

There are two important components that need to be developed for this:

(a) the notice+consent interface APIs to provide a dialogue at the browser-level;

Currently, the interface for consent is entirely dictated by the website. They decide when, where, how, and what is shown. Given that notices, in general, are important from a legal standpoint, the browser could provide a way to display such notices and to show controls. This is not limited to consent- but can also be unilaterally applied to other notices such as cookie requests, agreements for policies and terms/conditions, or even legal age requirements/warnings.

For a loosely-coupled interface, browsers can provide the APIs only to formalise the notice and controls i.e. the website (or CMP) still retains the ability to customise the information and controls within the dialogue, but the browser has the final accept/refuse options. In this, the interface is only about selecting or making a choice - the actual act of consenting takes place through the browser provided interface. This can help prevent abuse through dark patterns, and avoid confusion through uniformity. At the same time, this design acknowledges that websites or laws or jurisdictions can have different information needs and that they can specify them accordingly - but the user must control the formal and final form of how they consent.

The other alternative is a tightly-coupled design where the browser requires websites to utilise the APIs through fields representing common elements in consent dialogues. In this, the website (or CMP) specifies the purpose, personal data, recipients and so on - by passing these to the browser's APIs - which in turn uses this information to generate and display the interface to the user. The benefit of this is that all consent dialogues now look the same, have the same information structure, and there is no malpractices with ambiguity or obfuscation through making it difficult to see the orgy of recipients. Ideally, this is the best form of consent as the individual or user has all the control in that they can customise how they want their consent dialogues to look like, can even act to set reasonable defaults (in terms of pre-ticked boxes), and can set up preferences. Not-ideally, this is a fantasy and difficult to implement because of the backlash and cry for blood from data vampires.

(b) the management of given consent similar to how we can currently manage cookies.

Regardless of how consent was collected, an individual must have a way of knowing what they've consented to. For this, the browser should provide a history of records of consent - similar to how it has a history of web pages visited or cookies set per site. The current norm is that the user goes to the website, finds the consent dialogue, figures out how to reset the preferences, and then 'agrees' again. So the browser can simply record the information, as a minimum, for:

  1. Where consent was given i.e. website url, timestamp
  2. Link to go to withdraw or modify consent i.e. url

Then the user can browse the websites, and if they wish, exercise their right to change or withdraw consent. Think about this as being akin to the 'unsubscribe' link at the bottom of emails. Ideally, these links would be self-sufficient i.e. visiting the url should take you directly to the interface for consent.

For added benefit, it would help if users also know what their consent involves, which means knowing who they've given it to, for what purpose, for which personal data, and what are the data storage and sharing recipients gotchas involved. The best way to do this would be to have some form of consent record or metadata associated with consent - which brings me back to plugging in my current project: Privacy as Expected: Consent Gateway. There are also questions about establishing identities of parties involved, verification and authenticity, and whether these functionalities can be cross-device. However, if nothing else, the interface can provide some visibility and control to the users for their data and privacy in connection with consent practices online.

I came across some page or article that talked about Apple's plans for a consent attribute set on a per-website basis that utilised a two-bit (think double boolean) structure to indicate whether the user had indicated their consent preference (had made a choice on a consent dialogue) and what that preference was (accept/refuse). I could not find that resource again despite my best efforts. Regardless, its an interested and relevant approach to what I describe here - and the browser can then provide an interface for controlling the second bit i.e. set consent to accept/refuse.

Despite the notice+choice model being prevalent on all websites, there is no inherent (machine-readable and semantic) way for a website (or app) to specify that it is showing a notification for requesting consent, and what are the information, choices, and controls involved (this point was partially raised and discussed in the previous solution). Not only is this in contradiction to guidelines for accessible information on the web (see ARIA), it also is detrimental to efforts that want to observe, document, and automate interactions and compliance verification of such processes. By crafting standards within the web ecosystem it is possible to take advantage of available semantics and context to build better tools for the management of consent. I specify a few possibilities that build on this argument:

(a) Follow existing accessibility guidelines

Web accessibility refers to making it easier for people with disabilities to use and interact with information and interfaces on the web. A beneficial outcome out of this noble effort is that the web becomes better for everyone to use. Of note from these are the Web Content Accessibility Guidelines (WCAG) which are also enshrined as the ISO/IEC 40500:2012. There's a neat and helpful checklist that outlines readily understandable and testable items such as - "Provide text alternatives for any non-text content", and "Create content that can be presented in different ways (for example simpler layout) without losing information or structure" with further items listed categorically under each. While these guidelines are generic and abstract, applying them to consent dialogues can result in better design, functionality, expected interactions, and more importantly - help that interaction be more accessible and machine-testable. If we have a hard time navigating consent dialogues, imagine the nightmare for people with disabilities. The irony of "Agree to All".

(b) HTML tags for declaring notice or choice or contents at more granular levels

Consent dialogues are so <div>-isive. They're implemented as the most generic HTML element with no way or form to detect them without convoluted filtering and pattern matching. Maybe this is by design, who knows. To make this situation better, we can have better semantic representation of the contents through native HTML elements. As I pointed out earlier, there is a <dialog> element that represents, well, a dialogue, and can be used to contain the notice and controls for consent. This can be extended to formalise the 'controls' part by providing a way to structure information, choices, interactions, and indication of consent inside it, for example by utilising <form> or <button> elements in specific structures. Through this, there will now be a natively-supported way to provide a notice (as a <dialog>) with reliable structure information and choices through the HTML elements.

Going further, by arguing that the notice+consent itself is an important part of the 'free web' (or, in other words, throwing water back at the invaders) - the elements associated with notice and consent can be formalised in to the HTML specification. This means, there could be <notice> or <consent> or <privacy-preferences> elements in a web-page that indicate their role; or alternatively, there could be a single dialog element with semantics, e.g. <dialog role='consent'>.

Similarly, additional tags can be added to the webpage header to indicate site-wide preferences or controls. For example, instead of the text everywhere taking to a single page to control privacy and cookie preferences, this information can be set at the header level for the entire website using <meta name='privacy-preferences' content='url' /> or even <link rel='consent-controls' href='url'>. Some of these don't need to be standardised, and can be a general agreed upon convention - similar to how much of the content structuring takes place today.

(c) schema.org extensions that indicate information

For information and semantic purists who do not want to sully the HTML specification with annoying things like privacy and consent, there is the alternative of utilising HTML's native method of semantic annotation through mechanisms such as schema.org or RDFa. I focus on schema.org due to its existing prevalence on webpages in relation to search engines and discoverability. Utilising schema.org requires introducing and formalising concepts relevant to the consent dialogue so that the information and content within it can be annotated with appropriate semantic information. Some concepts possible through this are:

  1. Specifying an element is a notice or a consent dialogue
  2. Specifying a link is relevant to modify or withdraw consent
  3. Specifying an element is a textual description of a data processing purpose
  4. Specifying an element is a description of data sharing recipients
  5. Specifying an element is in connection with a right such as opt-out, withdraw, object
  6. Specifying identities e.g. controller, purpose
  7. Specifying privacy policies or T&C of a website
  8. Specifying an element is a choice or control in relation to privacy preferences or consent

When annotated with such information, this would make consent practices transparent and discoverable via agents e.g. think if you could search for something like, "withdraw consent for X", and the search engines could give you the perfectly relevant link. Or, getting the browser or extension to help you with the consent and consent management process by utilising the machine-readable information present. Or creating datasets of how websites utilise data on the web -- this is super important and useful for policy making.

Of course utilising schema.org does not require any changes to the browser, but there is only so much that schema.org can reliably do. For a truly efficient solution, I think we need HTML elements and optionally corresponding schema.org annotations. E.g., <dialog role='consent'>...<span itemprop='purpose'>Analytics</span>...

(d) portable consent records

Say you accepted consent on a website. This information is stored in cookies (most likely). Now you reset your browser, or you install another browser, or use another profile, or log into another account or computer/device. Do you think you've withdrawn your consent? No, you've merely erased the record that you gave consent, and thereby you're no longer in possession of the means to withdraw that consent by visiting the same website. If you contact the website, they will ask for some ridiculous documentation at best (e.g. picture of your ... drivers license or passport!) or just refuse to engage at worst. Maybe they will use arguments such as your data was collected in an anonymous fashion with no identifiers - which if true is okay. But if not, then they should have had better consent management in place that didn't rely on potentially ephemeral consent identifiers - but its your data so why would they care?!

Instead, if we have portable identifiers or receipts that you can take with you and wave in someone's (virtual) face and yell, Gimme back my privacy, then it gets much easier. You can save those identifiers or records, move/migrate them to another device, or inspect them at your leisure. Its better for websites as well - they get a good form of documentation to prove consent. And CMPs can utilise this 'added benefit' to customise their solutions, innovate, and create consent management products.

  1. I know of Signatu as a CMP who implements such consent records;
  2. My project, PaE:CG, works on creating specifications of consent receipts/records and their implementations

While this exchange of receipts can take place without browser-mediation, the issue of where should these receipts be stored, can they be generated client-side, how to sign them, or verify them - have an elegant solution if the browser gets on board and provides functionality for all this. Then the user does not have to fiddle with 'information management', and can use the browser to manage all of the web-related interactions. Similar to the argument about providing an interface for consent, the browser can provide an interface to manage such receipts. In addition, the web has existing verifiable credentials and signing mechanisms which could be utilised for records to be resilient to abuse.

(e) Extend existing permissions standard for consent interactions and management

The standardisation of consent as a permission can be based on extending the existing standard for Permissions. Currently, the spec talks about device resources/functions such as access to camera, background network usage, clipboards, and so on. By extending these to deal with consent, browsers and everyone else can just reuse the existing APIs to utilise and act on permissions. Neat and elegant! Even if there are is no formal agreement on content inside a consent permission, the data structure for representing, requesting, recording, and managing provides a good reason for why this should be implemented also for consent.

(f) Implement common UI/UX baselines for notice+consent models

Did you know the quickest way out of a consent dialouge is clicking Accept All? Or that dark patterns are a nuisance? So to fix it, we can have a common baseline implementation or a checklist or libraries or test suites - really, any number of things - that try to fix these. The argument for why anyone would want to use this is a distraction, like questioning why a casino would stop using its loaded die. If nothing else, we would have a stick to measure the badness of a consent dialogue, and this is something that's helpful in legal investigations, and also to the companies that actually don't know they're implementing bad practices.

When we make it easy for everyone to use a privacy-conscious measure, it becomes easier to call out for fixes to the broken implementations and malicious actors. By relying on CMPs and websites, we've been bystanders that wait for cars to stop before crossing the road. Either we die in large numbers and hope there is a law passed for our benefit, or we do stuff like put traffic lights and zebra crossing or have a say in how cars and roads should function - to summarise the analogy - we build the consent dialogue we want to use and offer them as 'best practice' implementations.

The ISO/IEC 29184:2020 standard goes some way towards providing guidelines for privacy notices / consent dialogues online (but note it doesn't meet GDPR's requirements for explicit consent). But I feel that this exercise should be an evolving work conducted under a web community, and should be borne out of discussions and problem-solving, and be continued as an ongoing activity. Remember, the famous quote - build it, and they will consent - is NOT what we want.

Solution#3 Tastier cookies: improving cookies and cookie management interfaces

Currently, most consent interactions are saved as cookies within the browser, with the only option available to most (generic or non-technical) users being deletion of cookies. This prevents individuals from managing their given consent since they have no way of knowing (i) which cookies are responsible for consent (ii) how to see the information about consent stored in a cookie (iii) how to delete consent cookie (iv) how to transfer cookie information outside the browser if it is of legal consequence. Therefore, there is a strong and urgent need for better cookie management within the browser.

While websites have the freedom of using any cookie (label, data) they want, there is an use-case for crafting better cookie management systems that feature different categories (flavours!?) of cookies - such as those for storing consent, or those for storing identifiers. The browsers in turn can also proactively work on identifying cookie contents and providing dedicated interfaces for inspecting and managing them at a more granular level.

While there is ongoing talk about banning use of third-party cookies, this does not solve the obfuscation of cookie purposes and cookie data to the user. Merely providing information about the existence of cookies without the ability to inspect, understand, analyse, and granularly control them is not sufficient. Especially when websites specify the ability to delete cookies as being in control of cookies. I'm in control of the cookies in my kitchen because I can see their brand, ingredients, expiry, and how bad they looks - so ultimately I decide whether I want to eat them or throw them out. I'm asking the same for cookies (real and otherwise).

Some ideas for concrete steps on this:

  1. Formalise the categories of cookies: analytics, functionality, login, data sharing, identifiers, etc.
  2. Provide more granular APIs and functionality for specific categories of cookies: handling login cookies should not be the same as storing non-required information. Similarly, consent cookies should have their own dedicated APIs / markers.
  3. Expand browsers' current functionalities to show what kind of cookies exist and how are they being used. Turn it into a dashboard, allow better controls and choices, enable setting preferences on type of cookies or domains.

What Next?

I've outlined a lot of ideas, which require a lot of work. Ultimately, taking these and putting them in the tools we use everyday is in the hands of: The Nexus of Working Groups and Browser Vendors, or the powers that be. Each of these topics, or sub-topics, can be turned into interesting research, debates, implementations, or even legal/guidelines. The first and foremost step in any of these is to communicate these to the correct people - the browser makers, the researchers, the working and community groups. This is where everyone can help by sharing, interpreting, citing, or summarising this work or others based on it. Some groups that might find this to be of interest, and where you can reach out to take up this work:

  1. W3C PING (Privacy Interest Group)
  2. W3C Privacy Community Group
  3. W3C Data Privacy Vocabularies and Controls Community Group (DPVCG) - which I chair and I welcome discussions/contributions on this
  4. W3C Community Group on Consent - which I chair and I welcome discussions/contributions on this