Exclusive gang of 10 to work on making ICANN the Whois gatekeeper

Ten people have been picked to work on a system that would see ICANN act as the gatekeeper for private Whois data.

The organization today announced the composition of what it’s calling the Technical Study Group on Access to Non-Public Registration Data, or TSG-RD.

As the name suggests, the group is tasked with designing a system that would see ICANN act as a centralized access point for Whois data that, in the GDPR era, is otherwise redacted from public view.

ICANN said such a system:

would place ICANN in the position of determining whether a third-party’s query for non-public registration data ought to be approved to proceed. If approved, ICANN would ask the appropriate registry or registrar to provide the requested data to ICANN, which in turn would provide it to the third party. If ICANN does not approve the request, the query would be denied. 

There’s no current ICANN policy saying that the organization should take on this role, but it’s one possible output of the current Expedited Policy Development Process on Whois, which is focusing on how to bring ICANN policy into compliance with GDPR.

The new group is not going to make the rules governing who can access private Whois data, it’s just to create the technical framework, using RDAP, that could be used to implement such rules.

The idea has been discussed for several months now, with varying degrees of support from contracted parties and the intellectual property community.

Registries and registrars have cautiously welcomed the notion of a central ICANN gateway for Whois data, because they think it might make ICANN the sole “data controller” under GDPR, reducing their own legal liability.

IP interests of course leap to support any idea that they think will give them access to data GDPR has denied them.

The new group, which is not a formal policy-making body in the usual ICANN framework, was hand-picked by Afilias CTO Ram Mohan, at the request of ICANN CEO Goran Marby.

As it’s a technical group, the IP crowd and other stakeholders don’t get a look-in. It’s geeks all the way down. Eight of the 10 are based in North America, the other two in the UK. All are male. A non-zero quantity of them have beards.

• Benedict Addis, Registrar Of Last Resort.
• Gavin Brown, CentralNic.
• Jorge Cano, NIC Mexico.
• Steve Crocker, former ICANN chair.
• Scott Hollenbeck, Verisign.
• Jody Kolker, GoDaddy.
• Murray Kucherawy, Facebook.
• Andy Newton, ARIN.
• Tomofumi Okubo, DigiCert.

While the group is not open to all-comers, it’s not going to be secretive either. Its mailing list is available for public perusal here, and its archived teleconferences, which are due to happen for an hour every Tuesday, can be found here. The first meeting happened this week.

Unlike regular ICANN work, the new group hopes to get its work wrapped up fairly quickly, perhaps even producing an initial spec at the ICANN 64 meeting in Kobe, Japan, next March.

For ICANN, that’s Ludicrous Speed.

Facebook clashes with registrars after massive private data request

Facebook is on the warpath, testing the limits of personal data disclosure in the post-GDPR world.
Via an intermediary called AppDetex, the company recently filed 500 requests for non-public Whois contact information with various registrars, covering potentially thousands of domains, and is now complaining to ICANN that almost all of the replies it received were “non-responsive”.
DI has learned that Facebook is not only asking registrars for Whois data on specific domains it believes infringe its trademarks, however. It’s also asking them to provide complete lists of domains owned by the same registrant, along with the Whois data for those domains, something registrars have never been obliged to provide, even pre-GDPR.
It’s now pissed that almost all of its requests were blown off, with registrars giving various reasons they could not provide the data.
AppDetex is a brand protection services firm and ICANN-accredited registrar. It’s built an automated system for generating Whois disclosure requests and sending them to registrars.
Ben Milam, its general counsel, wrote to ICANN last week to urge the organization to come up with, and more importantly enforce, a framework for brand owners to request private Whois data.
The company has stopped short of filing formal complaints against the registrars with ICANN’s compliance division, but Milam said it will in future:

we do plan to file complaints in the future, but not until ICANN has (i) established proper disclosure guidelines for non-public WHOIS requests for the registrar base to follow, and (ii) implemented an enforcement process that will ensure that brand holder requests are being satisfied.

The letter says that only one registrar responded adequately, to three of its disclosure requests. That was FBS Inc, which I believe is Turkey’s largest registrar. Turkey is not in the EU.
One registrar on Facebook’s naughty list is Ireland-based Blacknight Solutions, which received three disclosure requests but did not provide AppDetex with the information it wanted.
Blacknight CEO Michele Neylon shared a copy of one of these requests, which he said was received via email July 2, with DI.
In my view, the request is clearly automated, giving the registrar a deadline to respond 48 hours in the future accurate to the second. It cites five Facebook trademarks — Facebook, FB, Instagram, Oculous and WhatsApp.
At Blacknight’s request, I won’t disclose the domain here, but it begins with the string “insta”. At first glance it’s not an clear-cut case of cybersquatting the Instagram trademark. It’s currently parked, displaying ad links unrelated to Instagram.
The email asks the registrar to turn over the full non-public Whois contact information for the registrant, technical contact and administrative contact, but it goes on to also ask for:

4. All other domain names registered under this registrant’s account or email address
5. All information in requests 1, 2, and 3 for all domains provided in response to request 4

This would increase the volume of Whois records requested by Facebook from 500 to, very probably, thousands.
This reverse-Whois data was not previously available via vanilla registrar-provided Whois, though it may be under successor protocol RDAP. Brand owners would have to use a commercial third-party service such as DomainTools in order to connect a registrant to the rest of his portfolio.
It’s debatable whether registrars will be obliged to provide this reverse-Whois capability on non-public data to brand owners even after RDAP becomes the norm.
The request says Facebook needs the data in order “to investigate and prevent intellectual property infringement and contact infringing parties and relevant service providers” and “to facilitate legal action against the registrant”.
Facebook says it’s entitled to the data under Article 6(1)(f) of the GDPR as it’s “necessary for the purposes of our legitimate interests, namely (1) identifying the registered holder of a domain name and their contact information to investigate and respond to potential trademark infringement and (2) enforcing legal claims.”
Currently, registrars are governed by ICANN’s Temporary Specification for Whois, a GDPR-related Band-Aid designed to last until the ICANN community can create a formal policy.
Access to non-public Whois data is governed by section 4 of the Temp Spec, which reads in part:

Registrar and Registry Operator MUST provide reasonable access to Personal Data in Registration Data to third parties on the basis of a legitimate interests pursued by the third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the Registered Name Holder or data subject pursuant to Article 6(1)(f) GDPR.

In the absence of a formal ICANN policy, legal precedent, or specific guidance from data protection authorities, it’s not abundantly clear how registrars are supposed to comply with this clause of the spec, which may explain why Facebook is getting different responses from different registrars.
Neylon said that Blacknight responded to the disclosure requests by asking Facebook to produce an Irish court order.
He said the requests were overly broad, did not provide any contact information for the requester, did not provide a specific complaint against the registrants, and did not specify what privacy safeguards Facebook planned to subject the data to once it was handed over.
It seems Blacknight was not alone. According to AppDetex’s letter to ICANN, at least six other registrars replied denying the requests and saying:

complainant (Facebook) must utilize legal process of a subpoena or court order; complainant must file a UDRP action; complainant must file an action with WIPO; complainant must contact WIPO; and/or complainant’s request has been forwarded to the domain owner.

Milam said (pdf) that he expects the volume of requests to increase and that registrars’ responses will be forwarded to ICANN Compliance to help create a normalized framework for dealing with such requests.

ICANN approves messy, unfinished Whois policy

With a week left on the GDPR compliance clock, ICANN has formally approved a new Whois policy that will hit all gTLD registries and registrars next Friday.
The Temporary Specification for gTLD Registration Data represents the first time in its history ICANN has invoked contractual clauses that allow it to create binding policy in a top-down fashion, eschewing the usual community processes.
The policy, ICANN acknowledges, is not finished and needs some work. I would argue that it’s also still sufficiently vague that implementation in the wild is likely to be patchy.
What’s in public Whois?
The policy is clearest, and mostly unchanged compared to previous drafts, when it comes to describing which data may be published in public Whois and which data must be redacted.
If you do a Whois query on a gTLD domain from next week, you will no longer see the name, address, phone/fax number or email address of the registrant, admin or tech contacts.
You will continue to see the registrant’s organization, if there is one, and the country in which they are based, as well as some information about the registrar and name servers.
In future, public RDAP-based Whois databases will have to output “REDACTED FOR PRIVACY” in these fields, but for now they can just be blank.
While the GDPR is only designed to protect the privacy of humans, rather than companies, and only those connected to the European Union, the ICANN policy generally assumes that all registrants will be treated the same.
It will be possible for any registrant to opt out of having their data redacted, if being contactable is more important to them than their privacy.
What about privacy services?
Since the May 14 draft policy, ICANN has added a carve-out for domains that are already registered using commercial privacy/proxy services.
Whois records for those domains are NOT going to change under the new policy, which now has the text:

in the case of a domain name registration where a privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar MUST return in response to any query full WHOIS data, including the existing proxy/proxy pseudonymized email.

In the near term, this will presumably require registries/registrars to keep track of known privacy services. ICANN is working on a privacy/proxy accreditation program, but it’s not yet live.
So how do you contact registrants?
The policy begins to get more complicated when it addresses the ability to actually contact registrants.
In place of the registrant’s email address in public Whois, registries/registrars will now have to publish an anonymized email address or link to a web-based contact form.
Neither one of these options should be especially complex to implement — mail forwarding is a staple service at most registrars — but they will take time and effort to put in place.
ICANN indicated earlier this week that it may give contracted parties some breathing room to get this part of the policy done.
Who gets to see the private data?
The policy begins to fall apart when it describes granting access to full, unexpurgated, thick Whois records to third parties.
It seems to do a fairly good job of specifying that known quantities such as URS/UDRP providers, escrow providers, law enforcement, and ICANN itself continue to get access.
But it’s fuzzier when it comes to entities that really would like to continue to access Whois data, such as trademark lawyers, security service providers and consumer protection concerns.
While ICANN is adamant that third parties with “legitimate interests” should get access, the new policy does not enumerate with any specificity who these third parties are and the mechanism(s) contracted parties must use to grant such access.
This is what the policy says:

Registrar and Registry Operator MUST provide reasonable access to Personal Data in Registration Data to third parties on the basis of a legitimate interests pursued by the third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the Registered Name Holder or data subject

This appears to give contracted parties the responsibility to make legal judgment calls — balancing the GDPR-based privacy rights of the registrant against the “legitimate interests” of the requester — every time they get a thick Whois request.
The policy goes on to say that when European privacy regulators, the courts, or other legislation or regulation has specifically approved a certain class of requester, ICANN will relay this news to the industry and it will have 90 days to make sure that class gets full Whois access.
But the policy does not specify any formal mechanism by which anyone goes about requesting a thick record.
Do they just phone up the registrar and ask? Does the registrar have to publish a contact address for this purpose? How does the registrar go about confirming the requester is who they say they are? Should they keep white-lists of approved requesters, or approve each request on a domain-by-domain basis? When does the right of a trademark owner outweigh the privacy right of an individual?
None of these questions are answered by the policy, but in a non-binding annex ICANN points to ongoing community work to create an “accreditation and access model”.
That work appears to be progressing at a fair rapid clip, but I suspect that’s largely because the trademarks lawyers are holding the pens and discussions are not following ICANN’s usual consensus-building policy development rules.
When the work is absorbed into the ICANN process, we could be looking at a year or more before something gets finalized.
How will transfers work?
Because Whois is used during the inter-registrar transfer process, ICANN has also had to tweak its Inter-Registrar Transfer Policy to take account of instances where registrars can’t access each other’s databases.
Basically, it’s scrapping the requirement for gaining registrars to obtain a Form of Authorization from the Whois-listed registrant before they start an inbound transfer.
This will remove one hoop registrants have to jump through when they switch registrars (though losing registrars still have to obtain an FOA from them) at the cost of making it marginally easier for domain theft to occur.
What happens next?
ICANN acknowledges, in seven bullet points appended to the policy, that the community has more work to do, mainly on the access/accreditation program.
Its board resolution “acknowledges that there are other implementation items that require further community conversation and that the Board encourages the community to resolve as quickly as possible”.
The board has also asked ICANN staff to produce more explanatory materials covering the policy.
It also temporarily called off its Governmental Advisory Committee consultation, which I wrote about here, after receiving a letter from the GAC.
But the big next step is turning this Temporary Policy into an actual Consensus Policy.
The Temporary Policy mechanism, which has never been used before, is set up such that it has to be renewed by the board every 90 days, up to a maximum of one year.
This gives the GNSO until May 25 next year to complete a formal Policy Development Process. In fact, it will be a so-called “Expedited” PDP or EPDP, that cuts out some of the usual community outreach in order to provide a speedier result.
This, too, will be an unprecedented test of an ICANN policy-making mechanism.
The GNSO will have the Temporary Policy baseline to work from, but the Temporary Policy is also subject to board-level changes so the goalposts may move while the game is being played.
It’s going to be a big old challenge, and no mistake.

ICANN chief tells industry to lawyer up as privacy law looms

The domain name industry should not rely on ICANN to protect it from incoming EU privacy law.
That’s the strong message that came out of ICANN 60 in Abu Dhabi last week, with the organization’s CEO repeatedly advising companies to seek their own legal advice on compliance with the General Data Protection Regulation.
The organization also said that it will “defer taking action” against any registrar or registry that does not live up its contractual Whois commitments, within certain limits.
“GDPR is a law. I didn’t come up with it, it didn’t come from ICANN policy, it’s the law,” Marby said during ICANN 60 in Abu Dhabi last week.
“This is the first time we’ve seen any legislation that has a direct impact on our ability to make policies,” he said.
GDPR is the EU law governing how companies treat the private information of individuals. While in force now, from May next year companies in any industry found in breach of GDPR could face millions of euros in fines.
For the domain industry, it is expected to force potentially big changes on the current Whois system. The days of all Whois contact information published freely for all to see may well be numbered.
But nobody — not even ICANN — yet knows precisely how registries and registrars are going to be able to comply with the law whilst still publishing Whois data as required by their ICANN contracts.
The latest official line from ICANN is:

At this point, we know that the GDPR will have an impact on open, publicly available WHOIS. We have no indication that abandoning existing WHOIS requirements is necessary to comply with the GDPR, but we don’t know the extent to which personal domain registration data of residents of the European Union should continue to be publicly available.

Marby told ICANNers last week that it might not be definitively known how the law applies until some EU case law has been established in the highest European courts, which could take years.
A GNSO working group and ICANN org have both commissioned legal studies by European law experts. The ICANN one, by Swedish law firm Hamilton, is rather more comprehensive and can be read here (pdf).
Even after this report, Marby said ICANN is still in “discovery” mode.
Marby encouraged the industry to not only submit their questions to ICANN, to be referred on to Hamilton for follow-up studies, but also to share whatever legal advice they have been given and are able to share.
He and others pointed out that Whois is not the only point of friction with GDPR — it’s a privacy law, not a Whois law — so registries and registrars should be studying all of their personal data collection processes for potential conflicts.
Because there is very likely going to be a clash between GDPR compliance and ICANN contract compliance, ICANN has suspended all enforcement actions against Whois violations, within certain parameters.
It said last week that: “ICANN Contractual Compliance will defer taking action against any registry or registrar for noncompliance with contractual obligations related to the handling of registration data.”
This is not ICANN saying that registries and registrars can abandon Whois altogether, the statement stresses, but they might be able to adjust their data-handling models.
Domain firms will have to show “a reasonable accommodation of existing contractual obligations and the GDPR” and will have to submit their models to ICANN for review by Hamilton.
ICANN also stressed that registries may have to undergo a Registry Services Evaluation Process review before they can deploy their new model.
The organization has already told two Dutch new gTLD registries that they must submit to an RSEP, after .amsterdam and .frl abruptly stopped publishing Whois data for private registrants recently.
General counsel John Jeffrey wrote to the registries’ lawyer (pdf) to state that an RSEP is required regardless of whether the “new registry service” was introduced to comply with local law.
“One of the underlying purposes of this policy is to ensure that a new registry service does not create and security, stability or competition concerns,” he wrote.
Jeffrey said that while Whois privacy was offered at the registry level, registrars were still publishing full contact details for the same registrants.
ICANN said last week that it will publish more detailed guidance advising registries and registrars how to avoid breach notices will be published “shortly”.

Verisign and Afilias testing Whois killer

Verisign and Afilias have become the first two gTLD registries to start publicly testing a replacement for Whois.
Both companies have this week started piloting implementations of RDAP, the Registration Data Access Protocol, which is expected to usurp the decades-old Whois protocol before long.
Both pilots are in their very early stages and designed for a technical audience, so don’t expect your socks to be blown off.
The Verisign pilot offers a web-based, URL-based or command-line interface for querying registration records.
The output, by design, is in JSON format. This makes it easier for software to parse but it’s not currently very easy on the human eye.
To make it slightly more legible, you can install a JSON formatter browser extension, which are freely available for Chrome.
Afilias’ pilot is similar but does not currently have a friendly web interface.
Both pilots have rudimentary support for searching using wildcards, albeit with truncated result sets.
The two new pilots only currently cover Verisign’s .com and .net registries and Afilias’ .info.
While two other companies have notified ICANN that they intend to run RDAP pilots, these are the first two to go live.
It’s pretty much inevitable at this point that RDAP is going to replace Whois relatively soon.
Not only has ICANN has been practically champing at the bit to get RDAP compliance into its registry/registrar contracts, but it seems like the protocol could simplify the process of complying with incoming European Union privacy legislation.
RDAP helps standardize access control, meaning certain data fields might be restricted to certain classes of user. Cops and IP enforcers could get access to more Whois data than the average blogger or domainer, in other words.
As it happens, it’s highly possible that this kind of stratified Whois is something that will be legally mandated by the EU General Data Protection Regulation, which comes into effect next May.

Pilot program for Whois killer launches

ICANN is to oversee a set of pilot programs for RDAP, the protocol expected to eventually replace Whois.
Registration Data Access Protocol, an IETF standard since 2015, fills the same function as Whois, but it is more structured and enables access control rules.
ICANN said this week that it has launched the pilot in response to a request last month from the Registries Stakeholder Group and Registrars Stakeholder Group. It said on its web site:

The goal of this pilot program is to develop a baseline profile (or profiles) to guide implementation, establish an implementation target date, and develop a plan for the implementation of a production RDAP service.

Participation will be voluntary by registries and registrars. It appears that ICANN is merely coordinating the program, which will see registrars and registrars offer their own individual pilots.
So far, no registries or registrars have notified ICANN of their own pilots, but the program is just a few days old.
It is expected that the pilots will allow registrars and registries to experiment with different types of profiles (how the data is presented) and extensions before ICANN settles on a standard, contractually enforced format.
Under RDAP, ICANN/IANA acts as a “bootstrapping” service, maintaining a list of RDAP servers and making it easier to discover which entity is authoritative for which domain name.
RDAP is basically Whois, but it’s based on HTTP/S and JSON, making it easier to for software to parse and easier to compare records between TLDs and registrars.
It also allows non-Latin scripts to be more easily used, allowing internationalized registration data.
Perhaps most controversially, it is also expected to allow differentiated access control.
This means in future, depending on what policies the ICANN community puts in place, millions of current Whois users could find themselves with access to fewer data elements than they do today.
The ICANN pilot will run until July 31, 2018.

Registries rebel against ICANN’s Whois upgrade decree

Registry operators are challenging an ICANN decision to force them to launch a new Whois-style service, saying it will cost them too much money.
The Registries Stakeholder Group has filed a Request for Reconsideration — a low-level appeal — of a decision asking them to launch RDAP services to complement their existing Whois.
RDAP, Registration Data Access Protocol, is being broadly touted as the successor to Whois.
It offers the same functionality — you can query who owns a domain — but the data returned is more uniformly structured. It also enables access control, so not every user would have access to every field.
The RySG now claims that ICANN is trying to sneak an obligation to implement RDAP into its registry agreements through a “backdoor” in the form of the new Consistent Labeling and Display Policy.
That policy, which originated in a formal, community-driven GNSO Policy Development Process, seeks to normalize Whois (or Registration Data Services, in its generic not protocol-specific wording) output to make it easier to machine-read.
It applies to all gTLDs except .com, .net and .jobs (which are “thin” registries) and would come into effect February 1 next year.
Registries appear happy to implement the CL&D policy, but not as currently written. It now contains, almost as an aside, this requirement:

The implementation of an RDAP service in accordance with the “RDAP Operational Profile for gTLD Registries and Registrars” is required for all gTLD registries in order to achieve consistent labeling and display.

The RySG argues in its RfR (pdf) that implementing RDAP was never part of the community-endorsed plan, and that it is not “commercially feasible” to do so right now.

The 2012 new gTLD Registry Agreement specifies that implementation of the protocol now known as RDAP be commercially feasible before it’s required. The RySG can’t even respond as to whether it’s feasible or not since no reasoning to that regard was provided in the notice to implement such services.
Furthermore, some of our members are on record stating that since the RDAP profile replicates the known deficiencies of WHOIS – which is currently being studied by a PDP WG – so it’s not commercially feasible to deploy it to mimic a flawed system.
The introduction of RDAP represents an additive requirement for Registries to operate a new (additive) service. As there are no provisions for the sunset of the legacy Whois service, it’s unclear how this additional requirement can be considered commercially feasible.

In other words, the registries think it could be too costly to deploy RDAP and Whois at the same time, especially given that RDAP is not finished yet.
It’s yet another case of domain companies accusing ICANN the organization of slipping in requirements without community support.
Whether the RfR will be successful is debatable. There’s only been a few Reconsideration requests that have been approved by the ICANN board in the history of the mechanism.
However, the board may be feeling especially diligent when it comes to look at this particular RfR, due to the spotlight that was recently shone on the Reconsideration process by an Independent Review Process panel, which determined that the board just rubber-stamped decisions written by house lawyers.