The initial UI for the DNS over HTTPS feature was defined in 1482271. It assumes that there is only one default DoH provider. Now we have a policy [1] and are actively working to recruit more DoH partners around the world. As part of the launch of DoH, or shortly after, we need support for selecting from a list of approved DoH resolvers. This list may default to different providers based on the user's geography, on a random selection, or other factors. The choice may be presented to the user when DoH is first enabled, and must be available in preferences for the user to change at any time.

PI test request for 68: https://moz-pi-test.atlassian.net/servicedesk/customer/portal/9/PI-97

[1] https://wiki.mozilla.org/Security/DOH-resolver-policy

I'll be implementing the UI part of this.
Tiff, can you attach/link the mockups you have to this bug?

I presume this UI will be in about:preferences, so moving to there.

(In reply to Sam Foster [:sfoster] (he/him) from comment #1)

I'll be implementing the UI part of this.
Tiff, can you attach/link the mockups you have to this bug?

Here's what I know. We'll modify the existing preferences UI to have a heading, a series of labelled radio options and a picker for the DoH case, which will have options for the default (cloudflare), and a Custom... option. Selecting custom will show the custom input textbox we have today. Later, if/when other resolvers are available, we will insert them as options into that picker.

Domain Name Server
------------------

( ) Use system DNS
( ) Proxy DNS when using SOCKS v5
(•) Use DNS over HTTPS [--------------------------- ▼ ]
                       [ cloudflare-dns.com (default) ]
                       [ example.com                  ]
                       [ Custom...                    ]
    Custom: [ custom url ]

I'll need to figure out how that list will be populated - currently we've hardcoded the cloudflare url in a preference:
https://searchfox.org/mozilla-central/source/modules/libpref/init/all.js#5582

(In reply to Wayne Thayer [:wayne] from comment #0)

... The choice may be presented to the user when DoH is first enabled, and must be available in preferences for the user to change at any time.

As far as I know, we only have the preferences UI for enabling and configuring this. Unless there's been talk of some contextual UI or onboarding doorhanger or something?

(In reply to Sam Foster [:sfoster] (he/him) from comment #3)

As far as I know, we only have the preferences UI for enabling and configuring this. Unless there's been talk of some contextual UI or onboarding doorhanger or something?

It's not clear to me if we will choose a DoH provider for the user or allow them to select one. We do already have an opt-in banner (see attached).

I'll ask the team at next week's meeting and get back to you.

(In reply to Wayne Thayer [:wayne] from comment #4)

It's not clear to me if we will choose a DoH provider for the user or allow them to select one. We do already have an opt-in banner (see attached).

That seems like an opt-out banner? Is that already implemented? Its the first time I've seen it.

That is the banner being used in the DoH experiments. It's implemented in the go faster add-on (bug #1496738) that will be modified and used for the DoH rollout.

Hello everyone - apologies I was on PTO last week and I also don't check bugzilla that often. Markus would be the correct person to ping with questions and do a UI review of the feature. Thanks!

Sam: I confirmed that your assumption is correct: we only need a preferences UI for this. We'll use an algorithm to select an initial default and won't ask the user to choose a provider when enabling DoH.

(In reply to Wayne Thayer [:wayne] from comment #9)

Sam: I confirmed that your assumption is correct: we only need a preferences UI for this. We'll use an algorithm to select an initial default and won't ask the user to choose a provider when enabling DoH.

So we don't need a menulist or means of selecting from a list of provider/resolvers?

Will that initial default be set as the default value for network.trr.uri or will I use some other API to get the value?

I assume we still want to display that URI in preferences and provide the textbox for custom values.

I'm I right that DNS-Over-HTTPs and Socks5 are mutually exclusive options?

So right now I'm looking at needing to implement something like:

( ) Use system DNS
( ) Proxy DNS when using SOCKS v5
(•) Use DNS over HTTPS ( cloudflare-dns.com (default) )
    Custom: [ custom url ]

.. which is quite close to what we already have. Maybe a quick call would be an expedient way to answer all these questions and get this on track?

(In reply to Sam Foster [:sfoster] (he/him) from comment #10)

(In reply to Wayne Thayer [:wayne] from comment #9)

Sam: I confirmed that your assumption is correct: we only need a preferences UI for this. We'll use an algorithm to select an initial default and won't ask the user to choose a provider when enabling DoH.

So we don't need a menulist or means of selecting from a list of provider/resolvers?

We do still need the list you described in comment #3. We only need that list in Network Preferences.

Will that initial default be set as the default value for network.trr.uri or will I use some other API to get the value?

I suspect that the default won't be set until the user enables DoH, so there may not always be a default set.

I assume we still want to display that URI in preferences and provide the textbox for custom values.

yes

I'm I right that DNS-Over-HTTPs and Socks5 are mutually exclusive options?

I don't think that is necessarily true, and it isn't currently implemented that way.

So right now I'm looking at needing to implement something like:

( ) Use system DNS
( ) Proxy DNS when using SOCKS v5
(•) Use DNS over HTTPS ( cloudflare-dns.com (default) )
    Custom: [ custom url ]

.. which is quite close to what we already have. Maybe a quick call would be an expedient way to answer all these questions and get this on track?

I'll send you an invite to next week's meeting. Please let me know if that won't work for you.

(In reply to Wayne Thayer [:wayne] from comment #11)

Thanks for the clarification on SOCKS 5 vs DoH, that changes how we'll need to structure this UI and the choices the user will make.

I'll send you an invite to next week's meeting. Please let me know if that won't work for you.

To ensure this lands before 68's soft freeze (2019-05-06) it would be good to get most of this knocked out this week. I'll send you an email.

I suspect that the default won't be set until the user enables DoH, so there may not always be a default set.

My assumption would be this list of providers and their URLs would be populated from a pref that might be targeted to the user or come baked into the build with the locale. I don't think we have the timescale for anything more advanced to deliver different providers.

Some regions might end up being pref'd on by default with a designated provider but others will be totally disabled by default. So similar to search with the added caveat of that some regions won't have anything by default.

My understanding was the implementation in the preferences would be:

() Use provider [dropdown list V]
() Use custom url

(I attached a rough screenshot of how this might look)

• Create new network.trr.resolvers pref which is a comma-delimited list of resolver URIs
• Add menulist to represent the resolver choices, and a "custom" option to use the network.trr.custom_uri as the trr.uri value

Quick question before I put this in for review, Currently in the patch, the menu list with the resolvers just uses the url as the label and value. In the pref I just have a comma delimited list of URIs.

I think ideally that would be e.g. "Cloudflare" - i.e. a (possibly localized) provider name. Which I guess means storing a JSON structure in the pref like: [{ id: 'cloudflare', url: 'https://etc' }, { id: 'otherprovider', url: 'https://other' }]

.. which would allow us to render the localized provider name using that id.

I'm not sure where we stand currently on stuffing JSON data structures into prefs. Given that there is no current plan for a service/backend for this list, this seems like my best and only option?

I had also thought about landing the patch as-is for soft-freeze and adding those localized labels in a follow-up, but changing the expected data structure in a pref across revisions seems like potential trouble.

Thoughts?

(cancelling ni for johannh, :jaws got me an answer in #fx-team)

I'm trying to figure out the best way forward for building the menulist of DNS-Over-HTTPs resolver providers. The current patch just uses the URI as the item label, but if we want a provider name, and for that name to be localized I'm thinking to have something like this (via preferences)

[
 { id: "google", url: "https://dns.google.com/resolve" },
 { id: "cloudflare", url: "https://mozilla.cloudflare-dns.com/dns-query" }
]

I want to be able to render the menulist items with labels like so:

• Cloudflare (Default)
• Google

My understanding (from a similar situation in web payments) is that we may want those brand names in the .ftl file?
So I would localize each item something like:

document.l10n.setAttributes(item, "connection-dns-over-https-url-item-default", {
  // for the default case
   vars...
});
document.l10n.setAttributes(item, "connection-dns-over-https-url-item", {
  // for the non-default case
   vars...
});

I'm not sure a) if I'm over-thinking this and we should just put that brand/provider name in the data along with the id and url. That makes changing which providers ship in different regions a single pref change.

or b) how I would represent this in fluent?

In the interest of getting this landed before soft-freeze, I've put in the patch for review with the URL used as the menu item label, only using a localized string for the default item which gets a (Default) indicator. Depending on how review goes and the outcome of comment #16, I can either file a follow-up to use a provider name as the menu item label or amend this patch. ISTM that such a follow-up patch would be ok to land during soft-freeze whereas this one might be less ok. And if we really needed to, we could ship in 68 without the follow-up.

:jaws points out we shouldnt be localizing brand names anyhow. So, from comment #16, a) looks viable.

Confirmed, we shouldn't be localizing those brand names. The approach in the patch looks good to me, I'll wait to review just to make sure code changes don't impact strings.

I have one open question on this patch. I've put the network.trr.resolvers pref (the list of providers we'll populate the menulist with in preferences) alongside the others in modules/libpref/all.js. I'm not sure that pref has any utility outside of Firefox though, would it make more sense to put that in browser/app/profile/firefox.js?

Is Fennec and others covered by firefox.js if yes then moving it there is likely fine. I don't suspect Thunderbird will be using DoH anytime soon however Valentin would probably know for certain.

(In reply to Jonathan Kingston [:jkt] from comment #21)

Is Fennec and others covered by firefox.js if yes then moving it there is likely fine.

Do we intend to have an Android UI for the DoH chooser in the near future? If so we can put it in all.js otherwise firefox.js is fine too.

I don't suspect Thunderbird will be using DoH anytime soon however Valentin would probably know for certain.

That's up to them. Even if we put it in all.js they can overwrite it.

https://hg.mozilla.org/mozilla-central/rev/c7b00a72c46d

There are two options for setting the resolver: "network.trr.resolvers" and "network.trr.uri"

If both are filled, which one takes precedence? which one should be set in priority?

When enabled, the TRR service will always use the value of network.trr.uri.
network.trr.resolvers is only used for UI, which we need to make clear in the future.

Thanks, documented in https://wiki.mozilla.org/Trusted_Recursive_Resolver