Whois/privacy and the SSAD

[Raphael Beauregard-Lacroix]

Hi all

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.

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.

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

Have a nice day,


On Thu, Jan 6, 2022 at 10:37 PM Stephanie E Perrin <
stephanie.perrin at mail.utoronto.ca> wrote:

> 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>
> <farzaneh.badii at gmail.com>
> *Sent:* Tuesday, January 4, 2022 4:49 PM
> *To:* Mueller, Milton L <milton at gatech.edu> <milton at gatech.edu>
> *Cc:* NCSG List <NCSG-DISCUSS at listserv.syr.edu>
> <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/20220107/8cf352de/attachment.htm>