[CPWG] FW: Engagement on DNS Abuse
David Mackey
mackey361 at gmail.com
Thu Feb 4 17:45:01 UTC 2021
Joanna, Wonderful! Thank you!
I also found a useful ICANN66 - GAC Plenary Meeting
<https://gac.icann.org/presentations/public/ICANN66%20-%20Slides%20-%2021%20-%20DNS%20Abuse.pdf?language_id=1>
document
with DNS Abuse background material for other At-Large members who aren't as
well versed as the main players who are doing the heavy lifting on this
issue.
Cheers!
David
On Wed, Feb 3, 2021 at 1:04 PM Joanna Kulesza <jkuleszaicann at gmail.com>
wrote:
> Hi David,
>
> happy to help on the first issue:
> https://www.ecpat.org/wp-content/uploads/legacy/SECO%20Manifestations_CSAM.pdf
> ( *Child Sexual Abuse Material* (CSAM) ) and equally happy to explore the
> root of the picket fence (pun intended).
>
> Thanks,
>
> J.
> W dniu 03.02.2021 o 17:35, David Mackey pisze:
>
> Jonathan,
>
> Thanks for posting.
>
> Simple question first ... Can someone please tell me what "CSAM" stands
> for? I apologize for the uniformed question.
>
> Second question ... Can someone point me to a link that records ICANN's
> decision not to cross the content "picket fence". I'd like to understand
> the context ofJoanna's statement better ... "crosses the content "picket
> fence" that the ICANN community had set for itself".
>
> Thanks!
> David
>
> On Wed, Feb 3, 2021 at 10:27 AM Laurin B Weissinger via CPWG <
> cpwg at icann.org> wrote:
>
>> Dear all,
>>
>> My comments, adding onto Johanna’s:
>>
>> Keeping these in mind the proposed definition and scope of DNS Abuse
>> strikes as arbitrary: what were the criteria set for selecting these
>> specific categories as DNS Abuse while leaving other potential categories
>> out?
>>
>> The perspective I am getting from SSR2 is to start with the obvious,
>> technically detectable ones: phishing, C2, plus reports of those.
>> Essentially, stop crimes in progress that do not require complicated and
>> long human oversight.
>>
>> I am worried about including issues that are private disputes. Even if
>> many use Copyright to stop crimes in progress, as it is the only thing that
>> works. (Consider how insane this is: I need to use the fact that someone is
>> using my logo not as evidence but as a CR issue to stop an actual crime in
>> progress.)
>>
>> Including IP infringement on equal footing with CSAM raises serious
>> concerns among At-Large members
>>
>> Absolutely agree with Johanna on the CSAM aspect. It is, imho, ridiculous
>> and more so offensive to name _private_ copyright _disputes_ alongside
>> CSAM.*
>>
>> Again, speaking from SSR2 experience: focus can be put on forcing
>> immediate review in case of reports, allowing bulk reports, introducing
>> hurdles for criminals on registration, pre-review of suspicious names, etc.
>> (I.e. do things that reduce abuse before it happens)
>>
>> All the best
>> Laurin
>>
>> * Indeed, beyond this being ethically and morally unacceptable, companies
>> (not gonna name names) use copyright complaints to silence their critics
>> (free speech issue), arguably themselves being abusers of the system, at
>> least in some cases.
>>
>>
>> On Wed, Feb 3, 2021 at 15:49, Jonathan Zuck <JZuck at innovatorsnetwork.org>
>> wrote:
>>
>> Evin has suggested that I had, perhaps, NOT forwarded this to the group.
>> Here’s the discussion thread, initiated by Keith Drazek on the Contracted
>> Party House DNS Abuse Work Group. This includes, Joanna’s expression of
>> mission creep concern.
>>
>> Jonathan
>>
>>
>>
>>
>>
>> Jonathan Zuck
>>
>> Executive Director
>>
>> Innovators Network Foundation
>>
>> www.InnovatorsNetwork.org
>>
>>
>>
>> *From: *Joanna Kulesza <jkuleszaicann at gmail.com>
>> *Sent: *Wednesday, January 27, 2021 2:12 AM
>> *To: *Maureen Hilyard <maureen.hilyard at gmail.com>; Jonathan Zuck
>> <JZuck at innovatorsnetwork.org>
>> *Subject: *Re: Engagement on DNS Abuse
>>
>>
>>
>> Great stuff Jonathan, as always. Feel free to share. If I were to add my
>> two cents, I'd put these in the "pain points" section while these are of a
>> more general nature.
>>
>> "From the discussions we've had within At-Large it is clear that the very
>> scope and definition of DNS Abuse is a "pain point". This was also the take
>> away from the discussions we've had with the invited guests from within and
>> beyond the ICANN community. "DNS Abuse" as it is now defined in the
>> proposed Framework affects the entire internet community of end users while
>> being already covered by existing national and international norms and
>> standards. Keeping these in mind the proposed definition and scope of DNS
>> Abuse strikes as arbitrary: what were the criteria set for selecting these
>> specific categories as DNS Abuse while leaving other potential categories
>> out?
>>
>> This is particularly relevant with regard to our second concern: the
>> proposed scope of DNS Abuse clearly crosses the content "picket fence" that
>> the ICANN community had set for itself. Including IP infringement on equal
>> footing with CSAM raises serious concerns among At-Large members. We are
>> concerned not only with the very fact of the picket fence being crossed but
>> also by the way in which this is being done. Does this mean we should
>> finally abandon the well established yet always controversial narrative of
>> a strictly technical infrastructure management?
>>
>> Once content is concerned, the existing and proposed practice fails to
>> recognize international legal safeguards when it comes to restrictions put
>> on individual freedoms. Whenever an individual liberty is to be restricted,
>> due process must be ensured. The procedures proposed by the DNS Abuse
>> framework fail to ensure e.g. a right to an effective legal remedy. While
>> we realize this argument brings us back tot he general discussion on limits
>> of ICANN's contractual jurisdiction, that is an argument we would be
>> interested to during any upcoming DNS Abuse work.
>>
>> Only once these concerns relating to the scope of the definition of DNS
>> Abuse can be addressed, can we focus on metrics and effective enforcement
>> that will provide a fair and operational framework protecting the rights of
>> end users."
>>
>> By all means to feel free to rephrase!:) What I'm arguing for is that for
>> us to be able to "measure" DNS Abuse we should first clearly and
>> transparently decide what it means. The current framework means the
>> contracted parties are indeed trying to play a self-proclaimed internet
>> police (militia?). Why did we presume DNS Abuse is CSAM and (in the same
>> breath) fake Gucci bags but not hate speech and inciting violence? While we
>> clearly would not have the answer ready, that is definitely a discussion we
>> should have. The GAC might be interested in this as well (see last update
>> from Veni on the ITU processes).
>>
>> Thanks for considering team!
>>
>> Best,
>>
>> J.
>>
>>
>>
>>
>>
>> W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze:
>>
>> In your inimitable style. Love it. Send it.
>>
>>
>>
>> M
>>
>>
>>
>> On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck <
>> JZuck at innovatorsnetwork.org> wrote:
>>
>> Ladies,
>>
>> Here’s my draft response. Let me know what you think!
>>
>> Jonathan
>>
>> =============================================================
>>
>> Hey folks! Thanks for reaching out. Joanna and I, for sure, would be
>> willing to join you and I suspect others, as well, once we know the timing.
>> With respect to the questions below, I’ll do my best to provide some
>> initial responses but I suspect the first question might be pivotal. There
>> seems to be a lack of real data on the topic and perhaps some additional
>> objective research is the answers. We endeavored to begin this process,
>> during the CCTRT (sadag-final-09aug17-en.pdf (icann.org)
>> <https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf>,
>> but obviously barely scratched the surface. Perhaps a more comprehensive
>> study, funded by ICANN rather than the CPH or CSG might be in order? I know
>> DAAR provides some answers but it seems to be more of a survey than an
>> example of rigorous research. Specifically to your questions.
>>
>>
>>
>> 1. *What information do you use and how do you use it to assess DNS
>> Abuse levels?*
>> This is obviously where we are weak. There doesn’t appear to be a
>> great source for DNS Abuse “levels,” particularly because of the short time
>> period over which a particular initiative takes place. A snapshot analysis
>> doesn’t seem to get the full picture. The ALAC relies on the concerned
>> raised by the GAC and the SSAC to fuel our belief that there’s more we
>> should be doing. A recent report from Microsoft suggests the problem is
>> bigger than we realize and David Taylor’s analysis of “responsiveness,”
>> even among those who have signed onto the framework, seems damning.
>> 2. *What are the ALAC’s pain points regarding DNS Abuse?*
>> Not sure to answer this in terms of how it’s handled inside ICANN or
>> more generally from where our interests stems. To the latter point, we’re
>> tasked with advancing the interests of those not represented by a
>> constituency in the GNSO, namely those engaged in everyday use of the
>> internet, as opposed to registrants. As the user base continues to grow, as
>> we all desire, so too will the numbers of less sophisticated users, more
>> easily duped by a phishing, malware or fraudulent advertising attack.
>> As for the situation inside ICANN, the At-Large community have
>> attempted to engage constructively as opposed to “attacking” the CPH,
>> focusing instead on so-called “bad actors.” The first session
>> <https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09+March+2020?preview=/124847126/126428447/CCWholistic02.pdf>
>> was an attempt to bring the CPH and Contract Compliance into the same room
>> to figure out where the holes are.
>>
>>
>> 1.
>> *What exactly are the relevant limits on Contract Compliance? *We feel
>> this is a question which comes up constantly and is never successfully or
>> consistently answered. It seems to be an area in which the ICANN community
>> is constantly chasing it’s tail. It would seem that the only real enforced
>> contract provision is payment. I’m sure this is an exaggeration but it
>> seems to be a repeated situation where that is ultimately what foils a “
>> bad actor” after YEARS of neglect, if not outright facilitation of abuse.
>> The answer to THIS question should be a HIGH priority. It might just be
>> agreeing to an interpretation of the contracts or it might require an
>> amendment to the contracts but this issue needs to stop being a merry go
>> round.
>> 2.
>> *Insufficient Transparency from Contract Compliance *Contract Compliance
>> undocumented endeavors at soft touch diplomacy with bad actors seem to need
>> some better limits or, at least, transparency. For “the market” to play a
>> role in this, knowing about legitimate complaints for every contracted
>> party could help customers make better decisions about which businesses to
>> use and help us better understand where policy development needs to take
>> place.
>> 3.
>> *Deflection and Minimization of the Problem *I would say that one “pain
>> point” is that our efforts have been largely “trolled” by certain members
>> of the CPH, rather than engaging constructively. EVEN our effort to
>> conceive of some sort of end user education campaign, to take the pressure
>> off the CPH, was trolled. Jim, not to put you on the spot but, during one
>> conversation, you said you didn’t even understand why this was being
>> discussed because it affects such a small percentage of registered names.
>> To date, we have proposed:
>>
>> *i.* *Better
>> contract enforcement*
>>
>> *ii.* *More
>> tools for Contract Compliance*
>>
>> *iii.* *DNS
>> Abuse “threshold,” an idea that found some support among the CPH at one
>> point*
>>
>> *iv.* *Predictive
>> Analytics platform, perhaps financed by ICANN*
>>
>> The At-Large community has *absolutely* no desire to over regulate or
>> over tax the CPH and we understand most of the contracted parties,
>> particularly those showing up to meetings, are trying to do well and
>> continuously improve. That said, this notion that it’s somehow not “our
>> place,” to be trying to help is nothing short of offensive. It is the
>> active participation of the ALAC and GAC that enable the ICANN to portray
>> itself as something other than a trade association. The At-Large mandate is
>> to advance the interests of those MOST impacted by DNS Abuse. That said, we
>> WELCOME suggestions on how better to engage with the CPH for constructive
>> outcomes.
>>
>>
>>
>> 1. *Are you seeing practices from registrars or registries you find
>> helpful?*
>> If we haven’t said it enough, the At-Large appreciates the efforts of
>> those behind the Framework for DNS Abuse and the huge efforts that went
>> into cooperation with law enforcement to track down COVID related abuse.
>> We’d love to see the framework evolve to include specific commitments and
>> metrics, however, for it to be something on which the community could truly
>> rely.
>>
>>
>>
>> We hope these answers are constructive and not inflammatory as it is our
>> intention to find the most effective ways to proceed to further minimize
>> the incidence of DNS Abuse , in all its forms. Thanks for the opportunity
>> to be part of your conversation.
>>
>>
>>
>> Maureen, Joanna & Jonathan
>>
>>
>>
>>
>>
>>
>>
>> *From: *Keith Drazek <kdrazek at verisign.com>
>> *Date: *Friday, January 22, 2021 at 12:00 PM
>> *To: *"maureen.hilyard at gmail.com" <maureen.hilyard at gmail.com>, Jonathan
>> Zuck <JZuck at innovatorsnetwork.org>, "jkuleszaicann at gmail.com" <
>> jkuleszaicann at gmail.com>
>> *Cc: *"Brian F. Cimbolic" <BCimbolic at pir.org>, Jim Galvin <
>> jgalvin at afilias.info>, Graeme Bunton <gbunton at tucows.com>
>> *Subject: *Engagement on DNS Abuse
>>
>>
>>
>>
>>
>> Hello Maureen, Jonathan and Joanna,
>>
>>
>>
>> I hope you’re all doing well and staying healthy and safe. I am reaching
>> out to you on behalf of the Contracted Party House DNS Abuse Working Group
>> as we look ahead to ICANN 70 and the rest of 2021.
>>
>>
>>
>> The Contracted Party House (CPH) DNS Abuse Group is conducting outreach
>> to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously
>> noted by the CPH, DNS Abuse
>> <https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf>
>> comprises five categories: phishing, pharming, malware, botnets, and spam
>> when it acts as a delivery mechanism for one of the other forms of DNS
>> Abuse.
>>
>>
>>
>> We want to open a more direct dialogue to understand pain points, hear
>> suggestions and identify common ground where we can work together to
>> mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS
>> Abuse questions that would be able to join the CPH DNS Abuse group on a
>> call to discuss this topic? We want to encourage frank and productive
>> discussions on the topic that lead to really informing our dialogues and
>> actions.
>>
>>
>>
>> As a starting point, we propose the following questions to guide our
>> discussion. Are there any other questions ALAC would like discuss?:
>>
>>
>>
>> What information do you use and how do you use it to assess DNS Abuse
>> levels?
>>
>>
>>
>> What are the ALAC’s pain points regarding DNS Abuse?
>>
>>
>>
>> Are you seeing practices from registrars or registries you find helpful?
>>
>>
>>
>> Please let us know if a subgroup of the ALAC would be willing to join
>> us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please
>> propose a Tuesday when you are available.
>>
>>
>>
>> Best regards,
>>
>> Keith
>>
>>
>>
>> Keith Drazek
>>
>> Vice President, Public Policy & Government Relations
>>
>> Verisign, Inc.
>>
>> +1-571-377-9182
>>
>> Kdrazek at verisign.com
>>
>>
>>
>>
>>
>> --
>>
>> Kind regards,
>>
>> Joanna Kulesza
>>
>> -------------------
>>
>> Joanna Kulesza, PhD
>>
>> University of Lodz, Poland
>>
>> ICANN ALAC Vice Chair
>>
>> SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI
>>
>> TT: @KuleszaJ
>>
>>
>>
>>
>>
>> _______________________________________________
>> CPWG mailing list
>> CPWG at icann.org
>> https://mm.icann.org/mailman/listinfo/cpwg
>>
>> _______________________________________________
>> 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.
>
>
> _______________________________________________
> CPWG mailing listCPWG at icann.orghttps://mm.icann.org/mailman/listinfo/cpwg
>
> _______________________________________________
> 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.
>
> --
> Kind regards,
> Joanna Kulesza
> -------------------
> Joanna Kulesza, PhD
> University of Lodz, Poland
> ICANN ALAC Vice Chair
> SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI
> TT: @KuleszaJ
>
> _______________________________________________
> CPWG mailing list
> CPWG at icann.org
> https://mm.icann.org/mailman/listinfo/cpwg
>
> _______________________________________________
> 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: <http://mm.icann.org/pipermail/cpwg/attachments/20210204/dac1f7c5/attachment-0001.html>
More information about the CPWG
mailing list