[Gnso-epdp-team] Additional Information - Accuracy

Alan Woods alan at donuts.email
Tue Dec 11 12:02:34 UTC 2018

Thank you Margie for this comprehensive review.

I have 3 notes.

*1) Regarding the ICO statement:  **"So if you are using the data to make
decisions that may significantly affect the individual concerned or others**,
you need to put more effort into ensuring accuracy."*   To be clear the
'you' here is relating to the controller's use of the data and whether that
use, by the controller, in the processing of inaccurate data, has a
*significant* impact on the rights of the data subject, or 'others'. The
USE of this data by the controller is the registration of a domain or the
application of our T&Cs; this is not referring to the use by a 3rd party
(be that the registrant or indeed from your POV, Facebook). So from the
Controller's POV, all registration data is tested and the registrant is
indeed required to confirm that data (WHOIS Accuracy Specifications). This
seems very reasonable, given the data collected and the use to which it is
put. Are you expecting the controller to second guess, not 1 but 2
(collection and confirmation process) approvals of the data subject, when
the objective is to ensure that the registrant is contactable, in the event
of query on the domain. Furthermore, there is a secondary system of
accuracy testing, insofar as where WHOIS data is found to be inaccurate, a
complaints process does exist, and let's not forget that the consequence
for the registrant for not updating their data, is the suspension of their
domain. (Which, as Stephanie Perrin has rightly reminded us, is a pretty
severe and hefty consequence for the data subject on a very tight

"*Other" interests* : Beyond this, the impact of inaccurate registration
data in the USE by the controller, i.e. the registration of the domain, to
your interests as an 'other', if I may surmise, only goes so far as to your
ability to seek redress for matter you perceive to be IP infringement in
the domain name itself. Continued inaccuracy of the registrant data (if any
remains) does not however affect the availability of the RPMs which do not
require the registration data to be accurate, as under the temp spec, even
doe claims are now valid. In addition should you choose to go the court
route, obtaining service, substituted or otherwise, should be a simple
matter for any lawyer. I fail to see the how the 'use', therefore is
objectively prejudicing you, or how more watertight accuracy would make any
substantial difference on the avenues already available. I must say it
seems pretty unnecessary, and likely unreasonable, given the use to which
the data is put!

So my point is I fail to see how the use of the data, by the controller, is
substantially prejudicing the interests for which the BCs stand. Accuracy
in this context, and the safeguards inbuilt are objectively reasonable
given the nature of the data and the avenues of redress present. As such,
this is accuracy sufficient to meet the requirements of the GDPR.

*2) SCOPE* I am also struggling to see how this is in scope of the ePDP
team. Our task, again, is to decide whether the provisions of the temp spec
are capable of being confirmed as consensus policy, with or without
modification, as is necessary, to ensure compliance with Data Protection
law. Our job is not to rewrite the WHOIS accuracy specification, but to
apply the expectations of the GDPR (and other legislation as may be
applicable). As written, the temp spec's approach to accuracy vis á vis the
use of the data in the registration process, is reasonable in the
circumstances, and prejudice caused by inaccuracy present is mitigated by
the availability of redress mechanisms that are not actually dependent on
the accuracy of the data, surely this is objectively a sufficient level of
accuracy for that purpose.

3) *Viable Alternative?* Although I don't believe an alternative is
necessary, nor do I believe this task is in scope for the ePDP, you have
also have not provided us with a workable or viable alternative . Perhaps
you could provide us with such a viable option as to how you think accuracy
may be improved in the registration of a domain, in a manner that is
proportional to the objective of the use (i.e the registration). Perhaps
then we may be in a position to make a recommendation to the GNSO for
future policy development?

Kind regards,


[image: Donuts Inc.] <http://donuts.domains>
Alan Woods
Senior Compliance & Policy Manager, Donuts Inc.
The Victorians,
15-18 Earlsfort Terrace
Dublin 2, County Dublin

<https://www.facebook.com/donutstlds>   <https://twitter.com/DonutsInc>

Please NOTE: This electronic message, including any attachments, may
include privileged, confidential and/or inside information owned by Donuts
Inc. . Any distribution or use of this communication by anyone other than
the intended recipient(s) is strictly prohibited and may be unlawful.  If
you are not the intended recipient, please notify the sender by replying to
this message and then delete it from your system. Thank you.

On Sat, Dec 8, 2018 at 12:49 AM Margie Milam <margiemilam at fb.com> wrote:

> Hi-
> I was asked to provide further background for the accuracy discussion
> after yesterday’s EPDP call.   Here is some information to frame our
> further  analysis:
> This EPDP was chartered “to determine if the Temporary
> Specification...should become an ICANN Consensus Policy, as is or with
> modifications, while complying with the GDPR and other relevant privacy and
> data protection law.”  In order to fully comply with GDPR, data -- the very
> subject of this EPDP -- is required to be accurate.
> According to Article 5.1(d)  of the GDPR, personal data shall be "accurate
> and, where necessary, kept up to date; every reasonable step must be taken
> to ensure that personal data that are inaccurate, having regard to the
> purposes for which they are processed, are erased or rectified without
> delay."  Article 39 also has similar language.  Within the GDPR, this is
> the second of three principles about data standards, along with data
> minimization and storage limitation that needs to be addressed.  While we
> have had much discussion about data minimization and storage limitations,
> what’s clearly missing to finalize our deliberations and output about data
> standards is our discussion about data accuracy requirements.
> The ico. (Information Commissioner’s Office in the UK) points out in its
> writings on “Principle (d): Accuracy”
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorganisations_guide-2Dto-2Dthe-2Dgeneral-2Ddata-2Dprotection-2Dregulation-2Dgdpr_principles_accuracy_-23steps&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=h0lLMkeUF_rn5GMhlS2z3vK51MHCcjEetUszEZTvxyg&s=RhTeIrHiyk5mS4H700KfDrYVVkEJElZPkbQjxDs2DOs&e=>
>  that one of the new features of GDPR as compared to the principles under
> its predecessor is that there is now a “clearer *proactive *obligation to
> take reasonable steps to delete or correct inaccurate personal data.”  The
> ICO notes that while “[t]here are clear links here to the right to
> rectification, which gives individuals the right to have inaccurate
> personal data corrected” … “[i]n order to ensure that your records are not
> inaccurate or misleading in [the case of personal data someone else
> provides], you must:
>    - take reasonable steps in the circumstances to ensure the accuracy of
>    the information; and
>    - carefully consider any challenges to the accuracy of the
>    information.”
> The ico. goes on to say that “The more important it is that the personal
> data is accurate, the greater the effort you should put into ensuring its
> accuracy. So if you are using the data to make decisions that may
> significantly affect the individual concerned *or others*, you need to
> put more effort into ensuring accuracy. This may mean you have to get
> independent confirmation that the data is accurate.”  We can all agree that
> the accuracy of domain name ownership is paramount to collection of
> WHOIS/Registered Name Holder data in the first instance.  In addition, since
> this data will be used by others (with a lawful interest), ensuring that it
> is accurate for them is relevant.
> This isn’t a new concept for discussion, as you may recall that the
> European Commission’s technical input on ICANN's proposed GDPR-compliant
> WHOIS models
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_system_files_files_gdpr-2Dcomments-2Deuropean-2Dcommission-2Dunion-2Dicann-2Dproposed-2Dcompliance-2Dmodels-2D07feb18-2Den.pdf&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=h0lLMkeUF_rn5GMhlS2z3vK51MHCcjEetUszEZTvxyg&s=YxaHZrnJlPuW_9bhzSZjJ7TOa-8_9ht63KuwYlhHWxA&e=> underscored
> the GDPR's "Accuracy" principle and made clear that “reasonable steps
> should be taken to ensure the accuracy of any personal data obtained” for
> WHOIS databases and that ICANN should be sure to incorporate this
> requirement in whatever model it adopts.
> The ico. points out that
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorganisations_guide-2Dto-2Dthe-2Dgeneral-2Ddata-2Dprotection-2Dregulation-2Dgdpr_accountability-2Dand-2Dgovernance_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=h0lLMkeUF_rn5GMhlS2z3vK51MHCcjEetUszEZTvxyg&s=UWaASFRkG2npkSZLHMfzDbjdajEbgoyFxk7wLtqAmbc&e=>
>  “[o]ne of the biggest changes introduced by the GDPR is around
> accountability – a new data protection principle that says organisations
> are responsible for, and must be able to demonstrate, compliance with the
> other principles ... [y]ou now need to be proactive about data protection,
> and evidence the steps you take to meet your obligations and protect
> people’s rights.” With the main thrust of the EPDP being to ensure that the
> WHOIS policies ICANN and the contracted parties adopt comply with the
> principles of the GDPR, these accountability principles shouldn’t be taken
> lightly.
> Consistent with these commitments and the GDPR, accuracy is an issue fully
> within scope of the EPDP so that ICANN and contracted parties proactively
> address how they will ensure the accuracy of data in the first place, not
> just how they rectify inaccurate data brought to their attention after
> collection -- we simply see no way around the EPDP affirmatively addressing
> the GDPR’s accuracy principle in our deliberations and output.  Especially
> since accuracy is addressed in the Temp Spec itself (see 4.1), which states
> ICANN is responsible for “Maintenance of and access to *accurate* and
> up-to-date information concerning registered names and name servers”.
> Dbata accuracy needs to be addressed both proactively as well as
> retroactively.  As the ico. states
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorganisations_guide-2Dto-2Dthe-2Dgeneral-2Ddata-2Dprotection-2Dregulation-2Dgdpr_accountability-2Dand-2Dgovernance_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=h0lLMkeUF_rn5GMhlS2z3vK51MHCcjEetUszEZTvxyg&s=UWaASFRkG2npkSZLHMfzDbjdajEbgoyFxk7wLtqAmbc&e=>
>  “Accountability is not a box-ticking exercise. Being *responsible* for
> compliance with the GDPR means that you need to be proactive and organised
> about your approach to data protection, while *demonstrating* your
> compliance means that you must be able to evidence the steps you take to
> comply.”  The ico. goes onto say that “Documenting this information is a
> great way to take stock of what you do with personal data. Knowing what
> information you have, where it is and what you do with it makes it much
> easier for you to comply with *other aspects of the GDPR such as making
> sure that the information you hold about people is accurate* and secure.”
> (emphasis added)
> To that end, the WHOIS policy developed by the EPDP needs to incorporate
> steps for contracted parties to be in compliance with the GDPR – accuracy
> being one facet of compliance.   The WHOIS Accuracy Reporting System
> Reports showed that the accuracy levels are unacceptably low.
> We see the policy discussion on accuracy focused in three areas:
> *Collection*:  At intake, we should consider whether the current forms of
> validation are sufficient.  In this regard, it may be useful to include in
> the ccTLD survey a request to see what validation is done by the EU based
> ccTLDs.
> *Maintenance*: Once data is collected, Article 5 of the GDPR says that
> data must be “kept up to date”, which seemingly requires some sort of
> process that could be developed.
> *Rectification:* Article 5 of the GDPR says that ICANN and the contracted
> parties must “ensure that personal data that are inaccurate … are erased or
> rectified without delay” and so, a uniform method to report and rectify
> inaccurate data could be considered.
> Because there are so many facets to this conversation, perhaps the best
> way to address this is to talk about this in Toronto, at our F2F.
> All the best,
> Margie
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20181211/f5561540/attachment-0001.html>

More information about the Gnso-epdp-team mailing list