You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Public Comment CloseStatement
Name 

Status

Assignee(s)

Call for
Comments Open
Call for
Comments
Close 
Vote OpenVote CloseDate of SubmissionStaff Contact and EmailStatement Number

07 July 2017

Revised ICANN Procedure for Handling WHOIS Conflicts with Privacy Law: Process and Next Steps

COMMENT

Christopher Wilkinson

Erich Schweighofer

Annette Mühlberg

Olivier Crepin-Leblond

02 June 2017

26 June 2017

TBC

Hide the information below, please click here 

 

FINAL VERSION TO BE SUBMITTED IF RATIFIED

The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote. 

 


FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.

 


FIRST DRAFT SUBMITTED

The first draft submitted will be placed here before the call for comments begins.

DRAFT Rev 2 02/06/2017

ICANN Procedure For Handling WHOIS Conflicts with Privacy Law

Response to the public consultation

The At Large Advisory Committee wishes to respond to the public consultation. Although a few of our members participated in the WHOIS-IAG during 2016, we are not satisfied that their advice and other contributions have been adequately taken into consideration by the IAG and the ICANN staff in the final draft now under public consultation.

I. The procedure, as eventually revised on the basis of the IAG report, would include still significant shortcomings which ALAC cannot accept in the interest of the privacy of Internet users.:

  1. The Procedure does not create a level playing field among Registrars. On the contrary, Registrars (and some Registries) subject to privacy laws would have to undertake an onerous case-by-case procedure to obtain the right from ICANN to respect their domestic privacy laws. Whereas Registrars operating out of other jurisdictions would be free to ignore privacy laws which pertain elsewhere. (Point 5, below refers.) That outcome is inconsistent with ICANN's responsibility for maintaining the conditions of fair competition among Registries and Registrars.

  2. The Procedure is manifestly inefficient: We have been informed that the pre-existing procedure has hardly ever been used! Which means in practice, that Registrars subject to privacy laws have effectively functioned outside applicable local law and their Registrants' personal data have been potentially exposed to bulk downloads and other abuses, without their authorisation and possibly without their knowledge. Although we see some elements in the revised procedure that in future the procedure would be more regularly used and implemented, however, it is still far too bureaucratic: 

  3. The revised Procedure would still require a “notification of an investigation, litigation, regulatory processing or other governmental or civil action”, or, as an alternative trigger, a written statement from the agency, e.g. the local data protection authority, that Registry or Registrar may violate local law in fulfilling the he RAA. It is an excessive work for many Data Protection Authorities, Registries and Registrars, to establish evident facts. No Registry or Registrar based in Europe can comply with both GDPR and RAA. ALAC cannot support such an anti-social attitude to applicable laws where Registries and Registrars have to be subject to a formal investigation procedure in order to start the procedure.

  4. The international legal environment for privacy protection is rapidly evolving: We understand that – at least in the European Union and associated countries – the General Data Protection Regulation (GDPR) – will shortly introduce a more stringent, uniform and enforceable data protection law throughout that jurisdiction. This would render the proposed ICANN Procedure obsolete and superfluous

  5. The Procedure is not inclusive: ICANN's position ignores that several million .com/.net/.org domain etc. names are registered by European individuals or businesses  with a US-based registrar that publishes personal data that are not allowed to be published under the GDPR. Although this is not the place to address the GDPR in detail, we suggest that the proposed Procedure should be put on hold, until the implications of GDPR for ICANN have been thoroughly reviewed.

    Meanwhile – independently of the EU GDPR – ALAC rejects the proposed Procedure for the reasons outlined in Points 1-3, above.

II. An Alternative approach:

ALAC recommends that ICANN adopt an entirely different approach to the proaction of privacy in all DNS related applications, notably WHOIS and its successor implementations.

II.A The preferred policy would be for ICANN to implement globally, international best practice in privacy protection. Currently that would appear to be the EU GDPR, although there may well be enhancements arising from better implementations elsewhere.

It is not unusual for ICANN to implement best practice that goes beyond current applicable local laws:

  • Trademark protection in the DNS clearly goes beyond anything that can be ensured on the basis of national laws alone;
  • we are not aware of any network security policies elsewhere which go beyond SSAC's advice and implementation in ICANN's operations;
  • we expect that the global protection of geographical terms and geographical indications throughout the DNS will in due course in practice extend beyond those provided for by national laws alone.

Accordingly, we have no hesitation to formally request that ICANN implement global best practice in the matter of the protection of personal data.

II.B We note that the WHOIS IAG was offered an alternative 'easier' solution to the issue in the form of a 'block exemption' for EU-based and other Registries and Registrars subject to local privacy laws incompatible with ICANN contracts and procedures. That option was also rejected by the IAG and ICANN staff.

ALAC does not support this option at the present time, on the understanding that:

(a) the 'Best Practices' option II.A will be implemented quickly, and

(b) the proposed Procedure will be withdrawn.

  • No labels