-
Notifications
You must be signed in to change notification settings - Fork 6
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
Contradictory signals #20
Comments
My preferred suggestion on signal conflict is always: it should be in the favour of the individual. So where conflicts occur, the resulting outcome should prefer the prohibition of personal data sharing/use/collection/etc. A secondary event could then be the controller/website clarifying the signal conflict by asking explicitly which one to choose. This works for conflicts in the same signal as well as across signals. In the example you gave, the signal could be validated to say content is "ill-formed" since it contains the same purpose. It is difficult to express this in specification without semantics of content. Perhaps a more intuitive example would be:
Here, if I withraw consent to receive any email, but consent to receiving emails for new products, how should this be interpreted? To generalise, where there is a relationship between a purpose that is being consented to and another purpose which is being withdrawn or objected to, how should the resulting set of permissions or permissive actions be interpreted? I think the legal interpretation would be: Choose non-intersecting set of permissive purposes where possible. Example1: Purpose withdrawn is a subset of purpose agreed - then the new set of purposes permitted = agreed - withdrawn i.e. do anything related to agreed purpose except if it is withdrawn to. Example2: Purpose withdrawn is a superset of purpose agreed - then the new set of purposes permitted = agreed - withdrawn i.e. an empty set which means nothing is permitted. (edited: to add) a desirable outcome would be to receive emails about new products but not other emails. For this, one could say, choose the smaller set i.e. where withdrawal is broad and consent is narrow then the consent shoud be used for permission, and where withdrawal is narrow and consent is broad then the withdrawal should be used to prohibit. |
I agree with your stance :) |
Note there is a paragraph on this in section 10. Compatibility considerations:
|
In principle, yes this is what the law says. However, the notion of ambiguity in ADPC is determined by ADPC itself via its behaviours and correctness/validity conditions. What it currently says is: there should be no relation between purposes expressed in consent and withdraw variables, otherwise the entire transaction is considered invalid (and no clues as to how to proceed). The spec says the following (quote, emphasis mine) for Withdrawing Consent
Taken literally,
If these two are considered ambiguous, then it means ADPC cannot or should not be used for such communication of choices - which IMHO leaves a gap in its intent. |
Section 6.5 of the specifications introduces the combination of signals.
However, the protocol stays silent on its interpretation of contradictory signals.
For instance, how should a website interpret the following example, that may result from a malicious or faulty user agent:
ADPC: withdraw=q1analytics, consent=q1analytics
The current version of the document assumes that the interpretation of identifiers is order-oblivious and based on the superiority of specific signals over generic signals.
A simple way to tackle this issue is to combine an ordered interpretation with the current superiority of specific signals over generic signals; another way is to assume the superiority of the
withdraw
keyword over theconsent
keyword.The text was updated successfully, but these errors were encountered: