Whois/privacy and the SSAD

[Stephanie E Perrin]

Don't worry Milton, I have been thinking about this particular problem, 
just have not responded yet.  It is not a simple problem.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).I am tired of the sound of 
my own voice on this one; doubtless you are tired of hearing me but here 
goes again:

·We said this would be expensive

·We said we had not seen clear data about abuse that justified forcing 
decisions from the CPs or automating the SSAD.No cost benefit discussion 
can proceed without this data.Why build it? Is the first question.

·I particularly object to the comment in the analysis that there *could 
*be a “notional” cost for requestors.This is ridiculous, why should the 
RNH pay for third party access?We have pounded on that for years and we 
should continue to do so.

·ICANN is being timid about its role as a data controller.It appears to 
be throwing its hands up and saying this is too hard. [NB:Timid is not 
the first word I came up with here…nor the second or third.They are not 
taking responsibility for leadership here.]

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.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.There is a lot at stake here, but that does not mean we give up.

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:

First thing:

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.


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.

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.

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:

  * is this person who they claim to be?
  * 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.
  * 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
  * 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?

Fourth thing, and this one is really important:

  * 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.....


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.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.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.


Sixth thing, rather tangential but important because it is arising in 
the accuracy committee as well:

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:the historical WHOIS and their data collection 
obligations in the 2013 RAA.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.

cheers

Stephanie Perrin

On 2022-01-05 10:45 a.m., Mueller, Milton L wrote:
> Thanks, Farzaneh
> A bit surprised that yours is the only comment but perhaps it's the 
> holidays and the rest of the SG will wake up.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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).
>
> --MM
> ------------------------------------------------------------------------
> *From:* farzaneh badii <farzaneh.badii at gmail.com>
> *Sent:* Tuesday, January 4, 2022 4:49 PM
> *To:* Mueller, Milton L <milton at gatech.edu>
> *Cc:* NCSG List <NCSG-DISCUSS at listserv.syr.edu>
> *Subject:* Re: Whois/privacy and the SSAD
> Hi Milton,
>
> 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)
>
> 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.
>
> 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). 
> https://gnso.icann.org/sites/default/files/file/field-file-attach/ismail-to-fouquart-15dec21-en.pdf
>
> 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)
>
>
> Best regards,
>
>
> Farzaneh
>
>
> On Tue, Jan 4, 2022 at 3:04 PM Mueller, Milton L <milton at gatech.edu> 
> wrote:
>
>     Greetings all and happy new year.
>     As one of your representatives on the EPDP dealing with Whois and
>     privacy, I want to inform you of the latest development.
>
>     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.
>
>     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.
>
>     So now we are faced with a question about what to do next.
>
>     There are basically two options being presented to us:
>
>      1. Let the 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
>      2. Re-convene the EPDP and work out its own modification of the
>         recommendation.
>
>     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.
>
>     Cheers,
>
>     Dr Milton L Mueller, Professor
>
>     School of Public Policy
>
>     Georgia Institute of Technology
>
>     Internet Governance Project <https://internetgovernance.org>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20220106/2e4cc4c8/attachment.htm>