Replace owner/controller language with simpler language on controller (and define it)

[dmarti]

• Remove reference to Do Not Track

• Add a source and definition of "controller"

• Remove language on ownership, replace with more consistent mentions of "controller"

• Mention that common branding should apply to users of assistive technologies

Ownership verification is complex, does not add enforceable protections for users beyond the common controller requirement, and is likely to create costs and risks for some sites that would make it hard to use this feature.

Refs: #14 #18 #20 #49 #55 #75

[jwrosewell]

This PR improves the proposal. Thank you.

References to branding should be removed for the reasons mentioned in #50. Phrases "such as through common branding" could be replaced with "such as through a privacy policy" if specific guidance were required.

[dmarti]

@jwrosewell Just a common privacy policy is not sufficient. Privacy policies are generally long and go unread.

Obvious common set membership, that is likely to be perceived by all users and not just the few who read the privacy policy, is clearly a goal in this proposal. (See my comment on #50 -- branding is necessary for an FPS but not sufficient.)

I did use the term "branding" to cover user-perceptible and obvious indications of set membership. However, in common business language, "branding guidelines" tend to refer to graphic design elements such as logos. And it would be inadequate for FPS members to be connected only by elements that are perceptible only to people using particular categories of web client. People browsing the site with a screen reader or other assistive technology would also need an obvious message that the sites are connected.

If there is a better term for "obvious indication of set membership that would be perceptible to all users of the site" than "branding" I could update this PR.

[jwrosewell]

@dmarti Those involved in the development of swan.community debated this issue. We settled for providing a well known end point that would return JSON with additional information needed for identification of the controller. Here's a link to the Open Web ID (OWD) explainer that covers this.

The end point provides a field called "name" which contains the common name for the OWID creator (controller in this PR). This would then be used should the user wish to inspect the owner. The information returned could also include other information such as DUNS number, a signature from an notary confirming the relationship between the common name and registerable domain name, or some other identifier,

The common requirement here is that only a short common name for controllers that can be read or heard is going to fulfil the initial user requirements.

[dmarti]

@jwrosewell Providing additional metadata on the FPS controller would be useful, thank you. Since it's a different topic, it should probably be a separate pull request.

The FPS still needs to be obvious to a user when they are using the site normally.

Can you make your suggested Open Web ID information requirement into its own PR?

[krgovind]

Thanks for this PR, @dmarti !

There is also related recent discussion in the TAG Privacy Principles Task Force; where it appears that the group converged on "common controller" being preferable to "ownership".

Would you be willing to present this on the next PrivacyCG call? I'd also like to hear from the group before I merge in your changes.

[krgovind]

Can we remove the mention of assistive technologies here, but keep it in your second reference (line 76)? The sentences fits in better with the specificity of guidance around common group identity.

[dmarti]

Done (in 3c3e485)

[krgovind]

Since this PR removes the citation to the DNT specification, could you please specify the Section/Page number of the FTC report that supports the previous statement "The first party is defined as a common "controller" having a "group identity that is easily discoverable by a user"?

[dmarti]

I'll add page numbers for one portion of the report that covers this.

[krgovind]

@dmarti Could you clarify how this addresses #55 ? It isn't obvious to me.

[dmarti]

@krgovind Just added some explanation to #55 to hopefully make it clearer how ownership records could be a way for an attacker to try to "break" an FPS by misrepresenting ownership of companies.

[krgovind]

@krgovind Just added some explanation to #55 to hopefully make it clearer how ownership records could be a way for an attacker to try to "break" an FPS by misrepresenting ownership of companies.

Thank you!

Also, in case you missed it, I left a comment on the change itself and was wondering if you'd be willing to present this change on the next CG call?

[dmarti]

@krgovind Yes, I would be willing to present on the next CG call. If needed, I can summarize the points on concerns about ownership requirements and FPSs from the FPS adhoc meeting. I think most of the key points are in the issues linked to from this pull request.

[krgovind]

@dmarti Thank you for the addressing my feedback!

I added the agenda+ label, which the chairs will use to generate the agenda for the next meeting.

A written summary on the ownership requirement here on this PR would be very helpful, since there are multiple issues linked from the pull request, some of which have lengthy discussion. Thanks again!

[dmarti]

@krgovind Thank you. Here is a summary of the key issues related to ownership requirements in FPS, with links.

Common data usage practices, not corporate owners, matter to users

Most people don’t know which of the sites they use have common ownership, and in the case of independently operated subsidiaries with different data usage practices, common ownership does not change how the user's data is handled. In order for an FPS to be meaningful, set membership will need to be obvious to the user and set administrators will need to make an obvious commitment to common privacy and data stewardship policies. (“controllership”) Arbitrary/opaque nature of "organizations" as the arbiter of first-party sets · Issue #14 · privacycg/first-party-sets

Costs of enforcing an ownership requirement

Browsers and enforcement organizations do not have experts in corporate ownership documents in all possible jurisdictions in which an FPS could operate. Enforcement of organizational structure within FPS · Issue #18 · privacycg/first-party-sets

Ownership structures that would make an ownership requirement meaningless are practical

A new entity could be purposefully designed to comply with an ownership requirement without adding any meaningful privacy protections for users, but while increasing costs and risks for sites. MERS for web properties · Issue #49 · privacycg/first-party-sets

Attackers could falsify ownership records to break a site’s FPS

People who are familiar with the FPS governance process could break a site’s FPS by creating fake records that would be difficult for a browser vendor or FPS enforcement organization to verify. FPS as an attack surface · Issue #55 · privacycg/first-party-sets

[jwrosewell]

@dmarti I've submitted a PR to the document as you suggested.

I have also raised issue 64 related to the viability of the enforcement entity. Unless this can be resolved, which would mean an enforcement entity being willing to operate any future technical specification, another method will be needed.

[npdoty]

While ownership alone may not be sufficient to address all user concepts of a common party, and while mostly unrelated organizations may be able to show common ownership in some cases, I don't see the advantage of removing the DNT reference, reducing the alignment with the FTC document and removing ownership requirements from the concept of a party altogether. (Joint controllership appears to be a potentially very broad concept in GDPR law, including shared agreements between entirely different parties.) There can be multiple necessary conditions even if none alone is sufficient.

Potential corporate fraud attacks (#55) don't seem like a reason to remove common ownership from the definition of a party. That threat model could instead be considered in determining the best way to audit and enforce UA policies.

[jwrosewell]

DNT does not enjoy consensus. Removing the reference makes sense to maximise the chance of this document gaining consensus. If consensus is not the goal then it probably doesn't matter.

[jwrosewell]

Joint controller should be allowed for to ensure large single controllers are not advantaged over smaller controllers that need to operate with others to compete. I believe TAG touched on this. Regulators also recognise this.

[dmarti]

@npdoty I'm not trying to reduce the alignment with the FTC document, and would like to preserve it and strengthen this alignment as necessary. It looks like this document is a good reference point, to show a version of "controller" that reflects common understanding and is not tied to the European GDPR. Different jurisdictions have different ways to refer to the "person/entity that is responsible/accountable for decisions that affect how a person's information is used."

"Controller" is a relatively short, understandable way to refer to this, and just because it's a European term doesn't mean it's relevant to Europe only.

@jwrosewell Allowing for more than one controller per FPS would require changes to "site-declared sets in browsers" among other areas so should be a separate PR.

[michael-oneill]

Much thought, effort and debate went into defining the party idea in the DNT TPE, which itself referred to the well understood "controler" concept, which has had an accepted definition for at least 26 years, i.e. in the Data Protection Directive and then the GDPR.

The issue is that FPS should only be used for sites where there is an identifiable entity (or set of entities that are "jointly and severably" responsible) and so can be taken to court if necessary,.

There is no shortage of law enforcement and civll society organisations gearing up to do that.

Perhaps we should ask for input from some of them, e.g. the IWGDPT (an international regulator "umbrella", of which the FTC is a member), the EDPB, or NOYB

[dmarti]

@michael-oneill The FPS members, Independent Enforcement Entity (IEE), and browser user could all be in different jurisdictions. The ability of one party to take legal action against another party would limit the geography of where an FPS would be usable.

For example, you might be planning to go on vacation to another country, and check a news site in that country to learn about upcoming events and a travel site for hotel and airport shuttle recommendations. If those two sites claim to be in an FPS, but for some reason are not eligible, and the FPS is validated by an IEE in a third country, who would take who to court, and where?

[michael-oneill]

In most of Europe the controller would be the entity claiming responsibility for every domain in the FPS.
If the controller was an entity located in a country covered by the GDPR then the competent DPA would sue, and there are established procedures for determining that.
I expect when the US has a similar Federal regulator similar arrangements will be in place, there are already co-opererative bodies between the FTC ond international regulators, including most in Europe.
Also under the GDPR the residance or citizenship of the person (data subject) makes no difference, its the location of the data controller that matters.

[dmarti]

@michael-oneill Thank you. Does that mean browsers with a non-European locale would have to ignore FPS until appropriate processes are in place?

The more general problem is that if there is an ownership requirement, the IEE would need to be able to both (1) bring a complaint to a DPS with jurisdiction, and (2) verify ownership records in any jurisdiction that a site trying to form an FPS is located in. Researching corporate ownership is a complex exercise even in your own country. An IEE in California would take a while to understand the true owners of some Nevada LLCs, even if the UA Policy required FPS members to disclose relevant documents.

[michael-oneill]

My point is that there are already mutilateral agreements covering legal checks on companies' activites, including declarations made about privacy and other matters, a huge body of law in place to cover it, with a multitude of lawyers with expertise in it.
In the US you have the FTC Act making "unfair or deceptive acts or practices" a target for enforcement. and in EU ( & UK) law there are similar controls on what companies say and do.
In any jurisdiction, if a company makes declarations that are proved to be dishonest, then sanctions could be severe.

[johannhof]

This is outdated relative to the current proposal so I'll close the PR for now. Feel free to re-open if you still think that it's applicable at this point.