[VK Company Feedback] Privacy policy on FPS domains

[NekR]

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.

I'm having hard time imagining how this could be automated without creating special html markup or enforcing special usage of existing markup, given that websites could be on different languages, with different links, etc. Also it isn't clear who exactly is going to parse all the websites, browsers or third-party entities. But in any case, it sounds like such a thing would require its own specification.

It might be better if common privacy policy would be provided in .well-known endpoints and browsers would display it consistently in their UI for FPS websites.

[krgovind]

Thanks for the feedback! As we think about how to operationalize the policy, we’ll take this into consideration. For now, I'm tagging this issue with the ua_policy label and leaving it open.

[dmarti]

(Updated to simplify)

The privacy policy that is shared with users (which sites typically do by adding a regular link to at least the home page, possibly other pages) needs to be the same as the privacy policy that is checked by the IEE. If the IEE looked for a privacy policy under .well-known it would still need to check the homepage for a link with the text "privacy policy" or "privacy" and then check that the content of the target page matched what it got from .well-known.

Sites might have technical differences (template packages, JS bundling, and so on) that might make privacy policy pages not an exact match even if the privacy policy text is the same. In that case the site should be able to indicate the privacy policy text to be checked by adding an HTML id to an existing element (such as a div) or wrapping the privacy policy text in `

From an ease of implementation point of view: some sites are already required to disclose privacy policy URLs to government organizations, customers, or industry self-regulatory groups, so it would be better to not make sites move their privacy policy.

The IEE's privacy policy checker could then:

1. Start at the site homepage
2. Fetch the current page
3. If the page has an HTML element with an id of first-party-set-privacy, and the text content of that element is more than (say) 80% of the text on the page, then the content of that element is the privacy policy. DONE
4. If the page has an a with an id of first-party-set-privacy, then set the current page to the link target and go to step 2. 5. If the page has a link with the text "privacy policy" (case insensitive match, treat any whitespace character as single space) then set the current page to the link target and go to step 2.
5. Use the entire content of the page as the privacy policy.

(That way, if two FPS member sites already have identical privacy policies linked to from their homepages, they wouldn't have to change anything, otherwise the extra work to indicate the policy to be checked would be minimal)

[RussStringham]

5. If the page has a link with the text "privacy policy"...

What if the page isn't in English? How do we handle the case where the privacy policy has been translated into numerous languages besides the one reviewed by the IEE? How do we ensure that all translations commit to the same thing? I assume we would want the IEE to review all versions and make sure that all versions are unchanged?

Also, some company's privacy policies may change frequently with minor corrections or adjustments, but that shouldn't require a new certificate from the IEE unless the changed text is related to privacy guarantees that are relevant to FPS. Perhaps the IEE could identify key paragraphs and as long as those paragraphs remain unchanged, a review is not required until renewal time as long as all FPS sites use the same, updated policy?

As another option, we could have the IEE hash the policy(s) it has checked. On a first visit to an FPS, the browser could locate the privacy policy, hash it and verify the hash with the IEE. If it differs, it would send a copy of the policy to the IEE (in case the site is presenting a different version to the IEE than it is to regular users). The IEE would then add the hash of that policy to its list of hashes for the site so that other browsers would not need to also forward a copy. The IEE could asynchronously perform an automated comparison of the new policy to the original policy and flag a review if too much or critical sections have changed.

[dmarti]

@RussStringham Good point. If the privacy policy is available in multiple languages

• All FPS member sites should make the same languages available
• Corresponding text for each language should be identical

One way to handle this would be to put all languages on the same page. Or the ids could be "first-party-set-privacy-" followed by the language tag. (Example: first-party-set-privacy-en-US)

The question about what privacy policy changes are and aren't relevant to FPS would be a matter for the IEE to make a judgment call on, and there is already a lot of responsibility on the IEE. If the FPS members are truly under common controllership, it should be feasible for the set controller to bring all privacy policy pages up to date in a short time.

Having browsers report the hash of the privacy policy to the IEE could be useful. (The IEE would probably crawl from confidential, residential IP addresses to avoid "cloaking" by invalid sets)