Yes, it pays to remember that this is Nightly. The precautions Henri suggests are good, but more appropriate to experiments we would do on Release. For TLS 1.3, we did that sort of thing so that we could get measurements from Release; we just flipped the switch to "on" for Nightly.
I don't know if it is possible to know if you have a manually-configured DNS server, but disabling this experiment there if we can determine that would be good - that might not be something to worry about with Nightly, but it seems like it might be needed for this to hit the trains. How do we otherwise determine that a DNS server is not safe to replace? Split horizon DNS is going to cause unexpected failures when users - particularly enterprise users - try to reach names that aren't public. That's not just an enterprise thing; this will break my home router in some ways as well, though I'm actually totally OK with that in this case :) On Mon, Mar 19, 2018 at 11:25 AM, Patrick McManus <pmcma...@mozilla.com> wrote: > The objective here is a net improvement for privacy and integrity. It is > indeed a point of view with Nightly acting as an opinionated User Agent on > behalf of its users. IMO we can't be afraid of pursuing experiments that > help develop those ideas even when they move past traditional modes. > Traditional DNS is a swamp - ignoring that isn't doing our users any > favors. This is obviously not an engineering only driven effort. > > Nightly is an explicitly experimental channel which is part of the reason > it is the choice for the first validation. > > A question came up about geo based DNS and I've got a couple technical > comments about risk mitigation there: > 1] geo dns use is on the wane as TCP anycast approaches work much better > in practice > 2] the granularity of the CDN being used is much finer than the > granularity of most geoDNS resolution which tends to choose between very > big regions (O(~ 1/2 a continent)) so that should continue to work the same. > > I initiated this thread on dev-platform because imo it is a reasonable > scope for nightly changes, especially ephemeral flip pref changes, and > that's why the FYI goes here. Its definitely not a secret. Messaging to a > larger user base than is impacted invites confusion. Future possible > changes impacting larger populations or putting things on trains would use > other, more broadly read communications channels. > > -Patrick > > > > On Mon, Mar 19, 2018 at 9:05 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > >> On Mon, Mar 19, 2018 at 10:07 AM, Daniel Stenberg <dstenb...@mozilla.com> >> wrote: >> > On Sun, 18 Mar 2018, Eric Shepherd (Sheppy) wrote: >> > >> > I don't have such a far-reaching agreement with my ISP and its DNS. >> >> 1) Mozilla doesn't choose the ISP on users' behalf. (This is the key >> reason.) >> 2) The ISP sees the Host header in unencrypted traffic and SNI in >> encrypted traffic anyway. (This is a secondary reason.) >> >> > I don't >> > have such an agreement at all with 8.8.8.8 or other publicly provided DNS >> > operators. >> >> Using such resolvers is a decision that the user makes and not a >> decision that Mozilla *silently* makes on their behalf. >> >> > What other precautions or actions can we do to reduce the risk of this >> being >> > perceived as problematic? >> >> I suggested two ways on the bug. >> >> > Would reducing the test population really make it >> > much different? >> >> No. >> >> -- >> Henri Sivonen >> hsivo...@hsivonen.fi >> https://hsivonen.fi/ >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> >> > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
