Recommendation on privacy/proxy data.
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@colevalleyconsulting.com +1.415.488.6009
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@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@colevalleyconsulting.com +1.415.488.6009
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
I support Alan Woods solution. On Fri, Feb 1, 2019 at 7:47 AM Alan Woods <alan@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@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@colevalleyconsulting.com +1.415.488.6009
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
-- Farzaneh
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@colevalleyconsulting.com +1.415.488.6009 On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan@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@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@colevalleyconsulting.com +1.415.488.6009
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
Alan, please consider an alternate interpretation of recital 26. This is the way we interpret it at Microsoft, and our regulatory contacts are supportive of it. I have always been puzzled by interpretations of recital 26 which imply that a processor’s use of personal data is somehow constrained by the unrelated processing of a different processor, even if it’s not the same data. My lawyer says, “The additional information contemplated in this description [in recital 26] refers to additional information presented in conjunction with the email address; not just if someone had additional information that the effort to limit identifiability could be broken. There are ways for the pseudonymized email to stand alone, and for users to be directed to use business and not personal addresses or other personal information that would increase identifiability. “ 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.” /marksv From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Alex Deacon Sent: Saturday, February 2, 2019 11:57 AM To: Alan Woods <alan@donuts.email> Cc: EPDP <gnso-epdp-team@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@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan@donuts.email<mailto:alan@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 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alan Woods<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Senior Compliance & Policy Manager, Donuts Inc. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ________________________________ The Victorians, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex@colevalleyconsulting.com> wrote:<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> All, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Recommendation XX<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> There are two reasons why this is useful, IMO. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Happy to discuss further on a future call. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Thanks. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ___________<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex Deacon<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Cole Valley Consulting<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> alex@colevalleyconsulting.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> +1.415.488.6009<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@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>
Alan, if you are unable to attribute a pseudonym email address to a specific data subject using other information provided within the same data set then the pseudonymized email address is not considered personal data. So as long as the other information provided along with the pseudonymized email addresses cannot lead to identifying the data subject and the processor puts technical and organizational measures that ensure the additional relevant information that could tie the pseudonym email address to the data subject is kept separate then there is no problem in providing the pseudonymized email address. I refer you to the ICO website where you will find examples for good practices relating to this matter under GDPR. Hadia Eng. Hadia Elminiawi (M.Sc.) Director, DNS-Entrepreneurship Center [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-ash4/268513_180152888707645_7698168_n.jpg][logo] National Telecommunication Regulatory Authority Tel: +202 3534 4392 Fax: +202 3537 4000 Email: hadia@tra.gov.eg<https://mail.dnsec.eg/owa/redir.aspx?C=8f4aa197b9f840be8139d76b29a0df99&URL=...> From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Mark Svancarek (CELA) via Gnso-epdp-team Sent: Sunday, February 03, 2019 8:29 PM To: Alan Woods Cc: EPDP Subject: Re: [Gnso-epdp-team] Recommendation on privacy/proxy data. Alan, please consider an alternate interpretation of recital 26. This is the way we interpret it at Microsoft, and our regulatory contacts are supportive of it. I have always been puzzled by interpretations of recital 26 which imply that a processor’s use of personal data is somehow constrained by the unrelated processing of a different processor, even if it’s not the same data. My lawyer says, “The additional information contemplated in this description [in recital 26] refers to additional information presented in conjunction with the email address; not just if someone had additional information that the effort to limit identifiability could be broken. There are ways for the pseudonymized email to stand alone, and for users to be directed to use business and not personal addresses or other personal information that would increase identifiability. “ 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.” /marksv From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Alex Deacon Sent: Saturday, February 2, 2019 11:57 AM To: Alan Woods <alan@donuts.email> Cc: EPDP <gnso-epdp-team@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@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan@donuts.email<mailto:alan@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.doma...> Senior Compliance & Policy Manager, Donuts Inc. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ________________________________ The Victorians, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex@colevalleyconsulting.com> wrote:<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> All, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> Recommendation XX<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> There are two reasons why this is useful, IMO. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> 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.doma...> Happy to discuss further on a future call. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Thanks. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ___________<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex Deacon<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Cole Valley Consulting<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> alex@colevalleyconsulting.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> +1.415.488.6009<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@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>
Actually, I believe that the threshold is that the identifying data is "reasonably available". Not necessarily within the same data set. Stephanie Perrin On 2019-02-04 09:00, Hadia Abdelsalam Mokhtar EL miniawi wrote: Alan, if you are unable to attribute a pseudonym email address to a specific data subject using other information provided within the same data set then the pseudonymized email address is not considered personal data. So as long as the other information provided along with the pseudonymized email addresses cannot lead to identifying the data subject and the processor puts technical and organizational measures that ensure the additional relevant information that could tie the pseudonym email address to the data subject is kept separate then there is no problem in providing the pseudonymized email address. I refer you to the ICO website where you will find examples for good practices relating to this matter under GDPR. Hadia Eng. Hadia Elminiawi (M.Sc.) Director, DNS-Entrepreneurship Center [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-ash4/268513_180152888707645_7698168_n.jpg][logo] National Telecommunication Regulatory Authority Tel: +202 3534 4392 Fax: +202 3537 4000 Email: hadia@tra.gov.eg<https://mail.dnsec.eg/owa/redir.aspx?C=8f4aa197b9f840be8139d76b29a0df99&URL=...> From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Mark Svancarek (CELA) via Gnso-epdp-team Sent: Sunday, February 03, 2019 8:29 PM To: Alan Woods Cc: EPDP Subject: Re: [Gnso-epdp-team] Recommendation on privacy/proxy data. Alan, please consider an alternate interpretation of recital 26. This is the way we interpret it at Microsoft, and our regulatory contacts are supportive of it. I have always been puzzled by interpretations of recital 26 which imply that a processor’s use of personal data is somehow constrained by the unrelated processing of a different processor, even if it’s not the same data. My lawyer says, “The additional information contemplated in this description [in recital 26] refers to additional information presented in conjunction with the email address; not just if someone had additional information that the effort to limit identifiability could be broken. There are ways for the pseudonymized email to stand alone, and for users to be directed to use business and not personal addresses or other personal information that would increase identifiability. “ 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.” /marksv From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org> On Behalf Of Alex Deacon Sent: Saturday, February 2, 2019 11:57 AM To: Alan Woods <alan@donuts.email><mailto:alan@donuts.email> Cc: EPDP <gnso-epdp-team@icann.org><mailto:gnso-epdp-team@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@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan@donuts.email<mailto:alan@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.doma...> Senior Compliance & Policy Manager, Donuts Inc. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ________________________________ The Victorians, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex@colevalleyconsulting.com> wrote:<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> All, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> Recommendation XX<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> There are two reasons why this is useful, IMO. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> 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.doma...> Happy to discuss further on a future call. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Thanks. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ___________<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex Deacon<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Cole Valley Consulting<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> alex@colevalleyconsulting.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> +1.415.488.6009<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@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@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
Stephanie's clarification is an important one. As some 'historical WHOIS' services sell access to archived records, I believe such an identifying data set would be "reasonably available" to a wide number of actors, meaning that a pseudonymised email address could easily lead to the identification of a domain name registrant. Ayden ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, February 4, 2019 9:10 AM, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> wrote:
Actually, I believe that the threshold is that the identifying data is "reasonably available". Not necessarily within the same data set.
Stephanie Perrin
On 2019-02-04 09:00, Hadia Abdelsalam Mokhtar EL miniawi wrote:
Alan, if you are unable to attribute a pseudonym email address to a specific data subject using other information provided within the same data set then the pseudonymized email address is not considered personal data. So as long as the other information provided along with the pseudonymized email addresses cannot lead to identifying the data subject and the processor puts technical and organizational measures that ensure the additional relevant information that could tie the pseudonym email address to the data subject is kept separate then there is no problem in providing the pseudonymized email address. I refer you to the ICO website where you will find examples for good practices relating to this matter under GDPR.
Hadia
Eng. Hadia Elminiawi (M.Sc.)
Director, DNS-Entrepreneurship Center
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-ash4/268513_180152888707645_7698168_n.jpg][logo]
National Telecommunication Regulatory Authority
Tel: +202 3534 4392
Fax: +202 3537 4000
Email: [hadia@tra.gov.eg](https://mail.dnsec.eg/owa/redir.aspx?C=8f4aa197b9f840be8139d76b29a0df99&URL=...)
From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Mark Svancarek (CELA) via Gnso-epdp-team Sent: Sunday, February 03, 2019 8:29 PM To: Alan Woods Cc: EPDP Subject: Re: [Gnso-epdp-team] Recommendation on privacy/proxy data.
Alan, please consider an alternate interpretation of recital 26. This is the way we interpret it at Microsoft, and our regulatory contacts are supportive of it.
I have always been puzzled by interpretations of recital 26 which imply that a processor’s use of personal data is somehow constrained by the unrelated processing of a different processor, even if it’s not the same data.
My lawyer says, “The additional information contemplated in this description [in recital 26] refers to additional information presented in conjunction with the email address; not just if someone had additional information that the effort to limit identifiability could be broken. There are ways for the pseudonymized email to stand alone, and for users to be directed to use business and not personal addresses or other personal information that would increase identifiability. “
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.”
/marksv
From: Gnso-epdp-team [<gnso-epdp-team-bounces@icann.org>](mailto:gnso-epdp-team-bounces@icann.org) On Behalf Of Alex Deacon Sent: Saturday, February 2, 2019 11:57 AM To: Alan Woods [<alan@donuts.email>](mailto:alan@donuts.email) Cc: EPDP [<gnso-epdp-team@icann.org>](mailto:gnso-epdp-team@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@colevalleyconsulting.com
+1.415.488.6009
On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan@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.doma...)
[Senior Compliance & Policy Manager, Donuts Inc.](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...
[---------------------------------------------------------------](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[The Victorians, ](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland
](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[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.doma...)
[On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex@colevalleyconsulting.com> wrote:](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[All, ](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[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.doma...)
[Recommendation XX](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[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.doma...)
[There are two reasons why this is useful, IMO. ](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[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.doma...)
[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.doma...)
[Happy to discuss further on a future call. ](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[Thanks. ](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[Alex](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[ ](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[___________](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[Alex Deacon](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[Cole Valley Consulting](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[alex@colevalleyconsulting.com](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[+1.415.488.6009](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[_______________________________________________ Gnso-epdp-team mailing listGnso-epdp-team@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@icann.org
Yes, I understand the clarification, and I agree that we will sometimes have differing opinions until things are definitively settled. My point is that Microsoft is a “big target” to regulators, but we feel safe with this policy, so others may perhaps find similar confidence in it. Please note that I am only referring to interpretation of law; we can certainly create policy which is more restrictive. I just want to make a pedantic distinction between what we must do to be legal and what we optionally choose to do as a consensus-driven community. When we combine these in our discussions it’s sometimes confusing. /marksv From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Ayden Férdeline Sent: Monday, February 4, 2019 8:11 AM To: Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Recommendation on privacy/proxy data. Stephanie's clarification is an important one. As some 'historical WHOIS' services sell access to archived records, I believe such an identifying data set would be "reasonably available" to a wide number of actors, meaning that a pseudonymised email address could easily lead to the identification of a domain name registrant. Ayden ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, February 4, 2019 9:10 AM, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca<mailto:stephanie.perrin@mail.utoronto.ca>> wrote: Actually, I believe that the threshold is that the identifying data is "reasonably available". Not necessarily within the same data set. Stephanie Perrin On 2019-02-04 09:00, Hadia Abdelsalam Mokhtar EL miniawi wrote: Alan, if you are unable to attribute a pseudonym email address to a specific data subject using other information provided within the same data set then the pseudonymized email address is not considered personal data. So as long as the other information provided along with the pseudonymized email addresses cannot lead to identifying the data subject and the processor puts technical and organizational measures that ensure the additional relevant information that could tie the pseudonym email address to the data subject is kept separate then there is no problem in providing the pseudonymized email address. I refer you to the ICO website where you will find examples for good practices relating to this matter under GDPR. Hadia Eng. Hadia Elminiawi (M.Sc.) Director, DNS-Entrepreneurship Center [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-ash4/268513_180152888707645_7698168_n.jpg][logo] National Telecommunication Regulatory Authority Tel: +202 3534 4392 Fax: +202 3537 4000 Email: hadia@tra.gov.eg<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.dnsec...> From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Mark Svancarek (CELA) via Gnso-epdp-team Sent: Sunday, February 03, 2019 8:29 PM To: Alan Woods Cc: EPDP Subject: Re: [Gnso-epdp-team] Recommendation on privacy/proxy data. Alan, please consider an alternate interpretation of recital 26. This is the way we interpret it at Microsoft, and our regulatory contacts are supportive of it. I have always been puzzled by interpretations of recital 26 which imply that a processor’s use of personal data is somehow constrained by the unrelated processing of a different processor, even if it’s not the same data. My lawyer says, “The additional information contemplated in this description [in recital 26] refers to additional information presented in conjunction with the email address; not just if someone had additional information that the effort to limit identifiability could be broken. There are ways for the pseudonymized email to stand alone, and for users to be directed to use business and not personal addresses or other personal information that would increase identifiability. “ 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.” /marksv From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org> On Behalf Of Alex Deacon Sent: Saturday, February 2, 2019 11:57 AM To: Alan Woods <alan@donuts.email><mailto:alan@donuts.email> Cc: EPDP <gnso-epdp-team@icann.org><mailto:gnso-epdp-team@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@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan@donuts.email<mailto:alan@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.doma...> Senior Compliance & Policy Manager, Donuts Inc. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ________________________________ The Victorians, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex@colevalleyconsulting.com> wrote:<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> All, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> Recommendation XX<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> There are two reasons why this is useful, IMO. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> 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.doma...> Happy to discuss further on a future call. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Thanks. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ___________<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex Deacon<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Cole Valley Consulting<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> alex@colevalleyconsulting.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> +1.415.488.6009<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@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%7C11eb86f8709148c3b1db08d68abb6f23%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636848934978578451&sdata=xLcxBawWHFD6xzsKJYcmIpN4bJQCFm1sa6KqQSKJ0d0%3D&reserved=0> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C11eb86f8709148c3b1db08d68abb6f23%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636848934978588459&sdata=lbCzlA%2BgXzQ4c4ChOgce1hYZBt600lNevE9HqA8I32I%3D&reserved=0>
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@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Alex Deacon Sent: Saturday, February 2, 2019 11:57 AM To: Alan Woods <alan@donuts.email<mailto:alan@donuts.email>> Cc: EPDP <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan@donuts.email<mailto:alan@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.doma...> Senior Compliance & Policy Manager, Donuts Inc. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ________________________________ The Victorians, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex@colevalleyconsulting.com> wrote:<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> All, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> Recommendation XX<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> There are two reasons why this is useful, IMO. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> 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.doma...> Happy to discuss further on a future call. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Thanks. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ___________<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex Deacon<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Cole Valley Consulting<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> alex@colevalleyconsulting.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> +1.415.488.6009<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@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>
I agree with Milton’s interpretation. We also have case law that can help us understand the meaning of where pseudonymisation is “reasonably likely” to lead to the identification of a data subject. In Breyer v Germany, the Court of Justice of the European Union’s ruling mirrors much of the debate we are having here, and it found that pseudonymized data is almost always personal data. (While this case was a judgment on the 1995 Data Protection Directive and not the GDPR, the text of Recital 26 in the GDPR and in the Directive differ very little in substance.) In light of this, and given the relative ease with which historical WHOIS records can be retrieved, I believe it is only prudent that pseudonymised email addresses are not published. Best wishes, Ayden ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, February 4, 2019 1:57 PM, Mueller, Milton L <milton@gatech.edu> wrote:
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@icann.org> On Behalf Of Alex Deacon Sent: Saturday, February 2, 2019 11:57 AM To: Alan Woods <alan@donuts.email> Cc: EPDP <gnso-epdp-team@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@colevalleyconsulting.com
+1.415.488.6009
On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan@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.doma...)
[Senior Compliance & Policy Manager, Donuts Inc.](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...
[---------------------------------------------------------------](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[The Victorians, ](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland
](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[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.doma...)
[On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex@colevalleyconsulting.com> wrote:](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[All, ](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[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.doma...)
[Recommendation XX](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[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.doma...)
[There are two reasons why this is useful, IMO. ](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[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.doma...)
[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.doma...)
[Happy to discuss further on a future call. ](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[Thanks. ](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[Alex](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[ ](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[___________](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[Alex Deacon](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[Cole Valley Consulting](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[alex@colevalleyconsulting.com](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[+1.415.488.6009](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...)
[_______________________________________________ Gnso-epdp-team mailing listGnso-epdp-team@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)
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 the Breyer v 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 were taken into consideration. And the data under consideration - in this case IP addresses - were 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. The CJEU favoured a logic under which the means by which this additional data could be used to identify the data were taken into account. Hadia ________________________________ From: Ayden F��rdeline <icann@ferdeline.com> Sent: 05 February 2019 01:20 To: Mueller, Milton L Cc: Hadia Abdelsalam Mokhtar EL miniawi; Mark Svancarek (CELA); Alan Woods; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Recommendation on privacy/proxy data. I agree with Milton��s interpretation. We also have case law that can help us understand the meaning of where pseudonymisation is ��reasonably likely�� to lead to the identification of a data subject. In Breyer v Germany, the Court of Justice of the European Union��s ruling mirrors much of the debate we are having here, and it found that pseudonymized data is almost always personal data. (While this case was a judgment on the 1995 Data Protection Directive and not the GDPR, the text of Recital 26 in the GDPR and in the Directive differ very little in substance.) In light of this, and given the relative ease with which historical WHOIS records can be retrieved, I believe it is only prudent that pseudonymised email addresses are not published. Best wishes, Ayden �\�\�\�\�\�\�\ Original Message �\�\�\�\�\�\�\ On Monday, February 4, 2019 1:57 PM, Mueller, Milton L <milton@gatech.edu> wrote: 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@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Alex Deacon Sent: Saturday, February 2, 2019 11:57 AM To: Alan Woods <alan@donuts.email<mailto:alan@donuts.email>> Cc: EPDP <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan@donuts.email<mailto:alan@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.doma...> Senior Compliance & Policy Manager, Donuts Inc. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ________________________________ The Victorians, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex@colevalleyconsulting.com> wrote:<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> All, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> Recommendation XX<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> There are two reasons why this is useful, IMO. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> 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.doma...> Happy to discuss further on a future call. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Thanks. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ___________<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex Deacon<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Cole Valley Consulting<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> alex@colevalleyconsulting.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> +1.415.488.6009<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@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>
Hi Hadia, I don't follow your summary of Breyer v Germany. Or rather, I don't understand why you seem to have dismissed it? Let's break this down a bit differently. A correct interpretation of Recital 26 is critical to understanding the GDPR. Recital 26 sets forth a test for determining whether or not a natural person is identifiable. If a natural person is identifiable, then that data is personal and thus within the scope of the GDPR. As Recital 26 states very clearly, "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." I think this language is very clear. Back to Breyer v Germany. In this case, the German government stored the IP addresses of persons who visited German government websites. In and of themselves these numbers did not identify an individual. However, ISPs held additional information which, when combined with the records held by the German government, could identify natural persons. Note that the ISPs are privately held and did not freely disclose this data to the German government. Now, of course the original data set of IP addresses was not intentionally pseudonymised, but the Court found it analogous to pseudonymised data, because the original data set was only partial and did not directly identify natural persons. So the similarities here are very clear to me; our data (pseudonymised emails) may not directly identify a natural person, but when combined with another readily available data set (i.e. MarkMonitor's historical WHOIS archives, which anyone can subscribe to), it could very well lead to the identifiability of a natural person. Our case is actually a bit more extreme, because it's not just pseudonymised emails that could be retrieved, some also want the city field etc. This _is_ information that can reasonably lead to the identification of a natural person, and so we should treat it as such. Many thanks, Ayden Férdeline ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, February 4, 2019 7:06 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> 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 the Breyer v 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 were taken into consideration. And the data under consideration - in this case IP addresses - were 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.
The CJEU favoured a logic under which the means by which this additional data could be used to identify the data were taken into account.
Hadia
From: Ayden Férdeline icann@ferdeline.com Sent: 05 February 2019 01:20 To: Mueller, Milton L Cc: Hadia Abdelsalam Mokhtar EL miniawi; Mark Svancarek (CELA); Alan Woods; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Recommendation on privacy/proxy data.
I agree with Milton’s interpretation.
We also have case law that can help us understand the meaning of where pseudonymisation is “reasonably likely” to lead to the identification of a data subject.
In Breyer v Germany, the Court of Justice of the European Union’s ruling mirrors much of the debate we are having here, and it found that pseudonymized data is almost always personal data. (While this case was a judgment on the 1995 Data Protection Directive and not the GDPR, the text of Recital 26 in the GDPR and in the Directive differ very little in substance.)
In light of this, and given the relative ease with which historical WHOIS records can be retrieved, I believe it is only prudent that pseudonymised email addresses are not published.
Best wishes,
Ayden
Original Message On Monday, February 4, 2019 1:57 PM, Mueller, Milton L milton@gatech.edu wrote:
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 Policyhttp://spp.gatech.edu/
Georgia Institute of Technology
Internet Governance Project
http://internetgovernance.org/
/marksv
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.orgmailto:gnso-epdp-team-bounces@icann.org> On Behalf Of Alex Deacon Sent: Saturday, February 2, 2019 11:57 AM To: Alan Woods <alan@donuts.emailmailto:alan@donuts.email> Cc: EPDP <gnso-epdp-team@icann.orgmailto:gnso-epdp-team@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@colevalleyconsulting.commailto:alex@colevalleyconsulting.com
+1.415.488.6009
On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan@donuts.emailmailto:alan@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
Senior Compliance & Policy Manager, Donuts Inc.https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02|01|marksv%40microsoft.com|cd7ec2e952744fc76eb608d68948bdc7|72f988bf86f141af91ab2d7cd011db47|1|0|636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0
15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland
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|01|marksv%40microsoft.com|cd7ec2e952744fc76eb608d68948bdc7|72f988bf86f141af91ab2d7cd011db47|1|0|636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0
On Fri, Feb 1, 2019 at 12:57 AM Alex Deaconalex@colevalleyconsulting.com wrote:https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02|01|marksv%40microsoft.com|cd7ec2e952744fc76eb608d68948bdc7|72f988bf86f141af91ab2d7cd011db47|1|0|636847342852603079&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|01|marksv%40microsoft.com|cd7ec2e952744fc76eb608d68948bdc7|72f988bf86f141af91ab2d7cd011db47|1|0|636847342852603079&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|01|marksv%40microsoft.com|cd7ec2e952744fc76eb608d68948bdc7|72f988bf86f141af91ab2d7cd011db47|1|0|636847342852603079&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|01|marksv%40microsoft.com|cd7ec2e952744fc76eb608d68948bdc7|72f988bf86f141af91ab2d7cd011db47|1|0|636847342852603079&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|01|marksv%40microsoft.com|cd7ec2e952744fc76eb608d68948bdc7|72f988bf86f141af91ab2d7cd011db47|1|0|636847342852603079&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|01|marksv%40microsoft.com|cd7ec2e952744fc76eb608d68948bdc7|72f988bf86f141af91ab2d7cd011db47|1|0|636847342852603079&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|01|marksv%40microsoft.com|cd7ec2e952744fc76eb608d68948bdc7|72f988bf86f141af91ab2d7cd011db47|1|0|636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0
Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-teamhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02|01|marksv%40microsoft.com|cd7ec2e952744fc76eb608d68948bdc7|72f988bf86f141af91ab2d7cd011db47|1|0|636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0
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@gatech.edu> Sent: 04 February 2019 20:57 To: Hadia Abdelsalam Mokhtar EL miniawi; Mark Svancarek (CELA); Alan Woods Cc: gnso-epdp-team@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@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Alex Deacon Sent: Saturday, February 2, 2019 11:57 AM To: Alan Woods <alan@donuts.email<mailto:alan@donuts.email>> Cc: EPDP <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan@donuts.email<mailto:alan@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.doma...> Senior Compliance & Policy Manager, Donuts Inc. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ________________________________ The Victorians, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex@colevalleyconsulting.com> wrote:<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> All, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> Recommendation XX<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> There are two reasons why this is useful, IMO. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> 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.doma...> Happy to discuss further on a future call. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Thanks. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ___________<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex Deacon<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Cole Valley Consulting<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> alex@colevalleyconsulting.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> +1.415.488.6009<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@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>
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@gatech.edu> Sent: 04 February 2019 20:57 To: Hadia Abdelsalam Mokhtar EL miniawi; Mark Svancarek (CELA); Alan Woods Cc: gnso-epdp-team@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@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Alex Deacon Sent: Saturday, February 2, 2019 11:57 AM To: Alan Woods <alan@donuts.email<mailto:alan@donuts.email>> Cc: EPDP <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009
On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan@donuts.email<mailto:alan@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.doma...> Senior Compliance & Policy Manager, Donuts Inc. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ________________________________
The Victorians, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland
<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...>
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.doma...> On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex@colevalleyconsulting.com> wrote:<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> All, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> Recommendation XX<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> There are two reasons why this is useful, IMO. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> 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.doma...> 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.doma...> Happy to discuss further on a future call. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Thanks. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...>
<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> ___________<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Alex Deacon<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> Cole Valley Consulting<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> alex@colevalleyconsulting.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> +1.415.488.6009<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.doma...> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
All- I agree with Alex’s proposal below. All the best, Margie From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Alex Deacon <alex@colevalleyconsulting.com> Date: Thursday, January 31, 2019 at 4:57 PM To: EPDP <gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Recommendation on privacy/proxy data. 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@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009
participants (10)
-
Alan Greenberg -
Alan Woods -
Alex Deacon -
Ayden Férdeline -
farzaneh badii -
Hadia Abdelsalam Mokhtar EL miniawi -
Margie Milam -
Mark Svancarek (CELA) -
Mueller, Milton L -
Stephanie Perrin