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

snowbound commented 3 years ago

Don't forget about this other cookie deletion issue on Exit of Brave that still does not work properly https://github.com/brave/brave-browser/issues/9085 you have to resort to scorch earth and delete all cookies.

User198263321 commented 3 years ago

If Google is ditching cookies for FLoC then Brave should be Ditching FLoC WHILE making sure that cookie management is still functional. @snowbound

User198263321 commented 3 years ago

The fact that this is labeled as P2 is giving me some hope now. It still seems to be in the P3 backlog though... Probably just not being worked on at the moment :/

snowbound commented 3 years ago

@Michael82548 Well as you can see by my original bug report on google.com cookie that it was reported well over a year ago and only after I battled w the browser and Brave people in Brave community.

drstevens commented 3 years ago

The accounts.google.com and firebaseapp.com options are removed by turning off "Allow Google login buttons on third party sites"

allow_google

nisc commented 3 years ago

The accounts.google.com and firebaseapp.com options are removed by turning off "Allow Google login buttons on third party sites"

I mean this one makes sense to me. Could have been better explained from a UI perspective, but that's what you sign up for if you check this option.

I still have (a bit of) hope that this whole thing is just some UI confusion, not an actual security problem. Would be great to get an update from whoever is looking into this.

lllusion303 commented 3 years ago

The accounts.google.com and firebaseapp.com options are removed by turning off "Allow Google login buttons on third party sites"

Tnx. I wondered why they disappeared after I'd finished configuring settings in a new profile.

Tonev commented 3 years ago

I just updated to the latest stable version, and like I usually do, I went through the settings to check if something I don't want has appeared over there. Unfortunately, I can confirm the issue from the original post is still present.

I tried a workaround that I thought might work, as it made some sense to me. I tried adding a website from the list of websites that can always use cookies to the list of websites that can never use cookies, hoping my approach will remove the website from the first list, as I don't understand how a website can always use cookies and can never use cookies at the same time, but unfortunately the same website ended up in both lists, which is interesting.

Izofeu commented 3 years ago

I just updated to the latest stable version, and like I usually do, I went through the settings to check if something I don't want has appeared over there. Unfortunately, I can confirm the issue from the original post is still present.

I tried a workaround that I thought might work, as it made some sense to me. I tried adding a website from the list of websites that can always use cookies to the list of websites that can never use cookies, hoping my approach will remove the website from the first list, as I don't understand how a website can always use cookies and can never use cookies at the same time, but unfortunately the same website ended up in both lists, which is interesting.

https://github.com/brave/brave-browser/issues/12375#issuecomment-774566323

Tonev commented 3 years ago

Thank you for the trick!

I had to clear the browsing data for "Site and Shields Settings" in order to test another issue (https://github.com/brave/brave-browser/issues/15347), which in return cleared all websites from brave://settings/cookies so guess that approach is yet another temporary solution until developers commit a fix.

User198263321 commented 3 years ago

The accounts.google.com and firebaseapp.com options are removed by turning off "Allow Google login buttons on third party sites"

That actually worked for those two! Thank you!

I have also found that going to a website that is stuck and re-enabling the shields removes the cookie from the list

These are the only ones that remain say that they are embedded but I CANNOT remove those even if I do re-enable the shields. However, if I do end up going to those websites and disabling the shields, the icon for me changes to a reddit icon :\

There is probably a reason for this but I cannot find it because the UI is impossible to get hints from. Hence it taking this long to pin this problem down in the first place

User198263321 commented 3 years ago

Shields disabled on the embedded site

Shields enabled on the embedded site

I can't remove this one and I have NO INFO on what is preventing it from being removed. Brave's features probably weren't integrated well with the actual chromium backend so I cannot easily find the cause of this issue

I don't know if this is the same cookie or if it is switching between the two

The shield settings look default. I have no idea what the cause of this is.

User198263321 commented 3 years ago

Does brave store settings in the cookie? Is that why its getting added to that cookie list? That's confusing because when it is added to that list, the actual cookie is leaked when 3rd party cookies are enabled.

TLDR to this entire thing: Disabling shields on a website allows any website to read the cookie even if 3rd party cookies are enabled. This is leaking cookies and it is a security risk

One way to protect yourself would to be to re-enable shields every time you leave the website

This only affects SOME cookies. I have no idea what other brave settings could be blocking the deletion of cookies (Because it's not telling me), but this is NOT a good way to store settings in a browser if that is what it is doing, because its leaking website's cookies that seem to have certain brave features enabled/disabled

User198263321 commented 3 years ago

The fix for this would be to NOT store brave parameters in cookie settings (If that is causing the issue) so they don't leak or cause trouble! Fixing this issue would solve all of this if the cookies don't leak and abide by the 3rd party cookie setting!

User198263321 commented 3 years ago

https://github.com/brave/brave-browser/issues/12375#issuecomment-732533171

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!

Just realized that someone mentioned this already. Its also a solution on Microsoft Windows

Only to some cookies. Not all.

This has been mentioned 6 months ago

User198263321 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.

I have tried that with every value that had "myaccount.google.com" but they stayed.

https://github.com/brave/brave-browser/issues/12375#issuecomment-792388962 ^ This is probably the issue I am experiencing and it's very frustrating.

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.

I have tried that with every value that had "myaccount.google.com" but they stayed.

#12375 (comment) ^ This is probably the issue I am experiencing and it's very frustrating.

Does it say "Including third party cookies on this site" or does it say "embedded on "? If the latter then you need to delete both the normal site and the embedded on site. Make sure you do this while your browser is closed too (check task manager, by default chromium browsers can stay open in background if there is something running in them).

rebron commented 3 years ago

I've filed a meta issue #16127 as there's a few related issues with cookie settings and shields. This particular issue has morphed into a couple different use cases and I don't want to dupe this issue out to https://github.com/brave/brave-browser/issues/11772 and #8842 as there's good discussions here for the workarounds.

We are looking at this now and anticipate a fix in the next couple months. The meta issue has our punch list.

nisc commented 3 years ago

We are looking at this now and anticipate a fix in the next couple months. The meta issue has our punch list.

Hello and thank you for prioritizing this. If you expect the fix to still take a few months from now, it would be helpful to have some statement/synthesis from the dev team on what risks users are exposing themselves to by using the current version, and which measures are needed to mitigate those risks.

KevinSource0 commented 3 years ago

This workaround helps https://github.com/brave/brave-browser/issues/12375#issuecomment-848770755.

The accounts.google.com and firebaseapp.com options are removed by turning off "Allow Google login buttons on third party sites"

However, for a privacy focused browser, why cookies from privacy hogging companies(google/facebook etc.) are enabled by default? At least if this cookies is not deletable for some reason, instead of failing silently, the browser should inform user why this is happening and direct user to the right place.

snowbound commented 3 years ago

Another cookie deletion issue with Brave was solved for me by using a third party extension after 14+ months https://github.com/brave/brave-browser/issues/9085#issuecomment-864297911

RealDavidoff commented 3 years ago

23 June 2021: I confirm the issue told by the OP still exists in Brave browser, unfortunately.

The first two are apps I use, and Brave offers 3dot options. The last two I don't even know how they got there, and they have only the delete button (good) but it doesn't do a thing.

This issue existed ever since I installed Brave, but I didn't have time to report it sooner.

When you are at it, PLEASE make SITE-SPECIFIC COOKIE DELETION a click of a button! It's not "Advanced", it's no need to scroll forever, it's no need for any hurdle at all: It's the most essential function of any browser for conscious net citizens.

And because, other than this, I like Brave and WOULD continue using it. But not getting rid of site specific cookies AT WILL annoys me massively.

Thanks for reading :)

pitsi commented 3 years ago

Serious question. Am I the only one that has NO google related sites under there? All FOUR sites I have there are mentioned in issue #15122, if anyone wants to have a look.

Cautious-C commented 3 years ago

When you say NOT google related..Do you mean it is not a Google domain name? I suspect some of mine were google affiliated organisations, even if only using Google ad services...

pitsi commented 3 years ago

You can check all 4 sites I have there on the other issue report, I even have screenshots. They are xda-developers, no-ip, a page I run locally on a different pc and a site that I do not want to mention publically. None of the 4 is related to google.

nisc commented 3 years ago

Any update from the devs on this? At least a plan? Or an assessment of what this is? Sigh.

Cautious-C commented 3 years ago

Looks like one of my comments never appeared... If you set Block all cookies AND Clear cookies and site data when you quit Brave. Then restart. It will delete all the entries. At least it worked for me!

User198263321 commented 3 years ago

Looks like one of my comments never appeared... If you set Block all cookies AND Clear cookies and site data when you quit Brave. Then restart. It will delete all the entries. At least it worked for me!

Many users would not want to do that. it's also not reassuring that the same issue could arise at seemingly any given moment... or just never touch brave sheilds?

User198263321 commented 3 years ago

Status for me as of Version 1.27.102 Chromium: 91.0.4472.124 (Official Build) beta (64-bit)

snowbound commented 3 years ago

@Michael82548 That may be related to https://github.com/brave/brave-browser/issues/16127 which appears to be queued up to be fixed. When exactly it will be fixed is blowing in the wind. Hopefully fixing that bug also fixes https://github.com/brave/brave-browser/issues/9085#issuecomment-864297911 which I have been battling since March 2020 and which I had to resort to an extension to work around.

@nisc My frustration level with Brave at times has been off the scale especially when some of the issues/shortcomings don't occur in other Chromium browsers.

rebron commented 3 years ago

@nisc and @snowbound To be clear with process, when issues are filed we do our best to get the most information to be able define the issue, get it to a reproducible state, narrow it down, and work for a fix. We look at duplicates and related issues, we look at available workarounds which may help some users for the time being and we hope for additional comments that help shape a fix.

When a particular git issue turns into a conversation that belongs in a community forum and calls to fix it now or fix it yesterday, or go with Edge or Firefox or whatever browser -- in other words conversations that don't solve the problem, we will file the issue elsewhere and address the problem there. We have the meta issue filed, we have several developers looking at all these issues, and we're moving to address this issue and those in the meta one. Cookie related issues are complex ones.

For further feedback not related to this issue, I invite folks to https://community.brave.com/ Comments, sentiments, feedback we take to heart. We're in this to be the best browser possible. If you believe differently, please share that on our community forum. We like to keep git issues at a tactical level - define the issue, gather supporting info, the actual fix, and verification of the fix.

We'll keep this github issue open for progress and notification purposes.

snowbound commented 3 years ago

@rebron Understand what you are saying. I have to admit that I got more meaningful responsive feedback for issues that I have had with Brave over the years, by posting about issues here on Github than I have on Brave Community. One reason why I rarely go to Brave Community anymore other than responding to watched threads of mine.

Hence my frustrations were already high when I posted my bug report back in 2020 on the cookie issue.

nisc commented 3 years ago

@nisc and @snowbound To be clear with process, when issues are filed we do our best to get the most information to be able define the issue, get it to a reproducible state, narrow it down, and work for a fix. We look at duplicates and related issues, we look at available workarounds which may help some users for the time being and we hope for additional comments that help shape a fix.

This issue has been open since October 2020.... that was 9 months ago. People are CONCERNED when they see bugs like this, especially Brave users who are probably more privacy aware than the average WWW user.

In this thread there've been repeated asks for a quick status update. Why? Because people want to understand if they can keep using Brave until this is fixed. Have they been browsing with gaping vulnerabilities for almost a year? People are CONCERNED.

The lack of communication is not good.

EDIT: @rebron By the way, this has been discussed on the community forums, but I also didn't see any official statements there... https://community.brave.com/t/cant-remove-sites-in-settings-sites-that-can-always-use-cookies/176438

EDIT2: See this friendly ask for example: https://github.com/brave/brave-browser/issues/12375#issuecomment-850781256

tneo commented 3 years ago

This is stupid for a browser claiming to focus on privacy. Allow me to delete all cookies always unless I specify otherwise!

This issue is related to the shields implementation of Brave. When you visit the site that is mentioned in the list for which you can't remove the settings it turns out the shield was turned off. This in itself means that the shield is blocking functionality of a site. To remove the site settings turn the shield back on.

In itself that process is fine, the issue is that the shield in off-state should not result in me being unable to delete cookie settings through settings. Why does the shield implementation have such influence on behaviour in the browser settings?

When you track shield site specifics in a list (which I can manipulate) this should be sufficient. As Brave only needs to know when to turn off the shield as apparently the site was not working with the shield up. Record the URL and you're done, no need to not allow the user not to change settings for cookie. Or changing default Chromium behaviour.

bsclifton commented 3 years ago

Going to do some cleanup on comments here. @nisc thanks for sharing your opinion. @rebron is a Brave employee and has shared updates here. Let's keep conversation respectful and on-topic please

I've ran this issue by our security team and while it is important to fix, it hasn't bubbled up to be more important (priority-wise) than some of the other projects that our employees (the ones who could solve this issue) have been currently working on. Those folks are wrapping up projects and should soon be available. In May it was shared it would be in a few months. Two months later, we're just a few weeks away from a developer jumping in

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

Label for Android added 👍

bridiver commented 3 years ago

The fundamental issue here is that shield cookie settings are generated because they are a combination of cookie settings and the shields up/down state for the site. Because of that, they can't be stored the same way that regular chromium cookie settings are stored and that complicates things when it comes to the chromium content settings UI, particularly in the case of "block 3p" because that cannot be expressed as a single content setting in chromium. Things become even more complicated if you set a cookie override in shields and in the chromium UI for the same site. This has not been a high priority issue because most people just use shield settings. We kept this UI so advanced users could add custom rules, but the UI was only designed to handle chromium cookie settings and work needs to be done to correctly handle shields generated cookie settings as well.

nisc commented 3 years ago

@nisc thanks for sharing your opinion.

@bsclifton Never a problem, and thank you for the clean-up. Glad to see we're getting a bit of traction here. Happier bird now.

@bridiver most people just use shield settings

What do you suggest for the annoying people who always gotta try all the knobs and buttons? Would it all be worry-free if we only used the shield settings and never touched the Chrome cookie UI?

Is it safe to use the "advanced" shield settings?

For context, I just checked and I have 143 pages (Page-Down key presses) of entries under brave://settings/cookies?search=cookies just in my primary Brave profile. FYI, and don't worry, I didn't press the button 142 times — instead I counted the first page and then looked of the number of mentions of "embedded on" and "including third party cookies" to extrapolate).

I then tried deleting a sample of ~10 entries randomly but 100% of clicks did nothing.

So, are just the below 3 Chrome UI screens not to be touched to ensure defined behavior? Anything else that shouldn't be touched?

One:

Two:

Three:

Uj947nXmRqV2nRaWshKtHzTvckUUpD commented 3 years ago

Issue still present on Version 1.27.111 Chromium: 92.0.4515.131 (Official Build) (64-bit) - Windows

lazymonkey2 commented 3 years ago

to delete sites from this list I tried loading each site and enabling again brave shields. this way they are removed from the "Sites that can always use cookies" list. however the is a site that has changed domain: when I load that site it is redirected, and I have no chance to enable shields for it. is there no other way to remove it? maybe editing some config file, or some sqlite db?

Izofeu commented 3 years ago

to delete sites from this list I tried loading each site and enabling again brave shields. this way they are removed from the "Sites that can always use cookies" list. however the is a site that has changed domain: when I load that site it is redirected, and I have no chance to enable shields for it. is there no other way to remove it? maybe editing some config file, or some sqlite db?

https://github.com/brave/brave-browser/issues/12375#issuecomment-774566323

pitsi commented 3 years ago

The forementioned workaround worked for me, but for 3 of my 4 sites that are there. The one that failed is xda-developers and that is because it instantly redirects me from xda-developers.com to www.xda-developers.com so brave takes it as a different site and it shows the shields as enabled. If anyone has any idea, please comment.

---edit Same thing for my local address. The shields are enabled for 192.168.1.5 and for any page under that, like 192.168.1.5/ariang or 192.168.1.5:9090, but the entry under sites that can always use cookies remains.

Izofeu commented 3 years ago

The forementioned workaround worked for me, but for 3 of my 4 sites that are there. The one that failed is xda-developers and that is because it instantly redirects me from xda-developers.com to www.xda-developers.com so brave takes it as a different site and it shows the shields as enabled. If anyone has any idea, please comment.

---edit Same thing for my local address. The shields are enabled for 192.168.1.5 and for any page under that, like 192.168.1.5/ariang or 192.168.1.5:9090, but the entry under sites that can always use cookies remains.

https://github.com/brave/brave-browser/issues/12375#issuecomment-907785988 I literally wrote what you need to do above your comment and you failed to read that.

pitsi commented 3 years ago

@Izofeu I did read that, as I read any comment posted here. The file you mention, which is on ~/.config/BraveSoftware/Brave-Browser/Default/Preferences here in linux, is a SINGLE line 100kb file of endless text. Even if I open it on an editor like geany (equivalent to notepad++ for windows), searching for that specific line (let alone deleting it) is a hard task. So I avoided it and tried the method @tortino described, which worked fairly well for me.

Uj947nXmRqV2nRaWshKtHzTvckUUpD commented 3 years ago

On Windows, I managed to remove the offending sites by editing the file 'Preferences' under: C:\Users\\AppData\Local\BraveSoftware\Brave-Browser\User Data\Profile 1

Below, i composed a JSON with only the keys from the Prefernces JSON that I emptied. Most of them I emptied just for the sake of having a fresh profile since I do not rely so much on brave's shields, but rather use a combination of extensions such as umatrix and ublock.

The values that contained sites present in "Sites that can always use cookies" were: braveShields, referrers and shieldsCookies. I didn't test with various keys combinations, but my guess is that shieldsCookies might be enough.

To easily edit the JSON, use notepad++ with JSTool plugin (JSFormat feature), press ctrl+alt+m to format the JSON, then alt+0 to fold all keys and then unfold top parent '{' to see the keys.


{
    "gaia_cookie": {},
    "custom_handlers": {
        "ignored_protocol_handlers": []
    },
    "partition": {
        "per_host_zoom_levels": {
            "x": {}
        }
    },
    "profile": {
        "content_settings": {
            "exceptions": {
                "automatic_downloads": {},
                "braveShields": {},
                "client_hints": {},
                "cosmeticFiltering": {
                    "*,*": {
                        "expiration": "0",
                        "last_modified": "xxxxxxxxxxxxxxx",
                        "model": 0,
                        "setting": 2
                    },
                    "*,https://firstparty": {
                        "expiration": "0",
                        "last_modified": "xxxxxxxxxxxxxxxxx",
                        "model": 0,
                        "setting": 2
                    }
                },
                "fingerprintingV2": {
                    "*,*": {
                        "expiration": "0",
                        "last_modified": "xxxxxxxxxxxxxxxxx",
                        "model": 0,
                        "setting": 2
                    }
                },
                "httpUpgradableResources": {},
                "media_engagement": {},
                "notifications": {},
                "referrers": {
                    "*,*": {
                        "expiration": "0",
                        "last_modified": "xxxxxxxxxxxxxxxxx",
                        "model": 0,
                        "setting": 2
                    }
                },
                "shieldsAds": {
                    "*,*": {
                        "expiration": "0",
                        "last_modified": "xxxxxxxxxxxxxxxxx",
                        "model": 0,
                        "setting": 2
                    }
                },
                "shieldsCookies": {
                    "*,*": {
                        "expiration": "0",
                        "last_modified": "xxxxxxxxxxxxxxxxx",
                        "model": 0,
                        "setting": 2
                    },
                    "*,https://firstparty": {
                        "expiration": "0",
                        "last_modified": "xxxxxxxxxxxxxxxxx",
                        "model": 0,
                        "setting": 1
                    }
                },
                "site_engagement": {},
                "sound": {},
                "trackers": {
                    "*,*": {
                        "expiration": "0",
                        "last_modified": "xxxxxxxxxxxxxxxxx",
                        "model": 0,
                        "setting": 2
                    }
                }
            }
        }
    },
    "web_apps": {
        "daily_metrics": {}
    }
}

reddyshyam commented 3 years ago

I am a new user to Brave and so far loving it but when I look at how the bugs are squashed and the amount of time it takes in general, I will say I am very much disappointed. For an issue to be addressed if it takes an year or more, don't know how the users will be loyal.

sosinovitch commented 3 years ago

I'm having the same issue with Version 1.30.87 Chromium: 94.0.4606.71 (Official Build) (x86_64) on my Mac OS 10.15.7.

bitshark commented 2 years ago

to delete sites from this list I tried loading each site and enabling again brave shields. this way they are removed from the "Sites that can always use cookies" list. however the is a site that has changed domain: when I load that site it is redirected, and I have no chance to enable shields for it. is there no other way to remove it? maybe editing some config file, or some sqlite db?

This is the exact same issue that I have. Under "Customized Behaviors" / "Sites that can always use cookies" I cannot delete any of the entries without a workaround. Some entries (whose domains have changed) cannot be deleted at all.

EDIT: For clarification... (1) Prior to doing anything I cleared all cookies, top to bottom , (2) A number of entries remained in the list of "sites that could always use cookies", (3) These entries could not be deleted by hitting the trash can button (which did nothing), and (4) These entries were all for sites on which shields had been disabled manually at one time or another.

As other users have mentioned, and which I also replicate, it turns out the site entries which cannot be deleted are sites for which I had Brave Shields down.

I am seeing this issue on Windows 10 x64 , Brave Version 1.31.91 Chromium: 95.0.4638.69 (Official Build) (64-bit).

The only way I've managed to delete the entries is to manually go to each site in the list in a new tab, turn shields back on for each site one by one, and then they spontaneously disappear from the Brave cookie configuration list (perhaps because I have clear cookies on exit enabled?). If the target domain has changed in the meantime (for example, if the domain now has an HTTP 301 or 302 redirect to somewhere new, the entry cannot be deleted from the list.

As an example, I have an entry I cannot delete for https://[*.].firebaseapp.com . However, this domain has been bought or reconfigured by Google. When I go to the site to disable Brave Shields, I get an HTTP 301 to https://firebase.google.com/products/hosting/ , and the entry cannot be deleted since there is no longer a site at firebaseapp.com for which I can disable Brave Shields.

Hope this helps.

pitsi commented 2 years ago

Since this behavior is directly related to the deactivation of shields, is there a setting that shows the sites for which the user has disabled brave's shields?

Dylan-86 commented 2 years ago

Still an open issue.

We need a way to simply remove the cookies, also for websites for which we had to turn the shields down.

Sometimes I turn the shields down for a website just because it won't work with shields up, but then I won't need that website again in my life. It's annoying that I can't easily delete the cookies of that specific website after one year.

bridiver commented 2 years ago

Still an open issue.

We need a way to simply remove the cookies, also for websites for which we had to turn the shields down.

Sometimes I turn the shields down for a website just because it won't work with shields up, but then I won't need that website again in my life. It's annoying that I can't easily delete the cookies of that specific website after one year.

I fully agree this is a problem, but it's a complicated problem because 3rd party blocking for a specific site can't be expressed as a single chromium content setting and they are not persisted as chromium cookie settings, they are generated at runtime from shield settings. I think what we probably need is a separate section for shield settings that is independent from chromium cookie settings. It's a trade off because that could be confusing to some users, but seems like the best solution. wdyt @petemill ? We had something like this is the old browser-laptop settings

brave / brave-browser