In 2019, Mozilla Corporation introduced its Trusted Recursive Resolver (TRR) program to complement the addition of support for DNS-over-HTTPS (DoH) by its Firefox browser. The TRR policy that underpins the program “…describes data collection and retention, transparency, and blocking policies and is in addition to any contractual, technical or operational requirements necessary to operate the resolver service.”
Currently, the TRR program only covers North America and has recently been extended to Canada, but there have been suggestions that Mozilla is keen to expand its scope to other markets.
Possibly, as part of a plan to extend the scope of the program, Mozilla undertook a public consultation into the TRR policy, which closed in January 2021. The consultation posed a number of questions and sought input from the community, with a total of 57 responses received and subsequently published by Mozilla on its Open Policy and Advocacy Blog, including a response by this author.
At the time of writing, we are still waiting to see what conclusions Mozilla has reached since undertaking the consultation. It has, however, made an interim announcement relating to its requirement that participants in the TRR program publish the full list of any domains that they block due to legal requirements:
“Therefore, while we reflect on the input regarding our TRR policies and solutions for blocking transparency, we will relax this blocklist publication requirement. As such, current or prospective TRR partners will not be required to mandatorily publish DNS blocklists from here on out.”
This is an important and positive change to the TRR policy, addressing an issue that has been raised repeatedly with Mozilla, both through the consultation and directly. It has been a barrier to the expansion of the TRR program as, for example, it is illegal in some economies to publish details of sites containing certain material. It is also undesirable to publish such information as it could inadvertently be used as a directory by some to facilitate access to the content in question. In addition, publishing details of malicious domains would indicate to authors of malware and similar content which of their domains are being blocked, enabling them to adapt their tactics accordingly.
What alternatives to the TRR Policy are there?
When the TRR program was launched, concerns were raised about the way that DoH was enabled by default, bypassing any parental controls and other content filtering that may be in operation. In addition, the limited number of participating resolver operators lead to concerns about both lack of user choice and centralization (at the launch of the program, the only option was Cloudflare). Another issue aired at the time was the absence of any reference of adherence to legislative requirements.
As a result of discussions within the industry about issues with the TRR policy, we decided to develop and launch an alternative in the form of the European Resolver Policy (ERR). This addresses issues raised about the Mozilla TRR policy as well as including an explicit requirement to comply with GDPR and to incorporate operational practices that protect the privacy and security of users’ data, summarized previously in the APNIC Blog.
What are the main themes of the responses?
While it is expected that Mozilla will publish a full response to the consultation in due course, this has been some time in coming. The following is the result of an analysis of the responses submitted, identifying key themes and concerns with the TRR policy and Mozilla’s approach as it currently stands.
The responses incorporated a wide range of views, with the most frequently suggested changes to the TRR policy and Mozilla’s approach being:
- Respect user and/or system-wide settings and preferences, including those relating to DNS resolution
- Respect local legislation relating to matters including privacy, content blocking and information retention
- Allow (opt-in) content filtering within the TRR program to address concerns about exposure to malicious content and to support parental controls, both of which are not possible with the current policy
- Work with ISPs so that DoH is implemented more widely, ensuring more resolver choice and removing the need for users to share personal data with additional entities
- Provide better support for the needs of enterprises including, for example, split-horizon DNS, a common requirement amongst enterprise users
- Bring the TRR policy in line with GDPR, allowing users to avoid the need to share personal data with US-headquartered entities
In addition, some responses highlighted the need to address issues relating to centralization. This could be helped by increasing the number of resolver options, especially if more ISPs joined the program so that users were not forced to rely on cloud-based DNS resolvers.
Beyond the points above, which were raised in multiple responses, the following points raised in individual responses stood out as items needing attention by Mozilla:
- Replace the current user dialogue that appears the first time Firefox installs with DoH, providing proper user information and avoiding the use of so-called dark patterns (defined as “a user interface that has been carefully crafted to trick users into doing things”)
- Where access to a domain is blocked by resolver filtering policies, improve the user experience by providing an explanatory notice rather than simply presenting an error message as currently required
- Consider an industry-wide accreditation body to ensure uniformity of ‘auditing’ and to reduce costs, noting that this may otherwise present a barrier to entry for smaller resolver operators
- Expand the policy to include more detailed technical requirements, for example, by giving information on maximum session lengths and so forth. Compliance with RFC 8932, which contains operational, policy, and security considerations for resolver operators, was also mentioned (the ERR specifies compliance with section 5 of this document)
- Enhance the current DoH options supported by Firefox through the use of ‘same-provider auto-upgrade’, an option already adopted by, among others, Google in its Chrome browser
Finally, some responses encouraged Mozilla to support standards-based resolver discovery methods when these are agreed upon within the Internet Engineering Task Force’s ADD working group. This would also help to boost the number of resolvers accessible within Firefox without requiring users to resort to significant manual configuration, something that ordinary users won’t do.
More work needed
The content of the responses varies widely; it is clear, however, that more work is needed before Mozilla expands its TRR program. In particular, Firefox must respect user and system settings, adapt its implementation to reflect the legislative requirements in different economies and allow content filtering to be implemented. If Firefox is to expand its footprint within enterprises, more work will also be required to address the specific needs of this use case.
More generally, some of the points raised relating to GDPR compliance will need careful consideration as it is clear from the comments in the responses that there are issues in the current TRR policy that are inconsistent with the requirements of the GDPR. Any expansion of the TRR program to Europe will certainly need to address these. Mozilla will publish its own findings relating to the TRR public consultation in due course. I look forward with interest to reading these to see whether we have drawn similar conclusions. It is clear to me however that, given the breadth of issues identified in the consultation responses, there are significant concerns that still need to be addressed before the TRR policy can be considered a useful tool that reassures users that their personal data is secure.
Andrew Campling is Director of 419 Consulting, a public policy and public affairs consultancy focused on the tech and telecom sectors.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.