Closed Bug 1475321 Opened 6 years ago Closed 6 years ago

[Shield] Pref Flip Study: Trusted Recursive Resolver phase 3, trr-first

Categories

(Shield :: Shield Study, defect)

Product:
Shield
Component:
Shield Study
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox62 unaffected, firefox63 fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox62 --- unaffected
firefox63 --- fixed

People

(Reporter: bagder, Assigned: bagder)

References

Details

(Whiteboard: [trr]) 

Time to make the TRR study phase 3, setting TRR mode to 2 (soft fallback, aka trr-first) for the enrolled users, on Nightly.
Sign off for DNS Over HTTPS V3 - (GREEN)

DNS Over HTTPS V3
Targeted: Firefox Nightly 63.0a1

We have finished testing the DNS Over HTTPS V3 Shield Study experiment.

QA’s recommendation: GREEN - SHIP IT

Reasoning: We haven't found any issues during testing.

Testing Summary:
Based on the discussions we had with the dev team, we were only asked to test if the updated version of the study is not causing any regressions:
- We verified that there are no crashes, connection errors or load time problems on most visited Alexa websites (https://www.alexa.com/topsites);
- We verified that the experiment is working by checking the "true" value from TRR column in "about:networking" page.

Tested Firefox versions:
- Firefox Nightly 63.0a1 en-US;
- Firefox Nightly 63.0a1 de;
- Firefox Nightly 63.0a1 fr;
- Firefox Nightly 63.0a1 en-GB;
- Firefox Nightly 63.0a1 it;
- Firefox Nightly 63.0a1 ru;
   
Tested Platforms:
- Windows 10 x64;
- Ubuntu 16.04 x64;
- Mac 10.13.5.
Is this also something we may end up running on 62 release?
this study is for nightly >=63.

We would like the DoH code to be complete on 62 to support manual testing and potentially a beta-62 experiment (though I expect beta will be 63 by the time we're ready for that).
We're live on this.  Held off due to an issue in Shield itself.

Thanks
(In reply to Carmen Fat [:carmenf] - Experiments QA from comment #2)
> - Firefox Nightly 63.0a1 de;

https://twitter.com/ungleich/status/1026041643340845057 brought this topic again to my attention.

Question: Would DNS data be only transmitted to Cloudflare after a click on Opt-In has been made?

If you don't wait for an explicit Opt-In it would be a computer crime in Germany (§202c StGB [1]) because no legally valid authorization has been given and a web browser's Terms of Service legally can't include an auto Opt-In because no one would expect [2] such dramatic [dns] data redirection to a foreign dns provider (consumer proctection). Nightly's setup looks like a setup of a web browser in alpha state and not like a program of observing research participants like Firefox Pioneer.
If you are using an addon like the one from bug 1446404 comment 79 which declares that it is active by default and is not removed after dismissing the info bar by clicking on X it definitely sound like a data crime. If you see similar behavior in other software it would be a good moment to file some criminal complaints.

[1] https://www.gesetze-im-internet.de/englisch_stgb/englisch_stgb.html#p1759
[2] https://www.gesetze-im-internet.de/englisch_bgb/englisch_bgb.html#p0930
Potential exposure and redirection risk for organizations: intranet domain lookups are sent to the TRR. If no match, the internal organization host names are still on the wire while they never should be (LAN-first resolution, org privacy concern). If there is a match (will autocomplete/URL fixup take priority over the native DNS lookup or not?), organization users are potentially sent to off-site hosts while internal hosts should be used, and/or are sent to the public-facing side of combined internal/external websites, breaking workflows like SSO.
This seems like another case of Mozilla deciding what should be good for the user. It has the potential to:
- exfiltrate internal dns queries to a third party without user consent
- break geo-aware dns resolving for other parties
- break some captive portal based network logo-ons
- break some EU or national laws by leaking some data to a third party even when used in the context of a private network.
- takes control over the dns resolving process without user's request.

This "feature" should be disabled by default and the user should only opt-in for its usage.I would expect this "feature" from Google or Microsoft's browsers, not from Mozilla which takes pride in being one of the last independent browsers.
This study on nightly is complete. Thanks all!
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
If there is a better bug than this study bug (now closed) to post these concerns, please do let us know. TRR-first (and enabling it by default to begin with, outside of "tor browser" corner cases) seems to be a mistake and should be addressed.
You need to log in before you can comment on or make changes to this bug.