Security - DNS Blacklists and Whitelists

Brave Feature Requests Desktop Requests
1

For fine grained management of internet domains and subdomains to block or allow access to. Domain names and resource indicators / locators.

Use of SOcial Linked Data SOLID for single data source to configure all browsers. This would make the solution OS independent.

Might be used in tandem with hosts file 127.0.0.1 loopback. The hosts file localhost loopback is a non optimal solution to the issue of control of domains for inclusion in a blacklist and has no whitelist capability. It is also not fined grained in relation to subdomains. It is also restricted to machines/devices with a hosts file.

SOLID data pods may be a digital service govs offer in the near future. Particularly in relation to use case re digital security for citizens. Another use case of Health data, medical records, especially for countries like UK with a national health provider like the NHS. Provision might be outsourced.

DNS and URL. For URL example while an entire site might be blocked with a domain name in the blacklist a part of the site may be allowed in the whitelist. Would depend on precedence which might be of resources listed in a whitelist over domains listed in a blacklist. The details of precedence might well be different and be the remit of the working group not this post.

So while the domain www.foo.com might be banned the URL resource to a subset of the domain may be allowed www.foo.com/bha .

One mechanism is to parse the URL to be sent in the HTTP/S request before the request is sent. If the domain and/or resource on the blacklist is detected then the request is not sent.

A client side status/error, like the server side status/error, might then be displayed to the user on the browser client. A request status code, like a response status code, say HTTP 403 Forbidden or HTTP 451 Unavailable for Legal Reasons. The legal reason in this use case for example the duty of care of a parent or carer to a child.

This would likely require a minor change to the HTTP/S specification for client side (browser) request status codes which may also include error codes. Although in this case not an error but client , that is user/admin, forbidden status code.

Remembering the application resides in two places server side and client side.

Helps to rebalance the internet experience with client side control of applications to balance server side control of applications.

Work with the IETF and W3C on a proof of concept for revision to HTTP specification. Implement in Brave with brave://flags/#brave-http-request-status

Rationale
Manage social media
Manage clickbait
Manage imbedded media
Parental control of domains/subdomains for children
CSO enterprise control of domains/subdomains

Requirement
Use of wild cards.
Use of regular expressions.
User interface by SOLID application.
Ubiquitous standard minimum support from all browsers.

Standards Organisations
IETF
W3C

References
Normative
RFC8259, JSON, IETF, https://datatracker.ietf.org/doc/html/rfc8259
RDF, W3C, https://www.w3.org/RDF/
<todo; source normative references, >

Informative
RFC5782, DNS Blocklists an Whitelists, IETF, https://datatracker.ietf.org/doc/rfc5782/
RFC5782, DNS Blocklists an Whitelists, IETF, https://www.rfc-editor.org/rfc/rfc5782
DNS AttrLeaf Changes:
RFC8553, Fixing Specifications That Use Underscored Node Names, IETF, https://www.rfc-editor.org/rfc/rfc5518
Clarifications to the DNS Specification, IETF, https://www.rfc-editor.org/rfc/rfc2181
JSON, org, https://www.json.org/json-en.html
JSON, Wikipedia, https://en.wikipedia.org/wiki/JSON
HTTP 403 Forbidden, Wikipedia, https://en.wikipedia.org/wiki/HTTP_403
HTTP 451 Unavailable for Legal Reasons, https://en.wikipedia.org/wiki/HTTP_451

<todo; other standards and specifications to source, >

2

Brave is not the one resolving domains, so I don’t know where you got the idea Brave should add this, especially when you can either set up your own DNS server like pihole, adguard, there are others that can be used to whitelist and blacklist domains like dnscrypt and make it easy with dnscrypt-proxy or pay for one like NextDNS (which can be used for free too) and many others.

I don’t understand why you even mention URL and being able to allow some parts of the domain, while blocking just one portion, that’s not how DNS works and you are mixing two things, one that is already done by Brave (technically) and the other, DNS which if you block foo[.]com, you will block foo[.]com/bha as well and that’s it.

Anyway, Brave uses the system DNS service to resolve IPs, and all you need is to go to brave://settings/security and change the DNS provider and it would be bypassed because Brave shouldn’t just lock the browser to use one single DNS server, they must let you choose even if you think for ‘fine grained management’ they apparently should have their own local DNS server and then don’t let you change it even if it fails.

But like I said, Brave already does what it does about Blocking Network requests, if you go to Devtools → Network tab you can block anything about it, you use Brave’s adblock to manage what your browser connects or doesn’t connect to.

Of course there will always be a resolving of a IP because browsers don’t block the ‘main’ document, in Brave, by default you get the warning screen, so nothing gets resolved, it is when people click proceed, when the connection to the page is made.
So, in my opinion, it is already achievable in Brave, and Brave team only needs to add a policy or flag or a policy to control a flag that will not allow a person to proceed after the warning page.

For example, recently they added group policies to restrict the disable of Shields as you can see here https://github.com/brave/brave-browser/issues/25394
And that means you can restrict users in your organization from being able to toggle shields off as a workaround, so more policies would be better rather than asking for a feature that while it seems it belongs to a Browser, it shouldn’t, the browser shouldn’t be the one resolving the domains.

So I would rather if Brave spent time adding more flags and policies to control those flags that could, for example, add a policy so the warning screen won’t have a proceed button, policies that would let you add your own custom filters or/and custom lists, just like group policies for Windows Firewall works today (which you can technically use for blocking IPs too).

But for example using your foo[.]com as an example.

if you use:
||foo.com^$document You will be blocking only the document, so that means Brave will tell you it might be dangerous website and you must proceed with caution, that’s it, nothing else gets blocked when hitting proceed.

But if you do
||foo.com^ you will be blocking everything from that domain, scripts, images, css, and only plain text of a website will be shown, as far as I know, no 3p will be blocked.

and if you do
*$domain=foo.com you will block everything, but not the document so you will not get the warning message

It would do the same *$csp=default-src,domain=foo.com does, the only difference is CSP only will be shown in console, and not elements will shown blocked in Brave shields panel.

Of course you may say, these methods are not too great, and once a person clicks proceed in the warning screen, they can still see something rendered like text even if everything else can get blocked.

But then, in that case you could easily do another rule foo.com##* which would inject display: none !important; to every element in the page, that means you are not just blocking every network element but also hiding every element in a page, rendering completely useless.

Would you still say 1 connection (to the main document) is that bad? why is it important to block it? unless you don’t want anyone to know you even tried to attempt to connect to X websites, then I don’t see the need to block everything completely.

Like you can easily do what you suggested with Brave Shields, only block things in foo[.]com but allow in foo[.]com/bha, it can be achieved by using $document and/or CSP (because CSP is easy and great to use in so many situations like this):

foo.com$document, @@||foo.com/bha$document, *$csp=default-src,domain=foo.com and then @@foo.com/bha$csp

I think you want to add more complexity to an already complex browser for stuff that technically shouldn’t belong to Brave, especially when people can just load a portable Browser from their USB and access the websites you think you are blocking, that’s why a system wide DNS service will be what you are looking for, not a browser one, which is exactly what I said about using Brave adblocker for doing what you want, just like Brave already does by adding anti-malware and anti-trackers and other important lists by default that fight malicious websites.

Like I saw today they are adding anti-chat and anti-porn lists to the regional list (the ones you get here brave://settings/shields/filters) so that’s why I said, it would be better if Brave added more policies to fine control what can the user turn off or not, so you could turn those lists off as an admin for your organization or add any other custom list or filters and then don’t let anyone turn them off or override them (if done properly), like Firewall policies work today in Windows.
And then you can use all the rules I mentioned and maybe more because adblock is really deep in what it can do, and Brave still needs to support many features uBlock has that are interesting like denyallow or $all.

So, while I understand your feature request, I think, in my opinion, you are wanting the browser to do too much, in that case, add unnecessary bloat for no reason, when today you can already achieve that, and for now, you can restrict users from turning shields off for websites blocked.
Of course for now, it is not perfect solution because the only workaround to add lists that user can’t toggle off is to modify the source code to add your own custom filter lists, which they would not be able to turn off like custom lists or regional lists can be done.

3

Many thanks for all the information re Brave features that currently exit that relate to this topic.

The point with regard to separation of concern and Brave DNS feature request is very well made. This was not the intention of the post. A miscommunication with respect to the title of the topic.

Part of the rationale was in regard to usability, ease of use, for non technical users like parents.

Another was the use of SOLID as a mechanism for storing browser settings. So these would be universally applied to any browser not just Brave. See related post here

In that regard a Brave feature with SOLID capability perhaps. A topic for a further feature request.

4

On the hosts file as tool for black list.

hosts file technique to make accessing social media and traditional media and news sites of various types impossible. For example very marked advocacy journalism that does not conform to journalistic impartiality to fake news and misinformation and disinformation. Experiments in user attention and engagement as click bait.

So if a hyperlink is clicked on it does not display the page. The following message is displayed instead.

This site can’t be reached www.foo.com refused to connect.

Try:

Checking the connection

Checking the proxy and the firewall

ERR_CONNECTION_REFUSED

Sometimes this message is displayed

This site can’t be reached

The web page at https://www.kni.co.uk/en-gb might be temporarily down or it may have moved permanently to a new web address.

ERR_FAILED

Or this one

This site can’t be reached zha.com’s DNS address could not be found. Diagnosing the problem.
DNS_PROBE_POSSIBLE

Not investigated what qualifies one response message or other. Or if there are other possible response messages. It is may be outlined in the HTTP protocol specification from IETF or Brave documentation implementation for Brave HTTP/HTTPS handing.

The performance of different browsers varies. The Brave browser though always eventually works. That is it accepts the URL content as blocked.

It is the psychological gaming of people by social media and traditional media companies that make it likely a user will select a given link to view. That is why it is important the user have a means to block content from sources they do not want to be gamed by. Game theory.

The pattern is whatever appears as the domain name after the protocol part of the URL. For example HTTP:// or HTTPS:// . For example different ways in which the domain name might be formatted.

https://www.foo.com/
https://zha.com/
https://m.nee.com/
https://www.kni.co.uk/

hosts file entry example

127.0.0.1 www.foo.com
127.0.0.1 zha.com
127.0.0.1 m.nee.com
127.0.0.1 www.kni.co.uk

The hosts file can be found in the following folder in MS windows
C:\Windows\System32\drivers\etc

The hosts file must be edited with administrator privileges. Right click the Notepad app and select Run as administrator. In Notepad go to File>Open and navigate to the directory above System32\drivers\etc . To be able to see and select the file go to file type drop down next to the File Name field select All Files (.) . Edit file and save.

But this is not an optimal solution. It is a work around until such time as a better option is presented.

See discussion here

Also here