Brave can uncloak domains that pretend to be somewhere else. See:
In Brave on Windows, brave://flags/#brave-adblock-cname-uncloaking is set to Default which is enabled. However, in Brave on Android, it is also set to Default but means disabled. I changed it to Enabled.
If Cname uncloaking is a good protection on Windows, why was it disabled on Android?
You do not understand the topic. Has nothing to do with z-positioning of windows (e.g., always-on-top). Read the linked article in my opening message. Also read up what is DNS (Domain Name Service), and what is a Cname record. Start here: https://en.wikipedia.org/wiki/CNAME_record.
It is enabled ONLY IF Ad blocking is set to āAggressiveā. If you use default, it is disabled.
Any way to know to what else āaggressiveā block mode is linked? Without details, the modes are vague hence nearly meaningless. Something more happens in aggressive mode, but what isnāt delineated.
At https://brave.com/shields/, standard/aggressive blocking level and Cname cloaking are mentioned separately, not dependently. This makes it appear the settings are independent. At https://brave.com/shields/, there is some mention in differences between standard and aggressive modes, but Cname cloaking is not mentioned. There is a link to https://brave.com/privacy-updates/8-grab-bag-2/, but that doesnāt mention Cname cloaking, either.
So, if I enable aggressive mode, the setting of brave://flags/#brave-adblock-cname-uncloaking is ignored in that regardless of its shown setting the Cname [de]cloaking is employed, anyway?
When I switch between standard and aggressive block modes, the brave://flags/#brave-adblock-cname-uncloaking setting does not change hinting aggressive mode and this setting are not linked hence independent.
In addition, in my opening message with the link to Braveās Cname cloaking feature, there is no mention it is linked to the standard/aggressive blocking mode. However, that article never mentions having to go into brave:flags to enable/disable Cname cloaking. I forget why I went into brave:flags looking for the Cname setting.
There is a warning that aggressive blocking mode can break some sites. I donāt see how Cname [de]cloaking would break a site. The other features of aggressive mode might break sites.
Ignore that user, itās just a bot. When youāve worked with LLMās as much as I have, you can spot an LLM a mile away, including one incorrectly configured (it never finished its output).
EDIT: I reported it for moderation since we donāt need LLMās here anyway.
But to your question as to how to tell what else aggressive changes, Iād like to know as well. I canāt find any public documentation on it, and for auditing purposes, feel this should be transparent.
In Brave for Windows, Shields ā Trackers & ads blocking is Standard. When I go to brave://flags/#brave-adblock-cname-uncloaking, it is āDefault (Enabled)ā. That is, the default under Standard is to uncloak Cname. I do not have to change to aggressive blocking mode to get Cname uncloaking enabled. I did not set it to Enabled. It was at āDefault (Enabled)ā already while in standard block mode. For Brave for Windows, the default in standard blocking mode is to uncloak Cnames.
In Brave for Android, and also at standard blocking mode, brave://flags/#brave-adblock-cname-uncloaking is āDefault (Disabled)ā. For Brave for Android, the default in standard blocking mode is NOT to uncloak Cnames.
This is inconsistent safety setup. Both instances of Brave are set to standard blocking mode, but Cnames are uncloaked on Windows, by default, while Cnames are not uncloaked on Android, by default. If it is a good safety feature on Windows, the same should be true on Android.
Perhaps aggressive mode overrides the flags, but then there is no documentation to tell me just what aggressive mode does versus standard mode. Personally I donāt believe standard/aggressive mode has anything to do with Cname uncloaking in Brave. Those appear to be independent, especially since it is documented that way.
Iāve used uBlock Origin (the MV2 version) with its Cname uncloaking option enabled for years, and sites did not break because of it. Cname cloaking allows 3rd-party servers to disguise themselves as 1st-party servers, but that doesnāt affect the DNS lookup will still point to the same place with the same IP address from a lookup. Cname uncloaking is essential in the fight against ad servers pretending to be something else. Makes no sense why the default on Android is for Brave not to uncloak Cnames. This is not aggressive blocking. This is Cname redirect exposure which allows the blocklists to cover even the cloaked Cnames. Blocklists are standard blocking, not aggressive. Uncloaking Cnames it not iself a block action. It unhides the hidden (redirected) 3rd-party domain, so adblockers are not thwarted.
Characterizing CNAME cloaking-based tracking
Brave performed best, but that is because the Windows version mustāve been used in the testing where Cname uncloaking is enabled, by default, regardless of the standard/aggressive blocking mode. The test would not have been as favorable on Android (where Firefox Android with the MV3 version of uBlock Origin with its Cname cloaking enabled) where Cname uncloaking is DISABLED, by default.
An important safety feature, Cname uncloaking, which prevents thwarting the blocklists used by adblockers is disabled, by default, in Brave for Android. The default for Cname uncloaking should the SAME for Brave whether on Windows or Android.
Iāll review https://github.com/brave/brave-browser/issues?q=is%3Aissue%20cname to see if I can determine why Braveās author enabled Cname cloaking on Windows, but disabled it on Android. There are about 51 tickets on ācnameā. Probably get back to this in a couple hours.
I found one ticket:
Cname getting corrupted by $removeparm
where Cname uncloaking seemed to be a problem at Bing Maps, but turned out the actual problem was removing tracking parameters from the URL using the uncloaked domain. So, it was a combo of both. However, Brave on Windows has both uncloak and removeparms enabled, by default. If disabling Cname uncloak, by default, was the solution for Brave on Android, why didnāt Brave on Windows also get uncloaking disabled, by default?
Iāve used Cname uncloaking in uBlock Origin for many years (as an add-on to Firefox, so it was the full MV3 version of uBO); however, uBO didnāt modify URLs to remove tracking parameters. Seems the combo of these safety features can break web sites. In uBO, not a problem. In Brave that adds removal of tracking parameters, possibly a problem.
Braveās resolution was to not apply $removeparm on uncloaked URLs. That was closed 5 days ago, so I donāt know if a released version of Brave has it yet. Looks like the fix got into Brave 1.82. Iām still on 1.79.
However, because uncloaking is disabled, by default, in Brave on Android, the above problem should not arise there. One of the criteria is missing on Android. I doubt this fix to override removeparm when uncloaking will get effected in Brave on Android until that code branch enables uncloaking by default. With the fix, an uncloaked domain that is an ad server should get a network block (you donāt access the server) due to the block lists in the adblocker, so it doesnāt matter if there were tracking parameters in the uncloaked URL. You wonāt go there, anyway. If the uncloaked domain is not in a block list, it is not recognized as an ad server, so the parameters should not get stripped from the URL. If it is not yet recognized as an ad server, well, thatās why misses are reported, and block lists get updated.
So, regardless of this ticket, I donāt see why Brave on Android defaults to disabling Cname uncloaking. Nowadays this is critical to unthwarting the ad sources that hide behind Cname records in DNS. If they can lie, they will lie.
CNAME uncloaking is disabled in Brave on Android due to technical restrictions of the WebView engine.
So, although I enabled it in brave:flags, CName uncloaking is still unavailable in Brave for Android. The flag does nothing.
Makes Firefox for Android with uBlock Origin (MV2 version) a better choice. CName cloaking has gained momentum in the last decade to thwart block lists used by adblockers.
The issue ticket of https://github.com/brave/brave-browser/issues/24278 has an āOS/Androidā flag on it. It has a link to https://github.com/brave/brave-core/pull/14392 which says " Android only : not all of the test plans here are applicable, but for those that are, be sure to enable the #brave-adblock-cname-uncloaking flag in brave://flags. It is currently disabled by Griffin under the DisableCnameUncloakingForAndroid study."
The flag exists in Brave for Android. Why is it there if it is a bogus setting, like pressing a disconnected cross-walk button? Why add code to add a useless setting?
https://github.com/brave/brave-browser/issues/16053 also has the āOS/Androidā flag.
Seems inane to add a flag that has no effect. Do you have some references to cite that Cname uncloaking does not work, or has zero effect, in Brave for Android?
Also, since CName is a record at the resolver (DNS server), just why would a client not see that record when doing a DNS lookup? For example, I can go to https://mxtoolbox.com/SuperTool.aspx, select āCname lookupā in the drop-down list, and enter, say, www.intel.com which shows that is a Cname pointing to intel11.cn.edgekey.net. They can do it, Brave for Windows can get a Cname record, but Brave for Android cannot access ALL DNS records in a lookup? Your response makes it appear Brave for Android is DNS-crippled, and the WebView library used for rendering is limiting what DNS records a client can retrieve.
Webview is about displaying content, not about DNS lookups. Rendering a web doc is completely separate of DNS lookups.