Please Make Brave Refuse to Resolve .zip Domains

Ever since Google let people buy .zip TLDs, bad actors have been using them to take over websites, with one example being a malicious .zip TLD being used to temporarily steal fanfiction.net’s domain.

For the security of all Brave Browser users, please make Brave Browser refuse to resolve .zip domains.

Brave as a Browser can’t do that… if the DNS resolves the address, then Brave can’t stop it. It would be bad for Brave to start censoring based on FUD or fairy tales or only because there are some bad actors that manage them, like then why is Brave allowing .com or .xyz if so many malicious sites have them?

Anyway for that, use the adblocker, that’s all Brave team can do, make rules that can block malicious sites and trackers just like they have always done it with any site and tracker.

You can create it yourself, use Regex, so you can easily specify what you want.
For example you can use a rule like this /^https?:\/\/(www.)?[0-9a-zA-Z]{0,}\.(zip)/$document and it should only block domains that have zip, at least in my quick tests, of course I don’t have any idea if there are something special about zip domains besides being .zip, but it can be improved by you.

But you should report sites to Easylist or uBlock so they can improve their lists, and add the malicious websites to the list to be blocked as any other domain.

While .zip TLDs don’t necessarily open up new attack vectors, they’re certainly going to aid attackers and catch people out.

For example, the below link looks like a genuine Github link, however it would have nothing to do with Github – it would be a domain owned by an attacker and lead to a malicious file. Virtually nobody is going to pay much attention to the @ symbol or that the forward slashes between the https:// and @ are not forward slashes, but similar looking unicode characters.

https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1271.zip

It’s a dumb idea. It’s a shame DNS recursive resolvers didn’t just agree to outright reject the TLD and return NXDOMAIN for all .zip DNS requests.

Brave as a browser can absolutely do this. There are already extensions on the google web store that achieve this.

It doesn’t even need to be an outright block, just a warning on resolving .zip domains like so (taken from one of said extensions) with an option to switch off/whitelist certain websites:
image

Technically yes. But Brave is not a regulatory agency or authority. They have no right to block a domain TLD. They can block URLs though, if they are part of black lists.
What is asked in this post is non-sense. Although there are malicious websites, there are also many legit websites using the same TLD.

The agencies approving the use of TLDs are the only authority able to deny or allow these domain names.

Off the bat they immediately have this negative connotation so people will avoid them
Most organisations are probably going to block them due to the risk so companies aren’t going to use them

No Brave is not a “regulatory agency or authority” but people trust Brave to keep their browsing habits safe and private.
You have no issue with Brave blocking all cookies and ads, despite them not being a “regulatory agency or authority”; but by your own argument, only the ad regulatory bodies and lawmakers should be “authorised” to do that.

Brave, touting itself as the “Secure, Fast, & Private” Web Browser, arguably has a duty to its users to warn and protect its users against the risk of zip domains - and again, have the option to turn off or whitelist if someone genuinely does need to regularly access any legitimate .zip domain.

Please show me a legitimate .zip website, and I can provide the countless reports of .zip domains already being used in phishing campaigns.

@SamPhoenix

I am sorry, but maybe you should learn how to read.

Just like rodrige said, the point of my post is not Brave can’t do that, OBVIOUSLY they can, they can add features and do anything they want simple as blocking domains, just like they can resolve .onion and ifps and web3 and all that crap… I mean… are you for real? do you think you are the smart person who just made an account and we a just some dumb users who need your wisdom? I don’t, but apparently you need to comprehend before replying, especially if you are going to quote me.

The point of my post is that Brave, the TEAM, doesn’t have to build a feature and start blocking domains from being resolved based on just having a .zip at the end, because not all domains will be used for malicious purposes, I don’t care if there are 1 or 2 good .zip domains, Brave can’t just block ALL domains because they will block good ones, even if it is 1 or 2.

This is a Feature Request, which seems you don’t seem to understand, but my post was pretty much answering how the feature to block websites is already built in and it is called Brave Adblocker, because just like today, people can just use the Adblocker like it is used today to block websites with the $document feature or by using ||example.domain^ and modify websites, inject JS and do a lot of stuff inside a website with just the ‘adblockers’ because adblockers are more than just blocking and allowing connections and applying display: none !important to html elements.

The ones who have to start blocking malicious .zip domains are the same ones that block malicious domains today, which are Filter lists maintainers.
Brave already uses Easylist, uBlock lists, Peter Lowe’s, URLhaus Malicious URL Blocklist… if there is bad domain, then it should be blocked by them, because it is something that will affect everyone not just Brave, so it is obvious someone maintaining those lists will add the malicious domains, just like they do today.

Brave also has the Brave lists, but they are used for Brave specific reasons and this is a matter of everyone, that’s why I didn’t include them.

Of course, the user, by using the adblocker can do a lot of things, and by using regex, they can block all zip domains easily without affecting normal zip downloads as proved by my answer to PCD.
So people don’t need to wait for list maintainers to cover all grounds, people can do it themselves…

That’s the whole point of my post, I am not the one who wait for developers to hold my hand and give me a feature if I can do it myself, like in this case, just writing a regex rule for custom adblocker rules which are just basic knowledge.

Also Brave adblocker will be able to be used in Android versions of Brave, not just Desktop like using a pointless extension would do. iOS can also block these domains, but custom rules can’t be applied so only filter lists can be used, which means Brave can still use them but as long as filter maintainers do it.

Plus, Brave adblocker is even faster than those extensions you are showing the screenshot pointlessly, or even to extensions like uBlock brave is 95% faster applying rules.
The extension you showed an screenshot will use more memory than necessary for something Brave can already do.

Get it? This is about how Brave can already do it, not about Brave shouldn’t do it, so I don’t know what is the point of your comments, install and extension like the normal grandma or soyboy or do it yourself with a custom regex rules like a chad.
That’s your choice, it will be the same, the difference is memory usage and Android and all that.

But Brave doesn’t have to built a feature for something it already has, so it’s the job of filter lists maintainers, which you clearly don’t seem to understand.

That’s why I said people have to report the malicious sites, trackers, ads, cookie notices etc etc, that’s because FanboyNZ works for Brave, he also maintains Easylist and Fanboy lists, and has influence around so he talks to uBlock people as well if necessary.
But he will make the necessary adjustments if needed, when needed, instead of just thinking blocking everything is the best approach because you said it every .zip should be blocked.
That’s now how the internet should be doing things like that and less Brave as a company.

@PDC
Thanks for the example.

Yeah, the problem in that case is because of the encoded URLs, the real URL that will be parsed by the browser is

https://github.com%E2%88%95kubernetes%E2%88%95kubernetes%E2%88%95archive%E2%88%95refs%E2%88%95tags%E2%88%[email protected]/
So a rule like this:

/^https?:\/\/(www.)?.*((%[A-Fa-f0-9]{2})+[^a-zA-Z0-9-+]+|[^\u0000-\u007F]+.).*(\.zip\/)$/$document

well, that blocks it, but I don’t know how perfect it is, for example I tested downloading https://www.xyplorer.com/download/xyplorer_full.zip and it works, but blocks the one you gave, of course I am finding the %E2%88 or whatever encoded url is present with a url that finishes with .zip/ since that’s the only way the URL will be parsed and to avoid for example problems with https://yandex.ru/search/?text=%40%40+.zip

Of course that will block all .zip domains, which might not be good in some future where not all .zip is done for malicious purposes.

But like I said, it can be easily done by Brave’s adblocker or Adguard or uBlock, so eventually lists will be improved by them (they don’t have to be done by Brave) to protect anyone just like they try to do today by blocking thousands of domains that way.

Maybe you should learn how to read instead of making ridiculous statements and acting like a condescending pos.

The people who are most susceptible to these attacks are those who are unaware, and not going to through a filter list manually using regex to filter it out.

Maybe if you read my comment, you would’ve seen where I was talking about implementing it as a new feature, not as an extension to adblock, instead to warn users who may have accidentally clicked a zip link, allowing them to continue if it’s legitimate; not outright block it, because the vast majority of zip domains are being used for phishing

Oh and don’t bother replying if you’re going to act like an asshat because I won’t justify it with another response.