FPS members must allow technical verification #65
Conversation
dmarti
force-pushed
the
allow-verification
branch
from
7229eda
to
1dd0faa
Compare
|
The IPR check fails, @dmarti, because you're not a member of the Privacy CG. If you join the CG we can have the IPR bot run again. |
|
Some kinds of domain data that could be verified by an IEE: #43 (comment) (for example, an IEE might require that FPS members acknowledge mail sent to a whois admin contact.) |
Make it clear that a site cannot claim first-party set membership and then use ToS or configuration to disallow automated checks by a user agent or independent enforcement entity. An independent enforcement entity may be able to detect that an FPS member domain is handling user data in a manner inconsistent with the shared privacy policy. An FPS in which this occurs may be presumed invalid without waiting to check if other members of the FPS violate their posted policy in the same way. (Many downstream violations of privacy policy, such as email spam and telemarketing, are randomized, or data sets are partitioned. An independent enforcement entity may detect a privacy policy violation by one member of a set but not others that are doing the same thing, and would need to be able to disallow the FPS.) Refs: WICG#43
dmarti
force-pushed
the
allow-verification
branch
from
63dddeb
to
8fea8df
Compare
| @@ -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. | |||
There was a problem hiding this comment.
Would building in a notice period before marking a set invalid be appropriate, considering that losing FPS membership may have site compatibility implications?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
@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.
A site that claims first-party set membership must allow automated
validation so that user agents and independent enforcement entities
can check that it is in compliance with UA Policy.
Independent enforcement entities that detect that one member of an
FPS is handling user data in a manner inconsistent with the FPS shared
privacy policy should be able to presume that the FPS is invalid without
waiting to find out if other members of the FPS are violating the policy
in the same way.
Refs: #43