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

Tue Feb 5 00:32:54 UTC 2019

Perhaps I am confused, but if a request from a 
third party or under the IP purpose is made and 
information is deliverd, it is the real rds DATA 
THAT IS PROVIDED. Anonymized addresses are what 
might be in the public directory (or a pointer to a web form). No?

Alan

At 04/02/2019 07:19 PM, Hadia  Abdelsalam Mokhtar EL miniawi wrote:
>All, So we are talking about a pseudonym email 
>address that the processor (registrar) will 
>disclose to a requester (Third Party) 
>obviously,  we need to ask ourselves could the 
>requester identify the data subject using the 
>pseudonym email address and any other 
>information that could be reasonably available 
>to him? - and I am using here the interpretation 
>mentioned by Stephanie -   in other words could 
>this pseudonym email address be considered an 
>anonymous email address with respect to the 
>requester? The requester has no relationship 
>with the processor and thus does not have access 
>to the information that when linked to the 
>pseudonym email address could identify the data 
>subject so as long as the processor takes the 
>technical and organizational measures required 
>to keep the related information separate by no 
>means is the requester reasonably likely to 
>obtain the information necessary to identify the 
>data subject. Therefore to the requester this 
>data is considered anonymous and irreversible. 
>What remains to be answered now is can the 
>requester using the pseudonym email and other 
>reasonably available information like the domain 
>name, city, etc... identify the domain holder 
>the answer is no, if the processor has taken the 
>appropriate technical measures the pseudonym 
>email address doesn't add anything. If the 
>domain holder is to be identified through 
>publicly available information then he is 
>identifiable with or without the pseudonym email address.
>
>
>P.S. with regard to Breyer vs Germany case that 
>Ayden is referring to the Court of Justice of 
>the European Union favored a logic under which 
>the means by which additional data could be used 
>to identify  the data was taken into 
>consideration. The data under consideration - in 
>this case IP addresses - was considered personal 
>data only because of the existence of legal 
>channels through which the competent authority 
>could obtain identifying information from the Internet Service Provider.
>
>
>Hadia
>
>________________________________
>From: Mueller, Milton L <milton at gatech.edu>
>Sent: 04 February 2019 20:57
>To: Hadia Abdelsalam Mokhtar EL miniawi; Mark Svancarek (CELA); Alan Woods
>Cc: gnso-epdp-team at icann.org
>Subject: RE: [Gnso-epdp-team] Recommendation on privacy/proxy data.
>
>Marc:
>
>I have paraphrased this as:
>
>“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.  However, if the processor were 
>to publish a pseudonym, and a third party were 
>to subsequently locate additional data, 
>available from different processors or even from 
>the same processor in a different context, and 
>were then able to use these separate data to 
>unmask the pseudonym and render it identifiable, 
>such third party correlation ability would NOT 
>require the processor to treat the pseudonym as personal data.”
>
>
>I don’t find your lawyers’ opinion very 
>convincing, Marc. She is saying that even if 
>it’s known for a fact that the pseudonym can be 
>combined with other data elements that are 
>readily accessible to anyone to identify the 
>subject, it is not personally identifiable 
>simply because all the data isn’t in one place. 
>That doesn’t pass the giggle test.
>
>Second, the Whois DOES publish additional, 
>multiple personal data, such as country, state, 
>city, nameserver, domain name, etc. all of which 
>when combined could be used to identify.
>
>Dr. Milton L Mueller
>Professor, School of Public Policy<http://spp.gatech.edu/>
>Georgia Institute of Technology
>Internet Governance Project
>http://internetgovernance.org/
>
>
>
>/marksv
>
>From: Gnso-epdp-team 
><gnso-epdp-team-bounces at icann.org<mailto:gnso-epdp-team-bounces at icann.org>> 
>On Behalf Of Alex Deacon
>Sent: Saturday, February 2, 2019 11:57 AM
>To: Alan Woods <alan at donuts.email<mailto:alan at donuts.email>>
>Cc: EPDP <gnso-epdp-team at icann.org<mailto:gnso-epdp-team at icann.org>>
>Subject: Re: [Gnso-epdp-team] Recommendation on privacy/proxy data.
>
>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 little value.
>
>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 problematic.
>
>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 the case.
>
>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.
>
>Alex
>
>
>___________
>Alex Deacon
>Cole Valley Consulting
>alex at colevalleyconsulting.com<mailto:alex at colevalleyconsulting.com>
>+1.415.488.6009
>
>
>
>On Fri, Feb 1, 2019 at 4:47 AM Alan Woods 
><alan at donuts.email<mailto: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
>
>
>
>
>
>Alan 
>Woods<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>Senior Compliance & Policy Manager, Donuts Inc. 
><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>________________________________
>
>
>The Victorians, 
><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>15-18 Earlsfort Terrace
>Dublin 2, County Dublin
>Ireland
>
> 
><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
>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.<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon 
><alex at colevalleyconsulting.com> 
>wrote:<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>All, 
><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>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 - 
><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>Recommendation 
>XX<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>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.<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>There are two reasons why this is useful, 
>IMO. 
><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>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. 
><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>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. 
><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>Happy to discuss further on a future 
>call. 
><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>Thanks. 
><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>Alex<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> 
><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>___________<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>Alex 
>Deacon<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>Cole Valley 
>Consulting<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>alex at colevalleyconsulting.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>+1.415.488.6009<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>_______________________________________________
>Gnso-epdp-team mailing list
>Gnso-epdp-team at icann.org
>https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>_______________________________________________
>Gnso-epdp-team mailing list
>Gnso-epdp-team at icann.org
>https://mm.icann.org/mailman/listinfo/gnso-epdp-team