How to deal with Firefox extensions that require cookies

Some Firefox extensions require access to local storage and/or indexedDB, for instance to store data on the user device Firefox runs on.

These extensions may break if cookies are blocked. Extensions like uBlock Origin, uMatrix, or Stylus use the storage and thus require cookie permissions even if they don't set cookies to work correctly.

While some come with fallbacks built-in to overcome this limitation, it is best to address this head on instead as indexedDB usage is usually the better option to whichever fallback solution is used otherwise.

firefox extensions cookies

The easiest way to get to the profile folder is to load about:support, and click on the show folder button on the page that opens.

You can check the storage\default directory of the Firefox profile if extensions use indexedDB. If you have folders starting with moz-extension in there, you have extensions that use it and thus require cookie access. Note that the extensions are listed with their internal UUID and not their name. Note that the UUID is randomly assigned during installation. Means: if you uninstall and reinstall, or use the extension on multiple systems, it is different.

Firefox users have two options to address the issue:

  1. Allow first party cookies, and clean up cookies regularly or block cookies and storage.
  2. Keep the deny all setting, but use exceptions to allow extensions that need cookie access to use indexedDB storage to function properly.

Set cookie exceptions for extensions in Firefox

firefox cookie exceptions for extensions

  1. Load about:debugging in Firefox to get started. The page lists all system add-ons, and all installed extensions of the Firefox browser.
  2. Locate the browser extension that you want to add exceptions for. You find the internal UUID listed next to extensions that you have installed in the browser. This helps with the identification.
  3. Click on Manifest URL underneath the extension listing.
  4. Right-click on the page that opens, and select View Page Info from the context menu.
  5. Switch to the Permissions tab of the Page Info window.
  6. Locate Set Cookies in the list of permissions. Remove the checkmark from "use default", and set it to allow instead.
  7. Repeat the process for any other extension that requires access to cookies.
  8. Restart Firefox.
Read also:  Firefox blocks all GitHub release downloads as deceptive

Tip: You can manage cookie permissions under Options > Privacy & Security > History > use custom settings for history > Accept cookies from websites, Exceptions. You may use the prompt to add cookie exceptions as well. All that is required is to copy the entire folder name, replace the +++ with ://,  add it under "address of website" and set it to allow. (e.g. moz-extension+++23bf26fb-1c8d-40d3-b7c2-798882a0d55c to moz-extension://23bf26fb-1c8d-40d3-b7c2-798882a0d55c)

firefox whitelist cookies extensions

Additional information:

  • CCleaner detects extensions cookies but it makes no difference whether it cleans them or not as they get recreated automatically on the next start of the browser.

Closing Words

The Ghacks user.js file for Firefox blocks cookies by default. Users who apply it and run extensions that require cookies may run into issues afterwards. The article highlighted a method to overcome this without enabling first party cookies globally for all sites and extensions in the browser. (Thank you Pants)

Summary
Article Name
How to deal with Firefox extensions that require cookies
Description
Some Firefox extensions require access to local storage and/or indexedDB, for instance to store data on the user device Firefox runs on.
Author
Publisher
Ghacks Technology News
Logo
Advertisement
Please share this article

Facebooktwittergoogle_plusredditlinkedinmail



Responses to How to deal with Firefox extensions that require cookies

  1. Pants October 10, 2017 at 6:55 am #

    > All that is required is to copy the entire folder name, add it under "address of website" and set it to allow.

    Err .. nope. Better edit that, and the pic is wrong too. You need to replace "+++" with "://" (there's a colon there before the backslashes)

    Here's a picture: https://raw.githubusercontent.com/ghacksuserjs/ghacks-user.js/master/wikipiki/exceptions02.png

  2. Paul(us) October 10, 2017 at 1:10 pm #

    Thanks, Pants, and Martin, For another really outstanding handy article on ghacks.net.

    But what to do when you use the Add-on named self-destructing cookies (up to version 0.4.12)
    I ask this because this add-on is setting the default for cookies behavior use standard as allowed for the session (also for, the uBlock Origin add-on).
    So what to do should I change the setting to default on (and does that than not destroy the correct working of the add-on use?) as you suggest? Or should I do nothing?
    And/ Or Is this add-on a good add-on to have the add-on in general or it's maybe wiser (better) to change the individual settings one by one, like you suggest it do?

    https://addons.mozilla.org/en-US/firefox/addon/self-destructing-cookies/?src=api

    • Tom Hawack October 10, 2017 at 7:55 pm #

      You'd better switch to the 'Cookie Autodelete' Firefox add-on because it handles permissions in its own database independently of Firefox.

      Problem is 'Cookie Autodelete' (as 'Self-Destructing Cookies') won't be pertinent (will have no use) if Cookies are globally blocked. What you can do is :

      1- Set cookies as globally blocked;
      2- When as site requires a cookie (either to simply appear, or because you wish it) then once on that site open Firefox's Page Info and set your choice in Permissions / Set Cookie -> This modifies Firefox's exception list.
      3- With the 'Cookie Autodelete' add-on, choose
      - 'Clean after tab close' (default) and the cookie will be wiped once you qit the site,
      - 'Clean on browser' restart' and the cookie will be managed by 'Cookie Autodelete' as a session cookie;
      - 'Never clean' and the cookie will remain.

      Remember that the cookie exception you grant to Firefox has to fit with that you grant to 'Cookie Autodelete' : if you've set Firefox cookie permission to session then setting 'Cookie Autodelete' to 'never 'Never clean' won't work.

      This is what I do, which allows blocking all cookies even before they get installed (then wiped by 'Cookie Autodelete' on site exit), allows what used to be called 'temporary cookies' (for this session only, not for future sessions) and even better : 'one-hit' cookies (only when visiting a site which requires a cookie afer what the cookie is removed). The best of two worlds, that of blocking all cookies and that of building highly tailored exceptions.

      Note : rather than opening the Page Info for a site I still use a legacy add-on called 'Permit Cookies 2' : I therefor have two toolbar buttons, that of 'Permit Cookies 2' which grants user cookie permissions at the Firefox level, that of 'Cookie Autodelete' which grants cookie permissions at the 'Cookie Autodelete' level (considering the add-on manages cookies independently). Et voila.

      It's very simple, anything sounding complicated would be explained but my lack of good English. I do hope you get the idea.

      • SimonAlberta October 10, 2017 at 10:12 pm #

        That all seems fine Tom but in my experience it is impossible to keep all cookies at bay. I have tried every cookie blocker/manager/deleter I can find and used "block cookies" and/or "delete cookies" settings in FF and, without fail, when I use CCleaner it lists dozens of cookies that have been set, mostly 3rd party, that have not been stopped or deleted by FF or its' add-ons.

        It sometimes seems spooky how sites can get around privacy settings.

        Not to mention the completely useless "Do Not Track" setting. What a waste of space that is.

      • Tom Hawack October 10, 2017 at 10:29 pm #

        @SimonAlberta, CCleaner includes in its cookies list entries of all your browsers and concerning Firefox as well those found in the SiteSecurityServiceState.txt file in the user's profile. SiteSecurityServiceState.txt is a text file database for HSTS supercookies. HSTS cookies has its pros and cons. There are several Ghacks articles about HSTS, i.e. [https://www.ghacks.net/2015/10/16/how-to-prevent-hsts-tracking-in-firefox/}

        If you backup your SiteSecurityServiceState.txt file, then either delete it or empty it, then run CCleaner, you'll find only the "classical" cookies (as far as Firefox is concerned)

      • Paul(us) October 11, 2017 at 1:23 am #

        Tom Hawack, First of all, I want to thank you ferry much for taking the effort of taking the time to write such a well-written answer to the question I did put before you.
        Second I have uninstalled the self-destructing cookies add-on and installed the by you suggested add-on cookie autodelete. And from what I understand up to now from it it's working like a charm.
        Concerning the rest of your suggestions, I am going to look a really good hard look to them the coming days this because of today it was like you know Microsoft patch day, what to most of this evenings time took.
        Again thanks, Tom Hawack I am ableist to you!

  3. 12bytes October 10, 2017 at 2:26 pm #

    for those that want to browse the www in a (mostly) care-free manner, yet maintain a semblance of privacy as well, denying cookies globally and then manually white-listing extension data storage and whitelisting websites that require this functionality, is not a viable option in my personal opinion - it's just not something the average FF user is going to bother with - and so this needs to be automated

    currently there is 'Cookies Exterminator' for those who plan to run a FF derivative which continues support for legacy add-ons (Waterfox, Pale Moon, ect.) and 'Cookie AutoDelete' which is a WebExt, though it doesn't clean LocalStorage just yet - apparently it is planned however, depending on the FF API i suppose

    • SimonAlberta October 10, 2017 at 10:14 pm #

      As I mentioned to Tom above, these add-ons are only partially effective in my experience.

      • 12bytes October 10, 2017 at 10:54 pm #

        partially effective how? do you mean sometimes they work and sometimes they fail, or that they completely miss some storage altogether?

        i'm running Cookies Exterminator at the moment and it seems to ok, but it's early

        it seems a few these add-ons that deal with storage will not work properly unless 'privacy.firstparty.isolate' = 'false' - apparently this is being addressed (or is supposed to be) by the FF devs

      • SimonAlberta October 12, 2017 at 9:31 am #

        To: 12bytes (for some reason there is no "Reply" button below your comment below so I am replying here)

        By "partially effective" I mean that whichever cookie "exterminator" I use (and I think I have tried them all) CCleaner still finds numerous cookies to clean. They tend to mostly be 3rd party cookies, which is annoying because I have Firefox/Waterfox set to reject 3rd party cookies so this setting seems useless also.

    • versus October 11, 2017 at 11:41 am #

      What is the difference between Cookies Exterminator and Self Destructing Cookies & also, does it provide an option similar to "Strict Cookie Access Policy - Match cookie domains as proposed in the EITF HTTP State Management draft"?

      Thanks

      • 12bytes October 11, 2017 at 4:14 pm #

        > What is the difference between Cookies Exterminator and Self Destructing Cookies ...

        i don't know - they both do the same thing essentially - it's important to set "privacy.firstparty.isolate" to "false" if you're using the ghacks config, else CE and some other add-ons that deal with storage won't work properly

        there is no "Strict Cookie Access Policy" in CE - maybe it does that internally however, dunno - ask the dev

        i like CE - it seems to work (more testing needed though) and it has a white, gray and black (what it calls "red") list and has a log viewer right in the preferences UI

  4. TelV October 10, 2017 at 5:08 pm #

    Martin, you mentioned in step 1 that, quote, "The page lists all system add-ons, and all installed extensions of the Firefox browser." Unfortunately, that's not the case on ESR 52.4.0 at least. What appears is the same as shown in the first screenshot on the following site: https://developer.mozilla.org/en-US/docs/Tools/about%3Adebugging#Enabling_add-on_debugging

    As you can see, there are no system add-ons anywhere and no UUIDs.

    • Martin Brinkmann October 10, 2017 at 5:33 pm #

      Which version of Firefox do you run? On Nightly, I see them all listed. See https://imgur.com/a/nOQoa

      • TelV October 10, 2017 at 5:43 pm #

        ESR 52.4.0

      • Martin Brinkmann October 10, 2017 at 6:16 pm #

        Maybe it is not included in ESR yet? I just checked in Firefox Stable, and system addons are listed in it as well.

      • 12bytes October 10, 2017 at 10:57 pm #

        would like to confirm what TelV says - in my case on Mint Linux, there were no "features" listed at all in about:debugging (v55.0.2 i think), yet several were installed

    • Pants October 11, 2017 at 8:42 am #

      56 here, I have a system add-on, it is not listed as a "temporary add-on"

      "System Add-ons" are listed under "Firefox Features" in about:support
      "Extensions" are also listed under about:support under "Extensions" (and they show your UUID as well)
      "Temporary Add-ons" in about:debugging do not list "bundled" system add-ons, it's a different thing - eg loading an unsigned add-on for testing. I do not use Nightly, but maybe that's how nightly does it for system add-ons for some reason (see Martin's imgur pic) - also see https://www.ghacks.net/2015/12/24/temporary-add-on-loading-coming-to-firefox/

  5. TelV October 10, 2017 at 6:23 pm #

    OK, it's no big deal. I don't think I have any extensions that require cookies, or at least I've never seen any requests to allow them for those that I do have installed. .

  6. Pants October 11, 2017 at 3:20 am #

    I just re-read the article, and some things may not be clear

    - Extensions: This is "Web Extensions", not "Legacy Extensions". I am not an extension developer, but the Storage API for Web Extensions is more strict (and not mature yet?) and developers are limited to where and how they can store their settings and assets. FYI: storing settings in about:prefs is no longer allowed (so clean out your obsolete extensions.* prefs if you want to)
    - If you block all cookies by default, and say you update uBlock Origin from Legacy to Web Extension, because it does not have an allowed cookie, it has NO access to IDB, so you will not see any such moz-extension folder being created or used. And in this case, the cached assets that uBlock Origin uses will not exist - I think this means that every time you load Firefox the lists fall back to their saved state and update again (if you have auto update on). I'm not 100% sure on this. gorhill might explain it better. Some other extensions will flat out not work.
    - Private Browsing mode does not allow IDB - this is causing issues for uMatrix, uBlock Origin etc users. Hopefully Mozilla fix that situation at some stage

    If you want to know what extensions require IDB, just allow 1st party cookies for a while, maybe restart FF, and start browsing around for a while, load up extension options maybe. And then check what is in your storage/default folder.

  7. Anonymous October 14, 2017 at 10:09 pm #

    It appears as though Noscript, starting with version 5.1.2, requires indexedDB/storage now also. Noscript handled it automatically though as it adds the necessary exceptions to permissions.sqlite. One for persistent-storage, one for indexedDB and one for WebExtensions-unlimitedStorage.

    They are not visible under Options > Privacy & Security > History > use custom settings for history > Accept cookies from websites, Exceptions though. Just the permissions.sqlite file.

Leave a Reply