[Proposal] Show GDPR popup

Proposal for a similar API as the location API to show a popup to be compliant with the GDPR legislation in europe.

Problem Currently every website implements their own popup to be GDPR compliant. This results in a poor user experience where the user has to dismiss multiple popups to be able to read the actual content of the webpage.

Examples: https://www.google.com/search?q=gdpr+popup&tbm=isch

Example library that generates these popups for you. (useful to see what options we could include in this API) https://cookie-script.com/

Solution To improve this we could create an API in the browser that allows website developers to request a popup to be shown to the user. Similar to the location API popup.

In pseudo code this API would look something like this:

navigator.privacy.getCookieConcent({cookie: true, tracking: true}, allowHandler, denyHandler);

This would then show a dialog to the user:

54070243-d8e83880-425d-11e9-954b-61399c05b700.png940×637

This would might make it possible to circumvent the GDPR popups for users that check the “use these settings for all sites” (not sure if this is legal though * lawyer assistance needed *)

This would also allow the browser to give more info about the website privacy settings:

Discussion points:

• Is this repo the correct location to propose this API?
• Do you think this is a viable API?
• Would browsers implement this even though it is only for the European market?
• Is the “use for all sites” setting enough consent from the user to not show this dialog on other websites?
• Should we provide options for privacy tracking, so the user can consent to some tracking. eg: tracking for analytics, but not for marketing.
• Should this work with callbacks or promises or both?
• Should we include a “read more” link in the API, so users can read more about why privacy tracking consent is required for that particular website?

Frankly, no it isn’t.

1. Users are already overloaded with these permission notifications. We should be investigating ways (as some are) of trimming them back. Not adding more to get in the way.
2. This puts browsers in the direct path of legislation in any given country’s demands. Features in browsers should be based only on user needs. Only when a law absolutely targets browsers should they do anything regarding legislation.

The web is a global market. Just because a few make poor decisions based on a fundamental mis-understanding of what is going on and possible doesn’t mean browsers need to bear the burden. Especially when it fundamentally has nothing to do with them or their tech, but how sites decide to take advantage of it. This is clearly a site problem, not a browser problem.

Going forward, promises only.

Include anything you’d like. Most users never read anything so it’ll be the same effectiveness whether we have words or it’s empty space.

I am empathetic both to developers and users having to deal with this madness, and to what GDPR is trying to achieve. But I don’t think browsers should have any burden to react here. It’s bad legislation which requires an implementation like this to be seen by users. Or just lazy developers/businesses who don’t care about their customer experience. Or big business that can’t move rapidly enough to address the problems so they’re doing their best with the time they have.

Users are overloaded with cookie notices. This would make it much easier to globally accept or reject “non-essential” cookies, removing the annoyance.

ONLY if that is a legally accepted GDPR practice (which I somehow doubt as strict as the EU is being about things.) But that’s up to lawyers. The moment we need to get lawyers directly involved in specifying new functionality, we’ve crossed a clear line. Let’s leave it be and move on. Encouraging the EU To fix the broken areas of the law (including their cookie law mania) would be the best path forward. Get protections that are enforceable without annoying users. Win-Win.

This more or less seems to propose the same thing as: [Proposal] Use permissions API to request third-party cookie permissions.

There are a few things here I disagree with.

Users are already overloaded with these permission notifications.

This argument is completely moot because users are already overloaded with cookie consent popups. Moreover they often apply ‘dark design patterns’ to coerce the user to accept all of them

This puts browsers in the direct path of legislation in any given country’s demands. Features in browsers should be based only on user needs. Only when a law absolutely targets browsers should they do anything regarding legislation.

Adding a new API that developers can leverage to enhance the user’s experience is not only in their best interest (see my dark design pattern remark earlier) but is also optional.

The web is a global market. Just because a few make poor decisions based on a fundamental mis-understanding of what is going on and possible doesn’t mean browsers need to bear the burden.

This sort of thinking is precisely how to got to this mess in the first place. Legislation is a slow process and the GDPR framework is here to stay whether you agree it to be a good thing or not.

This is clearly a site problem, not a browser problem.

In reality every website uses cookies in some way for various reasons. Saying that “websites should not be doing it” is utopian.

Should this work with callbacks or promises or both?

Most web APIs work with either callbacks or event emitters. Individual libraries can be created to wrap the API and provide a promise-based interface if that’s what they prefer.

It’s bad legislation which requires an implementation like this to be seen by users.

Mentioned before, whether you agree with it or not it’s here to stay for a long time.

Or just lazy developers/businesses who don’t care about their customer experience.

If there was a browser API to show a cookie consent form I would most definitely use it and it would serve to benefit the visitor by

1. Not use any dark design patterns and make consent options obvious
2. Allow users to globally accept or reject cookies (and categories thereof)

How do we engineer around legislation well?

EU does their thing. Ok, browsers jump to implementing some API to show that stuff. Then California goes and makes their own thing but the needs are somewhat different. Does the API then get modified, appended to, or a new one set aside just for that? Then what about China if they create their own? And any other state?

Each local of legislation can have slightly varying levels of needs with an API like this. Browsers shouldn’t have the burden on them to provide an API to support them. What then happens if a locale changes their regulation in a way incompatible with the API? It’s just a nest of issues that shouldn’t be taken on.

Disagree all you want, Pandora’s Box is when we start letting legal drive web APIs.

I totally agree with @gillesdemey on all the points in his comment.

I also agree with @Garbee that the very moment we allow local legislation dictate browser standards we open the Pandora’s Box.

But (and here it goes my 2 ctn.) browsers are now implementing Do Not Track protection techniques that are aligned to give users more control and privacy when visiting websites (See Firefox, Brave or Safari). So if instead of engineering complex solutions on top of denying specific cookies by blacklisting domains or whatever implementation details they use, we create a web-standard that allows users to decide and control whenever a website has access to store cookies on their device we are providing more robust solutions that are not motivated by any country specific legislation, but are specifically created to provide consent and control to internet users.

I do believe that creating a non-obtrusive and soft failure cookies consent API will give users more control and will help into create a better web-experience for everyone.

DNT isn’t a new spec - it’s been around for years and browsers implemented it early on. It’s sites that have been slow to adopt it (if at all), and that lack of buy-in has led most major internet privacy advocates involved to consider it a failure.

Just as a reference, the Privacy Community Group of the W3C is looking in this direction. However it is very much early given the complexities of dealing with the legalities.

Link here to the current discussion thread for reference. PLEASE do NOT go just to +1 comment or similar. They are focused on an attempt and it is being worked on. But you can follow for some updates that may come to the thread as things happen.