Seems to have been a typo from legacy/trac#5642 (closed). Lucky for us, this pref is disabled by default in Firefox desktop and also the API is disabled by privacy.resistFingerprinting thanks to https://bugzilla.mozilla.org/show_bug.cgi?id=1372072. We could set "dom.netinfo.enabled" to false just to be safe, or just remove the "dom.network.enabled" line altogether.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Testing it on an upcoming Tor Browser for Android shows "Connection type is unknown", so I assume the resistfingerprinting part is working here. Thus, I think we can just remove the pref.
dom.netinfo.enabled=false returns "unknown" but RFP returns "undefined"
You need to decide what you want to enforce as your TBB fingerprint. RFP "clashes" with a lot of other prefs you have flipped in the past. You'll have to evaluate each one on it's own in order to determine if the pref or RFP wins out. Or even which one gives better protection (eg media.video_stats.enabled=false disables the API, but RFP returns dynamically spoofed values .. so which do you want? which is less entropy or fits your threat model)
For RFP, where we could, we choose values that would keep the API functioning; just in a constant way.
Therefore I think we would want netinfo to return unknown, rather than undefined. If RFP says undefined; we should open a mozilla bug to correct it....