<div dir="ltr"><div dir="ltr">Thank you Alex for reopening this matter. <div><br></div><div>From a practicality POV the inclusion of a pseudonymised email in a publication is a disclosure of public data, as a pseudonymised email, is still an email for a data subject. It may be in a form the data subject does not recognize, but I believe a number of excellent and practical examples, such as auto-relay / auto out of office responses could easily identify the non-pseudonymised email and lead to identification of the Data Subject. </div><div><br></div><div>I refer you recital 26 of the GDPR:</div><div><br></div><div>"…Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person..." </div><div><br></div><div><br></div><div>Alas the recommendation as worded, although I understand the practicality that is driving it, does not properly address data protection concerns. There is a lot of back and of forth possible on whether pseudonymisation may count as anonymization when published to a 3rd party, however in the context of Domain Names, where the domain name, and even the associated content, could be capable of linking the individual to the pseudonymised data (which is completely outside of outside of our control, but still relevant to our risk assessment), we need to tread carefully; more carefully than the ePDP has either the time or the scope to consider. </div><div><br></div><div>To refer again to our goal : We must look to the state of the data that is in the RDDS currently, and whether the publication of individual data currently used would be data protection compliant or not. In its current state, with the myriad the uncertainties, it is not, therefore our recommendation must be <b><u>not</u></b> to publish. </div><div><br></div><div><b>SOLUTION</b> </div><div><br></div><div>Allow the registrar / registry to consider (as Controller) the feasibility and the risk as it applies to them? Unless we, at this late stage, the ePDP can provide an actual means or suggestion as to implementation of how a registrar / registry can effectively figure out who is a P&P provider and thus publish those only details without an increase to risk, then our choice is plain. </div><div><br></div><div>If the recommendation is to stand, use of MAY, and other permissive language, as opposed to a 'must' will allow each CP to assess the risk as they see it, as it all comes down to the fact that the ePDP cannot force the CPs to assume higher risk to appease some. </div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><b>Recommendation XX</b></div></div><div><div><b><br></b></div></div><div><div><b>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), <font color="#ff0000">Registrar (and Registry where applicable) MAY</font> include in the public WHOIS and return in response to any query full WHOIS data, <font color="#ff0000">which may also </font>includ<font color="#ff0000">e</font> the existing privacy/proxy pseudonymized email.</b></div></div></blockquote><div><br></div><div><br></div><div>Kind regards,</div><div><br></div><div>Alan </div><div><br></div><div><br></div><div><br></div><div> </div><div><div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><table style="padding:0px;margin:10px 0px;border:none"><tbody><tr><td style="vertical-align:middle;padding:0px 7px 0px 0px"><a href="http://donuts.domains" rel="nofollow" target="_blank"><img alt="Donuts Inc." height="75" src="https://storage.googleapis.com/signaturesatori/customer-C02zzlf7k/images/-54f9d8ac97e7f575bf497d10ac1f1aafafddf8afceab5f269d49034f01b3217b.png" width="75"></a></td><td style="vertical-align:middle;padding:0px 7px 0px 0px;text-align:left">
<div style="font-family:tahoma,sans-serif;font-size:14px;line-height:17px;font-weight:bold;color:black"><span style="font-size:12px"><span style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(51,51,51)">Alan Woods</span></span></span></div>
<div><span style="font-size:12px"><span style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(51,51,51)">Senior Compliance & Policy Manager, Donuts Inc.</span></span></span>
<hr><span style="font-size:11px"><span style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(51,51,51)">The Victorians, </span></span></span></div><div><font color="#333333" face="arial, helvetica, sans-serif"><span style="font-size:11px">15-18 Earlsfort Terrace<br style="background-color:rgb(34,34,34)">
Dublin 2, County Dublin</span></font><br style="color:rgb(214,214,214);font-family:"open sans";font-size:12px;background-color:rgb(34,34,34)"><font color="#333333" face="arial, helvetica, sans-serif"><span style="font-size:11px">
Ireland</span></font><br>
<span style="font-size:11px"><span style="font-family:arial,helvetica,sans-serif"></span></span><br>
<span style="line-height:36px"><a href="https://www.facebook.com/donutstlds" rel="nofollow" target="_blank"><img src="http://storage.googleapis.com/signaturesatori/icons/facebook.png"></a> <a href="https://twitter.com/DonutsInc" rel="nofollow" target="_blank"><img src="http://storage.googleapis.com/signaturesatori/icons/twitter.png"></a> </span><a href="https://www.linkedin.com/company/donuts-inc" rel="nofollow" target="_blank"><span style="font-size:14px"><img src="http://storage.googleapis.com/signaturesatori/icons/linkedin.png"></span></a></div>
</td></tr></tbody></table><br>
</div><div><span style="font-size:12pt;font-family:Cambria,serif">Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . </span><span style="font-size:12pt;font-family:Cambria,serif">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.</span><br></div></div></div></div></div></div></div></div></div></div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <<a href="mailto:alex@colevalleyconsulting.com">alex@colevalleyconsulting.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">All, <div><br></div><div>Our review of ICANN's input on Temp Spec topics that were not covered by the Initial Report reminded me that we had at one point discussed ensuring that the current Temp Spec language on how Privacy/Proxy data should be handled (Appendix A 2.6) should added as a recommendation. Something along the lines of - </div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Recommendation XX</div><div><br></div><div>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 include in the public WHOIS and return in response to any query full WHOIS data, including the existing privacy/proxy pseudonymized email.</div><div><br></div></blockquote>There are two reasons why this is useful, IMO. <div><br></div><div>First, given the time and effort needed to properly process "reasonable disclosure" requests by Registrars it seems useful to avoid a situation where non-public data is quickly found to be P/P service data. Avoiding this situation and simply including P/P data in the the initial response would make life better for all involved. <br></div><div><div><br></div><div>Second, there is no need to redact information that is already "redacted" (by definition) by the P/P service. Also, given P/P services list the information of a legal person (in the case of a registrar affiliated service provider) in the place of the RNH's info it seems further redaction is unnecessary. </div><div><br></div><div>Happy to discuss further on a future call. </div><div><br></div><div>Thanks. </div><div>Alex</div><div><br><span style="color:blue;font-family:Arial,sans-serif;font-size:12pt"> </span><br><div><div><div dir="ltr" class="gmail-m_8537874273839167647gmail_signature"><div dir="ltr">___________<div><b>Alex Deacon</b></div><div>Cole Valley Consulting</div><div><a href="mailto:alex@colevalleyconsulting.com" target="_blank">alex@colevalleyconsulting.com</a></div><div><span id="gmail-m_8537874273839167647gc-number-620" class="gmail-m_8537874273839167647gc-cs-link" title="Call with Google Voice">+1.415.488.6009</span></div><div><br></div></div></div></div></div></div></div></div>
_______________________________________________<br>
Gnso-epdp-team mailing list<br>
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a></blockquote></div>