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, >