Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
Comment Close
Date
Statement
Name 

Status

Assignee(s) and
RALO(s)

Call for
Comments
Call for
Comments
Close 
Vote
Announcement 
Vote OpenVote
Reminder
Vote CloseDate of SubmissionStaff Contact and EmailStatement Number
n/aPolicy Development Process (PDP) on Privacy & Proxy Services Accreditation Issues
Status
colourGreen
titleadopted
12Y, 0N, 0A
Alan Greenberg17.04.201423.04.2014 20:00 UTC24.04.2014 00:00 UTC24.04.2014 00:00 UTC30.04.201401.05.2014 23:59 UTC*23.04.2014 22:00 UTC

Glen de Saint Gery gnso.secretariat@gnso.icann.org

AL-ALAC-ST-0414-03-01-EN

For information about this PC, please click here
Toggle Cloak

Cloak
alicebluedashedbluedefrance2

Dear SO/AC Chair,

As you may be aware, the GNSO Council recently initiated a Policy Development Process (PDP) on Privacy & Proxy Services Accreditation Issues. As part of its efforts to obtain input from the broader ICANN Community at an early stage of its deliberations, the Working Group that has begun to explore questions related to these issues is looking for any input or information that may help inform our deliberations.

Below you will find an overview of the issues that the WG has been assigned to address in its charter. We would appreciate it very much if you would examine the items and provide any input that your group may have to the GNSO Secretariat (gnso.secretariat@gnso.icann.org). If you cannot submit your input, but your group would like to contribute, please let us know when we can expect to receive your contribution so that we can plan accordingly. While we would like your thoughts on all items, responses to a subset still will be helpful. Please feel free also to suggest modifications to or additional questions that your group believes useful for the WG to address.

Your input will be valuable for informing the WG as we begin our work. We have included a list of relevant definitions at the end of this document in the hope that they will be of assistance to your group in providing input. For further background information on our WG’s activities to date and to follow our work as we move forward, see https://community.icann.org/x/9iCfAg.

 

With best regards,

Don Blumenthal, Chair of the Privacy & Proxy Services Accreditation Issues PDP Working Group

 

 

QUESTIONS FOR WHICH THE WG WAS CHARTERED AND IS SEEKING INPUT

This RAA PDP Working Group (WG) was created to provide the GNSO Council with policy recommendations regarding the issues identifiedduring the 2013 RAA negotiations, including recommendations made by law enforcement and GNSO workinggroups, that were not addressed during the 2013 RAA negotiations but are otherwise suited for a PDP. These issues focus onthe accreditation of Privacy & Proxy Services.

As part of its deliberations on the matter, the RAA PDP WG was asked to, at a minimum, consider those issues detailed in theStaff Briefing Paper published on 16 September 2013 and included in the WG Charter (seehttps://community.icann.org/display/gnsopnpsrvaccrdtwg/WG+Charter). The WG has organized the questions in the hope that it adds clarity.

I. MAIN ISSUES

  1. What, if any, are the types of Standard Service Practices that should be adopted and published by ICANN-accredited privacy/proxy service providers? 
  2. Should ICANN distinguish between privacy and proxy services for the purpose of the accreditation process?  
  3. What are the contractual obligations, if any, that if unfulfilled would justify termination of customer access by ICANN-accredited privacy/proxy service providers? 
  4. What types of services should be covered, and would be the forms of non-compliance that would trigger cancellation or suspension of registrations? 
  5. What are the effects of the privacy and proxy service specification contained in the 2013 RAA? Have these new requirements improved WHOIS quality, registrant contactability and service usability?
  6. What should be the contractual obligations of ICANN accredited registrars with regard to accredited privacy/proxy service providers? Should registrars be permitted to knowingly accept registrations where the registrant is using unaccredited service providers that are however bound to the same standards as accredited service providers?  

II. MAINTENANCE  

  1. Should ICANN-accredited privacy/proxy service providers be required to label WHOIS entries to clearly show when a registration is made through a privacy/proxy service?
  2. Should ICANN-accredited privacy/proxy service providers be required to conduct periodic checks to ensure accuracy of customer contact information; and if so, how?
  3. What rights and responsibilities should customers of privacy/proxy services have? What obligations should ICANN-accredited privacy/proxy service providers have in managing these rights and responsibilities? Clarify how transfers, renewals, and PEDNR policies should apply.
  4. Should ICANN-accredited privacy/proxy service providers distinguish between domain names used for commercial vs. personal purposes? Specifically, is the use of privacy/proxy services appropriate when a domain name is registered for commercial purposes?
  5. Should there be a difference in the data fields to be displayed if the domain name is registered or used for a commercial purpose, or by a commercial entity instead of a natural person? 
  6. Should the use of privacy/proxy services be restricted only to registrants who are private individuals using the domain name for non-commercial purposes?

III. CONTACT  

  1. What measures should be taken to ensure contactability and responsiveness of the providers? 
  2. Should ICANN-accredited privacy/proxy service providers be required to maintain dedicated points of contact for reporting abuse? If so, should the terms be consistent with the requirements applicable to registrars under Section 3.18 of the RAA?
  3. Should full WHOIS contact details for ICANN-accredited privacy/proxy service providers be required?
  4. What are the forms of alleged malicious conduct, if any, that would be covered by a designated published point of contact at an ICANN-accredited privacy/proxy service provider?

IV. RELAY  

  1. What, if any, are the baseline minimum standardized relay processes that should be adopted by ICANN-accredited privacy/proxy service providers?
  2. Should ICANN-accredited privacy/proxy service providers be required to forward to the customer all allegations of illegal activities they receive relating to specific domain names of the customer? 

V. REVEAL

  1. What, if any, are the baseline minimum standardized reveal processes that should be adopted by ICANN-accredited privacy/proxy service providers?
  2. Should ICANN-accredited privacy/proxy service providers be required to reveal customer identities for the specific purpose of ensuring timely service of cease and desist letters? 
  3. What forms of alleged malicious conduct, if any, and what evidentiary standard would be sufficient to trigger such disclosure? What specific alleged violations, if any, would be sufficient to trigger such publication?
  4. What safeguards must be put in place to ensure adequate protections for privacy and freedom of expression?
  5. What safeguards or remedies should be available in cases where publication is found to have been unwarranted?
  6. What circumstances, if any, would warrant access to registrant data by law enforcement agencies?
  7. What clear, workable, enforceable and standardized processes should be adopted by ICANN-accredited privacy/proxy services in order to regulate such access (if such access is warranted)? 


LIST OF RELEVANT DEFINITIONS

(1)   Privacy & Proxy Services

The following definitions are those used by the GNSO in the various WHOIS studies it commissioned between 2010-2012 (http://gnso.icann.org/issues/whois/whois-working-definitions-study-terms-18feb09.pdf):

  • Privacy services hide customer details from going into WHOIS. Privacy service providers, which may include registrars and resellers, may offer alternate contact information and mail forwarding services while not actually shielding the domain name registrant’s identity. By shielding the user in these ways, these services are promoted as a means of protecting personal privacy, free speech and human rights and avoiding personal data misuse.
  • Proxy services protect users’ privacy by having a third-party register the name. The third-party is most often the proxy service itself. The third-party allows the user to access and use the domain name through a separate agreement or some other arrangement directly with the user. Proxy service providers may include web design, law, and marketing firms; web hosts, registrar subsidiaries, resellers and individuals.

NOTE: The 2013 Registrar Accreditation Agreement contains a temporary specification relating to Privacy & Proxy Services, which refers to these services as follows (http://www.icann.org/en/resources/registrars/raa/approved-with-specs-27jun13-en.pdf):

1.1 "P/P Customer" means, regardless of the terminology used by the P/P Provider, the licensee, customer, beneficial user, beneficiary, or other recipient of Privacy Services and Proxy Services.

1.2 "Privacy Service" is a service by which a Registered Name is registered to its beneficial user as the Registered Name Holder, but for which alternative, reliable contact information is provided by the P/P Provider for display of the Registered Name Holder's contact information in the Registration Data Service (Whois) or equivalent services.

 1.3 "Proxy Service" is a service through which a Registered Name Holder licenses use of a Registered Name to the P/P Customer in order to provide the P/P Customer use of the domain name, and the Registered Name Holder's contact information is displayed in the Registration Data Service (Whois) or equivalent services rather than the P/P Customer's contact information.

 1.4 "P/P Provider" or "Service Provider" is the provider of Privacy/Proxy Services, including Registrar and its Affiliates, as applicable. 

(2)   Relay & Reveal Requests

The following descriptions are taken from the GNSO’s Terms of Reference for a proposed Proxy & Privacy Relay & Reveal Study in 2010 (http://gnso.icann.org/issues/whois/whois-proxy-privacy-relay-reveal-studies-tor-29sep10-en.pdf):

  • For many domains, Registered Name Holders can be reached directly at addresses obtained from WHOIS. However, for Privacy/Proxy-registered domains, Registered Name Holders or third party licensees cannot be reached directly via WHOIS- published addresses. Instead, communication relay requests may be sent to the Privacy/Proxy service provider published in WHOIS, or attempted using addresses obtained from other sources, websites or communications associated with the domain.

For many domains (including those registered via Privacy services), the Registered Name Holder's identity is published directly in WHOIS. However, for domains registered via Proxy services, the name of the licensee is not published in WHOIS; third party licensees can typically only be identified by asking the Proxy to reveal the licensee's identity, given reasonable evidence of actionable harm.

FINAL VERSION TO BE SUBMITTED IF RATIFIED

Please click here to download of the copy of the pdf below. 

PDF
nameAL-ALAC-ST-0414-03-01-EN.pdf

FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The ALAC strongly supports amending the Privacy Proxy Specification such that:

  • It is applicable to all Privacy and Proxy providers.
  • The personal details of the beneficial user are verified in accordance with verification requirements in the 2013 RAA. The process should ensure that, at least when the information is collected, that the proposed beneficial user is a real person/organisation and that the contact details are those of the proposed beneficial user.
  • Limits on access to the personal information of the beneficial user must be clear and balance the legitimate privacy requirements of the beneficial user as against the legitimate needs of law enforcement agencies and UDRP providers.

The ALAC further advises that in the case where a beneficial user is revealed during the process of a UDRP, and that UDRP proceeding finds in favour of the registrant and not the entity filing the UDRP, the identity and contact information of the beneficial user must NOT be revealed in any public document resulting from the UDRP.

FIRST DRAFT SUBMITTED

The ALAC strongly supports amending the Privacy Proxy Specification such that:

  • It is applicable to all Privacy and Proxy providers.
  • The personal details of the beneficial user are verified in accordance with verification requirements in the 2013 RAA. The process should ensure that, at least when the information is collected, that the proposed beneficial user is a real person/organisation and that the contact details are those of the proposed beneficial user.
  • Limits on access to the personal information of the beneficial user must be clear and balance the legitimate privacy requirements of the beneficial user as against the legitimate needs of law enforcement agencies and UDRP providers.

One further thought. The current UDRP process requires that the beneficial user be reported in the results of the UDRP, regardless of outcome. This allows a beneficial user to be revealed publicly even if the win the dispute and if the UDRP was filed with the explicit intent of revealing the beneficial user. I would suggest that in the interest of protecting registrants who opt for privacy, we recommend that the PDP WG consider the possibility of the beneficial user not be revealed in the case of a failed UDRP. It is unclear (to me) if this is strictly within the scope of the PDP, but if not, the WG could make a recommendation that this be done when the UDRP is revised (scheduled in the near future).