Feature #1264
openDisable DNS prefetching
0%
Description
I have found that on certain websites, the "Block all 3rd party requests" filter does not work.
For reference, the site that I discovered this issue is https://gamewith.jp/houkaistarrail/
Upon visiting the site, I could see lots of 3rd-party queries made from my VPN level DNS log (personalDNSfilter), which implies the 3rd-party filter didn't work, for some reasons.
Apart from the site's own domains and CDN domains, those are almost all ad domains (an.facebook.com, *.moatads.com, etc).
But here are the puzzling parts:
This only happen with "Android-ish" or "Webview default" UA. With the default UA, iOS or PC UAs, it doesn't happen. I have tested it on two Android phones (Android 14) and they both are positive, but on another Android phone (Android 8) it is negative no matter how I configured the UA.
As a side note, this behavior is also confirmed on Fennec Android and the addons can't see the requests too, but not in Cromite (a Chromium mobile browser), or Firefox desktop.
Updated by s s about 2 months ago
- Tracker changed from Feature to Bug
- Private changed from No to Yes
Updated by Soren Stoutner about 2 months ago · Edited
- Status changed from New to Feedback
- Assignee set to Soren Stoutner
- Private changed from Yes to No
It would indeed be very serious if Privacy Browser were making requests that are not logged in the Requests activity available through the navigation drawer on the left. From time to time such reports have been made, but when they were investigated, it always ended up being some other component of the device that was making the requests, like an autofill service loaded at the OS level. For example:
Bug #723: Connects to content-autofill.googleapis.com when tapping on an input field
Feature #1131: Contacts content-autofill.googleapis.com
Updated by Soren Stoutner about 2 months ago
The fact that this is happening for both Privacy Browser (Android WebView based) and Fennec (Firefox based) is indicative to me that the program actually making these requests is probably some OS component that is interacting with the browser rather than the browser itself.
Updated by Soren Stoutner about 2 months ago
If you would like to investigate this further, I would recommend posting a copy of About > Version from inside Privacy Browser. Also, please indicate if you are using a custom ROM.
Updated by s s about 2 months ago · Edited
My Privacy Browser version is 3.19.2 (with WebView 131.0.6778.200). I am using LineageOS custom ROM.
My device is officially supported by LineageOS so this is very shocking to me. Also the ad domains here contains lots of .jp and .co.jp domains, but I'm not browsing from a Japan IP, so I believe this is not fully tailored to my system. Very puzzling.
The fact that this is happening for both Privacy Browser (Android WebView based) and Fennec (Firefox based) is indicative to me that the program actually making these requests is probably some OS component that is interacting with the browser rather than the browser itself.
Yes, I'm starting to think that this is the case. But can you reproduce my issue successfully? Because then I could confirm it is not a "me-issue". And what kind of component do you think could it be interacting?
This is probably the only site that I discovered this issue. If you know any sites (that are full of ads) you can also let me test it.
I also suspect it could be some kind of DNS prefetch mechanism, but it's still the same on Fennec after I changed those "prefetch" related options. Though, Firefox likes to hardcode many questionable configurations and no mobile folks cares enough to neutralize them.
Updated by Soren Stoutner about 2 months ago
- Status changed from Feedback to In Progress
- Priority changed from 3.x to Next Release
Yes, I am able to replicate your issue. As you said, it doesn't happen with the default User Agent of PrivacyBrowser/1.0, which makes me think it has to do with the HTML returned by the server being different with different user agents. I am trying to figure out what is going on. I suspect you are correct about it being a prefetch issue, but so far I can't find any controls for how Android System WebView handles prefetch.
Updated by Soren Stoutner about 2 months ago
Based on the following discussion, I would guess that this is a DNS prefech, not an HTTP prefetch.
https://groups.google.com/a/chromium.org/g/chromium-dev/c/NZ5cGTR62FQ
Meaning that the current version of Android System WebView has probably been programmed to prefetch the DNS A and CNAME records for all the links on a website, even if it waits to make actual HTTP requests until a user taps on the link.
This paragraph from the link is interesting:
That appears to be the right thing. This component is not currently used in WebView because the point in Chrome where it gets hooked up
and enabled seems to be in src/chrome/browser/net/predictor.{h,cc} and no code from src/chrome is used in WebView. To add this support
to WebView you'd need to wire up and enable it from somewhere in src/android_webview, ideally without duplicating existing code from
src/chrome too much (it may be that this would require some refactoring to move more of the predictor implementation to a component,
as components are allowed to be shared between webview and chrome, but I haven't looked at the code in great detail). I don't know if
there are design docs for this feature.
There no longer seems to be a chrome/browser/net/predictor.cc in the Chromium source code, so it has likely moved somewhere else.
Updated by Soren Stoutner about 2 months ago
- Tracker changed from Bug to Feature
- Subject changed from "Block all 3rd party requests" not working as expected on certain sites to Disable DNS prefetching
- Status changed from In Progress to New
- Priority changed from Next Release to 4.x
Looking through firewall logs and comparing them against personalDNSfilter, as far as I can tell these are DNS prefetches instead of HTTP prefetches. Both are concerning, but HTTP prefetches would send information directly to the undesirable websites and would allow third-party tracking.
What DNS prefetching does do is allow the main website you are visiting to detect which DNS servers your device is using (by creating a DNS request with a random subdomain that has never been used before and seeing which DNS server requests it), which can provide them with approximate location information if the DNS server is only used for a small geographic area. Because most DNS servers service a large geographic area, or even a worldwide area, this information will usually not be very useful to a website. However, if you are using a poorly configured VPN (one that forwards all of your traffic except for DNS requests) this could reveal information to a website that you didn't want to disclose if the difference between the location of the DNS server and the location of the IP address conflicts strongly enough to make things look suspicious.
Even with this not being very serious (the DNS requests are sent to your DNS server, not to all of the bad websites listed, like an.facebook.com and *.moatads.com), this is definitely something I would like to disable. Doing so will require Privacy WebView, which is why I have moved the priority to the 4.x series.
Updated by Soren Stoutner about 2 months ago
By the way, researching this led me to find documentation about disabling pulling requests from the cache, which is something I didn't know I could do. Feature #1265: Disable using the web cache.
Updated by s s about 2 months ago
Thank you.
But approximately when will 4.x be ready?
And is it trivial to install and use the Privacy WebView? (like I could just install it easily as a regular package)
Updated by Soren Stoutner about 2 months ago
The 4.x series will probably not be released until I can hire several more people to work on Privacy Browser full time, which means it probably needs to generate somewhere along the lines of $1,000,000/year.