[Gnso-epdp-team] Recommendation on privacy/proxy data.

farzaneh badii farzaneh.badii at gmail.com
Fri Feb 1 17:13:06 UTC 2019


I support Alan Woods solution.

On Fri, Feb 1, 2019 at 7:47 AM Alan Woods <alan at donuts.email> wrote:

> Thank you Alex for reopening this matter.
>
> 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.
>
> I refer you recital 26 of the GDPR:
>
> "…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..."
>
>
> 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.
>
> 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 *not* to publish.
>
> *SOLUTION*
>
> 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.
>
> 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.
>
> *Recommendation XX*
>
> *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 (and Registry where applicable) MAY include in the public WHOIS
> and return in response to any query full WHOIS data, which may also include
> the existing privacy/proxy pseudonymized email.*
>
>
>
> Kind regards,
>
> Alan
>
>
>
>
> [image: Donuts Inc.] <http://donuts.domains>
> Alan Woods
> Senior Compliance & Policy Manager, Donuts Inc.
> ------------------------------
> The Victorians,
> 15-18 Earlsfort Terrace
> Dublin 2, County Dublin
> Ireland
>
> <https://www.facebook.com/donutstlds>   <https://twitter.com/DonutsInc>
> <https://www.linkedin.com/company/donuts-inc>
>
> 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 Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex at colevalleyconsulting.com>
> wrote:
>
>> All,
>>
>> 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 -
>>
>> Recommendation XX
>>
>> 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.
>>
>> There are two reasons why this is useful, IMO.
>>
>> 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.
>>
>> 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.
>>
>> Happy to discuss further on a future call.
>>
>> Thanks.
>> Alex
>>
>>
>> ___________
>> *Alex Deacon*
>> Cole Valley Consulting
>> alex at colevalleyconsulting.com
>> +1.415.488.6009
>>
>> _______________________________________________
>> Gnso-epdp-team mailing list
>> Gnso-epdp-team at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team

-- 
Farzaneh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190201/01f6efe9/attachment-0001.html>


More information about the Gnso-epdp-team mailing list