Cryptographic proof of a common privacy policy at a well known end point

[jwrosewell]

Introduced a requirement for domains in the First-Party Set to provide cryptographic proof at a well-known end point that they adhere to the common privacy policy.

Therefore removed reference to brand throughout the document as the verifiable common privacy policy provides all the proof needed. Brand will be very hard for an enforcement entity to rule on as it is subjective.

Removed the need for the website operator to display information about the First Party Set as this will now be possible for the User Agent to perform via the cryptographic proof provided at the well-known end point by each domain in the set. This will also provide a consistent user interface across all First-Party Sets and enable the user to find the information in a clear and commonly understood location within the browser. Placing the burden on the website operator will lead to confusion and inconsistency.

Removed optional section on guidance to others from the User Agent as cryptographic proof of common privacy policy no longer requires such guidance.

Removed HTML in the markdown file and improved the markup format of the document to make it easier to edit and maintain in the future.

[krgovind]

Hi @jwrosewell - Thank you for writing this up. It appears that your PR includes formatting changes, as well as substantive changes; which makes it really hard to review this PR. Could you please separate out the formatting changes into a separate PR; so it is easier to see your proposed changes to the requirements?

[jwrosewell]

@krgovind - The PR now clearly shows the 4 changes to the document around the introduction of cryptographic proof and the removal of brand.

Doritos.com and doritos.co.uk operate entirely different privacy policies. Neither website is readily associated with PepsiCo. Ownership, privacy policy and brand are unrelated concepts.

[krgovind]

@jwrosewell - I think the collapsing of the table under "Responsibilities of Independent Enforcement Entity" may also be a formatting change. The new format removes the previous "active voice" which lists out the responsibilities expected of the IEE, and changes the tone of the document compared to the previous two sections. Could you revert to the previous table format, since this formatting change is unrelated to the substantive aspects of this PR?

Regarding the substantive changes, I think this PR introduces a few new concepts that should first be discussed on independent issues:

• It introduces the notion of well-known end point operated by the domain, without any reference to how the cryptographic proof is obtained, or what the well-known location is. It is not clear to me which entity signs this cryptographic assertion - is it the IEE? If so, what would they be verifying?
• It removes the recommendation that browsers "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". Could you explain why this should be removed?
• It removes references to recommended common branding such as "As a best practice, site authors should strive to make domain affiliations easily observable to the user, such as through common branding.". This requirement is key to enabling user understanding, so we should discuss on a separate issue in further detail. The arguments that you make against this are:
  • "Brand will be very hard for an enforcement entity to rule on as it is subjective": As per the current proposal, the independent enforcement entity (IEE) isn't required to enforce this. The table that you removed in this PR explicitly stated against the common group identity requirement that the IEE's responsibility is "None (solely the browser's and site author's responsibility)".
  • "Placing the burden on the website operator will lead to confusion and inconsistency": Footnote#2 under the current IEE section goes into a bit more detail, but it may be possible that a coalition of browsers and the IEE can spell this out in further detail to remove confusion.

Could you please open separate issues to discuss the above three changes?

[krgovind]

Closing this PR. Since there are many substantive changes in this PR, please start with discussions in issues as I suggested in my last comment.