Thread · 19 tweets · 25 Jan 2022

Earlier today, Google announced "Topics" as their next iteration on FLoC to provide cookieless interests-based targeting on the Web. This is a thread of notes — in no particular order. Technical Explainer: github.com/jkarlin/topics Blog post: blog.google/products/chrom…

Google's blog post doesn't start off very well. "Transparency and control" sounds great, but it's what companies say when they don't want privacy. It means "we know we're doing things you won't like, that we've set a default you don't want, and that most of you won't change it."

They're doing a *lot* of transparency and control. The word "control" shows up five times in six paragraphs. I wonder if the privacy folks at Google cringe when they see that. It's the privacy equivalent of "we're the best at JavaBeans™!" Except older and less cool.

In fairness, this could just be the comms people comms being used to presenting privacy this way. It's the go-to for a reason: you can't be against "transparency & control" — why do you hate our troops? — even though it's established science it doesn't work.

Speaking of comms, it's interesting to see the mention of the @CMAgovUK commitments here. If adopted, these commitments are so ineffectual that they really amount to nothing other than a PR gift of the CMA to Google.

Sigh. That's all of the high-level blog — let's look at the tech proposal. The good news is: it seems better than the comms about it.

On any given page load, any origin (top or embedded) can become eligible to learn the topics matching the top level origin for that user. If you visit berjon.com and I embed adsA.org, both of these could know you like cats. (…)

If you later visit nytimes.com, and they embed both adsA.org and adsB.net, adsA.org might get the "cats" topic to target you with (depending on rules that introduce noise) but adsB.net won't.

The first noteworthy improvement over FLoC is that it doesn't require Chrome Sync to be safe against sensitive targeting. The "we need to know everything you do to keep you safe" part of FLoC was… not great. It doesn't mean that the "knowing everything you do" stops, but still.

Overall, the privacy properties of Topics are an improvement over FLoC. Less is revealed, the topics are controlled, and the sharing is more restricted. I don't know how that translates into utility, but the improvements are worth flagging. Problems remain.

The mechanism that controls who benefits from observing people is origin-based. So if CoolNicheSite.org and VaxxAreMurder.com both embed adsA.org, the latter free-rides on the topic value carefully curated by the former.

Not every API can solve this problem, but adtech (and Google) are key to monetising hate and disinformation — if we expect something Topics-like to become a standard, this consideration needs to be part of the threat model.

A better (if more complex) option here would be to enable sites to establish topic federations. Inside the boundaries of such federations, topics value can be shared, but not outside.

It's a rich-get-richer proposal: the more sites a third party is on, the more likely it is to get topics to target (meaning it gets more publishers, meaning more topics…). The explainer acknowledges that but doesn't list it as an issue.

This is another aspect for which allowing sites to federate around topics (and perhaps around a taxonomy or the means of setting topics?) could address structural issues and make Topics a more Web-friendly proposal.

That's it for now: • Better than FLoC; • Enables revenue transfer to disinfo; • Competition issues, structurally winner-take-all; • Might be fixable by pushing more power to first parties; • Talk to your kids about "transparency & control" before the data industry does.

Addendum: this perfect explanation of transparency & control just came across my feed.

Also: Topics heavily incentivises having an iframe calling the Topics API on as many domains as possible. You can expect things like Disqus, every embedded tracker, every SSO, etc. to add an iframe that does just this. And 3Ps would likely topic-sync, just like with cookies!

I just realised: this API forces header bidders to create an iframe before they can see topics. This will slow them down, and every ms counts. It's Death, Taxes, and Google stopping at nothing to prevent header bidding I guess.