EDIT: I recommend subscribing to the bug report of this issue in the Brave github page for updates:
Description of the issue:
In Settings → Sites that can always use cookies or brave://settings/cookies, when I try to remove one of the sites listed in there, either by the ‘remove’ menu item or the trash can button, it doesn’t get removed. The UI gives no notification on why the site can’t be removed.
Steps to Reproduce (add as many as necessary): 1. 2. 3.
Go to Settings → Privacy and security → Cookies and other site data → Sites that can always use cookies or brave://settings/cookies.
Try to removing one of the sites listed under ‘Sites that can always use cookies’, either by the ‘remove’ menu item or the trash can button. Notice that it doesn’t get removed. The UI gives no notification on why the site can’t be removed.
Actual Result (gifs and screenshots are welcome!):
Animated GIF screen capture of the settings UI when trying to remove sites:
Expected result:
That the sites be removed once I click on ‘remove’ or the trash icon. If it can’t be removed, at least give me a notification why, and instructions on how to allow removal.
Also, I didn’t add those sites in there. I expect no sites to be automatically added under ‘Sites that can always use cookies’ unless I manually put them in there.
Reproduces how often:
100%. Happens for all the sites that I didn’t manually set under ‘Sites that can always use cookies’ and even after multiple attempts to remove.
Operating System and Brave Version(See the About Brave page in the main menu):
Windows 7, Brave Version 1.16.72 Chromium: 86.0.4240.183 (Official Build) (64-bit)
Additional Information:
I have Brave shields enabled, but all settings are disabled or set to ‘allow’. The only Brave shield settings that I’ve enabled blocking are: Cookie blocking (cross-site / third-party cookies blocked) and Fingerprinting blocking (standard).
I’ve tried disabling Brave shields, reenabling Brave shields, removing all cookies for the sites (lock icon → cookies → remove each cookie), going to each of the site’s site settings (lock icon) → clear data & reset permissions, but the issue persists.
I had the same problem, but found a workaround, if not an actual solution.
In your Brave browser, open one of the sites you see in the list of “Sites that can always use cookies”. Click on the Brave Shields Settings icon in the address bar. Change the settings for Cookies to “Cookies Blocked”. You should then find that the site in question is removed from the list of sites that can always use cookies.
EDIT: What the eff, this is like a massive zombie cookie … I got tosdr.org and mashable.com to disappear but the hyatt entries won’t go away. Brave team? Any way to fix this without fully nuking my profile?
Okay I spent some time investigating this issue and I believe it’s a bug in the Brave Sync Chain mechanism. I grepped through my whole Brave profile directory and investigated all references to the websites for which cookie settings could no longer be deleted.
The only way I found to really fix this issue is to remove all my devices from the current sync chain, then thoroughly clean up the Preferences JSON file in my Profile directory (see below), remove (rm -rf) all the the sync caches (Brave-Browser/Default/Sync Data/LevelDB and Brave-Browser/Default/Service Worker/CacheStorage), and then finally create a new Sync chain and rejoin from all my devices.
I used a RegEx pattern similar to the below to clean up my Preferences file: %s/((?<=\":\{)|[\,])\"(https:\/\/)?(voice|mail|calendar|docs|drive|world|www)\.(slideshare|hyatt|google)\.(com|net)[^\{]+\{[^\}]+\}[\,]?//g
(Please be careful with your pattern … if you delete just one wrong character, Brave marks the file as “bad” and overwrites most of it. If you’re not into RegEx, you could also try clearing your Site Settings after leaving the Sync chain.)
If you don’t want to recreate your Sync chain for whatever reason, the only other way to work around this issue is to disable the “Settings” synchronization in brave://settings/braveSync/setup before cleaning up the Preferences file as described above. You would no longer have settings synchronization, though.
It’s a JSON file. On MacOS it is here: /Users/<username>/Library/Application Support/BraveSoftware/Brave-Browser/<profile name>/Preferences.
I just found the corresponding Github issue, which was opened in October last year. It only received a “P3” priority, which I don’t get. This seems way more serious from a “Trust” perspective. If it’s not, then the Brave team should explain how it doesn’t affect us (e.g., is it just a UI glitch but the cookies are blocked?).
PS: I think [at]BRAVE is just a user, not the Brave team. We’ll probably have more success by tagging [at]admins and [at]moderators. Or @rebron / @rebron2000 who triaged the issue.
I tried this workaround, but that just moves the sites from ‘Sites that can always use cookies’ to ‘Sites that can never use cookies’ where they still can’t be removed or deleted (like in the GIF screen capture I included in my original post).
@lookmeupunder404 I can’t guarantee it but it might work if you set global defaults to block all cookies and then visit the site and change the value from cross site only to block all
I tried that before and it worked for ~half of the entries. For the rest I had to make the mentioned changes to the Properties file and create a new Synch Chain.
In addition to the concerns already described here, I think the cookie control UI needs a major redesign in general. For people who make tons of changes to their shield settings (e.g., if default setting is “block all cookies” which is then adjusted for “worthy” sites), it quickly becomes so convoluted that it’s impossible to understand what’s going on.
Also, the very basic structure of the UI is not intuitive. E.g.,
What does it mean if some entry in the whitelist says “embedded on xyz.com”?
What exactly does “Always clear cookies when windows are closed” do? Which window needs to be closed for the cookies to be cleared? All windows? Just the window that the site is in? Just the tab even? Does it imply that cookies are automatically allowed until the window is closed? Very ambiguous.
What happens if I add a site to “clear when window is closed” but also to the “blocklist” / “whitelist”? Are the lists mutually exclusive? UI doesn’t explain it.
Which cookies are allowed when it says “Including third-party cookies on this site” and on what (sub-)domains?
Which wildcards are permissible in URL strings (besides the [*.]) vs. what just breaks the rule?
Etc., etc., etc… it is very convoluted. What doesn’t make it easier is that besides the Shield UI, I can also block/allow cookies in the standard Chrome UI (by clicking the “Lock” icon left to the URL). How is that different? What’s the interplay with Shield?
Google built total brainfuck, probably on purpose, and Brave should try to clean it up. There’s no way more than 0.25% of users understand what exactly their settings do.
