ICANN’s new domain Transfer Policy, which comes into effect tomorrow, creates risks for users of privacy/proxy services, registrars and others haved warned.
The policy could lead to private registrants having their contact information published in the public Whois for 60 days, the GNSO Council expects to formally tell ICANN this week.
“This could threaten privacy for at-risk registrants without clear benefit,” the Council says in a draft letter to the ICANN board.
The revised Transfer Policy was designed to help prevent domain hijacking.
The main change is that whenever there’s a “change of registrant”, the gaining and losing registrants both have to respond to confirmation emails before the change is processed.
However, “change of registrant” is defined in such a way that the confirmation emails would be triggered even if the registrant has not changed.
For example, if you change your last name in your Whois records due to marriage or divorce, or if you change email addresses, that counts as a change of registrant.
It now turns out that ICANN considers turning a privacy service on or off as a change of registrant, even though that only affects the public Whois data and not the underlying customer data held by the registrar.
The GNSO Council’s draft letter states:
ICANN has advised that any change to the public whois records is considered a change of registrant that is subject to the process defined through IRTP-C. Thus, turning a P/P service on or off is, from ICANN’s view, a change of registrant. It requires the CoR [change of registrant] process to be followed and more importantly could result in a registrant exposing his/her information in the public whois for 60 days. This could threaten privacy for at-risk registrants without clear benefit.
My understanding is that the exposure risk outlined here would only be to registrants who attempt to turn on privacy at their registrar then for whatever reason ignore, do not see or do not understand the subsequent confirmation emails.
Depending on implementation, it could lead to customers paying for a privacy service and not actually receiving privacy.
On the other side of the coin, it’s possible that an actual change in registrant might not trigger the CoR process if both gaining and losing registrants both use the same privacy service and therefore have identical Whois records.
The Council letter also warns about a possible increase in spam due to the changes:
many P/P services regularly generate new email addresses for domains in an effort to reduce spam. This procedure would no longer be possible, and registrants may be subject to unwanted messaging. Implementing the CoR for email changes that some providers do as often as every 3-5 days is not feasible.
ICANN has been aware of these issues for months. Its suggested solution is for registrars to make themselves the “Designated Agent” — a middleman permitted to authorize transfers — for all of their customers.
As we reported earlier this week, many large registrars are already doing this.
But registrars and the GNSO Council want ICANN to consider reinterpreting the new policy to exclude privacy/proxy services until a more formal GNSO policy can be created.
While the Policy Development Process that created the revised transfer rules wound up earlier this year, a separate PDP devoted to creating rules of privacy/proxy services is still active.
The Council suggests that this working group, known as PPSAI, could assume the responsibility of clearing up the mess.
In the meantime, registrars are rather keen that they will not get hit with breach notices by ICANN Compliance for failing to properly implement to what seems to be a complex policy.