From f769cdf291935404702eddd7d49901656628c8ae Mon Sep 17 00:00:00 2001 From: krgovind <54452408+krgovind@users.noreply.github.com> Date: Tue, 10 Aug 2021 10:51:07 -0400 Subject: [PATCH] Create ua_policy_proposal.md Expanded UA Policy Proposal for community discussion, and feedback. --- ua_policy_proposal.md | 87 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 ua_policy_proposal.md diff --git a/ua_policy_proposal.md b/ua_policy_proposal.md new file mode 100644 index 0000000..71bc21d --- /dev/null +++ b/ua_policy_proposal.md @@ -0,0 +1,87 @@ +# UA Policy Proposal + +First-Party Sets aims to define the notion of "first-party" as a technical construct that can be used by browsers in development of tracking protections in browsers. [The W3C Do Not Track (DNT) specification defines a ‘party'](https://www.w3.org/TR/tracking-compliance/#party) as having: + +1. Common owners and common controllers +2. "A group identity that is easily discoverable by a user" + +The DNT definition of ‘party' converge with the findings and recommendations of the 2012 Federal Trade Commission report titled "[Protecting Consumer Privacy in an Era of Rapid Change](https://www.ftc.gov/sites/default/files/documents/reports/federal-trade-commission-report-protecting-consumer-privacy-era-rapid-change-recommendations/120326privacyreport.pdf)". This report also recommends, for the sake of user transparency: + +3. "Privacy notices should be clearer, shorter, and more standardized to enable better comprehension and comparison of privacy practices." + +We propose that First-Party Sets will utilize these three principles as the cornerstones of its policy, to ensure sets are transparent and set defined limits of data access: + ++ 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). + +Alternatives Considered, and Discarded: + ++ TLS Certificate approach: we considered a standard by which all domains in a First Party must be present on the same TLS certificate or produce EV certification to confirm organizational affiliation. We assessed this standard didn't make sense to impose, given the security implications associated with EV/SAN requirements. ++ Common user journeys: we considered a First Party Set policy that included a standard stating that users must be able to easily journey between different entities and share sites within a set must share common experiences such that users would be able to determine that each site is related. We discarded this approach given the subjectivity around what a common user journey is, and because certain sites that are unrelated may share some common user journeys (e.g. a sign-in with Google flow or check-out path). + +# Responsibilities of the User Agent + +We recommend that browsers supporting First-Party Sets work together to: + ++ Come to rough consensus on a common set of principles for the UA Policy. ++ Periodically review, and refine policy requirements. ++ Implement a UI surface to educate users when the website they are visiting is part of a First-Party Set with other registrable domains; and link to the provided common privacy policy. ++ Ensure that the browser periodically fetches updates to sets. We recommend that the time period between updates fetched into the browser not exceed 30 days. ++ [Optional] Provide guidance/mechanisms for users and civil society to report potentially invalid or policy-violating sets, for investigation and manual verification by an independent enforcement entity. + +# Responsibilities of the Site Author + ++ 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. ++ 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 + +For each element of the First Party Set policy, we propose an enforcement method. Below we suggest how each element is enforced and what role, if any, an independent enforcement entity might play as part of the enforcement effort. + +
Policy | +Enforcement Method | +Role of independent enforcement entity | +
---|---|---|
Common owner and controller | +Annual self-declaration1 | +Maintains publicly-viewable declaration system, tracks changes, performs random "spot checks" for conformance based on publicly available information | +
A group identity that is easily discoverable by a users | +UI treatment (and co-branding in some cases)2 | +None (solely the browser's and site author's responsibility) | +
Common Privacy Policy | +Technical checks3 | +Performs technical check to ensure Privacy Policy is the same across all sites in the same set | +