<div dir="ltr">Hi all<div><br></div><div>Thanks to you three for your contributions. Regarding your initial question Milton, at the procedural level, I'd rather wait and have a Board resolution to work with rather than jumping the gun. I think there is value in letting the Board come forward with its full rationale rather than dangling the "threat" (not used here in a pejorative way) of one. </div><div><br></div><div>As for the substantive points, I am also of the opinion that we should steer clear, as a matter of principle, from any system that would allow mass and/or automated requests to be granted to any actor, either big IP and their proxies or law enforcement. So if a slimmed down SSAD allows for that, then yes. </div><div><br></div><div>The fear of "relitigating" should not let us fall into the sunk costs fallacy. Relitigating is a problem, but a lesser one than a system that allows automated mass disclosure. I'm pretty sure that such a system would end up on the CJEU's docket and face serious legal troubles there. And then we'd be in for relitigation all right. So better take pause and use this as an opportunity (although I know it's easy to say for someone who's not actually involved in the EPDP...) </div><div><br></div><div>Have a nice day, </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 6, 2022 at 10:37 PM Stephanie E Perrin <<a href="mailto:stephanie.perrin@mail.utoronto.ca">stephanie.perrin@mail.utoronto.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>
</p>
<p class="MsoNormal"><span>Don't
worry Milton, I have been thinking about this particular
problem, just have not
responded yet. It is not a simple problem.<span> </span>Firstly, with respect to
the staff analysis
that you attached to your email, let’s look at what we already
knew and in fact
reiterated throughout the EPDP (and in my case, since the EWG
and the RDS).<span> </span>I am tired
of the sound of my own voice on
this one; doubtless you are tired of hearing me but here goes
again:</span></p>
<p><span style="font-family:Symbol"><span>·<span>
</span></span></span><span>We said
this would be expensive</span></p>
<p><span style="font-family:Symbol"><span>·<span>
</span></span></span><span>We said we
had not seen clear data
about abuse that justified forcing decisions from the CPs or
automating the
SSAD.<span> </span>No cost benefit
discussion can
proceed without this data.<span> </span>Why
build it?
Is the first question.</span></p>
<p><span style="font-family:Symbol"><span>·<span>
</span></span></span><span>I
particularly object to the comment
in the analysis that there <b>could </b>be a “notional” cost
for requestors.<span> </span>This is
ridiculous, why should the RNH pay
for third party access?<span> </span>We
have pounded
on that for years and we should continue to do so.</span></p>
<p><span style="font-family:Symbol"><span>·<span>
</span></span></span><span>ICANN is
being timid about its role
as a data controller.<span> </span>It
appears to be
throwing its hands up and saying this is too hard. [NB:<span> </span>Timid is not the first word
I came up with here…nor
the second or third.<span> </span>They
are not taking
responsibility for leadership here.]</span></p>
<p class="MsoNormal"><span>Please
don't let’s rush to a go/no-go on this one. I don't want to
throw out
years of work on the off-chance ICANN is throwing up its hands
and begging to
be legislated, because they don't want any
accountability/liability for these
operations.<span> </span>We need to
have a fulsome
discussion about the apparent problem, which was sprung upon us
just before the
holidays, not just among fellow NCSG members, but at Council.<span> </span>There is a lot at stake
here, but that does
not mean we give up.</span></p>
<p class="MsoNormal"><span>I
propose we put the analysis from staff which you circulated in a
google doc for
NCSG input, and put our comments in. Members who wish to
comment on the doc, message me and I will send you the link.
Meanwhile, here are a few preliminary thoughts:<br>
</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>First
thing:</span></p>
<p class="MsoNormal"><span>I
agree with you re Janis' response. His example of getting a
visa
automatically from Canada is rather poor. Passport and visa
systems are
some of the most opaque in the business, subject access requests
do not get you
useful info, there is a heavy veil of secrecy about the decision
making apparatus
even in so-called democracies. So Janis, as a former diplomat
who may
still be travelling on a diplomatic or govt passport might well
get a rapid
response, particularly from a country that is an ally. Others
might
not....and it might not be so automated. Comparison of such a
binary
issue (yes/ no) under tight government control, with data
sharing only among trusted partners, with the complex series of
operations that CPS must go through to
evaluate the legitimacy of a third party request for PI
disclosure is not
appropriate in my opinion.</span></p>
<p class="MsoNormal"><span><br>
</span></p>
<p class="MsoNormal"><span>Second
thing: Our problem here, the centralization of the
accreditation and
verification of requestors, is a much more difficult problem. I
have
supported the concept of centralized identification,
accreditation, and
verification of requestors since I joined the Experts Working
group, because I
think a neutral third party could be useful for those tasks, and
shield contracted
parties from undue pressure from law enforcement and security
agencies in their
own territory. That is as far as I would go...it does not
include
automation, except in rather trivial respects (e.g. recognizing
repeat
customers). It certainly does not include decision making
regarding the
request. It might include verifying that all required data in a
request
is present. I would think that this could be a benefit for
CPs. Not
all CPS have competent people like the ones we have on our EPDP
to deal with
abuse reports and access requests.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Note
that accreditation and verification of a request does not mean
access. It
means steps 1-3 have been done, and someone has taken
responsibility for them.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Third
thing: As I have repeated (often) when a request from an
organization (or a person) is received, the data controller
needs to ascertain
the following:</span></p>
<ul type="disc">
<li class="MsoNormal"><span>is this person who they claim to be?</span></li>
<li class="MsoNormal"><span>do they have authority to demand information
under law (eg law enforcement, competition bureau, the
government department responsible for the protection of
endangered species, etc). Important to remember that a
request from a law enforcement official of any description
must include reference to the provision of the law that is
being enforced, a proclamation that they have delegated
authority to enforce that provision of the law, and ideally
(in my view) a signature from whoever has the authority to
delegate that task to them. In other words, just because
someone claims to be a cop or a food inspection officer or
whatever, you need to back that all up. Not so easy to
automate.......people move around a lot, revocation of
authority is often neglected and is expensive to manage in
bureaucracies, etc.</span></li>
<li class="MsoNormal"><span>does the authority match the request for data (
or is it a giant fishing trip)? Only the CP can answer that
one, in my view. Even if they know their customer, which is
unlikely</span></li>
<li class="MsoNormal"><span>do I have sufficient proof that I can rely on
this request as being valid, in the event of a complaint
regarding the release of the data? In other words, who is
liable here if there is a mistake?</span></li>
</ul>
<p class="MsoNormal"><span>Fourth
thing, and this one is really important:</span></p>
<ul type="disc">
<li class="MsoNormal"><span>What role is ICANN playing in terms of the
controller relationship, by running this engine and taking on
the above tasks? I don't believe it is a processor role, I
think it is a controller role, particularly when you add the
escrow controller role, and the accuracy oversight role that
they must play in other contexts of the data life cycle.
However, have we seen any legal opinions from 2Birds on this?
I must have slept through it if we have.....</span></li>
</ul>
<p class="MsoNormal"><span><br>
</span></p>
<p class="MsoNormal"><span>Fifth
thing: Jurisdiction. It matters a lot where the jurisdiction
is. It should be clear, and accepted by the RNH. Many of
Farzi's
very relevant concerns arise in this context....if I am a
political activist
and have chosen a registrar in a jurisdiction that I trust will
not hand me
over for torture, I need to be certain of the jurisdiction who
will be handling
access requests. The decision of acting on a verified LEA
request remains
with the CP, not ICANN, and if I have chosen my jurisdiction
well, I can count
on them operating under the rule of law. Screening requestors,
verifying
that relevant data in the request is present, and liaising with
the myriad law
enforcement portals in the various countries is certainly a role
that ICANN
could, as a full joint controller, play here without influencing
the
jurisdiction that any potential action might be taken in.<span> </span><span> </span>Better
ideas would be welcome here, but as I have indicated previously,
I am a fan of
secure anonymous credentials for verified human rights
advocates, refugees, the
free press, etc. who are at risk of persecution.<span> </span>I would note here that it
is getting more and
more difficult to predict who might be at risk under these
circumstances, the
field is getting larger and larger.</span></p>
<p class="MsoNormal"><span><br>
</span></p>
<p class="MsoNormal"><span>Sixth
thing, rather tangential but important because it is arising in
the accuracy
committee as well:</span></p>
<p class="MsoNormal"><span>WE
went at this whole GDPR compliance activity backwards, and in
pieces. WE
dealt with the data collection and disclosure requirements in
the temp spec,
and we examined the "disclosure instrument" in the EPDP. From a
data protection perspective, with the interests of the RNH in
mind, it matters
not what side of the "picket fence" an activity takes place.
The stuff in the RAA was the only data policy we had, and we
chartered the EPDP
within the boundaries of what the CPS wanted discussed in a pdp:<span> </span>the historical WHOIS and
their data
collection obligations in the 2013 RAA.<span>
</span>Certainly that was the burning building in 2018.
However, we ought
to be looking at the controller agreements between the CPs and
ICANN, because
there are a lot of things where the accountability remains
obscure. An
RNH has a right to know who is doing what to his/her data. It
is not
clear to me, and I have been paying attention to this process.
As a
result, we continue to scope out (i.e. remove from
consideration) questions
that are extremely relevant to the RNH.</span></p>
<p class="MsoNormal"><span>cheers
</span></p>
<p class="MsoNormal"><span>Stephanie
Perrin</span></p>
<p>
</p>
<div>On 2022-01-05 10:45 a.m., Mueller,
Milton L wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Thanks, Farzaneh</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
A bit surprised that yours is the only comment but perhaps it's
the holidays and the rest of the SG will wake up.
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Regarding your first comment, we cannot have a precise estimate
of the cost because cost depends on usage and usage depends on
how costly it is to use and what the alternatives are, which we
won't know for sure until it is implemented.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
The risk of re-litigating issues is real, but I think ICANN and
various SGs have made it clear that the final disclosure
decision has to be made by the contracted parties. So you are
right, the SSAD is basically a triage of requests +
accreditation.
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
I agree with you that the whole issue of accrediting governments
(and major users such as brand protection and so-called
cybersecurity researchers) is concerning and problematic. That
is why I would like to find a way to dump accreditation
altogether and slim down the SSAD into nothing more than a
centralized request system. I am afraid that accreditation will
confer some kind of de facto expectation or right to disclosure,
and to mass, automated requests. Especially for governments.
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
I know that some privacy advocates believe that accreditation is
going to be protective rather than enabling. I think this is an
incorrect view and needs to be more realistic about what will
happen if ICANN creates a globalized accreditation and access
system.<br>
</div>
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
If we (you, me, NCSG) can agree on that, we can then discuss
what next steps would help us get to that goal (the goal being
a slimmed down SSAD basically a centralized intake system for
requests).
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
--MM<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_721340770306215690divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b>
farzaneh badii <a href="mailto:farzaneh.badii@gmail.com" target="_blank"><farzaneh.badii@gmail.com></a><br>
<b>Sent:</b> Tuesday, January 4, 2022 4:49 PM<br>
<b>To:</b> Mueller, Milton L <a href="mailto:milton@gatech.edu" target="_blank"><milton@gatech.edu></a><br>
<b>Cc:</b> NCSG List <a href="mailto:NCSG-DISCUSS@listserv.syr.edu" target="_blank"><NCSG-DISCUSS@listserv.syr.edu></a><br>
<b>Subject:</b> Re: Whois/privacy and the SSAD</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div style="font-family:arial,sans-serif">Hi Milton,</div>
<div style="font-family:arial,sans-serif"><br>
</div>
<div style="font-family:arial,sans-serif">
<div>I looked at the cost report
of this and they really don't have enough information
and data to actually estimate the cost. Obviously the
Intellectual property crowd claims they submit "many"
requests but others say otherwise. I am more inclined
to see if they can pilot an implementation and see what
sort of problems they face (as laid out in the note you
sent). Opening another EPDP or getting back to council
and EPDP is going to risk re-litigating issues for sure.
If we have to take one of those paths, I go with number
1 (reluctantly, because I don't know how the Board is
going to articulate the reasons)</div>
</div>
<div style="font-family:arial,sans-serif"><br>
</div>
<div style="font-family:arial,sans-serif">Isn't this system
just a "triage" of request and an accreditation model?
That the final decision is by the registries and
registrars? I hear a lot of people thinking this is
"disclosure" mechanism, which adds to the complexity. </div>
<div style="font-family:arial,sans-serif"><br>
</div>
<div style="font-family:arial,sans-serif">There are many
unknown issues about the implementation of SSAD. Even the
governments don't want to accredit their own law
enforcement themselves (as mentioned in a letter from the
GAC chair, they just want to verify identity). <a href="https://gnso.icann.org/sites/default/files/file/field-file-attach/ismail-to-fouquart-15dec21-en.pdf" target="_blank">https://gnso.icann.org/sites/default/files/file/field-file-attach/ismail-to-fouquart-15dec21-en.pdf</a></div>
<div style="font-family:arial,sans-serif"><br>
</div>
<div style="font-family:arial,sans-serif">And anyhow that
recommendation that governments each get to accredit their
own law enforcement is unfortunately a terrible idea. And
what will happen to sanctioned countries that are usually
authoritarian and have law enforcement to suppress
opposition? will they get access to personal information
of people while people suffer from sanctions? Or perhaps
the contracted parties deny them access. (I raised the
issue at an NCSG meeting last year,implicitly, but I guess
the ship has sailed)</div>
<div style="font-family:arial,sans-serif"><br>
</div>
<div style="font-family:arial,sans-serif"><br>
</div>
<div style="font-family:arial,sans-serif">Best regards, </div>
<div style="font-family:arial,sans-serif"><br>
</div>
<div style="font-family:arial,sans-serif"><br>
</div>
<div>
<div dir="ltr">
<div dir="ltr">
<div><font face="verdana, sans-serif">Farzaneh </font></div>
</div>
</div>
</div>
<br>
</div>
<br>
<div>
<div dir="ltr">On Tue, Jan 4, 2022 at
3:04 PM Mueller, Milton L <<a href="mailto:milton@gatech.edu" target="_blank">milton@gatech.edu</a>>
wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Greetings all and happy new year. <br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
As one of your representatives on the EPDP
dealing with Whois and privacy, I want to inform you
of the latest development.
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
You will remember that a lot of sensitive domain name
registration data is now redacted (hidden), because
ICANN had to come into compliance with GDPR. The SSAD
(Standardized System of Access and Disclosure) was an
elaborate mechanism developed by the EPDP to allow
people who want to see the hidden data to request its
disclosure. The proposed SSAD had an elaborate
mechanism for accrediting users of the system,
including a process for each national government to
accredit its own law enforcement and government
agencies.
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
ICANN Org has done a study of the costs of the
proposed SSAD and estimates that it will be very
expensive and will take a long time to implement. The
ICANN board has indicated that it may not approve the
SSAD recommendation because of these problems.
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
So now we are faced with a question about what to do
next. <br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
There are basically two options being presented to us:</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<ol>
<li><span>Let the <span>ICANN Board formally refuse
to adopt the recommendation, tell us what's
wrong with it, and then let the Council and
the EPDP adopt a supplemental recommendation
that fixes the problems</span></span></li>
<li><span><span>Re-convene the EPDP and work out its
own modification of the recommendation.
<br>
</span></span></li>
</ol>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
I've attached a more detailed analysis of the options
that the ICANN staff circulated today. I have my own
opinion about this - I think the SSAD does need to be
simplified and agree with the staff's concerns about
its complexity and cost. But I am not sure what is the
best way procedurally to fix this problem. Hope we can
discuss this as a SG and reach a unified position.
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Cheers,<br>
</div>
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div id="gmail-m_721340770306215690x_gmail-m_6482575050224301035Signature">
<div>
<div id="gmail-m_721340770306215690x_gmail-m_6482575050224301035divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<p style="margin-top:0px;margin-bottom:0px">Dr
Milton L Mueller, Professor</p>
<p style="margin-top:0px;margin-bottom:0px">School
of Public Policy</p>
<p style="margin-top:0px;margin-bottom:0px">Georgia
Institute of Technology</p>
<p style="margin-top:0px;margin-bottom:0px"><a href="https://internetgovernance.org" target="_blank">Internet
Governance Project</a> </p>
<p style="margin-top:0px;margin-bottom:0px"><br>
</p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote></div>