Update (Feb 8): We’ll be doing some a/b testing with the consent interface. Once we’ve landed on a final design, we’ll use that design on all of our sites network wide. Additionally, we’re working on cross domain support and hope to have this ready to roll out with the final consent interface design. This will ensure that you aren’t prompted again across our domains if you’ve already confirmed your settings.

Update: We’ve rolled out the new cookie settings to the following four sites: Super User, Cross Validated, TeX - LaTeX, and Database Administrators

As part of the recent updates designed to create more transparency and give our users more control, we’re making some updates to how users can provide consent for our use of cookies and similar technologies across our sites. This update explains how we use cookies and how users can opt into categories of cookies that are not strictly necessary for us to operate our sites and products.

Starting today, we’re testing these new options on one Stack Exchange site (Ask Ubuntu). Next week we’ll roll out to four more sites and monitor things for a few weeks. If all goes well, we plan to roll out network wide the week of February 3rd (or sooner).

What cookies do we use?

Strictly Necessary Cookies

These cookies are necessary for our website to function properly and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You cannot opt-out of these cookies. You can set your browser to block or alert you about these cookies, but if you do, some parts of the site will not work. These cookies do not store any personally identifiable information.

Performance, Functional and Targeting cookies

We will only use these cookies with your permission when you accept our use of the cookies. These are explained in more detail below.

What categories of cookies can I consent to?

Performance Cookies
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.

Functional Cookies
These cookies enable the website to provide enhanced functionality and personalization. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.

Targeting Cookies
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.

How do I customize my cookie settings?

The first time you land, you’ll see a banner at the bottom of the page. Clicking “Accept all Cookies” will opt you into all optional cookie categories. Clicking “Customize Settings” will expand a modal where you can see the new category options.

consent banner

Once expanded, you can choose to opt in to one or more of the listed categories. Make sure to click ‘Confirm My Choices’ to save them.

content modal

If you ever change your mind about the consent you’ve provided, you can always come back and change your preferences by clicking “Cookie Settings” in the footer.


Here’s the rollout plan, just so you know what to expect if you frequent one of these sites:

Where When
Ask Ubuntu Today
Super User, Cross Validated, Tex-Latex, and Database Administrators Week of Jan 11th
Network wide TBD

You can also expect to see some updates to the cookie pages in our legal portal along the way as we iterate to improve the information we provide.

If you come across any bugs with the updated experience please add an answer to this post so we can address it. As mentioned before, we’re happy to answer any questions you have about this, but we can’t give legal advice (such as interpreting the GDPR or other regulations).

  • 2
    I wish I could award a bounty to your question ;) But thank you. I am pretty particular about cookies, trackers and similar stuff; it's great that I can now do this on SE only without using my browser settings. – Ollie Jan 7 at 22:33
  • 11
    Have a cookie for implementing this: 🍪🍪 – 10 Rep Jan 7 at 22:46
  • 1
    Just eat what you're given, redirects, cookies, even ADs are offered to allow the sites to function; people often overblock and ask why they can't login - the Targeting Cookies should never have been offered. – Rob Jan 7 at 22:54
  • 3
    @10Repsaysgetvaccinated why thank you. – Des Jan 8 at 18:34
  • 4
    Have the browser fingerprinting ads been removed yet? Because those act as "supercookies" that cannot be deleted by users. – The forest of Reinstate Monica Jan 10 at 3:15
  • 1
    @TheforestofReinstateMonica - Fingerprinting goes against our advertising policy and we don’t permit clients to do this. We haven’t received any complaints about this in about two years but if you see this, please report it. Additionally, if a user does not opt into the targeting category, we use Google’s Limited ads feature to mitigate the chance of this happening. – JD-Stack Jan 11 at 17:36
  • 2
    @JD-Stack It has been reported and there were lots of complaints, e.g. meta.stackexchange.com/a/332351/384528 – The forest of Reinstate Monica Jan 11 at 22:58
  • @TheforestofReinstateMonica - I think I've gotten my timelines a bit wrong here. This is indeed the last case I can personally remember where we had this issue, and it's 1.5 years ago. I don't think there was anything like that ever since, but please correct me if I'm wrong. – JD-Stack Jan 12 at 9:20
  • 1
    @JD-Stack As far as I know, they're still doing this, 1.5 years later. – The forest of Reinstate Monica Jan 12 at 23:55
  • Examples would be nice @TheforestofReinstateMonica. Gotta know what exactly is the ads causing it so we can avoid those companies 😁 – Journeyman Geek Jan 14 at 15:42
  • Uh. Y'all have a list of cookies that would be great to have in the main post stackoverflow.com/legal/cookie-policy#C0003-list . It's excellent and useful but not getting enough love 😒 – Journeyman Geek Jan 14 at 16:03
  • @JourneymanGeek good call. I've linked the page instead of copy/pasting the whole thing. – Des Jan 14 at 16:40
  • Thanks- that works for me. I suspect once the cookie preferences are fully rolled out, the link to the cookie list from ought to be the primary source of truth (tm) anyway (and that's where I got it from), but its useful that folks know its there before the full rollout. – Journeyman Geek Jan 15 at 2:35
  • Possibly related (the implementation): Cross Validated asking ad nauseam about accepting cookies? – P.Mort. - forgot Clay Shirky_q Jan 17 at 23:20
  • 1
    @TylerH gotcha. Yes, we definitely want it to be easy but more importantly it should be very clear. We don't want users unintentionally giving consent because of confusing UX. – Des Feb 8 at 20:23

15 Answers 15


Dumb question but - are these cookies per site or network wide?

More precisely, if I set them on AU today, will it take effect network wide either now, or as the feature gets rolled out?

  • 2
    I doubt that. There are a lot of different domains - serverfault, stackoverflow, stackexchange, askubuntu - and some cookies that Adam Lear stated would work network-wide didn't on those different sites. – Ollie Jan 7 at 23:08
  • Not that dumb a question then :D – Journeyman Geek Jan 7 at 23:13
  • No, not really ;) I see FR's on the horizon. – Ollie Jan 7 at 23:13
  • 8
    Not the project dev, just speaking as a dev. These cookie consent cookies are stored per TLD. That is, a decision on Ask Ubuntu will be recognized on any site that matches .askubuntu.com, but not for example .stackoverflow.com. Opting in on apple.stackexchange would opt you in and dismiss the banner on chat.stackexchange and judaism.meta.stackexchange though. It's conceivable that consent could be tracked for logged in users by replicating it to a user preferences store but I'm not sure how far that has been explored. – Brian Nickel Jan 8 at 0:23
  • Eh that works. So one might at most need to set it on the trilogy, au and somewhere on SE ... Which isn't too onerous – Journeyman Geek Jan 8 at 0:25
  • 6
    Cross-domain cookies are possible; there's many ways to implement them. – Rob Jan 8 at 1:23
  • 1
    Once you set your preferences, they will be stored for that domain. Given that we use a third party technology to manage your preferences, we cannot guarantee preferences set on one domain will be applied across the entire network (e.g. across different domains). You will however have the ability to check and set your preferences for each domain. – Des Jan 8 at 18:20

This is good, in theory. However, I'm rather upset that you've gone with the status quo and decided to use dark patterns. Just take a look at this:

Dark red "Accept all cookies" button, light pink "Customize settings" button

The primary button is the “accept all”. If people are clicking-without-reading, they'll accept all cookies. That's not consent. If you want to give people a choice, you don't have a primary colour and a secondary colour like this.

But let's ignore the “primary” “secondary” thing for now, and just treat them as the “light button” and the “dark button”, as my brain did.

The Cookie Settings window, with a dark red "Confirm my choices" button and a light pink "Accept all cookies" button

Yes, this all seems to be in order. I'll just click the pink button aga— Woah, what‽ The pink button, which previously meant “let me choose”, now means “discard my choices”? (Why is that button even there? I already said that I didn't want to do that!) And, worse, I have no way of knowing whether I accidentally clicked this? That's not consent.

But let's say I accidentally clicked the wrong button, then realised it. How do I change the settings? Well, I haven't the foggiest. Now, I'm no expert on GDPR, but I'm pretty sure that's meant to be “as easy” as clicking “Accept all cookies”. Which it's not. Don't get me wrong; it's still much better than the status quo, and I support going forward with the roll-out! Incremental change is better than no change. But keep in mind that you'll need to do another roll-out later, if you go ahead as-is.

If you want to see how it's done, Marco Saric wrote a blog post going into detail about the topic.

  • 5
    Yup. GDPR says (basically) that rejecting (“not approving”!) cookies must not be harder than approving them. Nudging and dark patterns like this generally do not lead to consent. – MEE Jan 12 at 17:57
  • 1
    Our intention is not to introduce a dark pattern – quite the opposite. We reviewed several comps and wanted to ensure there is a clear path to both accepting all and customizing settings. I’m passing this feedback to our design team to revisit button styling. As for a path back to cookie settings, there is a link available in the footer to quickly access and update your preferences. – Des Jan 15 at 22:34
  • @Des Could you also revisit having an “accept all” in the box that comes up? A “toggle all” switch at the top would be better. I know it probably seems to SE like it's better for users to accept everything, but your design should always be from the “make it easy for users to choose” point of view. No “they'll probably choose this, so make it a default option” type things; they're hard to do in a way that actually ends up with something that enables the majority of your users to give informed consent. (I'd argue that no “accept all” button is good, but I'm probably wrong there.) – wizzwizz4 Jan 15 at 23:02
  • I designed this modal's primary action to be "Confirm my choices" since the user had clicked "Customize settings" to show it. I didn't want users who wanted to customize their experience to feel like we opened this modal only to subtly push for users to "Accept all cookies". That was my rationale for the button order, anyway. – Aaron Shekey Feb 5 at 19:41
  • To further clarify, if we were to do Accept all cookies as the primary, with Confirm my choices and then Cancel, my fear was that would be considered a dark pattern. It's a bit of a tight rope. @wizzwizz4 We had some mockups with a toggle while removing the Accept all cookies button but it was also mildly confusing in early tests. – Aaron Shekey Feb 5 at 19:44
  • @AaronShekey That would've been a dark pattern, you're right. However, doing the opposite of the previous dark pattern is also confusing – so it must be a false choice. I think removing the “Accept all cookies” button on the bottom bar would make it okay to have in the box, but why do you make the user choose whether to “accept all cookies” twice? There's the strongest argument for having the one in the box, I think, since the one outside the box is only there for convenience but “I pressed the most convenient button” probably isn't grounds for consent anyway (though IANAL). – wizzwizz4 Feb 5 at 21:51
  • I'm surprised that the toggle at the top was confusing. It seems to be fairly standard on other sites, and it uses familiar GUI table idioms (like those in Excel, or the Windows Explorer details view, or Finder, or Wikipedia). – wizzwizz4 Feb 5 at 22:00
  • 2
    @Des - flopping the colors between the outer panel and the inner panel ("Accept all cookies" and "Confirm My Choices" having one color, "Customize settings" and "Accept all cookies" having the other) looks to be a pretty clearcut example of "Privacy Zuckering": You are tricked into publicly sharing more information about yourself than you really intended to. – dbc Feb 17 at 19:15
  • @dbc But as Aaron pointed out, the other way around would also be problematic. The fundamental design would need to be changed. (You have to keep in mind not only people's expectations for how normal UI works, and SE UI works, but also GDPR consent UI; I don't envy the designers' jobs.) – wizzwizz4 Feb 18 at 12:11

In the mobile web version of the site, the footer link is called 'consent management' instead of 'Cookie settings'. Not that that's wrong, but it could cause confusion.

enter image description here

  • 2
    It's probably "consent management", with a confusing line break between the two words. – Cody Gray Jan 8 at 8:44
  • @CodyGray yes, thanks. I wrote this answer on my phone in night mode just before sleeping; those details aren't easily visible then. – Glorfindel Jan 8 at 8:46
  • 2
    Look at the bright side: at least the link isn't a cookie emoji ;-) – Cody Gray Jan 8 at 8:47

Thank you for creating a real choice here, one that makes it reasonably easy to opt out of non-essential cookies. There are far too many versions of this dialog that are intentionally annoying.

I did encounter an issue that was self-inflicted, uBlock Origin blocked the customize dialog for me (the responsible list was "AdGuard Annoyances"). This is of course not something SE can do much about, and it did help me to identify a particular filter that was not doing what I expected it to do. I'm still a bit surprised the dialog uses a third-party script from a different domain, I'd have expected this to be self-hosted.

I really like that the individual cookies are actually listed in the linked help page. The functional cookies category still confuses me a bit though. I don't understand what they do, and what will stop working if I decline them. This doesn't matter that much to me personally right now as long as it's only SE and Github in that category, but that might change in the future.

  • 1
    Thank you for this feedback. We intend to update the individual cookies listed on that page to include descriptions to provide more context for you. You can expect it to be in place by the time we launch network wide. – Des Jan 8 at 18:18
  • 5
    @Des Please don't supply that functionality via a 3rd party. – philipxy Jan 15 at 23:48

Can you give some examples of functionalities that may stop working if users disable Functional Cookies?

Functional Cookies

These cookies enable the website to provide enhanced functionality and personalization.

  • 8
    One example is when we detect a non-english speaker on Stack Overflow, we display a notification letting them know about our international sites. This notification would no longer appear. This is considered enhanced functionality and not "strictly necessary" for the site to function properly. – Des Jan 8 at 18:13

If you do not allow [performance cookies] we will not know when you have visited our site

Does this mean that if one browses the site with performance cookies disabled, their site visits won't be registered for the purposes of the site visit counter in one's user profile, and the badges (Enthusiast and Fanatic) which are awarded based on that counter?

Or are site visits for that purpose counted separately? (Or are they counted using strictly necessary cookies, since the visit counter and badge awarding are considered "core functionality" of the site?)

  • 1
    We do not rely on cookies to award badges so in this example, opting out of performance cookies would not prevent you from earning a badge. – Des Jan 15 at 22:30
  • @Des But will users still have their site visits counted toward the site visit counter in their own user profile, if they've opted out of performance cookies? – Sonic the Curiouser Hedgehog Jan 15 at 22:32
  • Yes, it’s the same idea here as well. The site visit counter feature on your profile isn’t powered by a cookie. Additionally, we don’t use this data to analyze site performance. – Des Jan 15 at 22:41
  • 3
    @Des The quote says one thing, your comments say another. Please fix the cookie documentation page so it clearly says whatever it's trying but failing to say. – philipxy Jan 15 at 23:18

The gigantic black Cookie Consent panel is so enormous and obtrusive that https://superuser.com/ is effectively useless until a new visitor has clicked through its options:

enter image description here

The fact that you have chosen to render the site useless until a visitor has clicked through the various options smacks of being a "dark pattern" -- it's so obtrusive that you're trying to induce people to pick "Accept all cookies" rather than "Customize settings" where "Strictly Necessary" is the default.

Why make it so difficult and time-consuming to find and select "Strictly necessary"?

What's more, in my default profile I browse with cookies disabled. https://superuser.com/ is now useless and unusable with this profile. It is also useless and unusable with Javascript disabled (which I sometimes do to prevent obtrusive blocking popups on other sites). And in all profiles I clear cookies upon restart or reboot. Since you save these consent settings in cookies rather than in account settings, this is going to make viewing any stack exchange site in a new browser session painfully slow.

Some additional issues I have found using Firefox (85.0 (64-bit)) with regards to accessibility and keyboard navigation:

  • Because "Customize settings" and "Accept all cookies" are not links, Firefox "Search for text when you start typing" does not navigate to them, making them harder for those of us with mouse accessibility issues (such as myself) to select them.

  • If I try to navigate to "Customize settings" using Firefox "Quick find" functionality by typing /Customize then it seems I can navigate to "Customize settings":

    enter image description here

    However if I subsequently press CR to launch the "Cookie Settings" dialog, nothing happens. For some reason I have to type ShiftTAB once to navigate backwards, and then I can type CR to launch the dialog. And if I hit ESC to cancel the dialog, I again have to type ShiftTAB before CR to re-launch the dialog.

  • When the "Cookie Settings" dialog is displayed, I need to type Ctrl+F twice to display the Firefox search bar. Under normal circumstances one Ctrl+F is sufficient. Is your Javascript grabbing the keystroke for some reason?

  • Once "Cookie Settings" has been launched it's entirely unclear how to use keyboard navigation to select options within the dialog. None of the toggles are visibly focused initially. Ctrl+F + Performance cookies to navigate to that option doesn't work because Ctrl+F doesn't work. /Performance cookies doesn't work at all while the dialog is up, perhaps for the same reason.

    Hitting Space initially toggles "Performance Cookies". This is not bad, however the "Performance Cookies" toggle is not initially displayed as having focus so it is unexpected. Consider making the "Performance Cookies" toggle be explicitly focused when the dialog is opened. And please do make the focus more obvious and less subtle:

    enter image description here

  • Typing CR immediately after "Cookie Settings" opens shifts the focus to "Performance cookies". This seems wrong. I would have expected it to do "Confirm my choices".

  • All in all the minimal set of keystrokes required for a keyboard user to select "Strictly Necessary" with Firefox seems to be

    • /customize to navigate next to "Customize settings".
    • ShiftTAB to navigate to "Customize settings" itself.
    • CR to launch "Cookie Settings"
    • TAB + TAB + TAB + TAB (four tabs to navigate to "Confirm my choices").
    • CR to actually confirm my choices.

    Have I missed an easier way to do this? Because this was really not easy.

If we are going to be forced to make these cookie consent choices frequently, please try to make them less burdensome on those of us who mainly use keyboards for accessibility reasons.

  • I wonder if that gigantic cookie panel you are seeing is a bug. This is how the cookie control looks on super user for me: i.stack.imgur.com/fQqB4.png. The one in your screenshot seems odd: the content is not centered vertically in the panel. Could be a cross-browser compatibility issue. Looks like you are on Firefox. Can you try in a different browser. – Kodos Johnson Feb 17 at 0:54
  • 2
    On the other hand this could be some kind of A/B testing so maybe it looks different to different people on purpose. But I still think it looks odd. – Kodos Johnson Feb 17 at 0:56
  • I'm getting the same effect on Seamonkey but that is firefox-based. On (ahem) Internet Explorer the black panel isn't black at all, it's transparent and I just see some text floating in the upper right corner of the window. – dbc Feb 17 at 1:00
  • 1
    @KodosJohnson it's not a rendering bug. When I inspect it with the inspector on Firefox 85.0.1 (64-bit) on Ubuntu 20.04.2, I see classes that are declared to behave exactly as seen. .hmn100 { min-height: 100% !important; } and .w33 { width: 33.3333% !important; }. I'm also guessing at A/B testing, as you have suggested. – Levente Feb 17 at 4:01
  • @Levente ah yea and I just noticed there was a Feb 8 update on the original post that mentions they are doing a/b testing. – Kodos Johnson Feb 17 at 19:05
  • 1
    I just started getting the big black cookie panel :( – Kodos Johnson Feb 18 at 0:15
  • 2
    Also on AskUbuntu Meta: The new cookie consent banner is way larger than needed. – Quasímodo Feb 18 at 13:22

What is the rationale for choosing these sites to test, instead of MSE? Seeing that MSE is usually the site that tests these things very thoroughly.

  • 6
    since cookies are per domain, rolling out to stackexchange could potentially have affected all stackexchange domains. askubuntu is pretty standalone as a domain. – Robert Longson Jan 8 at 17:40
  • 4
    @RobertLongson is right. This allowed us to monitor things in an isolated way before expanding to more sites. – Des Jan 8 at 18:04

At the bottom of the Ask Ubuntu page, in the footer settings the following text is displayed:

By clicking “Accept all cookies,” you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Within the double quotes, there is a comma. The double quotes denote the exact text of the button text, but there is no comma in the button text.

Screenshot for reference:


The comma can be placed after the double quotes, it could be displayed as below:


  • 3
    This isn't a bug. There's no consensus among grammar style guides about whether punctuation belongs inside or outside of the quotation marks. Plenty of American English style guides (at least) recommend putting the punctuation inside of the quotation marks. I agree, it seems wrong, especially to programmers, since, as you say, the punctuation mark does not appear in the original text that is being quoted, but there are arguments in favor of it. – Cody Gray Jan 8 at 8:45
  • 1
    I think Strunk&White style guide advises to put the comma outside the quotes in this case. – bad_coder Jan 8 at 11:24
  • 1
    If it is any help the Guardian (a British respected newspaper) agrees with Arulkumar and @bad_coder – mdewey Jan 8 at 14:28
  • 1
    @mdewey Yes, because the British standard is to put the punctuation outside the quotes. The American standard (which, I'm not personally fond of) is to put the comma inside. For example, Grammarly and the punctuation guide. We tend to use American styles on our site, so the comma is correctly placed for us. – Catija Jan 8 at 17:15
  • 4
    @Catija, the programmer standard is for the quote to exactly match the thing being quoted. – Mark Jan 8 at 21:06
  • 1
    @Catija it is not just the Brits. Your neighbours to the south follow the same rule spanish.stackexchange.com/questions/5343/… – mdewey Jan 9 at 11:15
  • 1
    @Catija “Actually, the British standard is basically the programmer one,” said wizzwizz4. “To my knowledge, the only difference is the annoying handling of punctuation in what is known as “direct speech”.” – wizzwizz4 Jan 9 at 18:27
  • 3
    The MLA and AP guides both insist that commas and periods be placed inside of punctuation marks, as does the Chicago Manual of Style. These are the guidelines followed by most all major American publications, with a few exceptions, of course. Strunk and White, in Elements of Style, also endorse this style authoritatively. But, as I noted above, there is beginning to be pushback, especially in technical circles. Some related reading on that topic can be found here. – Cody Gray Jan 10 at 6:39

I noticed this came out a while ago and since it’s still in testing I thought I would ask: could this be saved by account? Ironically, as it is now, clearing my cookies seems to make the site give me more cookies because it doesn’t remember my options.

  • 3
    We don’t have any plans right now for saving preferences by account but is something we may explore in the future as a means to save preferences across domains. – Des Jan 15 at 22:33

I have problems with this new feature, as reported at Cross Validated asking ad nauseam about accepting cookies? which was closed. Many details there, also in comments.

I am on Ubuntu linux (20.10 fully updated.) Using Chromium browser (Firefox also tested, no problems ...) All the four sites Cross Validated, Tex & Latex, Ask Ubuntu, Super User, Database Administrators, was tested, same occurs. Each&every time (so Ad Nauseam) I open a new page/tab, it asks anew for "Accept All Cookies" and I accept, without effect. If I alternatively choose "Customize Settings", nothing happens, no window is opened ...


In a comment:

"Not the project dev, just speaking as a dev. These cookie consent cookies are stored per TLD. That is, a decision on Ask Ubuntu will be recognized on any site that matches .askubuntu.com, but not for example .stackoverflow.com. Opting in on apple.stackexchange would opt you in and dismiss the banner on chat.stackexchange and judaism.meta.stackexchange though. It's conceivable that consent could be tracked for logged in users by replicating it to a user preferences store but I'm not sure how far that has been explored. – Brian Nickel 🔷 Jan 8 at 0:23".

@Brian, that causes an unexpected (?) effect.

Choosing your cookie choices on meta.stackexchange.com sets your cookie preferences on *.meta.stackexchange.com (for example: https://stats.meta.stackexchange.com/), but not on https://stats.stackexchange.com/.

Normally a user would expect that making a cookie choice either applies to one or all Stack Exchange sites (regardless of TLD), but instead MSE cookie choices apply to itself and all per-child-metas; and each main site is baked separately.

Not sure if that complies with the spirit of "consent", to present the setting as only applying locally, when in fact sometimes it applies to a single site and in another instance it applies to 170+ sites.

I understand this, and the problem / way it is; but is it clear to everyone?


What cookies are necessary for the red dot to work on Custom Filters?

image of custom filters

  • 1
    Custom filters don’t use cookies. For a given filter, we store the "last viewed" timestamp as well as the timestamp of the most recent post activity in Redis. We compare the two to determine whether to show the red dot. – Des Jan 15 at 22:36

Please stop this. Firefox blocks third-party cookies, so the bar doesn’t go away no matter what I click.

As a workaround, I killed it with uBlock Origin like this:

  • 1
    For me, it works with no problem in Firefox, with either standard or strict tracking protection. – Emil Jeřábek Jan 16 at 16:49
  • 3
    I wonder if its an extra strict setting the user set... I don't think blocking all third party cookies would be a good default - since looking at the cookies SE has, that might break some log-in paths? – Journeyman Geek Jan 16 at 17:10

I think when you choose Customize Settings the selected default should be both "Strictly Necessary" and "Performance Cookies" instead of only "Strictly Necessary"; the performance cookies seem to have no downside, and are helpful to everyone.

@Des, what would the disadvantages (for the user) be if they enabled "Performance Cookies" - it would seem to be something that people (who want any cookies at all) would want:

Cookie Settings
(Click to enlarge)

  • 8
    Thanks for the suggestion. We enabled by default all the cookies that the law allows us to enable by default. GDPR regulations require us to treat performance cookies separately and differently from strictly necessary cookies. As such, we need to have users specifically opt in for the performance cookies (we can no longer have them default on/opt out) to ensure we're following rules to comply with the varied requirements around the globe. – Des Jan 8 at 19:03
  • @Des, thanks for your reply. I don't know that applies for "Performance Cookies": en.wikipedia.org/wiki/… but that only applies in the EU. Since cookies are not necessary defaulting to apply a particular set as required (especially when they can be switched off) is not well explained. – Rob Jan 8 at 20:03
  • 1
    ...the performance cookies seem to have no downside, and are helpful to everyone. People are likely to complain that anything that's not strictly necessary should be opt-in, not opt-out, if only on principle. – BSMP Jan 8 at 20:11
  • 3
    @Rob from that same wikipedia article: "According to Recital 30 of GDPR natural persons may be associated with cookie identifiers. Thus, cookies can be qualified as personal data and are therefore subject to GDPR. To use such cookies companies must receive prior user consent." Consent that needs to be given explicitly (thus opt-in) – Luuklag Jan 8 at 20:31
  • 4
    @Rob I hear you. However, since we are a global platform and need to handle this in a uniform way worldwide, we set the settings to comply with the “strictest” jurisdictions’ requirements. – Des Jan 8 at 21:18
  • Luuk+Oth While it's referred to as a cookie law it applies with restrictions (otherwise you'd be requesting a webpage and the site would be unable to reply because it didn't keep your information). There are opt-in models where it's made clearer; both to the user, and to the website, what is agreed to. Simply show the consent as i illustrated, that's compliant. – Rob Jan 8 at 21:20
  • Thanks for the (last) edit, Cat must have a 1280x640 screen. – Rob Jan 8 at 21:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .