Implications of Global Privacy Control

According to the UK Government's Center for Ethics and Innovation, 57% of respondents agree that collecting personal data "is useful for creating products and services that benefit them as individuals". Only 46% of respondents trust that big tech companies will let them make decisions about how their data is used, and that number drops to 31% when referring to social media companies.

We can interpret this to mean that most respondents distrust social media and big tech companies regarding decision-making and consent as it relates to their data. There's clearly a desire from users to have more control over how personal data is collected and shared, but striking a balance that's easy to control and enforce is delicate.

This isn't the first time that a tracking prevention mechanism has reached the W3C and been implemented by browsers. In 2009 the Do Not Track (DNT) header was created as a way for web users to express their tracking preferences. While it was widely implemented in browsers, it had a low adoption rate with websites.

The main problem with DNT was the lack of legal and regulatory backing it received. Website owners could decide if they'd observe the DNT signal and there were no legal repercussions if they chose not to. This is where GPC is different.

At the time of writing, the Attorney General for California has recommended observation of GPC to comply with CCPA. There are also intentions to work with the European Union's GDPR:

The GPC signal will be intended to communicate a Do Not Sell request from a global privacy control, as per CCPA-REGULATIONS §999.315 for that browser or device, or, if known, the consumer. Under the GDPR, the intent of the GPC signal is to convey a general request that data controllers limit the sale or sharing of the user's personal data to other da ta controllers (GDPR Articles 7 & 21). Over time, the GPC signal may be intended to communicate rights in other jurisdictions. – globalprivacycontrol.org/#about

The signal also has support from various browsers and extensions including Mozilla's Firefox, Brave and DuckDuckGo's Privacy Browser.

GPC is different from other proposals being discussed and developed in that it gives power to the web user. Google is working on the User-Agent Client Hints specification in the Web Platform Incubator Community Group, and Bounce Tracking Mitigation is on the Privacy Working Group's charter. While both proposals have their merits, neither gives the user a choice in the way that GPC does.

Web users want to have more autonomy over their data. They want to know who has it, where it's going and why, and they want to be able to consent to how their data moves between parties. GPC proposes two browser signals which can be set on all HTTP requests as headers. The two signals will be an interaction and a preference both called do-not-sell-or-share, which differ by scope.

Interaction is set per domain, for example, a web user may want to allow the National Health Service https://nhs.uk to share their data with their pharmacy or health insurance, so they could switch the do-not-sell-or-share interaction for https://nhs.uk off. The same user may not want https://tiktok.com to share their data with anyone so they'd turn the interaction on for https://tiktok.com.

The scope of the interaction is for a domain, and, the scope for the preference encompasses all interactions per browser. Setting a preference is setting a Global Privacy Control.

It's a requirement to return the GPC support resource as a JSON object from a well-known URI (/.well-known/gpc.json) with these members:

{
  "gpc": true,
  "lastUpdate": "1997-03-10"
}

Which has this meaning:

gpc

The value of the gpc is either true (the server intends to abide by GPC requests) or false, to indicate that it does not. For any other value the origin's support is unknown.

lastUpdate

A full-date (YYYY-MM-DD) or date-time (YYYY-MM-DDTHH:mm:ss.sssZ) indicating the time at which the statement of support was made. Later changes to the meaning of the GPC standard should not affect the interpretation of the resource for legal purposes.

For handling requests with a GPC signal, developers can implement a listener by checking for the Sec-GPC HTTP header in requests. An Express app might look like this:

// Any route
app.get("/", function (req, res) {
  // Check for a `Sec-GPC` header:
  const gpcValue = req.header("Sec-GPC");
  if (gpcValue === "1") {
    // Signal detected
    optOutUser(userId);
  }
});

You can alternatively use the globalPrivacyControl property in the browser:

const gpcValue = navigator.globalPrivacyControl;
if (gpcValue) {
  // Signal detected
  optOutUser(userId);
}

The examples above uss a placeholder optOutUser(userId) for illustration, but the backend should call whatever logic is needed to satisfy the user's choice.

The HTTP response would look something like this if the user has set GPC to "true":

200 OK
Access-Control-Allow-Origin: *
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
…
Sec-GPC: 1

It's up to the developer/business to decide how to treat the signal, for example, removing the user's details from third-party tracking or marketing, following a similar procedure as to when users opt out of sharing data for marketing purposes. If in CCPA jurisdiction, the signal must be observed to avoid legal repercussions.

GPC is currently available in the latest versions of Firefox, Brave and DuckDuckGo's Privacy Browser and users can turn the signal on in their settings (PDF). In addition to browser config, GPC extensions are available for Microsoft Edge and Google Chrome.

Developers can test GPC in Express apps using the express-gpc middleware, which you can to your project using npm i express-gpc.

GPC is an exciting specification, in a sea of companies hyper-focussed on how to do private advertising, it's refreshing to have a specification that prioritizes the needs of the web user. With growing browser support and not much integration needed for developers, it's a step toward greater transparency and control for web users.

Lola Odelola is a web standards technologist who works to make web standards accessible to developers. Lola sits on the W3C Technical Architecture Group and participates in various W3C groups as a W3C Invited Expert.