Cannot delete sites from "Sites that can always use cookies"

[aperullo]

Description

Sites cannot be deleted from the "always allow cookies" list, only added

Steps to Reproduce

1. Add a site to "Sites that can always use cookies"
2. Try to click the "garbage" icon to delete a site
3. Nothing will happen

Actual result:

Nothing occurs and the site remains

Expected result:

The site should be deleted

Reproduces how often:

Consistent

Brave version (brave://version info)

1.16.68 Chromium: 86.0.4240.111 (Official Build) (64-bit) b8c36128a06ebad76af51591bfec980224db5522-refs/branch-heads/4240@{#1290}

OS

Windows 10 64-bit

[rebron]

cc: @jumde Related to the google login exceptions?

[jumde]

@aperullo - Are you still seeing this if Allow Google login buttons on third party sites is disabled in brave://settings/socialBlocking

[aperullo]

@jumde Yeah, the issue persists when that setting is toggled off or on. Even after restarting the browser. One of the stuck sites is almost certainly not using Google login either, as its a microsoft domain. Please let me know how else I can help.

[dentistformyeye]

Seems to be a duplicate of #11259

[optimistiCli]

Same behaviour on Linux 1.16.68 x86_64

[elonj]

Same behaviour on Mac 1.16.72 Chromium: 86.0.4240.183 (Official Build) (x86_64)

[ghost]

Similar issue here Version 1.16.72 Chromium: 86.0.4240.183 (Offizieller Build) (64-Bit). There are three entries in the "Sites that can always use cookies" section that cannot be removed. They are also the only entries with a (not functioning) garbage can icon instead of a three dot menu. Even worse, they allow third party cookies which I have never done. Whenever I manually add entries I either used the cookies menu in the menu that pops up when you click the lock icon to the left of the url bar (which has no way of enabling all third party cookies) or use the "add" button on the cookies page and make sure the check box for third party cookies is unchecked. The settings are also active and not just some visual bug, I checked by closing and opening the browser again and found that there are still cookies of those websites saved even though the default setting of my browser is to delete all cookies.

[elonj]

Same behaviour on Version 1.17.73 Chromium: 87.0.4280.67 (Official Build) (64-bit)

[rotatingangles]

SOLUTION on Brave Browser Linux.
Go to website in question and toggle the "Shields" to "UP" as opposed to "DOWN"
Try it on github, you'll see it added or removed.
This is one hell of a way for this to operate.
Brave, give the user some control over this, make it more user friendly, and absolutely make it more easily removable.
The default DOWN should be temporary, maybe clear cookies when windows are closed.
There should be an UP, DOWN, etc., maybe a WTF as I can't believe this polar thinking!

[bsclifton]

@rotatingangles it's definitely not intentional! Thanks for sharing a work-around

cc: @rebron @karenkliu

[snowbound]

This is still happening on Version 1.18.78 Chromium: 87.0.4280.141 (Official Build) (64-bit) and Version 1.19.77 Chromium: 87.0.4280.101 (Official Build) beta (64-bit) on Windows10 x64 20H2.

As well if you add google.com to the list of sites under Always clear cookies when windows are closed the various subcookies are not being deleted. If they were then one would be logged out of Gmail and you are not. When Brave is started after being closed you are remained logged into Gmail. None of the sub cookies that are part of Google.com are being deleted. In particular, the SID subcookie that is under Google.com is NOT being deleted when Brave is shutdown. If it was then when one went to Gmail.com after closing and restarting Brave then you would find that you would be logged out.

This deletion of Google.com sub cookies works fine in MS Edge Chromium and Google Chrome.

[alexfrederiksen]

This is still happening for me as well on Arch Linux 5.10.7-arch1-1 with brave-bin 1:1.19.86-1. It happens in the "always allow" and "never allow" sections.

[Izofeu]

Still a problem in Version 1.19.92 Chromium: 88.0.4324.152 (Official Build) (64-bit)
Edit: I found a workaround to delete those entries - go to \AppData\Local\BraveSoftware\Brave-Browser\User Data\Default. Open file called Preferences and delete all site entries that you want to be gone. For example, if you want to delete a cookie permission from site "xxx.com", delete the following from the file (make sure the browser is closed):
"xxx.com,*":{"expiration":"0","last_modified":"<somerandomnumbers>","model":0,"setting":2},
Edit2: For sites that say "embedded on xxx.com" you might need to delete additional lines that look similar to the one above.

[snowbound]

I am also tagging this issue #9085 as it too is cookie deletion related but on exit of the browser.

[gloist]

@aperullo - Are you still seeing this if Allow Google login buttons on third party sites is disabled in brave://settings/socialBlocking

didn't work.

[rosolam]

I have sites that I cannot delete in both Sites that can always use cookies and Sites that can never use cookies and interestingly I have one stuck in both that is preventing me from using the website in Brave. Any way to adjust these settings from outside of brave?

[Izofeu]

I have sites that I cannot delete in both Sites that can always use cookies and Sites that can never use cookies and interestingly I have one stuck in both that is preventing me from using the website in Brave. Any way to adjust these settings from outside of brave?

Still a problem in Version 1.19.92 Chromium: 88.0.4324.152 (Official Build) (64-bit)
Edit: I found a workaround to delete those entries - go to \AppData\Local\BraveSoftware\Brave-Browser\User Data\Default. Open file called Preferences and delete all site entries that you want to be gone. For example, if you want to delete a cookie permission from site "xxx.com", delete the following from the file (make sure the browser is closed):
"xxx.com,*":{"expiration":"0","last_modified":"<somerandomnumbers>","model":0,"setting":2},
Edit2: For sites that say "embedded on xxx.com" you might need to delete additional lines that look similar to the one above.

[nisc]

Hey guys, can confirm that this been a problem on Mac OS and Windows for a while now. Here is the thread in the BraveCommunity Forums and my (inconvenient) workaround:

https://community.brave.com/t/cant-remove-sites-in-settings-sites-that-can-always-use-cookies/176438/13?u=nisc

I think this is WAY more critical than the P3 rating that it was given by @rebron.

As I describe there, the Sync Chain can be a big part of the problem. Even after deleting the entries from the Preferences file, Brave would auto-restore the settings immediately. I had to create a new Sync Chain AND clean up the Preferences file to resolve the issue. (Let's see for how long.)

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.

Good luck.

[thejoshuahenry]

How is this issue STILL not resolved? This is embarrassing, Brave, and it's not worth sticking with your browser over.

[snowbound]

Have given up on reporting issues with Brave myself. It gets frustrating after spending countless hours testing and providing feedback and hearing crickets. Really tiring shouting into the wind.

[bridiver]

At this point afaik the only cookie settings that cannot be deleted are the ones that are created by disabling shields on a site or the pref to allow google logins and that is by design. Deleting those settings would leave things in a confusing state where it looks like shields is down, but it's only partially down because 3p cookies are still blocked. The fix here is to show those settings as coming from another source (similar to settings created by extensions). To remove those settings you need to navigate to the site and re-enable shields. Nightly and beta have added shields to brave://settings to make it easier to remove those overrides and it will land in release soon.

[bridiver]

also the shields generated cookie settings should not show up as editable in the cookies UI (similar to how extension created settings works)

[bridiver]

If anyone has a case where settings that were not adding by disabling shields or the google login pref cannot be deleted then that's something we need to look into, but otherwise I think this issue can be closed and a new issue opened up for properly displaying those settings as non-editable

[snowbound]

Well, I posted this issue regarding Google-specific cookie deletion almost 2 years ago #9085. I haven't tried the normal deletion in Brave because I found a 3rd party extension that works to delete the cookie. Frankly, I am tired/frustrated spending hours testing and posting feedback regarding Brave issues and hearing crickets. I have resigned myself to putting up with the current quirks in Brave until my patience wears out and I switch browsers.

[Rob-Garner]

I have the same issue on the newest version of Brave. I looked at the HTML code associated with the trash can symbol. There is no code to execute, so clicking the icon does nothing. Not very trustworthy of the Brave team to be allowing this.

[bridiver]

I have the same issue on the newest version of Brave. I looked at the HTML code associated with the trash can symbol. There is no code to execute, so clicking the icon does nothing. Not very trustworthy of the Brave team to be allowing this.

@Rob-Garner I'm not sure what you're looking at, but the problem is definitely not that code does not execute when you click on the trashcan. The problem is that it doesn't always correctly delete cookie settings that were generated by shields. I'm also not sure what's untrustworthy about this because they are your settings that you selected and they can be changed in the shields panel.

[KioriSun]

I had this issue in v1.47.171 used the method of disabling google login in brave://settings/socialBlocking and it worked.

[DutchPete]

Today is 2023-03-19, 2½ years after this was 1^st reported here, and this issue still HAS NOT BEEN RESOLVED !!!!! I am on macOS.

This is a privacy issue of a browser that claims to be focused on privacy. Yeah, sure 🤣
This is beyond a joke, and all the workarounds that are mentioned should not be necessary, the Brave devs should have picked this up immediately, not some day when convenient, FFS.

If it is only done when convenient, then stop marketing yourself as a privacy focused browser: you can't have your cake and eat it.

[pitsi]

Tbh, it has been some months since I gave up on this issue. As mentioned above, the issue is somehow related to the shields.
I did what I mentioned above for those 3 sites and for the 4th one I simply deleted it from the "shields down" category under brave://settings/content/braveShields and it disappeared from "sites that can always use cookies".
I also removed any sites that were under the "shields up" category in there. As it seems, disabling and reenabling shields for one adds it in there.

[rocketphewl]

This is still an issue three plus years later.. as far as I'm concerned this is a data breach allowing cookies to track me and no way to stop it easily.. Chrome and/or Brave browsers are frauds...

[bridiver]

This is still an issue three plus years later.. as far as I'm concerned this is a data breach allowing cookies to track me and no way to stop it easily.. Chrome and/or Brave browsers are frauds...

Site overrides that were created through the shields UI can be changed through the shields UI, but overrides like "block third-party cookies" cannot be expressed as a single setting in the chromium cookie settings UI so you will see two rules (one for block and one for allow) that have slightly different values to block third party cookies while still allowing first party cookies. If you want to change those settings you need to do it through the shields UI, but you also need to understand what you're looking at in the chromium cookie settings because one rule does not necessarily tell the whole story. Using only the chromium cookie settings UI, most people would not be able to figure out how to add a site override to block 3p cookies on only that site and most people would also not understand why there is an "allow all" rule for the site when looking at a block 3p setting added by shields. If I set to brave.com to "allow all" and then back to "block cross-site", I end up with this

and

and "block cross-site cookies on brave.com" can only be expressed with both of those settings

The issue here is that shields cookie settings cannot be always be managed through the chromium cookie settings UI, not that cookie settings can't be changed. The other issue is that once you set a shields cookie override for a site, you can change it (through shields UI), but setting it back to the default doesn't remove the site override, it just makes the override the same as the default setting. I say "cannot always" because we don't know exactly what sequence of events results in people not being able to delete the individual settings added by shields. I just deleted the brave.com override in the chromium cookie settings by deleting both settings and it worked fine. I'm not doubting that some people cannot remove them, but getting into that state is not easily reproducible.

I agree this is confusing for users who are using the chromium cookie settings instead of the shields UI and tbh some of this is my fault because I wanted to keep the chromium cookie settings UI when other people wanted to just remove it and only manage cookie settings through shields. In the end I think they were right because the other issue is that adding cookie settings directly to the chromium cookie settings UI (which can only be removed through the chromium cookie settings UI) can result in settings that can't be expressed in the options provided by shields (allow, block 3p and block all).

[User198263321]

I know I probably forgot what I did with some sites, but sometimes I literally just start a completely new instance or guest mode because I have no clue what I did to break a site from working properly. It might still relate to this.

[drstevens]

Site overrides that were created through the shields UI can be changed through the shields UI

@bridiver The issue with the Shields UI is that you need to be on the site to change the settings. This is sometimes very difficult because those domains or hostnames have since setup 301 or 308 redirects making it nearly impossible to change settings for the site through the Shields UI. This is how I ended up following this issue actually. There was more than one site which I had added exceptions for in the past that were very difficult if not impossible to use Shields UI on at some point in the future.

[lazymonkey2]

@drstevens Agree. I'm in the same situation with redirected sites.

[bridiver]

@bridiver The issue with the Shields UI is that you need to be on the site to change the settings. This is sometimes very difficult because those domains or hostnames have since setup 301 or 308 redirects making it nearly impossible to change settings for the site through the Shields UI. This is how I ended up following this issue actually. There was more than one site which I had added exceptions for in the past that were very difficult if not impossible to use Shields UI on at some point in the future.

Understood and this is one of the reasons why I wanted to keep the chromium cookie settings UI, but the interaction between the two can be complicated and we need to come up with a better solution.

Another issue that complicates the situation is that shields cookie settings do not get persisted as chromium cookie settings. They are dynamically added/removed as chromium cookie settings at runtime so they can be disabled when shields is down without losing the shields up setting. If you disable shields for a site the rules will disappear from the chromium cookie settings, but they are only disabled, not removed.

I think the solution here is likely going to be replacing the chromium cookie settings UI with a shields cookie settings UI, but then there's an issue with how to handle existing chromium cookie settings that were not added through shields. The only really useful thing you could do with chromium cookie settings that can't be done with shields cookie settings is block or allow a third party site and on all first party domains, but I don't think that's really a meaningful setting with ephemeral storage/third party storage partitioning. Cc @pes10k

[bridiver]

So after more discussion the tentative plan is to make two changes:

1. Setting a site override to the default value will remove the override. This seems pretty straightforward and obvious, but there were some reasons why we previously wanted the ability to maintain the override if the default was changed, but this seems like an edge case and not worth the added complexity. This solves the issue of confusing settings showing up in cookies that people are sometimes misinterpreting.
2. Completely remove the ability to manually add chromium cookie settings and replace it with a page to manage shields cookie settings. This will allow us to properly represent shield cookie rules like block cross-site and will also eliminate any issues with chromium cookie settings that change the effective cookie setting to be something other than what shields says it is. As mentioned above the edge cases that can be added in chromium cookie settings but don't have an analog in shields cookie settings aren't really meaningful or useful with ephemeral/third-party storage partitioning. Any existing chromium cookie settings that map to shields settings will be migrated and those that can't map to shields will be dropped. This will simplify things and provide a consistent view of cookie settings that always aligns exactly with the shields drop-down

[drstevens]

@bridiver Thanks for the update. Love the browser and appreciate all that the Brave team does.
❤️

[edelstone]

I found something that worked for me on the MacOS Brave browser (at least regarding deleting the sites).

The same list of sites that is present in Privacy and security > Cookies and other site data > Sites that can always use cookies (brave://settings/cookies) is also present in Privacy and security > Site and Shields Settings > Shields status > Shields Down (brave://settings/content/braveShields).

The latter is where I was able to successfully remove sites. After doing so, all the sites were removed from both areas.

Hope that helps; sorry if this comment is superfluous or doesn't work for others.

[j-seeley]

I had this issue in v1.47.171 used the method of disabling google login in brave://settings/socialBlocking and it worked.

This fixed it for me... Go to brave://settings/socialBlocking and TOGGLE OFF all 4.

[ShivanKaul]

Is this still an issue now that the Google Login button is gone from social settings (and there is no dedicated social settings page)?

[kbulgrien]

Yes, I still cannot delete sites from, for example, Sites allowed to use third-party cookies.

[bridiver]

Yes, I still cannot delete sites from, for example, Sites allowed to use third-party cookies.

The chromium cookie interface has been going through a lot of strange changes recently and we're thinking we just need to dump the upstream UI completely so we can handle these correctly. Chromium cookie settings are now split between cookies and site data and it's very confusing imo.

[asheroto]

Also having this issue. No console messages exist when clicking the trashcan icon.

I have tried the brave://settings/socialBlocking and brave://settings/content/braveShields fixes above to no avail.