DNS over HTTPS same-provider auto-upgrade in Chrome: heads-up about our post-experiment plan

[Kenji Baheux]

Bcc: chromium-dev@

Tl;dr: we are sharing our tentative plan to add the finishing touches to the DoH experiment that’s currently running in Chrome stable 79. We are keeping the same auto-upgrade approach and enterprise/education related behaviors of the experiment, and adding the missing aspects required for a proper launch, e.g. user choice and control, formalization of criteria and process.

Hi all,

This is a heads up about our post-experiment plan for DNS over HTTPS in Chrome (design doc). For context, please see our PSA email for the experimental phase as well as these blog posts: 1, 2. The experiment is currently running in Chrome 79, and started rolling out to Stable users on December 10th. The data we’ve seen so far has been encouraging. While we will need to wait a few more weeks for the final results, we thought that it would be useful to share a tentative plan we’ve developed in light of the favorable initial results, so that anyone with an interest in the space has ample time to review it and share their feedback. Note that this still is contingent on the experiment results.

Overview of the tentative plan

• We are adding a setting in our “Privacy and Security” section to allow users to control and configure the feature in the rare cases where the default behavior wouldn’t meet their needs. This will include the ability to completely disable DoH, as well as manual configuration options.

• The setting will default to an automatic mode which corresponds to the “same provider, auto-upgrade” behavior we’ve been testing in the Chrome 79 experiment. We expect that this will be the preferred mode for the majority of our users.

• For users who fall into any of the following conditions, the setting will be locked down and DoH related command line options (if any) will be ignored.

• OS level parental controls -> locked in "off"

• DoH set via enterprise policies -> locked with a state reflecting the enterprise policies

• Detected managed environment (but no DoH enterprise policies set) -> locked in "off"

For DoH providers

As part of this launch, we also want to start formalizing the criteria and process for DoH providers. Here is our tentative proposal.

Tentative timeline

• Assuming a successful experiment, no implementation surprises or oversights, we are aiming for Chrome 81 (branch cut: end of January; estimated Stable: mid March).

• If it turns out that the experiment indicates issues with the feature, we will revise the timeline accordingly. Chrome’s release process and channels give us ample time to parallelize follow-up work and react to learnings from on-going experiments.

We believe that this plan provides answers to the concerns we’ve heard, while maintaining the benefits on user privacy and security:

• The default “same-provider auto-upgrade” behavior guarantees a continuity of the user experience (e.g. family filtering, malware filtering, established relationship with a provider).

• Administrators of Education/Enterprise deployments have total control over the feature, and we also disable it by default if we detect a managed environment to avoid surprises.

• Users have meaningful control and choice over the feature in case the default behavior isn’t working for them.

• We disable DoH and lock down its setting if Parental Controls are detected on the device, thereby preserving the safety measures provided by the OS or other client-side means such as software installed on the device.

As always, we welcome your questions and feedback.

Best regards,

--

Kenji BAHEUX

Product Manager - Chrome

Google Japan

[Vladimír Čunát]

I assume there are still no plans for DoT (rfc7858), e.g. something like Android has?

--Vladimir

[Kenji Baheux]

On Mon, Jan 6, 2020 at 9:48 PM Vladimír Čunát <vcu...@gmail.com> wrote:

I assume there are still no plans for DoT (rfc7858), e.g. something like Android has?

Correct.

 

--Vladimir

[Kenji Baheux]

Update: we are now aiming for Chrome 82 due to unexpected last minute tasks that extended our timelines.

2019年12月20日(金) 14:25 Kenji Baheux <kenji...@google.com>:

[Kenji Baheux]

Per this announcement,  the features that were meant to land in Chrome 82 (cancelled) are now slated for Chrome 83 with a revised schedule (Stable 83 around mid-May). So, we are tentatively aiming to launch DoH in M83 with the following scope and approach:

Scope

• Platforms: Windows, Mac, Chrome OS. (Support for Android and Linux is planned for after M83)
• Default experience: same-provider auto-upgrade (tested in Chrome 79).
• Setting in the “Privacy and Security” section to allow users to control and configure the feature in the rare cases where the default behavior wouldn’t meet their needs. This will include the ability to completely disable DoH, as well as manual configuration options. The setting will default to an automatic mode which corresponds to the “same provider, auto-upgrade” behavior we’ve been testing in the Chrome 79 experiment.

• For users who fall into any of the following conditions, the setting will be locked down and DoH related command line options (if any) will be ignored.

• • If parental controls are detected -> locked in "off"

• • DoH set via enterprise policies -> locked with a state reflecting the enterprise policies

  • Detected managed environment (but no DoH enterprise policies set) -> locked in "off"

 

Approach

• Progressive rollout.
• To ensure the stability and quality of the rollout, we will be monitoring metrics and have regular check-in with DoH service providers and other stakeholders.

Status: Chrome 83 should soon be reaching the Dev channel and DoH should soon be enabled (scope described above) for a fraction of Dev channel users.

As always we are looking forward to constructive feedback about DoH and our approach.

Stay safe!

2020年2月20日木曜日 14:30:34 UTC+9 Kenji Baheux: