At-Large GNSO Privacy & Proxy Services Accreditation Issues Working Group Initial Report Workspace

 

For information about this Public Comment, please click here 

• Comments Forum

Brief Overview

This public comment proceeding is being opened in order to obtain community input on the Initial Report from the GNSO's Policy Development Process Working Group on issues relating to the accreditation of privacy and proxy service providers. ICANN has committed to developing and implementing an accreditation program for privacy and proxy service providers. The 2013 Registrar Accreditation Agreement contains an interim Specification providing for certain minimum requirements relating to the provision of privacy and proxy services. This interim Specification is due to expire on 1 January 2017 or the implementation of ICANN's accreditation program, whichever first occurs. Public comments on the Initial Report may be provided directly to the Public Comment Forum. In case commenters find it more convenient to use a structured format for their responses, a template has also been provided. However, comments that do not use the template are also very welcome.

Section I: Description, Explanation, and Purpose

This Working Group was tasked to provide the GNSO Council with "policy recommendations regarding the issues identified during the 2013 RAA negotiations, including recommendations made by law enforcement and GNSO working groups, that were not addressed during the 2013RAA negotiations and otherwise suited for a PDP; specifically, issues relating to the accreditation of Privacy & Proxy Services." The Registrar Accreditation Agreement (RAA) is the contract that governs the relationship between ICANN and its accredited registrars (a directory of accredited registrars can be found at http://www.internic.net/regist.html). Its provisions also may have impacts on registrants and other third parties involved in the domain name system. In June 2013, the ICANN Board approved a new 2013 RAA (the provisions of which can be found at http://www.icann.org/en/resources/registrars/raa/approved-with-specs-27jun13-en.pdf [PDF, 913 KB]).

In initiating negotiations for the 2013 RAA with the Registrars Stakeholder Group in October 2011, the ICANN Board had also requested an Issue Report from the GNSO that, upon the conclusion of the RAA negotiations, would start a GNSO Policy Development Process (PDP) to address remaining issues not dealt with in the RAA negotiations that would be suited to a PDP. The GNSO Council approved the charter for this effort at its meeting on 31 October 2013 and a Working Group (WG) was formed. The outcome of this PDP will guide ICANN's implementation of the planned accreditation program for privacy and proxy service providers, as the current Interim Specification relating to privacy and proxy services in the 2013 RAA is set to expire on 1 January 2017.

The WG's charter contains 19 specific questions for the WG, derived from the Staff Paper that was published in September 2013 summarizing the outcome of the 2013 RAA negotiations, and several additional questions covering additional, related topics. The Charter questions cover issues including registration and maintenance of a privacy/proxy service, provider contactability and responsiveness, de-accreditation and topics that have been of longstanding discussion amongst the ICANN community, including provider obligations in relation to "relay" and "reveal" procedures to handle requests for the disclosure of a privacy/proxy customer's identity and contact details.

The WG's preliminary recommendations cover all aspects of its Chartered questions, and include specific recommendations concerning "relay and "reveal". Some of these preliminary recommendations cover only certain aspects of a Charter topic, with the WG yet to reach consensus on the remaining aspects and open questions. In some instances, a preliminary recommendation or an open question may include bracketed language indicating alternative versions still under consideration by the WG and for which they would particularly welcome community input.

Following analysis of all public comments received, the WG will finalize its recommendations and prepare a Final Report for delivery to the GNSO Council, for its review and action.

Section II: Background

The Working Group (WG) commenced its work in December 2013 through weekly teleconference meetings, discussions on its mailing list and face-to-face sessions involving the broader community at ICANN Public Meetings. In addition, the WG was selected by the GNSOCouncil to participate in a pilot face-to-face full-day session, assisted by a community facilitator, immediately prior to the ICANN Public Meeting in Los Angeles in October 2014. It also received briefings from ICANN's Registrar Services Department and feedback from ICANN's Compliance Department, as well as responses to its solicitations for ICANN community input on its Chartered tasks from the GNSO's Business, Intellectual Property and Internet Service & Connectivity Providers constituencies and the Non-Commercial Stakeholder Group, and ICANN's At-Large Advisory Committee.

The WG has developed preliminary recommendations for a number of the charter questions it was tasked to address, which are described in its Initial Report [PDF, 1.3 MB]. The Initial Report also contains several open questions on which the WG has yet to reach consensus as well as a number of alternative formulations for certain proposals. Community feedback is therefore sought on the preliminary recommendations, open questions and alternative formulations. TheWG will review all public comments received as part of its preparations of its Final Report for delivery to and vote by the GNSO Council.

Section III: Relevant Resources

• Working Group Initial Report [PDF, 1.3 MB]
• Template for Responses (if desired)
• Working Group Charter
• Working Group wiki space

Section IV: Additional Information

N/A

Section V: Reports

Staff Contact

Mary Wong

policy-staff@icann.org

 

FINAL VERSION TO BE SUBMITTED IF RATIFIED

Please download the PDF here.  

---

FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The final draft is provided in both Word and PDF formats. 

Word

PDF

 

---

FIRST DRAFT SUBMITTED

Draft Response to Initial Report of PPSAI 

The ALAC welcomes the opportunity to respond to the Initial Report of the Privacy and Proxy Services Accreditation Issues Report

The ALAC’s response is grounded on four general principles we believe must drive development of the Specifications:

• The protections provided in the final Specification should not be less than that which is required under the Interim Specification

• That there is no discrimination for accessing privacy and proxy services by either natural or legal persons provided the rules developed apply equally across all classes.

• A balance must be struck between legitimate privacy rights of individuals and the legitimate needs of law enforcement and others in determining when and in what circumstances a privacy or proxy service customer’s personal information will be revealed or published

• The specifications may not be so onerous as to result in a chilling effect for users to access privacy and proxy services 

The ALAC’s response to specific questions raised in the Issues Report are as follows:

When must contact requests to the customer be forwarded to the P/P customer?

We agree that all contact requests must be forwarded including:

• those required under the RAA, and from ICANN
• all requests from law enforcement agencies and other third parties alleging domain name abuse.

We hold that requests from law enforcement agencies and ‘other third parties alleging domain name abuse’ should include government agencies (in the jurisdiction of the p/p provider) charged with the regulation of potentially criminal behaviour such as fraud and/or consumer depredations such as misleading and deceptive conduct in that jurisdiction. 

It should be left up to individual p/p providers as to whether other contact requests are forwarded (possibly excepting spam, etc.). We recommend that the classes of such contacts subject be clearly stated and published in the provider’s terms of service. 

Should or must the provider forward a further request(s), at whose costs and should there be a limit on the number of requests?

In every day life, individuals are not required to respond to any communication, whether by post, telephone or other electronic communication. Communication through the Internet should not be treated differently.

In response to this question, it should be left up to the individual provider as to the circumstances in which a contact request will be forwarded by other means. Equally, it should be left to the provider as to whether they are prepared to use other means to contact the customer and whether they are prepared to absorb the costs.  In general terms, however, the cost should be on the party making a contact request.

In any event, persistent failure to reach a customer by means properly noted in the terms of service should trigger re-verification of customer’s contact by the provider in keeping with existing terms of the RAA.

If the matter involves potentially serious criminal behaviour or serious misuse of the DNS, law enforcement agencies can become involved.  In other cases, dispute resolution processes such as the UDRP can be used.

Should it be mandatory for accredited P/P service providers to comply with express requests from LEA in the provider’s jurisdiction not to notify a customer? 

Yes.

Should there be mandatory publication for certain types of activity e.g. malware/viruses or violation of terms of service relating to illegal activity?

If misuse of the DNS and/or illegal activity has been proven, most likely other and more severe responses will have been made including termination of use of the domain name by the party providing the privacy or proxy service.

Other questions raised in an Annex to the report include the following:

What (if any) should the remedies be for unwarranted Publication?

Once personal details have been made known either to an individual requestor or more broadly published, the damage has been done.  Depending on the facts of each case, there may be compensation for damage caused by a breach of contract thru civil means.  ICANN Compliance must be notified since such breach may also amount to a breach of the Specification.

Should requestors be allowed to escalate every request to a 3^rd party forum or should the WG develop standards and thresholds

Again, it should be up to individual providers on how they handle contact requests from third parties, as long as the customer is informed of the individual provider’s policies on this issue. 

Finally, one issue that was not addressed in the Issues Report, but is of concern to the ALAC is compliance with the Specification.  Under the 2013 RAA, registrar compliance with the Specification is required, and through the Registrar, its affiliates and resellers. 

Proxy services can be provided by a registrant who, in turn, licenses the use of the domain name to their customer and it is the registrant’s details that appear in the Whois database rather than the proxy service customer.  In those circumstances, it may be possible for registrars (and their affiliates and resellers) to include in contracts with their customers (registrants), a requirement that if the registrant provides a proxy service, they will comply with the Specification.  In that way, enforcement of specification requirements can be through that contractual arrangement.