W3C Ads Privacy Brief: January 2023
This brief is the first of its kind. A lot is happening in privacy-related W3C meetings, Github issues and side conversations. We follow all we can. For the important stuff, the impact could be major. However, we know of no single source synthesizing the activity so companies can plan accordingly. This brief fills that gap, freeing up your time and bringing you peace of mind. We pull meaningful overall highlights and summaries by focus area, plus share thoughts on how your business might respond.
We plan to publish this brief monthly because it allows for all the groups to meet at least once or to have had some offline activity occur (i.e. Github issues and discussions).
The first issue is long. There’s a lot to introduce, as you’ll remember from our OS and browser ads tools primer. Future briefs will be shorter.
Highlights
Topics API: Feature Incubation vs Standards Setting and the Impact of the CMA
Feature Incubation vs Standards Setting
Recent Topics API news that W3C’s Technical Architecture Group (TAG) rejected Topics API in its current form is a reminder of the two basic purposes W3C serves: incubation and standards setting. It’s a classic funnel. More ideas come into W3C groups than ever go out the other end as standards. Most reporting on Privacy Sandbox, a set of ideas Google brought to W3C, misses the distinction, which confuses the market about Privacy Sandbox’s status.
Publicly incubating and refining ideas into features deployed by a single browser and, in the case of Privacy Sandbox, an operating system, is a worthwhile end in itself. This is particularly true given Chrome and Android market share.
Browsers and OSs can and do release features on their own. An unfavorable opinion from W3C’s Technical Architecture Group (TAG) indicates an incubating idea is unlikely to enter the standards track anytime soon. We don’t know of anyone who believed Topics was on its way to cross-browser adoption even ahead of TAG’s review.
Many responses to TAG’s decision assume Topics is dead in the water, but don’t make the distinction that dead in the standards track doesn’t mean dead in incubation. Google will continue to develop Topics API. We expect Topics discussion to continue at W3C in a Community Group setting.
Impact of the CMA
Why will Google continue pursuing Topics? Google’s commitments to the UK Competition and Markets Authority (CMA) require it to offer adequate replacement technology before Google can remove third-party cookie support from Chrome. Market participants must test the new Privacy Sandbox features in order to establish that Privacy Sandbox replacements work similarly well for advertiser and publisher use cases as third-party cookies. The easiest to test, by far, is Topics. The other flagship Privacy Sandbox features, FLEDGE and Attribution Reporting API, require non-trivial updates to ad technology stacks and close coordination between ecosystem actors. Topics, however, is a single signal to pull into ad decisioning logic. Given the pressure to get more companies to test Privacy Sandbox and provide CMA with testing feedback, Google likely will keep Topics in the mix as low hanging fruit.
Bigger picture, we think the W3C community is prematurely excusing itself from the table simply to get a news cycle’s worth of credit for appearing to stand up to Google. W3C TAG representatives can see the situation Google is in with Topics as easily as we can. Knowing Google will move forward, but stepping away from that discussion, means less potential for impact in the longer-term direction of this browser feature. Advertisers will always want to understand user behavior online or off. TAG should guide the W3C community to lean in to opportunities to create accountability and control over that practice instead of wishing the incentives would just disappear.
Private Advertising Technology Community Group: Likely Progress in New York
On February 6 and 7, Private Advertising Technology Community Group (PATCG) will meet in person for the second time. From our Intro to W3C:
Chartered by Google, Meta, Microsoft and Mozilla just over a year ago after frustrations with the circus that was the Improving Web Advertising Business group, PATCG is the most likely group at W3C to give way to a web standard for emerging browser (and operating system) ads tools.
PATCG has two clear goals at the moment to:
- Align on an attribution measurement approach that is ready for the standards track.
- Form a W3C working group to take the reins and develop the idea into the level of detail web standardization requires.
Meeting in person for two days likely will lead to significant progress on both goals. Meta is serious enough about its desire to hammer out a cross-browser attribution approach that it offered up office space in New York and will fly one of its W3C representatives halfway around the world.
There are two attribution approaches under serious consideration: Google’s Attribution Reporting API (ARA) and Mozilla/Meta’s Interoperable Private Attribution (IPA). A small group is hammering out key areas to align between the two approaches. We expect that group to report progress at the meeting in New York. Meanwhile, Google still tests ARA at full speed alongside its other flagship Privacy Sandbox features. This reinforces the position highlighted above: incubating individual browser features and producing standards are two distinct courses at W3C.
Chrome and Android progress ARA while still participating in the PATCG (and eventually PATWG) to chip away at an attribution standard that may look different than ARA. If the working group to be formed (“chartered” in W3C parlance) lands on an attribution standard that is not ARA, we likely will see Chrome (and possibly Android) support both the standard and ARA for a time. This may sound confusing, but it’s rational. Google wants to move forward with Privacy Sandbox features for many reasons. Waiting on the standards process isn’t a great option when trying to not delay the third-party cookie deprecation timeline again and meet CMA requirements. Yet, we see Google’s leads for ARA actively working to come to consensus with Mozilla/Meta while seeing whether there’s also a path forward with Apple. We expect Microsoft’s Edge browser to fall in line with Chrome in the short term.
Forming the working group sounds easy enough, but the first attempt was unsuccessful. The W3C process requires a working group to create a standard recommendation. The process makes it so this doesn’t happen willy-nilly. James Rosewell, founder of device identification service 51Degrees, and his Movement for an Open Web (MOW) with undisclosed members objected mightily to the initial attempt to form a Private Advertising Technology Working Group (PATWG). Criteo’s Joshua Koran echoed many of James’ objections. A few other companies, including Magnite, objected to the proposed group’s exclusionary scope (focusing on features only browsers can deploy), while some, like Apple, declared the scope too broad.
W3C is a consensus-driven consortium so there’s no specific bar to meet in order for a charter to proceed. It requires approval by the W3C team after a charter is put to members for acceptance, feedback or objection. The W3C team weighs formal objections and what they see as dissent or lack of support to the charter. Few members participated in the review process for the PATWG charter. Between this and the formal objections cited above, the W3C team sent the PATWG charter back to the PATCG for more work. We expect the working group to resubmit the charter for approval soon after the February in-person meeting.
This group is worth paying attention. If it succeeds in producing an attribution measurement standard that’s interoperable across web and, perhaps, even mobile, it would provide massive scale that will not be achieved party-by-party using email matching or other PII-based identity services.
Updates by Focus Area
We focus on measurement, targeting, foundations and cross-site identity surface area removal. Each feature includes what we think is the best link to learn more, a status, the name of the forum where discussions are happening and an update. This first issue includes more detail about the feature itself for building context.
Measurement
Attribution Reporting API (ARA) - Google
Status: Live testing in Chrome
Forum: Web Incubator Community Group (WICG)
Google indicates its intention to ship ARA in early 2023, while acknowledging other standards work in progress addressing attribution. This is a big deal. Effectively, it’s a verifiable clean room with a 100% match rate at Chrome scale (and, at some point, Android).
ARA has been available for live testing in Chrome for a portion of web traffic for quite some time. “Intention to ship” means a stable version of ARA will go to all Chrome users. This gives companies time to integrate ARA into their attribution pipelines and practices. The announcement stresses insights gathered from broad deployment should inform the concurrent standards work in PATCG (see Highlight above).
As we hypothesized, Chrome says there may come a time when a bigger-than-just-Chrome standard is hammered out. Chrome will be open to supporting both ARA and whatever that standard is, potentially even deprecating ARA if the ecosystem preferred the alternative standard. Recently, a Meta employee gave notice to developers it is in development with an Interoperable Private Attribution test in Chromium, the open-source project behind Chrome.
The intention-to-ship announcement is for Chrome only. ARA for Android will follow the schedule Google laid out in mid-November.
Private Aggregation API - Google
Status: Live testing in Chrome
Forum: Private Advertising Community Group (PATCG)
While ARA focuses solely on attribution, Private Aggregation API, a relatively new proposal in the Privacy Sandbox lineup, is more general purpose. It is designed to support non-attribution measurement outcomes connected to other Privacy Sandbox proposals like FLEDGE and Shared Storage API. For example, there’s discussion of Shared Storage API supporting daily reach measurement with the help of Private Aggregation API. A general-purpose measurement at Chrome (and eventually Android) scale holds a lot of potential. We wonder how many advertisers, agencies and their technology providers are following how much ad tooling will be at their disposal in the browser (and OS).
Interoperable Private Attribution (IPA) - Mozilla/Meta
Status: Advanced discussion and prototyping
Forum: PATCG
IPA is the only credible contender to Google’s ARA. Even so, it has an uphill battle to fight given it hasn’t entered origin trials. By the time it does, ARA will be fully out the door in Chrome. The Chrome team will be the first to tell the Mozilla (Firefox) and Meta team it’s not easy to get companies to test in origin trials. Firefox has less scale and the companies that test or adopt ARA will be wary of devoting more resources to R&D.
The Mozilla and Meta team are working on a prototype, including Chromium. The proposal has evolved quite a bit since its introduction this time last year. Its main impact has been bringing other browsers into the ads attribution proposal space, a space that is more palatable than targeting. Additionally, it forced a discussion on the merits of multi-party computation vs. confidential computing in trusted execution environments. This discussion isn’t over yet, but there’s a good public record of positions to inform future action.
Private Click Measurement (PCM) - Apple
Status: Generally available in Webkit (Safari); no recent discussion at W3C; Mozilla is not supportive
Forum: Privacy Community Group
Apple’s John Wilander, leader of Safari’s Intelligent Tracking Prevention, introduced Private Click Measurement (PCM) to W3C’s Privacy Community Group in mid-2019, ahead of releasing the feature to Webkit, the open-source project behind Apple’s Safari browser. It got some attention, but for the last year it’s been quiet.
PCM is live in Safari and has even seen updates. We know Meta integrates with it, but do not know of many independent ad technology companies that have bothered to integrate. PCM has limited usage due to several reasons: Safari’s smaller browser market share, industry’s years of operating without PCM and writing off Safari traffic, and a lack of awareness that PCM exists. As we approach Google’s announced deadline for third-party cookie deprecation in 2024, we may see an uptick in PCM testing.
Targeting
FLEDGE - Google
Status: Live testing in Chrome
Forum: WICG
FLEDGE continues trucking along. Meetings are focused. Github discussions resolve quickly. Proposals to make it more powerful abound.
It is clear which companies are leaning into FLEDGE-based R&D: Criteo, Google (buy- and sell-sides), RTBHouse and, just recently, Epsilon (owned by Publicis). Three of the four published FLEDGE test findings. All four regularly put forward detailed ideas that are often incorporated in the design or at least spur productive discussions. FLEDGE’s biggest challenges remain its complexity, the coordination required to test it and the industry’s general lack of awareness (particularly of its evolution into a sophisticated multi-tool).
Topics API - Google
Status: Live testing in Chrome
Forum: PATCG
Topics API faces fundamental misunderstanding and animosity, which is evident at Topics meetings. People confuse Topics’ approach with IAB Tech Lab’s Seller Defined Audiences (SDA). Topics API is based on the browser’s ability to observe consumer activities across sites. The category of the most frequented site for a period is returned. SDA, on the other hand, is based on what a single site or sites sharing data can see within their scope, which will always be more limited than the browser. Moreover, SDA mixes what a site infers about its audience and knows is valuable to advertisers. Those commercial incentives distinguish it from Topics.
Also, some assume Google wants to keep Topics alive to maintain a revenue stream from money spent on long tail sites that are, at best, questionable and, at worst, dangerous (e.g. misinformation, hate speech, etc.). We think it’s far fetched, but the argument is widely made and regularly hurled. Misunderstanding and animosity will be hard to overcome, but we suspect ad technology companies will gradually start pulling in Topics signals anyway. If they’re factored into buying models, advertisers might not even know they’re there.
Foundations
Cookies Having Independent Partitioned State (CHIPS) - Google
Status: Generally available in Chrome; Mozilla is supportive
Forum: Privacy Community Group
Less commonly known, CHIPS provides per-site partitioned storage for third parties. Chrome created this great visual to illustrate how this differs from today’s third-party cookies:
Currently, third parties can set and read the same cookie value across sites on a single browser. CHIPS enables a third party to still set and read a cookie, however the cookie set/read is scoped to that site. Thus, partitioned storage stops cross-site user recognition.
We expect this will be the workhorse for companies working with vendors to collect and use first-party data in their own context. Passing first-party cookies to vendors requires more coordination than a utility like this. We use the term context here instead of site because there is another mechanism that will allow storage across sites on a limited and transparent basis: First-Party Sets.
First-Party Sets (FPS) - Google
Status: Advanced discussion
Forum: WICG
FPS experienced an overhaul after poor reception from the browser and privacy communities. The core idea behind FPS is supporting use cases for cross-site recognition of users within a given set of related domains. The updated proposal is specific about categories of relationships between domains. For instance, different country code top level domains (e.g. example.co.uk and example.com) are a type of subset and different service domains are another (e.g. content-hosting-for-example.com and example.com).
The most contentious FPS issue is the associated subsets category. Associated subsets is the area a parent company like Disney might declare disney.com, abc.go.com and espn.com are related and, thus, should be able to recognize the same user across itself (within browser storage tech like CHIPS). It’s contentious because the current limit is three related domains and the process for validation leans on centralization in Github.
Big media companies that liked the first version of FPS are frustrated by the changes, particularly in Europe where it appears more media companies are paying attention. Other browsers and privacy professionals say a user might not expect a parent company to track them across domains within that family, like the Disney example, and three is already too many.
Google says the limit and validation method could change based on community feedback, but notes the UK CMA is wary of giving large media companies a competitive advantage over smaller sites not owned by the same parent. It’s a catch-22.
Federated Credential Management (FedCM) - Google
Status: General availability in Chrome; support from Mozilla; significant changes still in development
Forum: Federated Identity Community Group (FedIDCG)
FedCM has evolved a lot over the last two years. Early on, it looked like the equivalent to Apple’s Hide My Email. Now, it’s primarily about fixing the parts of federated login that will break when third-party cookies are deprecated in Chrome. Google, Meta and Microsoft provide the most popular federated login providers, but there are other examples, like European netID.
The W3C forum where FedCM is under discussion just requested a review from TAG, the same respected group that provided Topics API with negative feedback. Unlike Topics API, FedCM has support from other browsers, most notably Mozilla.
FedCM’s current goal is reducing impact to federated login post-third-party cookie deprecation. It’s likely Chrome and other browsers who support FedCM will eventually move toward a world where the email used for the account cannot be used as a cross-site tracking category.
Shared Storage API - Google
Status: Live testing in Chrome
Forum: WICG
Arguably, Shared Storage API is the most powerful and least recognized proposal from Google in discussion at W3C. It’s a general purpose way to run specific controlled functions that can access cross-site information in the browser without leaking that cross-site information. Recently, Google began publishing recipes for Shared Storage, sometimes with Private Aggregation. Reach measurement, frequency control, A/B testing and creative rotation are all possible to some degree using the worklets Shared Storage API describes.
Unlike many items in this brief, Shared Storage API does not have a regular meeting cadence. Google may be attempting to lay low on Shared Storage use cases until its flagship features—ARA, FLEDGE and Topics—are better and more widely tested. Developers can only test so many things at once.
Removing Cross-Site Identity Surface Area
Status: Recent Github activity indicates Google may be remounting previously stalled efforts
Forum: No dedicated home at W3C; Internet Engineering Task Force (IETF) is where most discussions of this nature occur
There is no W3C forum dedicated to or regularly discussing the removal of third-party cookies given Chrome is the only browser that still supports them in an unpartitioned way. Similarly, IP address obfuscation doesn’t have a home at W3C, though it’s apparently been on agendas regularly over the years.
Google seems to be reviving discussion under the name IP Protection which sounds a more buttoned-up, if less fun, than Gnatcatcher. Documentation for IP Protection says proposals have entered public discussion, but point to an older IP Blindness Github repository. The latest idea, dated November 2022, appears to be standardization of Apple Private Relay’s two hop methodology.
IP addresses comprise much of the ad industries’ post-third-party cookie tech, so you may be either disheartened or excited, depending on your privacy feelings, to find we’re still a long way from scaled IP address tracking mitigations. Every time the discussion comes up in mixed forums, there’s always a staggering number of use cases presented that would break.