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

Weak requirements language #35

Open
martinthomson opened this issue Oct 12, 2022 · 3 comments
Open

Weak requirements language #35

martinthomson opened this issue Oct 12, 2022 · 3 comments

Comments

@martinthomson
Copy link
Member

websites MAY interpret an expressed Global Privacy Control preference as they find most appropriate

This one might be unavoidable, but this is effectively a meaningless statement. Consider avoiding normative language and instead concentrate on the intended semantics of carrying the signal. The real teeth in this mechanism lies in the legal enforcement part, so explain that more directly rather than use a "In the absence of regulatory, legal, or other requirements" preface to this statement.

User agents SHOULD strive to represent what the user agent best believes to be the person's preference for the Global Privacy Control value.

This could easily be a "MUST".

@j-br0
Copy link
Contributor

j-br0 commented Dec 8, 2022

websites MAY interpret an expressed Global Privacy Control preference as they find most appropriate

This one might be unavoidable, but this is effectively a meaningless statement. Consider avoiding normative language and instead concentrate on the intended semantics of carrying the signal. The real teeth in this mechanism lies in the legal enforcement part, so explain that more directly rather than use a "In the absence of regulatory, legal, or other requirements" preface to this statement.

This could be addressed by including a cross-reference to § 5 (Legal Effects) after the prefatory phrase.

User agents SHOULD strive to represent what the user agent best believes to be the person's preference for the Global Privacy Control value.

This could easily be a "MUST".

Different jurisdictions are going to have different UX requirements. One country may require an express act to turn on the signal, another may say that the choice of a privacy-specific browser or browsing mode is sufficient to imply intent. Still others may be entirely silent, or they may say that the signal should always be sent by default to accord with the reasonable expectations of most users. I think SHOULD is appropriate to express the general subjective principle of reflecting user intent while affording the flexibility necessary to accommodate varying legal regimes.

@darobin
Copy link
Member

darobin commented Dec 15, 2022

Just for context: the MAY there comes from the fact that this spec shouldn't be defining legal requirements. It's not just in the absence of legal requirements: we are explicitly stating that you may do whatever you want, including breaking the law. It's a pretty safe bet that that comes with consequences, but those consequences will hold not because of anything the spec says.

I personally don't have a preference either way on this one; I'm just flagging that this is there because people keep saying "but you can't set law." We don't need to.

The SHOULD is because browser folks tend to be quite fussy about UI requirements. Also, MUST strive to … best believes is really a SHOULD in disguise. (Candidate addition to RFC6919 I guess.) I agree with @j-br0 that SHOULD reflects the fuzziness and leeway that really is there. Again, I'm not married to this specific formulation, but I would be very reluctant to add a MUST that I don't know how to write a test for.

@rinchen
Copy link
Member

rinchen commented Nov 7, 2024

My view is that the GPC is web spec. We're defining what the control signal should do at a minimum. It's independent of any laws but we should use those as an informative source for us setting what we believe should be the minimums.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants