[Gnso-epdp-team] Recommendation on privacy/proxy data.
alex at colevalleyconsulting.com
Sat Feb 2 19:57:26 UTC 2019
Thanks Alan. As always I appreciate your input and views. A few thoughts
and questions on your proposed solution.
First, given all of the "MAYs" in your suggested update, it is not clear to
me how this will be translated in the implementation phase. Specifically
it is a no-op from a compliance point of view. I understand this may be
the main reason for your update, but we end up with a Recommendation with
Second, given the general agreement that we avoid "squishy" language in our
purposes and recommendations, the language you propose is unclear (to me at
least). If a Registrar or Registry decides to not return P/P data or the
"existing p/p pseudonymized email” does that mean no email address will be
available in a public response? If so that seems to go against our
existing Contractibility purpose (Purpose 3). (Alan G made this point I
believe.) Or does this language assume that there will be a Registrar
pseudonymized email that points to a P/P pseudonymized email? Both seem
Third, regarding the language you point out in Recital 26 of the GDPR, its
not clear to me it applies in the privacy/proxy context, where the only the
psuedonymized email could be seen as personal. Perhaps this would be a
good question to pose to Ruth. From what I understand if a processor were
to publish or disclose multiple personal data, one of which was a
pseudonym, and if that collection of data could be used to render the
pseudonym identifiable, then the pseudonym would be considered to be
personal data. For responses that only included P/P data this wouldn't be
Fourth, I appreciate your concern that it may not be possible to figure out
a P/P provider and suggest we can use the language in the RAA (Section 2)
to be more specific here - essentially limit it (for now) to affiliated
services. e.g. “For any Proxy Service or Privacy Service offered by the
Registrar or its Affiliates, including any of Registrar's or its
Affiliates' P/P services distributed through Resellers, and used in
connection with Registered Names Sponsored by the Registrar,". In the
future, and once the PPIRT completes, all accredited P/P services will be
flagged in RDS/WHOIS (PPSAI Recommendation 4) so this issue will be solved.
Finally, I continue to believe we can find a pragmatic solution where we
eliminate (or perhaps minimize) the situation where P/P data is returned in
response to a "reasonable disclosure" request. It is a very inefficient
use of time/cycles for both the requestor and person responsible for
manually processing these requests. This was the main reason for the Temp
Spec language and this new Recommendation. If we can't address this issue
in this new Rec then perhaps language needs to be added to Rec 12 to
address this case....
Apologies for the long email.
Cole Valley Consulting
alex at colevalleyconsulting.com
On Fri, Feb 1, 2019 at 4: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
> 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.
> 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,
> [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 Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex at colevalleyconsulting.com>
>> 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
>> 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.
>> *Alex Deacon*
>> Cole Valley Consulting
>> alex at colevalleyconsulting.com
>> Gnso-epdp-team mailing list
>> Gnso-epdp-team at icann.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnso-epdp-team