Discuss FPS membership standards

[brownwolf1355]

Follow-up discussion on email thread First-Party sets and the potential application of the JournalList trust.txt specification [1].

[1] https://lists.w3.org/Archives/Public/public-privacycg/2022Jan/0012.html

[brownwolf1355]

In doing my homework of getting up-to-speed on the prior discussions that were referenced in the email thread, I noted Kaustubha's comment [1] that articulated the objectives of this work with regard to what I asked about sufficient representation to confirm the controlling/controlled relationship implied by First-Party Sets.

'We hope to strike a balance between scalability, and abuse-resistance by having acceptances primarily based on self-attestations and technical checks; along with supplemental accountability measures such as a publicly auditable log, random spot checks, and a mechanism for users and civil society to report potentially invalid or policy-violating sets. We think that the public self-attestations will play an important role in deterring abuse, because as footnote#1 in this section points out, "[Public] Misrepresentations about an entity's ownership/control of a site that lead to the collection of user data outside of the First Party Sets policy would be enforceable in the same way that misrepresentations or misleading statements in privacy policies are."'

This is not dissimilar to the approach we have envisioned in JournalList, but with a focus on self-attestations to begin with to facilitate adoption.

[1] #48 (comment)

[dmarti]

The Independent Enforcement Entity (IEE) is likely to receive a large number of challenges of FPS validity. Some will be duplicates or invalid, but many will require some work by the IEE.

• Automation-friendly challenges. Examples include cases where the text of a privacy policy does not match across set members, or the content of industry-standard files is inconsistent with FPS membership criteria. These could be handled once, manually, and then used to improve the IEE's crawler and validator process. (See FPS members must allow technical verification #65)

• Challenges requiring fast, basic human checks. Most common example would be lack of user-obvious set membership, based on site design and copy. In these cases the IEE could run an online quiz for a panel of users and ask them to identify sites with an FPS in common, then reject an FPS where too many users fail. Would require some human interaction, but if the IEE sets up a decent quiz tool, a few IEE employees could process many challenges.

• Challenges requiring checks with predictable delays. For example, if a challenge claims that two sites do not share controllership, the IEE could automatically make a test account on one site, carry out some kind of opt out (such as an email preference or objection to processing) and then see if it is reflected on the other site. Delays are likely, and allowed for by all the regulations I'm aware of, but the scope of the work is predictable.

• Challenges requiring specialized expertise. This is where language on ownership and corporate governance in FPS membership standards could expand the work of the IEE in an unpredictable way. (Links: Replace owner/controller language with simpler language on controller (and define it) #56 (comment))