Steve and Seb, also off-list, I offer further views on Steve's proposed requirement list follow (in italics). These are my views alone - the Board has not taken any position on these issues.
In an ideal world, the requirements Steve identifies are entirely sensible. But in almost all cases - including in the case of the dozen US State data protection laws adopted in recent years - data protection law consists of a set of principles. While there is some similarity in the fair information principles underpinning data protection law, interpretation (and enforcement) varies from sovereign to sovereign and from regulator to regulator, even in a single sovereign space. But, with rare exception, all of the following things are true:
- Data protection laws require a data Controller (for purposes of this discussion, the registrar) to apply a set of high-level principles to a specific situation, on a case-by-case basis.
- The data Controller is on the regulatory/judicial hook for applying those principles, in each case, in accordance with the views of the relative regulator in the first instance and, ultimately, the relevant judicial authority.
- There is not enough relevant case law, whether at the local/regulatory level or at the broader judicial level (e.g., ECJ), to enable the level of regulatory/judicial predictability needed to support Steve's requirements.
- Absent regulatory clarity, a registrar's response to a request for registration data will necessarily turn on a combination of: (i) its interpretation of how the principles should apply to a particular situation; (ii) its best guess as to how a relevant regulator would apply those principles; and (iii) its risk appetite.
- The absence of on-point precedent incentivizes Controllers to take a conservative approach to disclosure - in the eyes of lawmakers and regulators, that is a feature, not a bug. This, in turn, reduces the likelihood that clarifying precedent will emerge.
- ICANN has no authority or ability to impose its views on (i)-(iii) above on a registrar/controller that is liable for compliance with applicable law.
- A very broad indemnification from ICANN might address a registrar's financial exposure for disclosure, but will not protect the disclosing registrar against reputational and operational risk. As a result, even indemnification by ICANN might not change outcomes, i.e., output will continue to vary from request to request based on the specific use case, the relevant jurisdictions (both the data subject's and the registrars), and the specific registrar.
- Data protection laws disfavor - and in some cases specifically prohibit - automated decision-making where resulting decisions will have a legal or other material impact on data subjects.
Steve, off list, I offer some observations on your comments in blue (Becky's additional thoughts in green italics)
- Users (requesters) of the system need to know whether their requests will be fulfilled and what data they will receive. As part of this, they need to know what they have to do to be qualified to make those requests, and they need to know what their obligations are after they receive the requested data. Under relevant data protection laws, each request must be evaluated based on the relevant standard on a case by case basis. In the EEA/UK/Switzerland, for example, registrars will need to decide on a case by case basis whether: (i) the requestor has a legitimate interest in the data and (ii) whether the privacy rights of the individual should take precedence over those interests. Agree, see above.
- Holders of the data, usually the registrars, need to know they will not incur significant risk if they provide responses in accordance with the rules. There is, at present, no way for registrars to be assured this is the case.
- The vast majority of the requests and responses should be handled automatically. This is the only way to keep costs under control and to make the system usable for the majority of cases. Automated processing with legal/similar/serious impact on individual rights is affirmatively prohibited under GDPR. Note that we specifically sought a legal opinion on this issue and Bird & Bird opined that regulators were likely to conclude that a decision to release registration data rose to the legal/similar/serious level. Please note that this concern about automated decision making is NOT limited to GDPR. Most of the 12 US states that have adopted data protection laws in the last couple of years impose higher standards with respect to automated decision making. E.g., under §59.1-573(A)(5) of the Virginia CDPA, consumers have the right to opt out of the processing of their personal data for purposes of profiling in furtherance of decisions that produce legal or similarly significant effects concerning the consumer.
- There needs to be a way to perform searches and correlations. These may need to be done via trusted intermediary processes. This functionality was not present in the old whois system and I don't think it was a requirement coming out of the policy development process. Can the small team, or even the GNSO Council, obligate registrars to provide new services in the absence of a PDP? Agree, further policy development is required to impose this obligation on registrars. But in the context of bona fide cyber security research, couldn't searches and correlations be done without personal data or using pseudonymized data, at which point personal data could be requested? The necessity prong of the legitimate interest test requires a finding that there is no less intrusive way to serve the legitimate interest(s) of those conducting searches and correlations.
- The quality/accuracy of the data has to be addressed. Allowing privacy/proxy services without control vitiates the entire notion of accurate registration data. I don't disagree, although once again I don't think either the GNSO Council or the Board has authority under the bylaws. Agree, further policy development is required to impose this obligation on registrars.
- Privacy laws and general privacy principles have to be observed. Agree
- The system should be designed and operated to apply to and be for the benefit of the entire Internet community, not just the ICANN contracted parties. Agree
I'll try to say more going forward. For the present, this note signals an objection to the proposed charter as it is currently written.
Thanks,
On Tue, Sep 5, 2023 at 5:07 PM Sebastien@registry.godaddy <Sebastien@registry.godaddy> wrote:_______________________________________________Hi Steve,
I fully understand the approach the group has agreed upon for the RDRS is not your preferred path. I believe the point has been clearly made on a number of occasion and yet the group has agreed to proceed with it. We collectively note your assessment that it is a mistake.
To be clear, in my view there is no foregone conclusion and no one benefits from temporising for 2-3 years. If either were the case we’d be wasting our time and ICANN’s investment. I hope we collectively remain responsible enough to avoid both.
To your key points:
- Users (requesters) of the system need to know whether their requests will be fulfilled and what data they will receive. As part of this, they need to know what they have to do to be qualified to make those requests, and they need to know what their obligations are after they receive the requested data.
The template originally provided by the Registrars, which we are using on the Request side is both meant as a tool to gather the required elements, and a checklist to ensure the Requestor does not miss any key information.
This in itself doesn’t guarantee “qualifying” for the data as it will depend on the assessment of the Sponsoring Registrar not only based on the data provided, but also on the jurisdiction they operate from and the local DPA’s own thresholds for what does or not qualify. There are efforts to harmonize these things within the EU and we are already experiencing wide differences; in our case we are building an international tool that will need to cater for entirely different legislations.
I assume we will cover the Requestor’s obligations when we review the T&C’s, but here too, responding Registrars may need to cover additional requirements to ensure adherence to their local law.
- Holders of the data, usually the registrars, need to know they will not incur significant risk if they provide responses in accordance with the rules.
The difficulty here is that it is neither for us nor for ICANN to guarantee that. Registrars will not incur risks if they adhere to their local legislation. I’ll let ICANN Org speak for itself, but I don’t see it offering a blanket protection to respondents in its T&C’s, if fact it has made clear from Day1 that it leaves the responsibility squarely in the Registrar’s camp.
- The vast majority of the requests and responses should be handled automatically. This is the only way to keep costs under control and to make the system usable for the majority of cases.
We have had this conversation before: it is unfeasible, someone needs will own the responsibility for every answer and we cannot demand that this decision be taken blindly.
- There needs to be a way to perform searches and correlations. These may need to be done via trusted intermediary processes.
I am not sure what is involved here. Can you please elaborate as long as we are not discussing doing research on specific requests and their responses, this has already been assessed and refused both by ICANN Org and the Respondents.
- The quality/accuracy of the data has to be addressed. Allowing privacy/proxy services without control vitiates the entire notion of accurate registration data.
The issue of Privacy/Proxy has been addressed: it will not be tackled here, but we have engaged the Board to ask that the work on PPSAI be restarted. RDRS may need to be adapted in consequence, but we are not pre-empting the outcomes of that work which may be months/years away.
- Privacy laws and general privacy principles have to be observed.
It’s a given.
- The system should be designed and operated to apply to and be for the benefit of the entire Internet community, not just the ICANN contracted parties.
We are in full agreement.
To be clear if it wasn’t for the benefit of the Community, I believe ICANN (and I assume you mean Org) would probably want to stay away from any involvement at all.
I don’t believe we can reduce taking in account the risk incurred by the contracted parties for potentially inappropriately handling the PII entrusted in them, as working “just” for the contracted parties.
I remain available to discuss this further.
Kindly,
Sebastien Ducos
GoDaddy Registry | Senior Client Services Manager
+33612284445
France & Australia
From: Steve Crocker <steve@shinkuro.com>
Date: Thursday, 24 August 2023 at 3:03 pm
To: Sebastien Ducos <Sebastien@registry.godaddy>
Cc: gnso-epdpp2-smallteam@icann.org <gnso-epdpp2-smallteam@icann.org>, Steve Crocker <steve@shinkuro.com>
Subject: Re: [GNSO-EPDPP2-SmallTeam] EPDPP2-SmallTeam - Next stepsCaution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@.
Sebastian, et al,
Thanks. As best I can tell, the proposed revised charter is to proceed with the old SSAD. To say this another way, the implementation and deployment of RDRS is a two to three year temporizing step, and then the plan is to return to the previously proposed SSAD concept. I think this is a major mistake. At the very least, it deserves a careful assessment of the purpose and whether the design will accomplish the purpose.
Here are the key points. (This is not necessarily complete; there may be other key points.)
- Users (requesters) of the system need to know whether their requests will be fulfilled and what data they will receive. As part of this, they need to know what they have to do to be qualified to make those requests, and they need to know what their obligations are after they receive the requested data.
- Holders of the data, usually the registrars, need to know they will not incur significant risk if they provide responses in accordance with the rules.
- The vast majority of the requests and responses should be handled automatically. This is the only way to keep costs under control and to make the system usable for the majority of cases.
- There needs to be a way to perform searches and correlations. These may need to be done via trusted intermediary processes.
- The quality/accuracy of the data has to be addressed. Allowing privacy/proxy services without control vitiates the entire notion of accurate registration data.
- Privacy laws and general privacy principles have to be observed.
- The system should be designed and operated to apply to and be for the benefit of the entire Internet community, not just the ICANN contracted parties.
I'll try to say more going forward. For the present, this note signals an objection to the proposed charter as it is currently written.
Thanks,
Steve
On Thu, Aug 24, 2023 at 8:46 AM Sebastien@registry.godaddy <Sebastien@registry.godaddy> wrote:
Dear Small Team,
As we will all be back at our desks in the next week or two I wanted to get us back into thinking about what is ahead of us with the RDRS.
1/ Thank you to those who contributed to the documents shared by Yuko last month. I am including her 27 July email below if anyone needs a refresher.
We agreed that there was no immediate need to pivot this into presentations, brochures or any other support you might need to promote the service, but as we are now able to look at our calendars for the next few months, it would be good to raise possible requests and deadlines if you are attending relevant events and would want Staff support in producing material.
2/ Marika sent 2 days ago a reminder to review and confirm the proposed charter for the Standing Committee to continue our good work after launch (see https://docs.google.com/document/d/1IFmCY1xEtWy7IoyM-uSYiRkzFkc0jLdM/edit). Thank you to those who confirmed it works. Thumbs up also from the Requestor side would be great.
3/ We will need to get into reviewing T&Cs before launch. I understand these have been in the working and we can look forward to drafts soon.
4/ We have not scheduled our next meeting yet. A number of us haven’t yet returned from their break.
Next week (28 July) looks early and the following Monday is Labor Day in the US. Unless anyone is itching to get back to it earlier, can I suggest for prepare our next call for Monday 11 September at our regular schedule, for a call every second week thereafter? I will ask Staff to send us invite to block the time slot. We can always agree to augment the cadence in the lead to launch if we find we need more time to get ready for it.
Kindly,
Sebastien Ducos
GoDaddy Registry | Senior Client Services Manager
+33612284445
France & Australia
_______________________________________________
GNSO-EPDPP2-SmallTeam mailing list
GNSO-EPDPP2-SmallTeam@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdpp2-smallteam
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
GNSO-EPDPP2-SmallTeam mailing list
GNSO-EPDPP2-SmallTeam@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdpp2-smallteam
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.