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

aperullo commented 3 years ago

Description

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

Steps to Reproduce

Add a site to "Sites that can always use cookies"
Try to click the "garbage" icon to delete a site
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 commented 3 years ago

cc: @jumde Related to the google login exceptions?

jumde commented 3 years ago

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

aperullo commented 3 years ago

@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 commented 3 years ago

Seems to be a duplicate of #11259

optimistiCli commented 3 years ago

Same behaviour on Linux 1.16.68 x86_64

elonj commented 3 years ago

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

ghost commented 3 years ago

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 commented 3 years ago

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

rotatingangles commented 3 years ago

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 commented 3 years ago

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

cc: @rebron @karenkliu

snowbound commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

I am also tagging this issue https://github.com/brave/brave-browser/issues/9085 as it too is cookie deletion related but on exit of the browser.

gloist commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

dentistformyeye commented 3 years ago

Okay I spent some time investigating this issue and I believe it’s a bug in the Brave Sync Chain mechanism.

I've visited the sync setup page (brave://settings/braveSync/setup) and have pressed some of the buttons on that page before, but I've never finished setting up a sync chain, so I'm unsure that the sync mechanism is the cause of this bug.

snowbound commented 3 years ago

First I want to apologize for the following post. It is a result of my frustration with Brave at times and bugs that only Brave seems to have amongst Chromium browsers that I have used. I will be doing some evaluation in the coming days on whether I will put up with these bugs in Brave in the hopes that they will eventually be solved.

For the past couple of days, I have switched to MS Edge Chromium on multiple Windows computers and on iOS. I have not experienced either this issue nor https://github.com/brave/brave-browser/issues/11183 nor https://github.com/brave/brave-browser/issues/9085.

Both Brave and MS Edge are chromium-based browsers. Only Brave uses a passphrase to allow a sync chain. With Brave even recreating a sync chain from scratch does not help solve any of these issues.

nisc commented 3 years ago

Okay I spent some time investigating this issue and I believe it’s a bug in the Brave Sync Chain mechanism.

I've visited the sync setup page (brave://settings/braveSync/setup) and have pressed some of the buttons on that page before, but I've never finished setting up a sync chain, so I'm unsure that the sync mechanism is the cause of this bug.

I also don't think that this is the cause of the funny cookie settings entries, but it is probably what makes them "Zombie Cookie" like after they first appear. Otherwise I could just clear my site settings and the funny entries should be gone.

Brave-Matt commented 3 years ago

@rebron can we get an update on where we're at with this issue?

User198263321 commented 3 years ago

Affects me as well. This can be a potential security risk if someone wants to prevent website cross tracking but can't because they can't remove permissions

User198263321 commented 3 years ago

I'm honestly surprised that brave also does not allow cookie exceptions for SPECIFIC websites (Using third party cookies). Not to apply globally like it normally does. This is extremely annoying. Except now, I can't even remove them. Found a GIF in this thread: https://community.brave.com/t/cant-remove-sites-in-settings-sites-that-can-always-use-cookies/176438

Izofeu commented 3 years ago

I'm honestly surprised that brave also does not allow cookie exceptions for SPECIFIC websites (Using third party cookies). Not to apply globally like it normally does. This is extremely annoying. Except now, I can't even remove them. Found a GIF in this thread: https://community.brave.com/t/cant-remove-sites-in-settings-sites-that-can-always-use-cookies/176438

Brave allows cookie exceptions for specific sites. If you want to allow 3rd party cookies on one site, change it in Brave Shield settings.

snowbound commented 3 years ago

Brave will not even delete specific cookies on the closing of the browser and has not done so for over a frustrating year https://github.com/brave/brave-browser/issues/9085 I have given up on these items ver getting fixed or Sync v2 ever working properly. Other Chromium based browsers do not have these issues and it is darn frustrating to hear excuses after excuses for a browser whose marketing spiel is security and privacy yet these types of issues remain unfixed.

I guess adding features and looking after BAT issues are more important to Brave.

Uj947nXmRqV2nRaWshKtHzTvckUUpD commented 3 years ago

Same for me on Version 1.23.75 Chromium: 90.0.4430.93 (Official Build) (64-bit)

User198263321 commented 3 years ago

I have Cross-site cookies blocked but it does not allow me to make exceptions for specific sites. Also, the chromium cookie settings override the Brave settings

nisc commented 3 years ago

Still the same problem in V1.23.75 and it's getting worse every day.

@rebron @jumde @Brave-Matt

User198263321 commented 3 years ago

This affects Android also (in sync with desktop (Windows))

The way it works on mobile is that you can block cookies that were previously allowed but when you delete blocked cookies, it moves it back to "allowed" and when you try to remove them from allowed, it does nothing.

User198263321 commented 3 years ago

Add OS/Android @Brave-Matt

yeldarb1983 commented 3 years ago

okay, just adding some stuff in the hopes of it being useful to tracking this down.

1) I've NEVER set up sync, nor do I intend to. I'm sure it's a fine feature if you want it, but it's really not that useful to me.

2) How are these sites being set to "always allow" in the first place? I've NEVER added a website to my whitelist, yet a dozen or so have exceptions, which tells me either there's some code in the browser itself that does it automatically, which should have an "always ask" option or some other mechanism(see next point)

3) I'm wondering if this isn't some bug in the code that certain companies have exploited to force their cookies to remain regardless of user interaction. It may even be present in other browsers based on chromium, but hidden from the user, and something that brave did just happened to make it visible to the user?

hoping this is useful.

drstevens commented 3 years ago

Changing brave settings through the lion icon once a page has rendered does appear to work in most cases for me. It's tedious though, and hard to do when the domain in question causes 302 redirects to other domains.

nisc commented 3 years ago

Unless you use Brave with very permissive default Shield cookie settings (cookies allowed or at least same-site cookies allowed), the domain-level exceptions site (brave://settings/cookies) will become unusably polluted with these zombie cookies very quickly. Not a good UX.

User198263321 commented 3 years ago

It looks like I can edit the cookie URL, then it saves, then when I try and delete it, it reverts back to the initial cookie. (Only while the cookie is visually blocked) and when I try the same while the zombie cookie is allowed, it just adds a new entry.

It is truly impossible for me to remove the cookie through the UI.

User198263321 commented 3 years ago

It just multiplies. I can delete these entries fine but not the zombie cookies

User198263321 commented 3 years ago

Clarifying, If I edit a zombie cookie that I moved to the "block" list, then it creates a new entry on the blocklist and moves the cookie back to the allow list

User198263321 commented 3 years ago

It looks like it is only visually in the block list. It is always in the allow list.

User198263321 commented 3 years ago

Brave allows cookie exceptions for specific sites. If you want to allow 3rd party cookies on one site, change it in Brave Shield settings.

BTW Brave's "Cross site cookies blocked" option in shields seems to do nothing when you are affected by this bug. (Assuming you have google accounts as a zombie cookie)

Test it yourself https://browserleaks.com/social

Its leaking for me and it also shows in the cookies menu despite cross site cookies being disabled

User198263321 commented 3 years ago

If you want to make a browser that blocks "Tracking" (Google), at least google chrome allows us to make these exceptions!

The only thing that I can POSSIBLY do right now is nuke my profile. Worst part about that is the fact that the bug isn't fixed so it will just continue happening again. I am sick of this.

User198263321 commented 3 years ago

I simply cannot recommend this browser due to this potential security issue that people probably won't even know about! This doesn't just affect "power users", this can affect anybody.

snowbound commented 3 years ago

If you use multiple Gmail accounts there is no easy way to force a logout of all accounts by simply closing the browser and deleting one cookie. You have to do a scorch earth deletion of all google.com cookies which will wipe out all configuration for YouTube and 2FA cookies that you want to keep. This has been a festering problem I have been battling with Brave for over a year now.

nisc commented 3 years ago

Brian in da house. Seems we're finally getting some attention here. Can we move this to P1 maybe?

User198263321 commented 3 years ago

Also add Android tag. It seems to affect android as well

pitsi commented 3 years ago

Same thing in 1.24.84 and 1.24.85.

lllusion303 commented 3 years ago

Confirmed bug in 1.24.86 Chromium: 90.0.4430.212 (Official Build) (arm64) on macOS 11.3.1. Cannot delete cookies from "Sites that can always use cookies". I've not allowed 99% of the sites listed under this heading.

Creating a new profile automatically places two cookies in the "always" list.

User198263321 commented 3 years ago

Confirmed bug in 1.24.86 Chromium: 90.0.4430.212 (Official Build) (arm64) on macOS 11.3.1. Cannot delete cookies from "Sites that can always use cookies". I've not allowed 99% of the sites listed under this heading.

Creating a new profile automatically places two cookies in the "always" list.

I also experience this issue. Version 1.26.34 Chromium: 91.0.4472.57 (Official Build) beta (64-bit)

I loaded some test websites with a new profile and whenever I allow cookies or change a shield setting in brave (Such as fingerprinting), some of these cookies are stuck now. I cannot remove them.

User198263321 commented 3 years ago

If you cannot remove sensitive cookies from the always allowed list, then it is literally a security flaw. Any website to access them, even if 3rd party cookies are enabled.

nisc commented 3 years ago

literally a security flaw.

This. I don't understand what the F is going on. This has been raised more than half a year ago, has a huge thread on their community forums, the team has been pinged many times by several concerned users.

But it's still a "P3" issue in Github and there is no communication from the team at all.

How can they not take this seriously? @bsclifton

nisc commented 3 years ago

But it's still a "P3" issue in Github and there is no communication from the team at all.

Label descriptions: P3 — The next thing for us to work on. It'll ride the trains. (454 open issues and pull requests) P2 — A bad problem. We might uplift this to the next planned release. (128 open issues and pull requests) P1 — A very extremely bad problem. We might push a hotfix for it. (4 open issues and pull requests)

🤣 🤣 🤣 It would not even make sense if this was NOT a privacy-oriented browser.

brave / brave-browser