Testing the FLEDGE Prototype

[jefftk]

Link post

(I work at Google, but not on Chrome. Speaking only for myself.)

Chrome has proposed TURTLEDOVE to support remarketing ads without sending your browsing history to advertisers. (discussed in why I work on ads). Since the overall proposal is very complicated and requires large changes, they have also proposed an initial version, FLEDGE, that they expect to build and ship this year. They’re building it incrementally, and they’ve now checked in very initial prototype support.

Lots of things are still missing, but if you download Chrome Canary and start it with --enable-features=FledgeInterestGroupAPI,FledgeInterestGroups you can play with what they have. For example, on my Mac this looks like:

”/​Applications/​Google Chrome Canary.app/​Contents/​MacOS/​Google Chrome
Canary”—enable-features=FledgeInterestGroupAPI,FledgeInterestGroups

I made a demo:

1. Visit auction.html. You should see “no turtledove winner” because you are not yet in any turtledove interest groups.

2. Visit join.html. You should see “joined interest group”, because it is adding you to an interest group.

3. Visit auction.html again. This time, you should see an iframe containing “TC AD 1”. This is an ad selected by a turtledove auction.

Things I ran into in setting up the demo:

• Even though the spec uses snake_case the implementation uses camelCase (#156)

• DevTools support is still minimal

• You have to send X-Allow-FLEDGE: true response headers on anything the FLEDGE API is fetching.

Keep in mind that this is a minimal initial implementation, and there are large parts of the spec they haven’t gotten to yet. If something that is implemented doesn’t work yet, though, it’s probably worth filing a bug.

Comment via: facebook

[Viliam]

The explanation at FLEDGE link is difficult for me to understand. Would prefer some simpler language, examples, maybe even pictures.

If I understand it correctly, the basic idea is that users get some “tags” which mark them as interested in certain topics, and those “tags” are stored in their browser. And the advertiser can specify that certain ad be shown to people who have a certain “tag”.

What I don’t understand is how exactly the tags are set. Your example mentions that if I visit a page about cars, I get a “car” tag set. But who exactly provides the information that “this page is about cars”? Is it the person who made the HTML page?

If yes, I can imagine some ways to abuse it: I can make a page about cars, but set to my readers some unrelated tag, like “porn”, just to mess with them. What is my incentive to provide true information? Why should I care whether other people get shown correct ads, especially if they never find out it was me who provided the incorrect information? Actually, why should I bother to provide any information at all? Let’s go even further, as a user I would actually prefer if authors of web pages I read do not set any flags to my browser.

[jefftk]

The prototypical use case is something like:

1. You visit Amazon and add a blender to your shopping cart

2. You visit the NYT, Amazon shows a blender ad to see if you want to come back and complete the purchase

Today this happens via third-party cookies, but with FLEDGE this would look like:

1. On the Amazon page, when you put the blender in your shopping cart Amazon would call the FLEDGE API joinAdInterestGroup to add you to some sort of amazon.com:prospective-blender-purchasers interest group.

2. On the NYT page, their ad network calls the FLEDGE API runAdAuction, and includes Amazon as a buyer. Amazon gets to run JavaScript in an isolated context which can look at amazon.com interest groups, see that you are in the prospective-blender-purchasers group and bid to show you a blender ad.

What you are calling “tags” would normally be called “user lists” or, in the language of FLEDGE, an “interest group”. (And “tags” are something entirely unrelated: snippets of JS people put on pages)

The incentive to provide true information in the simple version is that the advertiser is leaving a note for themself.

(There’s also a more complicated version, where an ad tech company makes some deals. For example, say ads.example contracts with a car website. On each page, the website includes some code from ads.example that adds users to ads.example:cars. Then, the ad tech company contracts with an advertiser, and agrees to target their ads to users who are in the ads.example:cars interest group.)

[Viliam]

Ok, thanks, makes sense. So large companies like Amazon can set their own groups, and small companies will use Google-defined groups. (And competitors of Google can specify their own groups, which their customers will be able to use.)

The groups are a replacement for third-party cookies, because cookies allow to store arbitrary value, which makes it possible to assign an individual identifier to every user, while with groups the API is only “add this user to group X” and “check whether this user is in group X”. Also, small advertisers can only add you to groups when you visit their website; while their ad is displayed to you elsewhere, your data are read-only from their perspective.

Let me think for a moment… the first thought is that actually you can assign unique identifiers to users who visit your website. Using N groups, you can track 2^N users: user 1 is in the “id-1” group, user 2 is in the “id-2“ group, user 3 is in both “id-1” and “id-2” groups, etc. But this will not be so helpful, because when you are at the Amazon website, Amazon can track you using first-party cookies anyway.

And if you are on a different website… Amazon can create a rule “if the user is in groups id-8 and id-256 and id-2048, but not in groups id-1, id-2, etc., show banner saying ‘Jeff, I know it’s you’”, but Amazon will never be told if the rule was actually used. Or perhaps, they will (because they will be billed for displaying the banner), but they will not be told which website displayed the banner to you. So Amazon can only find out how active you are on websites with Google ads in general, but not which specific websites you follow.

They could find out your other groups, if they decide to spend their resources so, by making rules “if the user has id X (i.e. is in groups id-A, id-B, but not in groups id-C, id-D) and is in group ‘porn’, show banner ‘X-porn-yes’; if the user has id X and is not in group ‘porn’, show banner ‘X-porn-no’”, and then look at the invoice which of the banners was displayed. But they would need to set up rules individually for each user they want to explore.

[jefftk]

if the user is in groups id-8 and id-256 and id-2048, but not in groups id-1, id-2, etc., show banner saying ’Jeff, I know it’s you

Except you can only target ads based on membership in a single group, not a collection. generateBid only receives one group at a time.

[ChristianKl]

If yes, I can imagine some ways to abuse it: I can make a page about cars, but set to my readers some unrelated tag, like “porn”, just to mess with them. What is my incentive to provide true information?

Google’s search engine uses tags of websites to access what they are about. The SEO people spends a lot of effort on providing information via tags about what pages are about to Google already today. The change is going to be about storing the information.

[jefftk]

No, that’s quite different. You’re talking about contextual advertising: showing ads to people based on information about the page they are currently visiting. FLEDGE is intended for remarketing: showing ads to people based on the pages they have previously visited.