What follows is the exact text of a dissent presented to the Expert Working Group (EWG) for inclusion with the final report on A Next Generation Registration Directory Service (RDS), released on June 6, 2014. A more thorough discussion of the issues raised, with footnotes to the original, will follow in my next blogpost. In particular, please note that in our public presentations and ancillary materials presented at the London50 ICANN meeting, the group clarified that most purpose-based contact information (PCBs) is intended to be protected and made available to accredited users for permissible purposes only. While this clearly states our intention, I maintain that the report still requires clarification in its language, to avoid confusion.
It has been an honor and a privilege to serve on the EWG for the past 16 months, and I am truly impressed at the work we have done, and the spirit of consensus that has enlivened our discussions on the complex matters we were tasked to address. This has been a tremendous amount of hard work, and my colleagues have worked selflessly, with weekly calls, research and reading, and many face to face meetings.
Finding the correct balance between transparency, accountability, and privacy is never easy, especially in a global context with different cultures, legal regimes, and economic power. I am very proud of what we have achieved, so it is with great reluctance that I raise issues where I cannot agree with the consensus on some aspects of this report. I feel it is my responsibility, as one who was brought on the committee to provide data protection expertise, to point out some weakness in some of the provisions that we are recommending.
The EWG report is complex, and must be read in its entirety; sometimes it is quite hard to follow how things would actually be implemented, particularly if you are a reader who is not immersed in the arcane details of domain name registrations on a daily basis. There is nothing devious in that, the matters are very detailed and deciding which order to put them in, what topics ought to be addressed in which section, is not easy. The end result, however, is that one must follow a thread through the report to determine ultimate impact.
The purpose of this appendix is to follow the thread of protection of the sensitive information of the average simple domain name registrant. Whether they be an individual, small company, or small organization, we need to see what happens, and how rights, whether legislated or simply claimed on the principle of fundamental fairness in the administration of a public good, are enforced. I regret to say that I am not happy with what I find when I follow that trail.
I have tried to explain how these rights ought to be implemented and enforced, to those who are more familiar with their own areas of expertise both within the EWG and in the broader community, and this appendix is added in an attempt to help further clarify these issues. I am concerned that the rights and important interests of these individuals may not be effectively protected by the inter-related provisions which we have set out.
There are three basic outcomes where I cannot agree with the consensus.
1) The requirement to have a legal contact, where address and phone number are mandatory to provide, and published outside the gate, in the publicly available data.
2) The default, if one is a simple registrant who does not want to hire a lawyer or other actor to assume the role of legal contact and publish their details in the RDS, to publishing registrant information, notably address and phone number in the RDS outside the gate.
3) The inclusion of a principle of consent (28), whereby a registrant may consent to the use or processing of her gated information for the permissible purposes enumerated for accredited actors behind the gate.
Let me provide some context around each of these points.
Firstly, these details appear in the section on purpose-based contacts (PBCs), which proposes a new ecosystem of validated contacts. I support this, and the associated accountability mechanisms, whole-heartedly. I agree with the consensus view, that domain name registrants must be accountable for the use of the resource. Being a privacy advocate, I do not equate accountability with transparency of detailed personal or business information, I equate it with responsiveness. If a registrant fails to respond to serious issues, it is appropriate to expedite the action, depending on the issue, and contact the registrar to take action.
However, I understand the objective of our proposal of gated access to be the sheltering of customer data: the purpose of the gate is to screen out bad actors from harassing innocent registrants, deter identity theft, and ensure that only legitimate complaints arrive directly at the door of the registrants. It is also to protect the ability of registrants to express themselves anonymously.
Placing all contact data outside the gate defeats certain aspects of having a gate in the first place. Obviously large companies are eager to publish their contact data, as it makes it easier for them to streamline requests and manage the actions over thousands of domain names. A simple registrant with a couple of domain names has entirely different needs and resources, and is unlikely to want to spend money hiring an ISP or Registrar to provide these contacts for them.
I whole-heartedly applaud the emphasis we have achieved in this report on the necessity of having privacy/proxy services in the RDS ecosystem, for both individuals and organizations. I do not believe that should be the only way an individual or small organization can avoid having their private information published. We have a principle that recommends providing resources for registrants who are economically disadvantaged, but it is not clear how we could implement that globally, particularly in developing economies where the need is likely greatest.
An additional context, is that we propose a rules engine that enforces jurisdiction, with respect to the privacy rights of individuals who are protected by personal data protection law. This is an ambitious and potentially very useful proposal, but it only protects individuals, and occasionally legal persons in some jurisdictions, and only where data protection is in place, and would find the presence of name, address and phone number in a public directory to be in conflict with data protection law. These are very important caveats. Not all data protection regimes would find, or have found, that directory information must be protected. Secondly, it is not clear enough for me how that rules engine would encode rights. Would it be based on precedents? My interpretation of the law? Your interpretation of the law? This is a difficult question and provides no certainty as to the outcome in the instances where I have cited my disagreement. A third problem with the rules engine, is that it proposes to address regimes with data protection law only….what happens to organizations that have a constitutional right to privacy for the purposes of free speech and freedom of association, such as in the United States? Finally, is it fair to individuals in jurisdictions where their countries have not enacted data protection law? Does ICANN, in the monopoly administration of a public resource, not have a responsibility to set standards on an ethical basis, based on sound best practice?
The two remedies then, I find inadequate for the reasons cited above:
1) Hire a privacy proxy/service provider, or proxy contact, if you do not want your contact data published in the public portion of the RDS;
2) The rules engine will enforce data protection rights, and place this data behind the gate.
I would like now to address the consent principle. It is my view that we cannot elevate one principle of data protection above the others, because they are inter-related. Consent must be read in the context of legitimacy of purpose, proportionality, rights to refuse, rights to withdraw consent, specificity of purpose and use, and so on. To offer individuals and organizations the opportunity to consent to the use of their sensitive, gated data, for all the permissible purposes, in my view can be read as providing blanket consent to accredited users behind the gate. It can be read as voluntarily giving up any privacy protection one might have expected under local law, and any right to select some purposes as opposed to others. It greatly simplifies one of the biggest problems we faced as a group in grappling with the concept of accrediting users only for certain specific purposes, but from a privacy perspective it greatly reduces the effectiveness of the gate as a privacy mechanism. Once again, if you understand the risks, you will hire a proxy service. From the perspective of an elite North American, this looks like a no-brainer, just hire a proxy.
However, we have a responsibility to examine this from the perspective of a global eco-system. We have now set up a system where accredited actors have access to inside data, others do not. We have labored long and hard in the group to ensure that the parameters of the RDS are flexible and allow individuals to apply for access beyond the gate to resolve specific problems and issues they encounter, but in fact the vast majority of end-users will be unlikely to make effective use of this right. I totally agree with my colleagues that the market will rush to provide this kind of service at low cost, but I flag it as an element to watch in this discussion.
I hope that this clarification serves to flag some issues that are important with respect to data protection. I would like to reiterate my strong support for this report. I believe this report, and the work that lies behind it, is an important contribution to the WHOIS evolution. I would stress however, that we are setting up the ecosystem to manage personal information globally. Different cultures have different norms with respect to the transparency of their citizens, and it is appropriate to err on the side of protection of information.
I would therefore conclude with the following recommendations:
- Gate the legal contact information for individuals and organizations who wish to protect their private data
- Consent needs to be meaningful, specific, explicit and for legitimate purposes. A blanket consent as envisioned here does not meet these requirements
I appreciate the opportunity to make these comments.