Please raise a Class 0 criticality defect with immediate effect.
https://en.wikipedia.org/wiki/Defect_criticality
Brave or Chromium or both are non conformant with IETF and IANA.
There are multiple issues which all likely need separate but related defects raised.
Internal host loop back address is likely the most pressing.
The testing above would seem to indicate strongly that despite a domain name being assigned an 127 < any > loopback address Brave forwards the domain name for resolution by a regional DNS or its own DNS for resolution.
As specified by IETF 1122
Brave and/or Chromium appear to be favouring Internet Protocols in the Application Layer like DNS above lower level Internet Protocols in the Internet Layer like IP (v4 v6) .
https://en.wikipedia.org/wiki/Internet_Protocol
The browser is acting as a de facto Virtual Network Interface.
In the ISO model the respective layers are Application and Network.
https://en.wikipedia.org/wiki/OSI_model
The lower level Internet/Network layer should take precedence over the higher level Application layer.
The mastheads in the images of the news outlets cbsnews and inews in the thread above indicates an http server associated with the domain name has returned a default HTTP response to its own bogon filtering. This poses at minimum a security risk as the host that allocated the loopback address did not want the domain to be contacted. Ignoring the loopback address and applying DNS resolution and forwarding an HTTP request is a breach of trust.
Further the response message is clearly not true, that is it is false. Both the domain which sent the response and the host which received the response are clearly ‘online’ and there is an ‘internet connection’. A response from the domain to a request the host was intent should never be sent in the first place. This message will confuse an inexperienced or naïve user. The message, in these two cases from a news organisation, is ‘fake news’. Although it is likely the intent was good to provide a user friendly message.
The default response from other news organisations throws an exception that is a little more honest. The connection was refused, probably due to bogon filtering, by the domain. Again to note no request was sought and no response expected. Therefore also providing confusion to an inexperienced or naïve user.
It will be interesting to see if these sites owners opt for free advertising with a mast head display or report the issue for resolution to stay in line with, conformant to, IETF specifications and IANA guidance. That is they should not be receiving these bogus logon bogon messages in the first place. However communication in regard to this topic would likely be request to the domains ISP from internal networking staff. This is amongst other things a separation of concern issue. Network admins would not expect the Application layer to highjack Internet/Network layer internet protocols as this is a network security issue.
It is likely at the domain side this is lost in low level logging and there is little or no reporting up lines of responsibility. Network management at this level for a large corporate is likely outsourced in part to an IT Services Provider. Particularly for webhosting. For an SME it would likely not even register. Reporting would therefore likely not even reach service owner managers or if it did appear seemingly so low level as to not bother reporting to the enterprise architecture practice let alone the CIO or CSO or COO and there would be no board visibility of the issue.
Yet it should. As loopbacks might have been set as one means adhere to internal policy or external regulation. Loopbacks might also have been used to stop communication with competitors from insiders,. See also regulation like MiFID II on separation between business functions. Digital hygiene issues. And so on.
To be clear, the internal loopback defect is a back door for communication which had been presumed shut.
protocol://domain = address
/resource = postbox, dropbox
? query string = payload, message,
and for the HTTP protocol HTTP header information.
In IoT parlance communication which might include inter alia; H2H, H2M, M2H, M2M.
0 - Affects critical data or functionality and leaves users with no workaround
Class 0
Stability, Reliability and Availability
Security
Legal (Liability, ADA, Copyright)
Testability
Storage (data loss/corruption)
Please advise on the timeline for the resolution of this defect.