Still NOT working!!! Pleas fix this ASAP! i thought it would be somekind of “virus” or bad extention.
I experience this same issue.
I use version 1.20.103 Chromium: 88.0.4324.152 (Official Build) (64-bit) on Windows 10
I have the same issue.
Have the same bug, this is super weird and doesn’t create trust. Windows and Mac, latest stable release. See below.
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?
I think that this is important
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
(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.
@BRAVE fix this ASAP!!! This is inexcusable.
Where is the preferences folder?
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?).
@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
THIS actually worked for me:
Check the the site and shields settings box when clearing browsing data!!! Viola!!!
Worked!!! I didn’t know that…
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.
Unfortunately, I had previously tried this and it did not work.
After looking more into it, it’s a problem with the “Brave Shields”. Whenever you turn Shields off, the websites will be added to the whitelist.
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.
This worked for me (at least for now), based on @dmbutler’s fix: Select “Block all cookies” (under Additional Settings > Privacy and security).
Then the cookies that were previously showing up all disappeared (I didn’t even need to delete them one by one).
As of now, the setting has remained that way even after I changed the Privacy and security settings back to “Block third-party cookies”.
I hope this helps, and thanks @dmbutler . But yeah, disappointed that this was an issue to begin with.
This is the best suggestion I’ve seen for this incredibly confusing and annoying problem. I was left with 2 that I couldn’t delete. I never enabled a Synch Chain though, and couldn’t find the aforementioned Properties file on my system.
So I think there must be at least one other way undeleteable entries can get into this list. But just taking this suggestion got rid of most of it so thanks.
Obvious Bug annoying a lot of people currently PLEASE FIX !!
Solution. This setting only occurs when you take shields down for any site. All you need to do to remove the site from the list is to go to it and put shields up. That’s it. It does mean that the site will not work properly, that’s why you had to take the shields off, but all you need to do is take them down then put them back up.