Contradictory signals

[Victor-Morel]

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 the consent keyword.

[coolharsh55]

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:

ADPC: withdraw:any-email-sending, consent=send-email-new-product

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.

[Victor-Morel]

I agree with your stance :) It seems that once again, semantics can solve problems.

[gb-noyb]

However, the protocol stays silent on its interpretation of contradictory signals.

Note there is a paragraph on this in section 10. Compatibility considerations:

If the ADPC signal is sent in the same transaction as another signal with related meaning (e.g. when clicking an “agree” button on a website, or sending another signal such as a DNT or Sec-GPC HTTP header), any non-contradicting communication can be interpreted combinedly without problem. Any expressions of consent that are in conflict with each other will not be “unambiguous” as required by Article 4(7) GDPR, and should thus be interpreted as a lack of valid consent.

[coolharsh55]

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

The user can also withdraw all consent for purposes not explicitly consented to in the current exchange.

Taken literally, withdraw=* will revoke all prior consent except that which is in current transaction/communication. Expanding on this behaviour, if there is a consent=something clause alongside a withdraw=something clause, then the interpretation as per definitions is to withdraw prior given consent and provide a new consent. Which leads to following two examples:

1. withdraw=* consent=something :: this will/should withdraw all prior consent and give new consent for something
2. withdraw=all-marketing consent=some-marketing :: this will/should withdraw a prior broader consent and give a new narrower consent

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.