A new approach to web privacy — Browser ID
Cookie based user identification is a poor method for user identification, both from a user and technology point of view. There is limited ability to manage and control cookies, leading to generalised behaviour, such as blocking all 3rd party cookies, and encouraging bad actors to find loopholes to managing this.
Identity management is currently completely out of a user’s hands. The average internet user has no idea who is tracking their identity, what it’s being used for, how to revoke it and certainly doesn’t have any fine grained control. Industry provided tools, such as Your Online Choices, are weak implementations to satisfy the minimum level of privacy acceptable by regulators.
Given a blank slate to work from IDFA and AAID (advertising IDs) were developed. These both begin to address a lot of these problems, although by no means perfectly.
- The user has a simple control to reset their ID, although discoverability of this is poor.
- ID access is restricted to companies approved by Apple/Google. It could be argued that long term it shouldn’t be down to platform owners to decide this with the potential to abuse their position.
Despite the shortcomings, advertising IDs are both generally user accepted and have big advantages to all technology companies as many “tracking” requests can be moved to server-to-server communication.
The web browser is now, in comparison, a “Wild West” of 3rd party trackers and abuses of the user that originate from unanticipated use of a technology that standard bodies tried to stop as far back as 1997 (rfc2109).
A better system can exist — one that puts full control of identity into the user’s hands:
- A single Browser ID that is resettable through simple browser settings. This should be easily discoverable and users should be educated. Standard settings could be introduced to reset yearly, monthly, daily… to automatically create discontinuities in user identity, similar to purchasing a new phone every 2 years.
- An extension to existing browser permissions models. Users should have to grant access to the ID before it is shared, although ideally without too much friction. GDPR requires explicit opt in for data processing and this is a strong way of enforcing that. GDPR requires a record of consent. A global ledger, potentially using something like blockchain, or possibly some kind of DNS-like system run by trusted operators.
- The ID should only be transmitted over HTTPS. This forces any ID sensitive activity to be secure, and is generally a good progressive move for the web in general.
- ID consumers should be required to have an ID encryption key. Any request originating from a user’s browser with a Browser ID should have that ID encrypted with a public key that is issued under authority of a regulator such as ICO. All IDs in transit should also be encrypted using the recipient consumer’s public key. This ensures that data can only be read by the intended recipient and ability to process legally could be revoked by the regulator through revocation of the encryption key.
The two encryption methods are complementary. HTTPS ensures that it isn’t possible for a 3rd party to detect whether you are sending your user ID out or not. It does not act as a good identifier for whether an ID consumer is trusted to handle sensitive data, for that we need the secondary revocable encryption. If a company is found to be implementing poor data handling practices it needs to be possible to prevent them from receiving any additional Browser ID.
If the data is compromised, then as long as each ID consumer is maintaining the encryption of the data using their own provided key the impact of a data breach is much reduced. A bad actor could start sending out unencrypted IDs, but legislation, such as GDPR, outlines harsh penalties for acting in this way. I’m not sure there necessarily is a simple, good and necessary technical way to resolve that.
There are some key user benefits to an approach like this:
- This has the benefit of moving the vast majority of 3rd party tracking out of the users browser and into server to server calls. Other than getting the initial approval to handle data an advertiser, or even a site analytics tool, would potentially never need direct communication from the user’s browser. It could all be sent direct from the originating web server, increasing message reliability and not making the user pay a bandwidth/CPU cost.
- Tracking would be more easily revocable per consumer, including easily revoking all tracking privileges to a single platform regardless of the number of domains that they use.
- It opens up the possibility in the future of sharing the ID across devices, but puts the control in the user’s hands, rather than single repositories of user information and probabilistic algorithms.
- If user IDs must remain encrypted at rest then it limits the potential for wide reaching data breaches
- 3rd party cookies could potentially just be removed as a feature altogether. Apple have essentially started the process already so the industry needs to react and adapt. Retargeting companies like Criteo are already feeling the impact of this.
There is also one major publisher benefit that is worth highlighting outside of the obvious. If a global consistent ID is used then it is theoretically possible for a programmatic auction to be completely executed server side, faster than header bidding even allows, and the final ad can be delivered to the browser via the originating domain, significantly reducing the effectiveness of ad blocking.
I see a few main objections to this:
1. It’s regulation of who can do business on the internet.
In the EU (and likely many other places) you have to be registered with an ICO equivalent to be able to process data. This proposal just ensures that those people you do business with online meet that requirement.
2. If a user has to opt in they likely won’t.
GDPR is going to require users to opt in to any company handling data. Currently most people are suggesting page hijacking banners to obtain this opt-in, which is terrible UX. Parts of the industry are going to struggle to get opt ins, e.g. cross device graph vendors. Something browser controlled may allow a user to opt in without needing to directly interact with a technology vendor.
3. Who is going to pay for encryption key servers/consent ledgers?
Most businesses within advertising (publisher side and buy side) are already considering paying for access to cookie based universal IDs. If those budgets were redirected to a more central solution, as part of some kind of data processor registration it should easily cover costs.
4. Digitrust (or similar) already solves this problem.
Digitrust still suffers from many of the inherent problems of cookie based systems. Cookie deletion rates means there will still be a lot of vendors constantly trying to sync cookies. Apple’s hostility to 3rd party cookies also limits the effectiveness of this. I think Digitrust is potentially a good bridging technology, but it is also being handled as an advertising enablement technology, rather than a privacy enabling technology.
What does this look like as a global implementation?
The biggest challenge is how to get global government implementation. It also raises questions that I don’t think are adequately answered, like what does it mean to be an Asia only company that is visited by a user situated within a GDPR bound country.
1. As an ID consumer do I now need to register on every country separately?
2. Is everywhere capable is supporting privacy registration?
As an end goal I can imagine that certificates are country restricted, your browser by default only checks in the local region keystore for ID encryption keys. I envisage that you would end up with an EU wide data policy, and perhaps reciprocal agreements with other countries to standardise data handling policies, and therefore share keys across borders. The nice thing about this approach is that a country would default to full privacy until there was enough internal lobbying to set up certificates. I would also expect a lot of the technical heavy lifting could be managed by ISPs/browser makers/etc. rather than expecting that to be all government controlled.
A business approved by a country that has very lax privacy regulations (and so would fail to develop reciprocal data agreements with other countries) would be limited to only tracking the citizens of that country (as defined by browser settings). I am aware I’m glossing over some potentially complicated mechanics there, but this, or something similar, is a potentially feasible approach.
So it really comes down to timelines. My gut feeling would be that we would need to be thinking of timelines around 3–5 years to move to something like this. There isn’t particularly any new technology at play here, and developers are already having to think about going 3rd party cookie less.
If Google, other browser makers, and the EU announced that Browser ID was being released in 6 months and enabled for ID consumers with valid encryption keys, along with 3rd party cookies being disabled in 2 years, that leaves a long migration window with strong incentive to move faster for better tracking. I think the key element would be that a unified decision, either amongst browser vendors or legislatively, would need to be made to retire 3rd party cookies and approve Browser ID.