Last week ISPA included Mozilla in our list of Internet Villain nominees for our upcoming annual awards.

In the 21 years the event has been running it is probably fair to say that no other nomination has generated such strong opinion. We have previously given the award to the Home Secretary for pushing surveillance legislation, leaders of regimes limiting freedom of speech and ambulance-chasing copyright lawyers. The villain category is intended to draw attention to an important issue in a light-hearted manner, but this year has clearly sent the wrong message, one that doesn’t reflect ISPA’s genuine desire to engage in a constructive dialogue. ISPA is therefore withdrawing the Mozilla nomination and Internet Villain category this year.

While we are withdrawing the nomination, we still believe that it is important to properly scrutinise the implementation plans for DoH. Below we set out our position in more detail and we will continue to develop this position and engage with our members, browser and app companies, DNS resolvers and vendors, policymakers and the wider Internet community on this issue.

Any implementation of DoH (or equally any other flavour of encrypted DNS) should be capable of achieving the expected privacy and security benefits, while at the same time being mindful of the complex internet eco system, as well as the different user relationship and trust models that are in play.

  1. User choice: An application switching to DoH should ensure that this switch does not undermine choices that have been previously made by the user. For example, if parents have decided to filter an internet connection in their home via network or local level DNS controls, these choices should not simply be ignored by the application.
  2. User consent: Any application switching to DoH should ensure that the decision to switch resolvers is made by a user who is:
    a/ fully informed about the implications of switching resolvers, and
    b/ fully capable of expressing consent, e.g. relevant admin rights need to be protected and decisions should be made by main account holders
    Furthermore, DoH discovery and selection should allow users to change their resolver selections as they wish too, e.g. they may wish to revisit selections when new resolvers become available.
  3. Data protection: Any application switching to DoH should ensure that a DoH resolver fully complies with the local data protection requirements.
  4. Security: Any application switching to DoH should ensure that the selected DoH provider is capable of replicating existing security policies and capabilities such as malware protection that are currently in place for that user.
  5. Online safety: Any application switching to DoH should ensure that the selected resolver should be capable of replicating the online safety policies that are currently in place for that user.
  6. User and access-network-operator support: If DoH doesn’t work or is slow, a customer’s internet access will be affected. The customer will contact their ISP, not the DoH provider, but the ISP won’t be able to fix things for them. As a minimum, any application switching to DoH should ensure that the selected resolver should provide a 24/7 user call centre reachable via low-cost/local rate telephony and an online support capability. Support for fault-diagnosis and resolution between ISP, resolver and users should also be provided.

There are numerous other areas that we could go into, e.g. how DoH affects enterprise networks, or content caching, and the points raised in this post are only an initial outline. We recognise that things have started moving at Internet Engineering Task Force level, for example, and look forward to engaging in a constructive discussion.