#601: Early design review for the FLoC API

Visit on Github.

Opened Jan 25, 2021

HIQaH! QaH! TAG!

I'm requesting a TAG review of the FLoC API.

In today's web, people’s interests are typically inferred based on observing what sites or pages they visit, which relies on tracking techniques like third-party cookies or less-transparent mechanisms like device fingerprinting. User privacy could be better protected if interest-based advertising could be accomplished without needing to collect a particular individual’s exact browsing history.

The FLoC API would enable ad-targeting based on the user’s general browsing interest, without the websites knowing their exact browsing history.

Please read the Security and Privacy self-review for the privacy goals and concerns.

Further details:

  • I have reviewed the TAG's API Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
  • The group where standardization of this work is intended to be done ("unknown" if not known): Unknown
  • Existing major pieces of multi-stakeholder review or discussion of this design: Unknown
  • Major unresolved issues with or opposition to this design: None at the moment
  • This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

☂️ open a single issue in our GitHub repo for the entire review

💬 leave review feedback as a comment in this issue and @-notify @xyaoinum, @jkarlin, @michaelkleber

Discussions

2021-02-08

Minutes

Amy: a few red flags...

[discussion of whether this fixes any problems with current ad-tech]

Ken: I don't think it helps...

Amy: I'm worried it centralizes grouping - under control of the browsers - using machine learning.

Sangwhan: fairly transparent - the alg. they are using is transparent. Anyone can implement it.

Ken: like privacy sandbox

Sanfwhan: spin-off from privacy sandbox- instead of identifying users you identify someone as part of many groups...

Lea: a permission?

Ken: no, but you have to opt in.

Sangwhan: i think the idea is to support it by default.

Amy: I worry about the anonymizing - youre anonymous but only in a group of x-thousand people.

Lea: are users able to change these if they think they are incorrect.

Sangwhan: I think you could scrub your history.

Lea: could still be generated incorrectly. A lot of websites that track you today allow the user to change things. It seems reasonable to give that control to the user.

Amy: sensitive categories - somne of the cohorts could be sensitive like protected classes...

Ken: what about the VPN - change country.

Dan: what happens if you have a shared computer - like a school computer?

Amy: their answer to protected classes is "we won't do it" but need more detail.

[assigned and set for next week]

azimuth

Sangwhan: angle of the pen in pointer events...

Dan: let's discuss it at the plenary.

insertable media processing

Sangwhan: I just triaged and assigned myself.

[set milestone]

webotp

[ken and sangwhan assigned]

[set milestone]

css color adjust level 1

Lea: assigned myself... Not prepared to discuss now.

[set to next week]

app history

Sangwhan: [assigned and milestoned]

managed device

Sangwhan: we need some security expertise here... Not sure if this should be part of the web. Feels like something that is part of chromeOS - leak a unique identifier to specific web sites - for managed enterprise environments. That's my first impression.

Ken: I'm sure MS would want the same thing.

Dan: Fugu thing?

Sangwhan: I don't think so.

Ken: It's about enterprise...

Sangwhan: there is something called "Chrome Enterprise"... lets you centrally control extensions in Chrome for employees...

Dan: so why in WICG?

Ken: if you have to have a proprietary API for each platform...

Amy: what does a standard API solve? so an employee could choose the browser that controls them?

Ken: yes...

[...discussion on whether you need a standardised API...]

Amy: in that situation they might tell you what browser to use anyway...

Ken: you can have multiple browsers - all managed...

Amy: I don't know if it's a bad thing to increase friction for that. If they need to implement for different browsers. Anything that discourages ...

[vigorous debate of whether "the enterprise" belongs in the standardization process]

Dan: what's Apple's opinion? What's igalia's opinion?

Sangwhan: this is likely to be a chromium-specific feature.

Dan: that also brings up the question of why do this in W3C?

Ken: we could end up with a better result if it's done in w3c... make it as good as possible.

Lea: no strong opinions but that sounds reasonable...

Sangwhan: Ok with the use case not entirely comfortable with the venue... Concerned.

[went over time - let's discuss further at the plenary]

2021-02-15

Minutes

Dan: bump it a week?

[bumped]

2021-02-22

Minutes

Dan: be good to get a PING opinion. Should we start the conversation? ... privacy and security self-check...

Rossen: any reason to rush?

Dan: not that I know of. It says early review. Profiling people based on sensitive criteria can be harmful to them. Targeted ads to do with baby care because of a certain age range, etc. There are plenty of high alarming value type stuff. Is there something we can say immediately to provoke that discussion? Have they already accounted for it?

Amy: they say something about sensitive categories, that they will just not use them... but not clear who decides what is sensitive.

Tess: if catgories are algorithmically generated and not designed by humans you can't say you're not going to make sensitive ones. And who watches the watchers? how do they decide what's sensitive and what's not?

Dan: leaves comment

Amy: I will leave a comment about the centralisation of the lists, transparency of that to users

2021-03-08

Minutes

Amy: left feedback, still waiting

Dan: leaves comment

... they replied: 'still thinking' will respond in a week or two.

2021-05-Arakeen

Minutes

Amy: lots of community discussion (negative).. no more followup from original requester.. more issues coming up.. cohort size.. forging FLoC ID.. matching it with existing user data.. rolled out but not being trialled in EU..

Dan: we should leave strongly worded feedback about no action happening on issues raised, and it's shipped

Rossen: agree.. invite them for a call?

Dan: not a separate document

Rossen: nothing substantial addressing review feedback. Evidence of additional community feedback which isn't being taken in.. but we're not here to manage and channel community feedback. Considering closing as unsatisfied based on lack of engagement. Happy to arrange a breakout with them to have that conversation.

Amy: will leave comment

2021-08-09

Minutes

Amy: they responded ot say based on our feedback they're redesigning it. Close and ask to reoopen or open a new one when they have a new design?

Dan/Peter: yep

Amy: [closes with comment]