Fenix wants to be able to toggle and configure Gecko DoH. Emily says this would be a new API on GeckoRuntimeSettings.

vgosu says: "The implementation should work on Fenix with a simple flip of the pref network.trr.mode=2. There are a few differences though:

• on Android we're missing captive portal detection, so that will not factor into the decision whether to use TRR or not - a small chance it'll cause issues in some captive portals.
• the long lived keep-alive connection we use for TRR might cause extra battery usage. An experiment would be useful in that regard.
• Some UI will of course be necessary, since about:preferences does not work in Fenix (AFAIK) and users who want to opt out should not be forced to use about:config for the task

(In reply to Chris Peterson [:cpeterson] from comment #0)

Fenix wants to be able to toggle and configure Gecko DoH. Emily says this would be a new API on GeckoRuntimeSettings.

vgosu says: "The implementation should work on Fenix with a simple flip of the pref network.trr.mode=2. There are a few differences though:

• on Android we're missing captive portal detection, so that will not factor into the decision whether to use TRR or not - a small chance it'll cause issues in some captive portals.

Android generally will not activate a wifi connection until after the captive portal has been passed. It uses an internal WebView instance for this. Users can choose to use the connection as-is, but it's probably a fairly unlikely occurrence.

• the long lived keep-alive connection we use for TRR might cause extra battery usage. An experiment would be useful in that regard.

Yikes. We should shut that socket down when the app is in the background.

• Some UI will of course be necessary, since about:preferences does not work in Fenix (AFAIK) and users who want to opt out should not be forced to use about:config for the task

Yeah, presumably Fenix will take care of that.

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) (he/him) from comment #1)

• on Android we're missing captive portal detection, so that will not factor into the decision whether to use TRR or not - a small chance it'll cause issues in some captive portals.

Android generally will not activate a wifi connection until after the captive portal has been passed. It uses an internal WebView instance for this. Users can choose to use the connection as-is, but it's probably a fairly unlikely occurrence.

That is great!

• the long lived keep-alive connection we use for TRR might cause extra battery usage. An experiment would be useful in that regard.

Yikes. We should shut that socket down when the app is in the background.

I am not sure if we have a way to do that at the moment. I don't think we currently close keep-alive connections when in the background (it seems we don't but I could be wrong) - the TRR connection is only special in the fact that it has a 10 times larger keepalive. We should probably have a separate bug for that.

This PR adds a couple GeckoView API to setup and specific DoH TRR mode
and server URI, which enables the DNS-over-HTTPS capability on Firefox
Fenix

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)

I am not sure if we have a way to do that at the moment. I don't think we currently close keep-alive connections when in the background (it seems we don't but I could be wrong) - the TRR connection is only special in the fact that it has a 10 times larger keepalive. We should probably have a separate bug for that.

Hey Valentin, has anything changed since you wrote this comment? could we get a bug opened for this? :)

I've filed bug 1724166 for this.

Hi, is there anything I can help with progressing this PR? I am very keen on having TRR as a new feature on Fenix.

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

There is a performance concern with our current DoH implementation:
When DoH is rolled out in a region, users are pinned to a single regional TRR (with network provider steering being an exception).
But when the user travels with their device the DNS queries are still made to their home region TRR.

Depending on how far from their regional TRR they travel, the increased latency could be significant.
It would be unfortunate if Firefox for android became noticeably slower than the competition when used for personal or business travel.

gald to new updates on this ticket, I will update the patch in a few days. thanks.

(In reply to Andrew Creskey [:acreskey] [he/him] from comment #8)

Depending on how far from their regional TRR they travel, the increased latency could be significant.
It would be unfortunate if Firefox for android became noticeably slower than the competition when used for personal or business travel.

Good point. I think the solution would be to not rollout DoH to Android by default just yet. However, having an API & interface to enable it manually is not blocked on that.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #10)

(In reply to Andrew Creskey [:acreskey] [he/him] from comment #8)

Depending on how far from their regional TRR they travel, the increased latency could be significant.
It would be unfortunate if Firefox for android became noticeably slower than the competition when used for personal or business travel.

Good point. I think the solution would be to not rollout DoH to Android by default just yet. However, having an API & interface to enable it manually is not blocked on that.

Totally agree. I can imagine there are cases where some users prefer additional security and privacy over internet speed, e.g. upon traveling to regions with government internet censorship / DNS poisoning. It is highly valuable if an user is able to turn DoH on when needed. Even if Mozilla would like to discourage the DoH uses due to the performance concerns, it is not necessary to block API & interface changes.

I updated the differentials in https://phabricator.services.mozilla.com/D121455, and I would like to request prioritizing its review if possible .

My patch is passing tests and ready for review. This is a discrepancy of an important security feature of Firefox desktop and Fenix, shall we make this bug priority P1/ P2?

Thanks for your patience! I'm asking the Android engineers to recommend an appropriate code reviewer.

Note that we don't have plans to enable DoH in Fenix or Focus at this time due to performance concerns, but we would like this API so other GeckoView apps can use DoH if they choose.

Thanks. I'm looking forward to the code review to take place.

(In reply to Chris Peterson [:cpeterson] from comment #14)

Thanks for your patience! I'm asking the Android engineers to recommend an appropriate code reviewer.

Note that we don't have plans to enable DoH in Fenix or Focus at this time due to performance concerns, but we would like this API so other GeckoView apps can use DoH if they choose.

May I know if there is any updates?

Tasks and enhancements should have severity N/A.

Depends on D121455

Depends on D181939