Description of the issue:
Custom filters created in private window persist after all private windows are closed.
Steps to Reproduce:
Set shields to “Aggressively block trackers & ads” (Settings > Shields > Trackers & ads blocking = Aggressive"
Add custom filter list. The issue seems to require the URL to be content filtered. (Settings > Shields > Content Filtering > Add custom filter lists > paste “https://pastebin.com/raw/G8Numdy6” > Add, which will content filter “reddit.com” as a test)
Developer Mode in Content Filtering can be disabled or enabled. (Settings > Shields > Content Filtering > Developer mode)
Look at “Create custom filters” to see if there are any rules for “reddit.com”. There should not be. (Settings > Shields > Content Filtering > Create custom filters)
Custom filters created in private browsing should be persistent when private windows are closed.
I do not want to completely restore a stack of custom filters, every time I use Private Browsing - which is always. (The only times that I do not use Private Browsing, is when I test Brave Browser issues reported by Brave Community members.)
All the OP has to do, is NOT choose to check/enable the:
You could set the custom filters outside private browsing if you want them to always exist inside private browsing.
There are other changes in private browsing that do not persist, like turning off shields for a website. This setting only lasts while in private browsing. After leaving private browsing, it gets reverted to the original setting. I believe the expectation is anything happening inside private browsing should not make permanent changes to settings that would reveal your browsing history. I think this is pretty obvious and is already the default behavior of brave’s private browsing in other areas.
Here brave shows that this setting is temporarily set for private browsing only. The same thing could be done for custom filters that originate while in a private window for that session. To have settings persist between private browsing sessions is what the global settings are for.
I am aware not checking the "Don’t warn me about this site again” would resolve it, but for your private browsing session maybe you don’t want it to pop up multiple times, so it would make sense someone would check it, not thinking it is now writing a permanent rule on their computer in regards to this specific site. Which I would assume most people who are using private browsing are not wanting to happen. Knowing this now, yes I can avoid it, but I was caught off guard to see custom filters of sites visited in private browsing. I would think others would not want this default behavior.
It seems to clearly go against the whole concept of private browsing. At least it should have a warning that says “checking this box will make a permanent rule outside of private browsing”
@youwouldliketoknow any changes to brave://flags or to custom content filters will actually persist across profiles and be included in private. I agree that it might be nice to have toggles for it. Or at the very least I think it shouldn’t persist across profiles.
The second part is being said because I was originally going to tell you to use a guest profile or create a second profile to avoid it, but I tested first and was reminder it’s not an option.
What I am going to do is tag in @Mattches on this to see if he can offer any insight as to whether this is something that can be improved on or if he has any potential solutions to your specific issue.
So the “bad” behavior here is that any information that occurs during Private browsing should not be saved or reflected anywhere else in the browser once Private browsing has ended.
I’ll inform @fanboynz and some privacy folks about this.
@Saoiray In regards to your first statement, changes to brave://flags should persist and be included in private, which is not quite the issue. Just wanted to be clear with what the issue is: the custom content filters are being modified permanently while browsing in private when you check "Don’t warn me about this site again”.
Basically this in a private window:
@youwouldliketoknow I see what you mean. Skimming through, I initially thought the issue was that custom content filters were carrying over into private windows. But after looking closer and considering what you just said, I see it’s more about new rules being created based on changes.
It still connects to what I mentioned earlier. Custom filters are stored in a way that applies across all profiles. In your case, you’re creating rules to block things but then overriding them, which requires another rule to counteract the restriction. Since these custom rules are stored permanently and affect everything, they persist as you’ve noticed.
The issue seems niche, but it highlights the broader concern about the lack of temporary overrides or Shields-related settings. Because everything gets logged in the permanent custom filter area, it can cause unintended effects.
On the bright side, Mattches is looking into it and discussing it with the privacy team.
Regarding disabling list/rules in private window mode. We have discussed the previously internally.
Would be hard to implement, and if a user does want lists enabled in private window mode would be constantly re-enabling. So more tooling would be needed here.
We’re just mirroring uBO+private window mode, which when enabled acts the same in normal window mode. uBO doesn’t change lists or rules based on normal/private.
No clear privacy issue, since all these lists and scriptlets are user added modified.
Probably the only helpful change would be webcompat breakage test, if a user added a bad list or rule. Thus switching to private window mode to test this.
Testing can also be done manually in normal window mode. I have yet to see reported breakage that would require switching to private window mode as test.
Most switch to private window mode fixes, are extension (bad) interaction related. Since most users don’t enable “Work in private window mode”. Easy way to pick out bad extensions.
We’re still discussing this internally, it’s not the final decision. Things may change or not.
@fanboynz I don’t know if you are responding to the original issue or the follow up posts where people were incorrectly making this about the ability to toggle on/off content filters, which has nothing to do with the original issue.
This is the core issue. The changes to the custom filter I am trying to point out are not added manually by the user. The custom filters in question are added because the user checked “Don’t warn me about this site again” while in a private window. I may be the only one, but I did not think that while in a private window if I checked that box it would automatically create a custom filter rule that would persist outside the private session. Thus, revealing web history. Everyone should know that checking that box is basically the same as writing a custom filter rule that will exist outside of the private session, which to me was not clear.
I could see this being an issue if someone is opted into some content filter lists, but while in a private window they visit one of those filtered sites and when prompted, check that box. Then their custom filters outside of the private session would be populated with all the website they visited while in the private window where they checked that box.
The website might issue a set of pixel tests, in order to detect if an element is being hidden.
But in general, it seems, that a determined effort to observe and/or penetrate a computing device, would be required to find settings of a software application.
And a greater determination would be required, to decrypt settings that are secure.
