هذا المحتوى متوفر فقط باللغة (أو اللغات)
Name: Brian King
Date: 13 Jan 2022
Original Public Comment: EPDP Phase 2A Policy Recommendations for ICANN Board Consideration
1. EPDP Phase 2A Rec. #1 provides, in part, “The EPDP Team recommends that a field or fields MUST be created to facilitate differentiation between legal and natural person registration data and/or if that registration data contains personal or non-personal data. ICANN org MUST coordinate with the technical community, for example the RDAP WG, to develop any necessary standards associated with using this field or fields within EPP and the RDDS.” Please refer to p. 6 of the Final Report for the full text of the recommendation. Is there any new, specific, and concise information the ICANN Board should consider with respect to Recommendation 1?
The BC and IPC oppose Recommendation 1. The EPDP Phase 2A team was unable to reach consensus on recommending changes to Phase 1 Recommendation #17.1, which makes it optional for contracted parties to differentiate between data of legal vs. natural persons for purposes of the registration data directory service (RDDS). While the Phase 2A Final Report recommends that a field or fields must be created to facilitate differentiation between legal and natural person registration data and/or indicate if that registration data contains personal or non-personal data, contracted parties remain free not to differentiate and further not to even use this field, and thus the creation of this field will be irrelevant. As stated in the BC and IPC Minority Statements, the failure to require use of this technical mechanism will result in an inconsistent and unreliable RDDS, and is a missed opportunity to reduce the number of requests for non-personal data which has been unnecessarily redacted, such as the contact data for unaffiliated privacy/proxy services. Again, this outcome falls well short of the needs of those involved in the investigation of DNS abuse, cybercrime activity, intellectual property violations, and other activity that threatens the welfare of Internet users.
2. EPDP Phase 2A Rec. #2 provides, in part, “The EPDP Team recommends that Contracted Parties who choose to differentiate based on person type SHOULD follow the guidance1 below and clearly document all data processing steps.” Please refer to p. 7 of the Final Report for the full text of the recommendation. Is there any new, specific, and concise information the ICANN Board should consider with respect to Recommendation 2?
The BC and IPC oppose Recommendation 2. This recommendation provides voluntary “guidance” and not binding policy, which is not consistent with the mandate of a GNSO EPDP and is therefore procedurally deficient as outlined in more detail in the BC’s and IPC’s Minority Statement. The differentiation process outlined in this recommendation should be required as part of mandatory differentiation by contracted parties between natural and legal person data. As the text of the Final Report itself states, “The GDPR does not cover the processing of personal data which concerns legal persons and in particular undertakings established as legal persons, including the name and the form of the legal person and the contact details of the legal person.” And yet, contracted parties are not required to differentiate and thereby publish such legal person data, despite the purported goal of the EPDP to preserve the RDDS to the greatest extent possible while complying with privacy law. The guidance in this recommendation provides a legally sound process for achieving this goal and should be made mandatory for all contracted parties, rather than left as non-binding voluntary guidance that contracted parties are free to (and therefore will) ignore.
3. EPDP Phase 2A Rec. #3 provides, in part, “The EPDP Team recommends, in line with GDPR Article 40 requirements for Codes of Conduct, that the above developed guidance concerning legal/natural differentiation should be considered by any possible future work within ICANN by the relevant controllers and processors in relation to the development of a GDPR Code of Conduct.” Is there any new, specific, and concise information the ICANN Board should consider with respect to Recommendation 3?
The BC and IPC oppose Recommendation 3. As discussed in the BC’s and IPC’s Minority Statements, this recommendation does not define any enforceable obligations on the part of any specific party. Recommending that work on a Code of Conduct be “considered” by “any possible future work within ICANN” is vague and unenforceable, and it leaves unaddressed community priorities that deserve due attention. The BC and IPC would support a recommendation mandating a multi-stakeholder, open and transparent process to establish a Code of Conduct on the issue of differentiating between natural v. legal persons for purposes of RDDS and/or a more holistic Code of Conduct covering various RDDS policy issues that have been the subject of the EPDP.
4. EPDP Phase 2A Rec. #4 provides, in part, “The EPDP Team recommends that Contracted Parties who choose to publish an intended to be pseudonymized registrant-based or registration-based email address in the publicly accessible RDDS should evaluate the legal guidance obtained by the EPDP Team on this topic (see Annex F), as well as any other relevant guidance provided by applicable data protection authorities. Is there any new, specific, and concise information the ICANN Board should consider with respect to Recommendation 4?
The BC and IPC oppose Recommendation 4. The EPDP Phase 2A team recognized that it is technically feasible to have a registrant-based email contact (i.e. a unique anonymized email address, i.e. a pseudonymized email address), but failed to mandate such a contact on the basis of certain risks and concerns identified by some stakeholders. While the BC and IPC acknowledge that this approach carries a slightly higher risk profile than a registration-based or fully anonymized email address or web form (the current requirement under the EPDP Phase 1 policy), the benefits to anti-abuse efforts far outweigh these additional risks and the BC and IPC believe such an approach would still comply with privacy law. The non-binding guidance in Recommendation 4 bears out this balance of risks and benefits. Thus, the BC and IPC continue to believe that a registrant-based pseudonymous email address should be required to facilitate the investigation of DNS abuse by enabling contactability and cross-referencing of registrations by registrants.
Summary of Attachment
The attached is the joint BC and IPC comment on EPDP Phase 2A Final Report.
Summary of Submission
As previously stated in the BC’s and IPC’s Minority Statements on the EPDP Phase 2A Final Report, the BC and IPC are ardent supporters of privacy rights and the protective intent of the GDPR. However, in the context of the EPDP team’s work -- a team that was explicitly directed to “preserve the WHOIS database to the greatest extent possible” while complying with privacy law -- the resulting policy exceeds what is necessary to protect the data of natural persons. As it has previously stated, the BC and IPC strongly believe that optional differentiation of legal vs. natural persons is inadequate and that ICANN policy must require such differentiation to ensure the security and stability of the global DNS. The EPDP Phase 2A recommendations, by not requiring a mandatory distinction between the data of legal vs. natural persons, results in a significant number of registration records being redacted or otherwise unavailable, which substantially inhibits online anti-abuse efforts. Further, the EPDP Phase 2A recommendation declining to require a unique anonymized email address for unique contacts significantly inhibits anti-abuse efforts again through an overly conservative approach that far exceeds what is necessary to comply with applicable law.
Thus, while the EPDP Phase 2A Chair designated the Phase 2A recommendations as supported by “consensus”, the BC and IPC restate that they do not support the Phase 2A outcomes, do not support a “consensus” designation, consider the recommendations as mostly unenforceable non-policy, object to the GNSO Council’s approval of these outcomes, and implore the Board to reject these non-consensus outcomes that do not serve the mission of ICANN in preserving the security, stability, and resiliency of the DNS and which go well beyond the need of ICANN and contracted parties to comply with applicable law.