[NCAP-Discuss] The threshold of harm issue

Fri Apr 29 21:59:13 UTC 2022

Anne – respectfully, you didn’t address my concern or any of my 4 questions. You dodged the issue with the tired “yes but bad things might happen!” argument that gets us nowhere.

What is the acceptable level of “harm?” If one computer is down for one hour, is that too much? Defining the level of acceptable harm is a necessary pre-requisite to everything you suggest needs to be done. You state: “…get a system in place that avoids applications being made for strings that actually pose too much risk from a name collision standpoint…” I’m asking us to carefully define the “too much risk” part. We have not, and it sounds like we have implicitly defined it as “zero risk is acceptable.”

It’s a hard slippery slope problem. No one wants to see anyone harmed for any period of time. But the Internet is a messy place and any innovation -- really any change -- causes non-zero risk. If we are truly adopting a zero-acceptable-risk posture, then the only intellectually-honest position for NCAP is to (1) recommend against the addition of new TLDs, and (2) recommend that the transfer of any existing Registration in all existing TLDs be prohibited. Lest we forget: the most dangerous collisions -- bar none -- happen in .com – simply as a product of its size, popularity, and dynamism.

Anne, please read our report starting at page 11 where we address the “harm” issue:

https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf

Jeff

From: Aikman-Scalese, Anne <AAikman at lewisroca.com>
Date: Friday, April 29, 2022 at 4:26 PM
To: Jeff Schmidt <jschmidt at jasadvisors.com>
Cc: NCAP Discussion Group <ncap-discuss at icann.org>
Subject: RE: The threshold of harm issue
Jeff,
As you know, I heartily disagree with your conclusion that if there were harms occurring to consumers in the name collision arena, we would know about it.  There is no way consumers are going to search for ICANN reporting systems.  They mostly have no idea what ICANN is and what it does.  If the consumer is the subject of a Man in The Middle Attack (which you agreed in chat in our Wednesday meeting can happen anytime)  the consumer is just going to say “I’m the victim of fraud and I don’t know where to go to get that fixed.”

There is no evidence for your conclusion that this type of harm is a “hiccup”.  It affects the Security and  Stability of the Internet and Consumer Trust and Confidence in the DNS.  Reports apparently appeared on blogs and the results of Casey’s report in relation to system harm should not be ignored.

The Sub Pro Final Report Recommendation 29.1 clearly states that the Board MUST have a system in place for assessing name collision risk and that is exactly what has been happening here for months – trying to develop a system that meets that Sub Pro Final Recommendation.    It would be great if folks could move forward constructively to get a system in place that avoids applications being made for strings that actually pose too much risk from a name collision standpoint the so-called DO NOT APPLY list referenced in the Sub Pro Final Report.

As I pointed out on the Wednesday call, it would also be great if the system being developed were to allow for individual applicants to submit mitigation/remediation plans where volume and diversity of name collisions creates a fairly high level of risk – all in accordance with the Sub Pro Final Report Recommendations.    The Workflow is evolving in that direction and that is positive.

Anne

Anne E. Aikman-Scalese
Of Counsel

AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>
D. 520.629.4428
[cid:image003.png at 01D85BD4.AFCD6EA0]

From: NCAP-Discuss <ncap-discuss-bounces at icann.org> On Behalf Of Jeff Schmidt via NCAP-Discuss
Sent: Friday, April 29, 2022 1:59 PM
To: ncap-discuss at icann.org
Subject: [NCAP-Discuss] The threshold of harm issue

[EXTERNAL]
________________________________
We must address the threshold of harm issue. Our collective failure to address this head-on results in the “but bad things might happen!” logic that is currently, and unhelpfully, driving this group.

During the call this week, I again brought-up the importance of calling-out what *specific* problems from the 2012 round we are trying to remedy, in agreement with the public comment we were reviewing. NCAP has never done this. As a response to this during the call, someone pasted in the chat one of the horror-stories self-reported to ICANN’s collisions reporting system. It was – roughly - along the lines of X machines were unavailable in Y offices globally, for Z period of time to remediate. The implication was that this was unacceptable and is a problem that needs to be solved in the next round.

Question 1: Is it?

Question 2: What about X-1 machines in Y-1 global offices? What if Z was a day, a week, or a month?

Question 3: What if it was a hairdresser? What if it was an electric utility? What if it was the propaganda arm of a national government we disagree with?

Question 4: Does there arise a duty to verify self-reported harms given that it could cause a scenario that will negatively impact someone else (i.e. will a self-reported harm deny an applicant the string they want or cause an increase in the applicant’s costs to obtain said string (because of “mitigation strategies,” etc.) given some unverified, self-reported harm?

I realize most folks on this list have not read our reports. I would encourage (beg?) each of you to do so. We discuss this topic deliberately and the resulting impossible slippery slope problem. The reason for the high threshold (“impact to human life”) is very deliberate, well-reasoned, and as appropriate now as it was years ago.

If we consider basically any Internet-age hiccup (spam, malware, MITM, transient outages, etc) as an unacceptable harm if they’re caused by collisions, we need to say that and define a threshold. Else, we’re kicking the can for the Board to make these determinations which is not a winning strategy.

Jeff

________________________________

This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220429/49df1f09/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 281 bytes
Desc: image002.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220429/49df1f09/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 2100 bytes
Desc: image003.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220429/49df1f09/image003-0001.png>