Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FPS members must allow technical verification #65

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions ua_policy_proposal.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,7 @@ We propose that First-Party Sets will utilize these three principles as the corn
+ Domains must have a common owner, and common controller.
+ Domains must share a common group identity that is easily discoverable by users.
+ Domains must share a common privacy policy that is surfaced to the user via UI treatment (e.g. on the website footer).
+ Domains must facilitate reasonable verification measures by user agents and independent enforcement entities.

Alternatives Considered, and Discarded:

Expand All @@ -35,7 +36,8 @@ We recommend that browsers supporting First-Party Sets work together to:
+ Maintain accuracy in self declaration of common ownership and controllership of the domains listed in a First-Party Set formation request.
+ This means that changes in ownership/controllership must be followed up with a request for changes in the site's First-Party Set within _XX [to be determined]_ days.
+ Make domain affiliations easily discoverable to the user. As a best practice, site authors should strive to make domain affiliations easily observable to the user, such as through common branding.
+ Use First-Party Sets as a mechanism to enable user journeys, and improved user experience across related domains.
+ Use First-Party Sets as a mechanism to enable user journeys, and improved user experience across related domains.
+ Use site configuration and policies that allow for reasonable verification and enforcement. For example, terms of service must allow independent enforcement entities to make test or spamtrap accounts if needed to verify a common privacy policy.
+ Where relevant, site authors may choose to form multiple, disjoint First-Party Sets. In other words, it is not required that all domains owned and controlled by an organization must be part of a single First-Party Set. We recommend that site authors strive to create sets consistent with user understanding and expectations.

# Responsibilities of Independent Enforcement Entity
Expand Down Expand Up @@ -64,7 +66,7 @@ For each element of the First Party Set policy, we propose an enforcement method
<tr>
<td>Common Privacy Policy </td>
<td>Technical checks<sup>3</sup> </td>
<td>Performs technical check to ensure Privacy Policy is the same across all sites in the same set </td>
<td>Performs technical check to ensure Privacy Policy is the same across all sites in the same set<sup>4</sup></td>
</tr>
</tbody>
</table>
Expand All @@ -80,6 +82,8 @@ For each element of the First Party Set policy, we propose an enforcement method

<sup>3</sup> Site authors must ensure that a hyperlink to the common group privacy policy is placed on the default page of each domain listed on their proposed set; such that an automated technical check can be used to verify its presence.

<sup>4</sup>When an independent enforcement entity discovers that one member of a First-Party Set is using user data in a manner inconsistent with the common Privacy Policy, it may consider the set as invalid, without waiting for further verification steps to discover whether or not other members of the set are also violating their own policy in the same way.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would building in a notice period before marking a set invalid be appropriate, considering that losing FPS membership may have site compatibility implications?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like a notice period would increase the resources required for the IEE. If a set can violate its own policy, then step back with little or penalty if it gets caught, then many marginal sets will try various violations to see what they can get past the IEE, and make the IEE have to check for more kinds of violations, more often.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dmarti, do you have thoughts on how the independent enforcement entity can discover if a member of the FPS is using user data that is inconsistent with the common Privacy Policy. I don't believe it is reasonable for IEEE to audit whether data usage aligns with privacy policy or not.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@HarneetSidhana The section on Responsibilities of the Independent Enforcement Entity includes Conducts manual reviews/investigations of First Party Sets that have been flagged by civil society/research community.

Either the terms of service for each site in the set would need to allow the IEE sufficient access to carry out these reviews/investigations, or the controller for the set would need to separately grant the IEE permission to access the site as needed for a review/investigation.


Additional roles of enforcement entity:

+ Verifies that the requester of the set formation has control over the domains. This may be done by requiring that manifest files in a prescribed format be hosted at `.well-known` locations on each domain in the set.
Expand Down