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

New: Avoid revealing that consent was denied #475

Closed
martinthomson opened this issue Mar 6, 2024 · 1 comment · Fixed by #476
Closed

New: Avoid revealing that consent was denied #475

martinthomson opened this issue Mar 6, 2024 · 1 comment · Fixed by #476
Labels
Status: PR in review A PR has been created and is being iterated on

Comments

@martinthomson
Copy link
Contributor

Isn't this a larger principle? Namely where designs that depend on something from a user, where the user might reasonably deny that something, those designs should avoid leaking information about denial such that sites might retaliate in some way. Designs can help with that by making denial indistinguishable from other reasons that the something might not be available (like in this case, where the something might not even exist). If that is not possible, then it might be appropriate to manufacture some base rate of failure.

Originally posted by @martinthomson in #470 (comment)

martinthomson added a commit to martinthomson/design-principles that referenced this issue Mar 6, 2024
This is not a full generalization of the concepts that discussed in w3ctag#470 and w3ctag#475, but I think that it suffices.

Closes w3ctag#475.
@dbaron
Copy link
Member

dbaron commented Mar 7, 2024

It might make sense to connect this with the section on feature detection which currently suggests that "not supported in browser" and "not available in insecure contexts" should always be detectable in the same way, but that "not supported because of device unavailability" should be detected differently. That doesn't currently mention denial of consent, but maybe it should in some way. (However, I'm not sure how -- it's not clear to me that there's an obvious answer.)

@torgo torgo added this to the 2024-04-01-week milestone Mar 31, 2024
@torgo torgo modified the milestones: 2024-04-01-week, 2024-06-03-week Jun 2, 2024
@rhiaro rhiaro added the Status: PR in review A PR has been created and is being iterated on label Jun 3, 2024
plinss pushed a commit that referenced this issue Jun 3, 2024
* Denying consent is better if undetectable as such

This is not a full generalization of the concepts that discussed in #470 and #475, but I think that it suffices.

Closes #475.

* Link feature detection to consent

This is based on @dbaron's excellent feedback.  However, I took an extra
step with the last sentence here, which I'm not committed to.  There's
an argument to be had that anything like this probably shouldn't be part
of the web platform.

Now, with the controversy established, go!

* Typu

* can-be

Co-authored-by: Amy Guy <amy@rhiaro.co.uk>

---------

Co-authored-by: Amy Guy <amy@rhiaro.co.uk>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: PR in review A PR has been created and is being iterated on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants