[At-Large] DomainIncite : Is this why WhatsApp hates some TLDs but not others?

Sun Sep 17 19:37:07 UTC 2023

Although I served as a member, I am not speaking for the CCT Review Team.
So what was my thinking in supporting these recommendations?

ICANN committed to engender competition, consumer choice and consumer trust
in the DNS; check the AOC. The review team was chartered to see how well
competition, choice, and trust are holding up and what to do if threats to
conservation are uncovered.

We are clear the product of the concession is complicit in doing harm to
end users.  Defrauded end users lose trust. Abnormal extraction of value
from end users causes them to think there is a breakdown in the security
of the DNS.  Taken together, this development devalues competition
objectives, undermines consumer trust and suppresses consumer choice.

Mitigating systemic harms require systemic action. How we address harm at
source when the harm, on its face, is an extension of an ordinary business
process?  Some of us thought a product liability framework may not be the
right approach but certainly elements of that thinking could be useful for
mitigation.

We could avoid capricious compliance action, systematically privilege
registrants who rent for non-fraudulent use and incentivize contracted
parties to go beyond current commercial practice to winnon out
registrant fraudsters.

The CCT outlined a very modest framework proposal. Rejected. Let's see a
better mousetrap then.

Carlton

==============================
*Carlton A Samuels*

*Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround*
=============================

On Fri, 15 Sept 2023 at 17:20, Karl Auerbach <karl at cavebear.com> wrote:

> In order to avoid reading the actual text (yes, I am lazy) what is the
> definition of "DNS security abuse"?
>
> The reason I ask is that I've seen the phrase "DNS abuse" (absent the word
> "security") tossed about to whine (yes I am being hyperbolic and
> pejorative) about things such as "this or that practice annoys my cat" or
> "go to website abc.def.tld and buy solid gold 1kg bars for $1 each."  The
> first is simply out of ICANN's scope and the second probably violates
> fraud/misrepresentation laws in pretty much every country and ought to be
> beyond ICANN's scope.  I would put anything that is covered by national and
> international trademark law outside the umbra or penumbra of the word
> "security".
>
> On the other hand it would, to my mind, be quite within ICANN's scope to
> knock registr* bodies and TLD server operators if they do bad things, like
> leaving logins open via telnet (clear text passwords) or are running on
> easily penetrated foundations such as (let me pick a crazy example) Windows
> 95.
>
>     --karl--
> On 9/15/23 10:58 AM, Carlton Samuels via At-Large wrote:
>
> If you missed it, after a year in pending status, the ICANN Board just
> voted to reject Recs 14 & 15 from the CCT Review.  These were offered for
> mitigating systemic DNS *security* abuse.
>
> #14 recommends amendments offering incentives - inclusive of financial
> ones - in the [RA/RAA] Agreements for the contracted parties adopting proactive
> anti-abuse measures. Nothing too heretical.
>
> #15 recommends amendments to [RA/RAA] Agreements that establish thresholds
> of abuse at which compliance inquiries are automatically triggered and a
> higher one at which registrars and registries are presumed to be in
> default of their agreements.
>
> We went on to recommend a community-developed DNS Abuse Dispute
> Resolution Policy (DADRP) if ICANN Compliance falls asleep on the
> enforcement job. [The text delicately eased into that like only "...*i**f
> the community determines that ICANN org itself is ill-suited or unable to
> enforce such provisions.*"]
>
> In my own view #14 is something regulators do with concessionaires time
> and again. Even the "light touch and by suasion" telecoms ones I know well
> in my home region.
>
> Our ICANN don't play that!
>
> Carlton
> ==============================
> *Carlton A Samuels*
>
> *Mobile: 876-818-1799 Strategy, Process, Governance, Assessment &
> Turnaround*
> =============================
>
>
> On Thu, 14 Sept 2023 at 20:33, Barry Shein via At-Large <
> at-large at atlarge-lists.icann.org> wrote:
>
>>
>> As a company which provides email and other internet services maybe if
>> the new gTLDs agreements included some serious commitment to avoid
>> allowing the use of these gTLDs for massive spamming and phishing etc
>> maybe the service providers would have been more enthusiastic about
>> acceptance.
>>
>> Unfortunately the opposite is true and many of these new gTlDs can
>> safely be blocked in entirety, they just spew spam etc, with no
>> customer complaints.
>>
>> I'll guess these new gTLD registrars/registries would complain that's
>> not equitable since it's not required of other TLDs.
>>
>> Which is all a very nice argument to make sitting in an airless room
>> somewhere.
>>
>> So instead they tend to get blocked and ignored, or at least marked
>> "suspicious" by spam filters, but equitably!
>>
>> If I had a nickel for every ISP who said or recommended "oh just block
>> all .pick-a-nGTLD, you and your customers will be happier"...
>>
>> --
>>         -Barry Shein
>>
>> Software Tool & Die    | bzs at TheWorld.com             |
>> http://www.TheWorld.com
>> Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
>> The World: Since 1989  | A Public Information Utility | *oo*
>> _______________________________________________
>> At-Large mailing list
>> At-Large at atlarge-lists.icann.org
>> https://atlarge-lists.icann.org/mailman/listinfo/at-large
>>
>> At-Large Official Site: http://atlarge.icann.org
>> _______________________________________________
>> 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.
>>
>
> _______________________________________________
> At-Large mailing listAt-Large at atlarge-lists.icann.orghttps://atlarge-lists.icann.org/mailman/listinfo/at-large
>
> At-Large Official Site: http://atlarge.icann.org
> _______________________________________________
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://atlarge-lists.icann.org/pipermail/at-large/attachments/20230917/b0f5a9f1/attachment-0001.html>