Getting rid of cookie warnings

robin · 2015-08-05

Thanks to clueless legislators, cookie warnings have fast become near-universal, implemented with varying degrees of aggravation from simple discreet banners to full-on doorslams.

We can’t fix clueless legislators, and we can’t fix the fact that lawyers will advise caution. We can, however, find a technical solution. All that is required is for such warnings to be recognised by the browser. It is in the sites’ interests to add a standard marker that browsers can act upon since everyone knows this annoys users.

Many syntax options are possible (bikeshed at will!), perhaps this would work:

<!DOCTYPE html>
<title>Cookie Warnings Must Die</title>
<p>
  <link rel="cookie-policy">
  This is an annoying warning that we're using cookie that our lawyers scared us
  into adding because some clueless legislators made us do it.
  <button>close</button>
</p>

The basic idea is that the parent of the link[rel=cookie-policy] just gets deleted. This can be tried out in a browser extension.

It would be a very simple standard to bang together if there’s interest.

stuartpb · 2015-08-05

Moreover, I’d like to see this user-awareness paradigm for cookies/sessions made exposed as part of the browser (eg. the way Lynx does it by default, but only blocking the setting of the cookie rather than the entire page render), the way we currently prompt the user if they wish to allow sites to track their physical location. There should be a prompt for “google.com wants to follow you as you browse” (with a callout after they make their “allow” or “deny” decision the first time explaining how to change these confirmation/denials, which is currently not stated, probably because these confirmations aren’t widespread).

(Since this is admittedly a not-so-great UX for stateful browsing, what I’d want to see replace cookies is some kind of default on temporary session tracking header sites could use, which could be expanded beyond session on request, and would be specifically omitted for iframes/cross-origin fetch to gimp cross-site tracking.)

While I agree that this legislation was stupidly implemented, I think the stupid part was putting the burden on page authors and not the user agents, and a standard to allow migrating this warning to UAs would be great.

robin · 2015-08-05

That’s fair enough @stuartpb, but I think it’s a different topic. What I’d like to fix here is a small and simple problem. I agree that UAs could do a much better job with tracking protection (notably regarding fingerprinting) but that’s much more an implementation issue than a standards one.

stuartpb · 2015-08-05

Sure (although you kind of need a standard expected behavior before you can go bowling with the implementation), but my point is, I wouldn’t want UAs to block these warnings unless the UA is presenting it themselves. This legislation was introduced for a reason - there’s a rising distrust of big entities nonconsensually tracking ordinary users by the public, and cookies are at the forefront of that.

Yes, the masses have been putting up with it for years - but I feel it’s an “out of sight, out of mind” problem, not an actual consent problem. If we actually asked users if they wanted to be followed, they’d say “no” (which I think is part of the trend Apple is banking on right now as they allow / add ad blockers in iOS).

robin · 2015-08-05

The idea isn’t that UAs would unilaterally remove these warnings. It’s a feature that would have to be user-activated. I would activate it, the warning is useless.

I don’t disagree that there are much broader tracking issues, but: scope, scope, scope.

LJWatson · 2015-08-05

Good idea. If there is one thing more irritating than a cookie warning, it’s a cookie warning that is inaccessible and can’t be closed.

Robin’s solution should be ok for accessibility and interaction. The proviso being that it would need to be an acutal button (or if push comes to shove, a properly customised pseudo-button).

stuartpb · 2015-08-05

Sure, I think that’s a good start, but we need to go into it with a full, end-game use case in mind. Starting the discussion with “cookie warnings are useless, let’s remove them” is dangerously short-sighted (it’s basically opening with a thesis of “let’s let users opt to go from aware non-consensual tracking to oblivious non-consensual tracking”, which is junk).

As for the actual bikeshedding of how to implement this: is there a precedent for including link elements inside of content? The way I’ve usually seen this done with other types of content identification is with microformats, but I think it’s sensible to keep microformat recognition out of UAs (at the browser level, class names should remain opaque identifiers).

stuartpb · 2015-08-05

Wait, are you talking about letting browsers remove the fait accompli cookie warnings on a per-site basis, after dismissal and/or if the site’s cookies aren’t actually being allowed? I didn’t notice that, since part of this UI that I’ve almost universally seen sites implement is, if the user dismisses the banner, it sets a cookie / localStorage marker to not display the banner on the next navigation (so this only not suppressed, ironically, if said cookie is not accepted by the UA).

I think a standard for identifying the banner for hiding/removal by the UA in the no-cookie case is sensible, but I don’t think trying to spec a standard for a page-defined UI button to dismiss the warning is worth it (since, like I said, most sites I’ve seen this on have figured out the UI to do so for themselves, and any better UI should be derived from a better behavior by the UA itself).

stuartpb · 2015-08-05

I think the most sensible way to do this, seeing as how we already have standard elements for common page components like <header>, <footer>, and <main> (and even those only really having UA behaviors for navigation assistive technologies), would be to introduce a <cookies> element to the HTML Living Standard, which works like all of the aforementioned elements in terms of default style, and has the recommendation that UAs set it to display: none if they aren’t allowing cookies on the page (similar to <noscript> when the UA supports scripting).

ianjmacintosh · 2015-08-06

I like the idea of standardizing how to request consent from visitors for various things, and agree that designers and developers are wasting time figuring out new ways to present the same question. I’d also love to see this approach abstracted to ask consent for other things like, “Are you age 18+ to view this explicit content?”

Instead of inventing a new element, what about working within our existing space?

I know that the data- attribute is turning into a vehicle for adding all kinds of useless crap, but maybe something like this?

<p data-consent-request data-consent-type="cookies">Keep browsing <em>only</em> if <em>you</em> explicitly consent to <em>our site</em> having permission to <em>set</em> and <em>read</em> cookies on <em>your browser</em>.</p>

npdoty · 2015-08-06

I love the sentiment. I tend to agree that using <link> as the machine-readable trigger seems strange compared to a class or data- attribute on an existing tag.

However, I think the motivation perhaps misses something. Site developers are putting in these boxes because their lawyers advised them that showing a box will satisfy or help them satisfy their legal obligation. If UAs implemented that automatic hiding or deletion (quite a jump, but let’s assume for a moment), then does it make sense for the site developer to add the <cookies> tag or the data-consent-type attribute? I imagine the site’s lawyer won’t like that the box no longer shows up for some class of users.

It might be that we could help convince the lawyers if user agents/extension developers made a good UI that helped users explicitly opt-in to this state where these boxes were hidden. We could also ask some European legal experts what they think would be sufficient. Another alternative would be to standardize a communication of consent to be sent by the user agent, so that the site knows that the user already consents to cookies and thus doesn’t need to show the box and has a reason to give to the lawyers about why the box is unnecessary for those users. There was some hope that the DNT header could serve that purpose. If lawyers don’t think it does, we could propose a DNT header extension, or a different header which means “I consent to the use of cookies on this site”.

tabatkins · 2015-08-06

The data-* attributes are not appropriate for anything involving communication with the browser. That entire namespace is reserved for pages to use on their own (or in concert with tools that know exactly what they’re working with).

stuartpb · 2015-08-06

Also, before somebody chimes in saying we could use class names instead, as I understand it, the same reserved-namespace opacity restrictions apply to class names (in other words, as I said above, microformats are a no-go).

rvaneijk · 2015-08-07

npdoty, robin, to me - speaking in personal capacity - suppressing cookie banners sounds like a silly solution to remedy the overarching tracking problem users are faced with today. A consent banner is just one of many consent meachnisms implemented today. My point is that removing the banner adds to the confusion in the ongoing dialogue between the user and the parties. Parties have legal obligations to engage in these dialogues, users - luckily - still have the freedom to ignore/block the dialogue with browser add-ons.

However, the sentiment about expressing consent through browser settings is an interesting one. In fact, in Europe, there is long standing discussion on expressing consent through browser settings. The full recital is as follows:

“Third parties may wish to store information onthe equipment of a user, or gain access to information already stored, for a number of purposes, ranging from the legitimate (such as certaintypes of cookies) to those involving unwarranted intrusion into the private sphere (such as spyware or viruses). It is therefore of paramount importance that users be provided with clear and comprehensive informationwhenengaging inany activity which could result insuch storage or gaining of access. The methods of providing information and offering the right to refuse should be as user-friendly as possible. Exceptions to the obligationto provide information and offer the right to refuse should be limited to those situations where the technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user. Where it is technically possible and effective, inaccordance with the relevant provisions of Directive 95/46/EC, the user’s consent to processing may be expressed by using the appropriate settings of a browser or other application. The enforcement of these requirements should be made more effective by way of enhanced powers granted to the relevant national authorities.”

Therefore, my personal opinion is that the browser may become an extention of the users consent, if the browser feature is enabled knowingly and willingly by the user after understanding what the feature does in a specific web context. The benefit of automating the negotiation of consent by the browser on behalf of the user is that that it can be much more granular, specific and frequent in comparison with manual consent mechanisms. To me, the suggested idea to delete the parent of the link[rel=cookie-policy] contradicts this idea.

However, the feature to disable the cookie consent banners could be a use case for a DNT extensions, which ndoty rightfully points out. Since the DNT extensions are at risk, the use case may be an interesting one. You may consider raising the use case as a comment to the ‘last call’ public review of the DNT standard. (http://lists.w3.org/Archives/Public/public-tracking/2015Jul/0000.html).

npdoty · 2015-08-07

This is a little orthogonal to the question of cookie warnings (on a mailing list, I would reply to the quoted message and change the subject line, but I’m not sure what the equivalent is in this forum), but for my own edification: what is the objection to recognizing microformats in the UA? I understood the whole point of microformats as being a semi-standardized set of class names so that user agents can recognize them (and provide a handy calendar link or address book connector or what have you). Is there some reason a browser or browser extension couldn’t be configured to recognize class="cookie-notification" attributes?

stuartpb · 2015-08-07

It’s the “Reply as linked Topic” button in the margin to the right of each post. (You may have to hover your cursor over that margin first since apparently the Discourse devs never got the memo about display-on-hover being a bad design for this exact reason of discoverability.)

There’s no guarantee that the content author was following that microformat when the authored the page. I could just as plausibly be making my own version of Cookie Clicker and using the class “cookie-notification” to style the notification that pops up when an oven has baked “new cookies!” for the player. While tags have semantics that are agreed upon by UA contexts outside my page authoring, the semantics of attributes like class and id only apply within the page - as an author, I can make up my own class and id names without needing to care about how the rest of the world may use them. (Of course, this runs into trouble when I want to bring things into my page’s namespace that were created by the rest of the world, but that’s why we have conventions like BEM and emerging standards like Web Components and Walls.)

In the use cases where microformats are recognized, it’s in situations where there’s some guarantee that the page being fed in is in a space where the microformat’s classes would apply- the page sort of loosely opts in to it (and, in the event that there’s an overlap/miscoding, the failure case is just a user-correctable munged output, not incorrectly disabled functionality).

incloud · 2015-08-09

The EU’s e-privacy directive does not require a “cookie banner”, only that consent is obtained before personal data, such as someone’s web activity, is collected or used. The DPAs have already said that it covers browser fingerprinting etc., as well as the use of cookies.

Pressure from some sections of the computer industry, backed by Governments, pushed for an “implied consent” interpretation of the law, and this is what opened the gates to these annoying and ineffective “cookie banners”.

The best way is to deal with them is to make them redundant by using technology that offers real user control over tracking, and basing that on explicit consent.

Although there are other ways to do this, the DNT signal is important because it is universal and transparent, its description insists that consent must be explicit, and it has meaning in other jurisdictions such as the US.

The ability to indicate user consent can already be already conveyed by the DNT:0 request header. Although confusingly named a User Granted Exception (UGE), it simply means the user has agreed to being tracked, either by the use of cookies or any other mechanism.

In terms of the basic W3C DNT Tracking Compliance and Scope (TCS) specification DNT:0 means that the user given “explicit and informed consent” to “practices otherwise proscribed by this specification” i.e. to “the collection of data regarding a particular user’s activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred”.

Until more browsers implement the DNT UGE (so far only Microsoft has done that) another protocol element (the Tk: C response header) can be used to indicate that another mechanism, such as a cookie, is being used to record user consent.

EU data protection and privacy law covers a wider scope, particularly on the issue of personal data collection and use by first-party sites, but the DNT protocol and API can be used to indicate that also. The user must be informed when consent is registered in their browser, so a wider interpretation could be explained then. There is also a defined protocol element (the Tracking Status Resource “compliance” property) that can make any alternative legal compliance statement persistent and transparent.

Once the majority of third-party servers respect DNT, perhaps with legal backing for that, then most sites would no longer need these banners, just to ensure they only embed DNT compliant third-parties.

stuartpb · 2015-08-09

Wait, huh, did I miss something? When did Microsoft implement Do-Not-Track meaningfully? Last I heard, they shipped it on-by-default in IE10 (or earlier?) and rendered it meaningless (leading Apache to land a patch ignoring its presence when defined by IE). And I thought the consensus was that it was going to be implemented as an opt-in, not an opt-out (even though opt-out, as Microsoft did it, is clearly what’s in the user’s best interest).

In any case, why are we leaving this tracking behavior separate from cookie acceptance behavior (which is what makes DNT so ignorable by end servers)? Why not just have browsers block/control the actual acceptance of cookies (the way we do with pop-ups)? That way, if the user doesn’t want to be tracked, they just don’t give browsers the means to do so (while, yes, still stating that they don’t want the server to do any additional fingerprinting).

alastc · 2016-12-05

Sorry to bump this up, but I independently thought of something similar and found this was already here.

To properly automate it (i.e. not bother the user) it seems best to have:

a header from the browser that says “I don’t mind 1st party cookies”
a function on the website that detects this header and never shows the damn pop-up.
If the header is not detected, it shows the pop-up/pop-over/banner.

I’m not sure if DNT would fit this, as tracking and cookies are not aligned. I don’t mind 1st party cookies but I like to disable cross-site tracking (and do so with Privacy Badger). It doesn’t help with the stupid pop-overs though.

Does that seem feasible?

robin · 2016-12-05

A header is overkill for this. Besides headers aren’t cheap, and I doubt this would make the cut. A simple attribute to identify the warning and kill it (either directly by the browser or in an extension) is much simpler and all it takes.