Create a fallback if no ADPC is available

[jucktnich]

Problem and Motivation

For an website project I chose to use ADPC, but since its not supported by most browsers and few people use the Add-on you still need a classic banner. This is extra work needed. So I thought it was cool if there was a JS module which took care of it all and the developer only needed to import the module and make requests like with native ADPC, so I developed the banner for my site and made a module from it.

Benefits

Many devs (hopefully) would opt for this module and therefor if ADPC becomes more widespread, many sites will support it.

My implementation: jucktnich/adpc-compatibility-mode

[coolharsh55]

Hi, you raise a valid point regarding 'fallback' in case ADPC is not implemented. And you're correct that in such scenarios a 'classic' banner would be used. That being said, IMHO the case where 'ADPC is unavailable' is the same as today's existing situation. So while it seems like a 'solution', it isn't one since it comes with all the issues and tricks that ADPC was created to resolve.

I suggest generalising this issue by instead asking/stating:

1. (how to detect) If server/provider/controller doesn't support ADPC, then what should the user(-agent) do? --> I think there is no recourse here except for hoping there is some industry/community/legal nudge to support ADPC. This is the more important use-case to tackle IMO.

2. (how to detect) If user(-agent) does not support ADPC, then what should the server/provider/controller do? --> Here, the server can show a 'classic' banner, but IMO in order to avoid pitfalls related to such banner, we could discuss how to make such banners 'ADPC compatible'. E.g. by embedding ADPC's info within the banner. This is nice for cases where browsers refuse to support ADPC, and extensions reading all HTTP requests (to look for ADPC) is not desirable because of privacy.

[gb-noyb]

Fantastic, thank you for sharing this work @jucktnich! I will try have a closer look; we were thinking of creating something like this. Perhaps it could even work as a polyfill, i.e. modifying the DOM such that the website can use the ADPC Javascript API as if the browser supported it. This is roughly what our browser extension does too. The main differences would be how it is displayed (of course the page cannot access to browser UI, but that seems acceptable), and how to store the responses between visits; I see you set a cookie (line 266) named adpc-compatibility-mode; which seems a logical solution.

[flavi1]

Ok. So, in a pollyfill point of view, to detect if a banner should be shown (if ADPC is nativelly supported), we can read the adpc-compatibility-mode cookie.

First problem

Actually "adpc-compatibility-mode" is not mentionned in the spec. We want a pollyfill to detect all possible implementations, not just this web extension...

Second problem

What we can do when a user disallow javascript execution on the page? We can provide a simple no-js GET form banner to set consents. But in this case, your extension will continue to work, because JS execution is not forbidden for web extensions. Consents configuration will be asked twice.

Possible solution

We may need a global attribute, or class "no-adpc" or something like that to put on the parent DOM element of the consent form. An APDC implementation should (or must?) hide or delete the element. We can add this class/global attribute on the script tag of the polyfill, then the polyfill will never be loaded when APDC is already supported. (From a web extension, it's easy to implement it with an Observer)

To be discussed ?

I know that exposing a such information ("is supported ADPC or not ?") is a possible privacy issue, and can result in a discrimination of ADPC users. But I think it's a justified feature. We can't stop agressive marketing strategies. This is not our role. Lawyers may or may not do what they consider to have to do. What we can do is to provide a way to respect final users without destroy their experience with unwanted banners.