Block trackers & ads option blocks websockets on localhost

[levicki]

This should be enough to explain what the problem is:

The website needs to connect to ws://127.0.0.1:1025/feedback (a local instance of Visual Studio) in order to work.

Why would Aggressively block trackers & ads in Shields settings block 127.0.0.1?

Is it because of feedback being on some blocklist?

[levicki]

I changed the title because I tested also with plain Block trackers & ads — it still blocks websockets which are needed for the site to work while not blocking a real tracker:

List of active filter lists:

After disabling all filter lists websocket is still blocked:

Please fix.

[levicki]

@rebron Please take a look at this.

[levicki]

In order to reproduce this you need to have Visual Studio installed and be signed into a Microsoft account in it, and then try to submit feedback from within Visual Studio which will launch the browser as shown in the image.

EDIT: Another possible issue with this blocking would be if you needed to use some e-signing USB token or smart card middleware on your PC which also uses websockets on localhost to communicate with an e-government website.

[diracdeltas]

cc @ryanbr

[levicki]

@Emi-Emi-Emi Thanks for the detailed response.

It is one thing to block the 3rd party domains and I totally agree with that even if it's pain in the ass to figure which ones are required for the 1st party site to work.

However, it is totally another thing to indiscriminately block localhost.

This line with an exception right under the block proves me right.

Blocking localhost is opening a can of worms. It will break developer tools like Visual Studio (and not just bug reporting feedback but probably also debugging web sites and services you develop), e-signing apps made by governments and banks running on locahost that need to sign online documents like tax submittal forms or approve transactions using a physical USB token and keys stored in it, etc.

It may stop some attempts at fingerprinting or even malware, but unless Brave is willing to spend time curating ever-growing list of exceptions as soon as they are reported (and let's be honest most people won't be able to figure out why their stuff isn't working much less where and how to report it) there should be an off switch somewhere in the UI for this kind of filtering.

On a side note, it would be useful if we could see in the console which rule from which list blocked something on the page like we can in uBlock Origin.

[levicki]

@Emi-Emi-Emi Main issue for me is this default hidden filtering which cannot be turned off. Yes, I can whitelist it now, but to do that I need to first know it is there which I obviously didn't.

For example, Brave was (maybe still is, not sure if the change was implemented) proxying extension downloads from Chrome Web Store and if you didn't know that and blocked their updater URL for any reason you would get a cryptic error when trying to download any extension. Worse yet, the request wasn't logged to the devtools so you had absolutely no way of knowing what's going on.

So yes, protection is good as long as it is transparent.

This 127.0.0.1 blocking isn't transparent, and please don't tell me "you could have looked at the Brave adblock extension code, found the hidden list it uses, read and understood the rules, and then just whitelisted what you need" because while I with my programming knowledge could have certainly wasted time to do it, most Brave users wouldn't be able to do it and shouldn't be expected to do it.

TL;DR — This list should be visible in the UI and it should be possible to enable / disable it for troubleshooting and to see its contents from the browser. Same goes for other lists which you can enable — why not add a link to the name so they open in a new window when you click on them? That way you can see the list source instead of having to Google them by name and guess which variant of each list is used.

[levicki]

@Emi-Emi-Emi

The problem is that the 'transparency' of the adblockers is the filters themselves, they are open for anyone to see.

That's simply not true, because this particular list is not visible in the user interface.

Think about this, do you trust every rule from Easylist or uAssets?

This is not a matter of trust at all, it's a matter of discoverability. Please don't change the subject.

Do you agree or disagree with that?

I fail to see how that is relevant to the discussion.

well, you can't just start questioning some rules but no others.

First, what I am questioning is the way this rule is tucked in a list which is not visible in the user interface and which can't be easily enabled / disabled when you need to check if it's the one causing issues.

Second, I am not questioning the rule — I am stating with confidence of a system administrator in a medium software company who was administering dozens of PCs in a domain for the last 15 years that this localhost rule will do more harm than good.

Finally, you can disagree with my viewpoint, but you can't tell me what I am allowed or not allowed to question.

So as you can see, there will be an endless argument about 'transparency' with adblocker rules and the hundred of list maintainers that exist today.

Again you are missing the point — the only transparency I am interested in is from the Brave itself. Brave adblocking list should be visible in the user interface so I can inspect it, and it should be possible to enable / disable this list just like any other list.

Again, the way to turn it off is custom adblock rules,

And again, that's only a viable option if you know which list is causing a problem. Since you cannot turn off the built-in Brave list and you can't open it from the user interface to check its rules because it is not exposed you can't know which rule is causing the problem for you.

That's the lack of transparency I am talking about, and it is totally pointless to argue against having an option to turn off the Brave adblocking list — the option should have been there to begin with.

I see no reason why Brave's adblocking list should have preferential treatment compared to all other lists. Same goes for both built-in adblocking extension and for the Brave Shields extension — they should be visible in the extensions page and it should be possible to fully disable both if I want to do so.

that's what makes Brave adblocker good, it gives you the custom adblocker rules and filters, and therefore you are able to turn off these rules you disagree with

Newsflash: uBlock Origin has had all those same options since forever and it is even more advanced than Brave adblocker. uBlock Origin is an extension and it is playing by the rules (you can install / uninstall / enable / disable it), and with Brave adblocker you can't do any of that because for a regular user it's an opaque black box built into the browser.

Brave could easily add an exception to visualstudio...

Brave could have as easily tested the default rules with a couple of popular sites, e-government and e-banking apps and developer tools and ensured there's no breakage instead of having to fix it by adding exceptions after the fact.

I don't see it as a priority, since there are real features Brave should support that are more important

Yeah, like installing not one but two VPN services on my PC without my informed consent which brings us back to the subject of transparency.

No transparency example:

• Browser gets updated and suddenly you have some VPN services and autorun entries you didn't have before and didn't ask for because Brave wants to sell you VPN access.

Transparency example:

• Browser gets updated and on next launch you get prompted whether you would like to sign up for VPN and if you accept services get installed, otherwise they don't get installed. Option is added to settings where you can sign up later which will install the services if you do.

No transparency example above is simply shady behavior which erodes trust of the user audience which Brave is trying to capture with their boasting about choices and privacy.

Same goes for:

• impossible to uninstall hidden extensions (Shields, built-in adblocker)
• invisible implicit adblocking lists which can't be disabled
• invisible proxying of requests for chrome web store downloads

would you rather a blank canvas you have to block everything yourself or a set of rules that you can whitelist or improve if necessary so you don't start from zero?

I am ok with having a default list — what I am not ok with is not being able to see it in the user interface and disable it if I choose so.

Your power to tell the adblocker what to do is there...

The thing is — I really don't want to waste time on that.

In this particular case Brave was between me and my work. I had to try submitting feedback several times while disabling lists one by one until I realized that I have to fully disable ad & tracker blocking in Shields settings for that site in order for it to work. I was not aware of the default list, I had no idea where Brave saves it, and I couldn't find the rule responsible for blocking the localhost just from looking at the dev tools console.

I not only wasted considerable time to investigate this (and finally relented and turned all protection off to be able to finish work making a cure worse than a disease in the process), but I also wasted additional time reporting the problem here with absolutely no effect so far, and now I am wasting even more time arguing with you about something that should be obvious to anyone who doesn't have an agenda.

Fix it, don't fix it, I don't care. There are other browsers out there and failing that I can always make a custom build based on either Chromium or Firefox. That way if I waste time at least I know why.

[ghost]

You have to understand that 140K rules, can't be 'transparent' someone will have the power with the adblocker to implement whatever they want because they think it is needed. So yes, it was relevant to the discussion, you agree or disagree adblockers injecting code like that? you agree or disagree blocking 127.0.0.1? it's obvious the reason for the question, you either agree with filter maintainers having the power or not. So I don't get 'what I don't get' from you, it's like playing 'dumb' because it doesn't help your case. The job of the adblock filters is a gray area, but the adblockers just do what they are told to do. Adding toggles million toggles for 140K rules because you might agree or disagree with some, it's not something to think about.

So it's obvious why I asked it and why I showed the example, because just like you don't agree with 127.0.0.1 being blocked as a third party connection in a random website, someone thinks uBlock.org shouldn't be blocked or manipulated by uBlock Origin team, just because it doesn't 'benefit' them.

Of course the most simple answer is: if you don't like it, you can switch adblocker or Browser, because this is the world of Browsers and Adblocking. You can easily use uBlock, turn Brave adblocker off and don't get these issues, you will get other issues, like Anti-Brave detection, but that's easily handled by uBlock by loading the scriptlet brave-fix in uBlock and done, ##+js(brave-fix) will apply to all websites, which is better than what Brave does since Brave doesn't allow generic scriptlet injections.

Anyway, you reported the issue, your issue got ignored, you had kind of a valid reason for a whitelist and nothing happened. My point will always be, what are you going to do? sit on the corner and complain about it or do something about it? I know most people would rather wait 2 years for a feature to appear in settings than hacking it and doing it themselves, but some stuff is like you spent more time typing the original issue, than @@||127.0.0.1 and done.

That's my point.

That's why I never report any issue with adblocker lists, and that's exactly why, not because I fix stuff myself, it is because reporting and waiting, is usually a pain in the butt, always a waste of time especially when I can fix it myself, and I don't need to beg some people that have the 'power' of the lists to do it, when I probably already make better rules than they will ever make, I have even done PRs ignored by them, so that's the point. I don't just make issues hoping for fixed, when I can make a fix I made it, but always to get ignored or an issue always to get ignored even if I give the solution, they only need to copy and paste my rules.

Anyway, it was still a mistake to write a comment in this issue like 99% of the time, people don't like learning and complain at me like if I had any power only because I am honest about things and know the reality of internet life and dealing with devs and all and filter maintainers and that's why I seriously hope when I close a gtihub account, I will never have to open a new one ever again, always regret it, and I get tired of trying to fix or even commenting like if I was getting paid or something.

Have a good day.