CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe.
Folks,
The IRT has reached closure and consensus on the wording for
Urgent Requests. Here are the concerns I continue to have.
1.
How to reach the registrar
So far as I can tell, the proposed procedures and policies do not include a
well specified means for reaching a registrar urgently. This seems to me a gap, i.e., an incomplete
solution. A gap of this sort means the
proposed system is not fit for purpose (NFfP).
NFfP is a showstopper. No amount
of process or consensus or reference to the policy development process manual
overcomes NFfP.
Current registrar contact info is idiosyncratic, i.e. not organized in any
uniform way. Some of the registrar representatives (Sarah, Owen) claim
law enforcement personnel know how to reach them. Some law enforcement
personnel (Gabe) say that when law enforcement specific contacts exist, they
are not universally known to all law enforcement entities for all registrars.
I did not claim that LEA know how to reach registrars.
I stated that the RAA (in Section 3.18.2) requires all registrars to maintain a contact to receive abuse complaints from LEA. The RAA, however, does not require this contact to be public (as once a contact becomes public, it becomes a honeypot and loses its value). If a registrar will not provide LEA with the dedicated LEA contact, ICANN Compliance 100% can require the registrar to do so.
Recent ICANN audits have also tested LEA abuse contacts and made registrars remediate if it was determined that they were noncompliant. I am very frustrated seeing the whole “we don’t know how to contact registrars” line, because for 10 years, the RAA has required registrars to provide these contacts. I also know that ICANN has terminated registrars for not providing the proper contacts.
Whois queries now include contact info for reporting Abuses. However, when I suggested LEA could use the
Abuse contact, a registrar representative said fielding Abuse reports and
fielding Urgent Requests requires different skill sets, and the people on duty
to handle Abuse reports cannot be used to field Urgent Requests.
This was a requirement in the 2013 RAA, and I’ll be blunt, it was a complete disaster.
The 2013 RAA required abuse contacts to be an email address, which resulted in almost 100% of emails being spam. Because the abuse contact was originally supposed to be towards the top of the whois output, a decent amount of people assumed the abuse contact was the registrant’s contact leading to more confusion. Many registrars now automate the abuse email to reply with a link to a form to ensure the proper data is supplied and to reduce spam. ICANN also allowed abuse emails to be displayed towards the bottom of whois output.
And yes, an LEA contact should be different than an abuse contact. The requirements in the RAA for an abuse complaint are to "take reasonable and prompt steps to investigate and respond appropriately” which is a lot different than the LEA obligation, which require a non-automated response within 24 hours. Namecheap processes over 1 million abuse complaints a year, so yes, LEA and data disclosure requests should be through a different contact so they can be timely identified and actioned.
This begs further discussion. What will
the person fielding Abuse complaints do if the input is from a law enforcement
agent presenting an Urgent Request?
Further, law enforcement personnel, when asked “What do you actually do
in practice?” respond, “We use all available means.”
Again, as I have stated repeatedly, disclosure requests should be separate from abuse complaints. Registrars do not just have one single queue for handling the myriad of inquiries we receive- whois inaccuracy, UDRP provider emails, customer support inquiries, web hosting requests, DMCA complaints, ICANN tickets, ccTLD tickets, etc, etc, etc. Some of these require special training to respond to (e.g. LEA abuse complaints), whereas others can be handled by low level/introductory support staff.
Disclosure requests require legal review. Lawyers are not working these queues, and for many smaller registrars, the lawyers are outside counsel. We need to stop conflating disclosure requests with general registrar requests/inquires such as abuse complaints, because they require a significant level of sophistication that the other 99.9% of requests do not require.
Although Namecheap does not maintain data, I can confirm that a large number of people use our abuse queue to submit data disclosure requests. This is despite that our website clearly states how to request data, and it is completely outside of our abuse process. Yes, those requests are delayed because our abuse team is trained to process… abuse complaints.
I suggested registrars supply a contact for
Urgent Requests, and that it be available only to trusted requesters, principally
known law enforcement personnel.
Further, ICANN could maintain such a list and act as an
intermediary. The financial impact on
registrars should be negligible because this only requires reaching a
responsible party within the registrar.
It does not impose any specific requirement on what the registrar does
with the call. Making the contact data
available only to trusted personnel and/or having ICANN field the requests
would essentially eliminate the registrars’ concerns about being inundated with
false requests.
I disagree that the financial impact is negligible.
As the registrars have stated on numerous occasions, data disclosure requests require legal review. Lawyers are expensive. Keeping such a lawyer (or lawyers) on call 24/7/365 is cost prohibited for Namecheap, and we are one of the largest registrars in the world. This would be impossible for most (if not all) registrars. The penalties for improper disclosure are staggeringly high, which is why lawyers have to be involved (plus it is a legal balancing process, not looking to see if a domain is phishing or not). The potential liability for suspending a benign site for abuse is so much lower.
If I recall correctly, this was rejected
for two distinct reasons. One was an
insistence that such calls would necessarily require bringing an attorney into
the conversation to determine whether the request is genuinely Urgent and that
it is permissible to provide the requested data. The other response was this constituted a new
proposal and thus is outside the scope of the Implementation Review Team.
Yes, this is correct. Lawyers will always be involved in a data disclosure request due to the high risk of improper disclosure and the nature of the balancing test. I am concerned that this fact does not appear to acknowledged by those who continue to insist on impossibly short disclosure periods.
2.
Actual data
There does not seem to be any data on situations that have arisen in the past
that resulted in Urgent Requests. Or,
even if the criteria is loosened to include other requests that do not fit the
narrowly defined definition of an Urgent Request but nonetheless were urgent
(lowercase) and high priority, there doesn’t seem to be any concrete data.
This makes it hard to know whether there really needs to be a defined procedure
for handling Urgent Requests. I assume
the group has nonetheless agreed to this.
Going forward, Urgent Requests should be reported and the data reported
on a regular basis.
Agreed there should be data.
As far as I can tell, nothing along this line is included in the current
proposal. This is not a showstopper, but
it’s a lack and should be addressed.
3.
Confusion; Optics
The wording embodies two kinds of confusion.
First, by emphasizing the maximum response time, it creates the
impression that ICANN is officially specifying the response time for Urgent
Requests to be measured in days. This is
both confusing and a bad look. At the
very least, the description of the rule should make it clear that registrars
are expected to respond quickly. The
specification of a maximum response time is intended to deal with worst case
situations, not normal emergencies.
A fine under the GDPR can be up to 2% of a company’s worldwide annual revenue. While I appreciate the optics and the need for urgent requests (and in most scenarios Namecheap can accommodate an urgent request), I cannot commit my company to an impossible timeline that could result in a $5 million fine if Namecheap makes an improper disclosure.
I’m a lawyer, so I cannot approach this by looking at "most scenarios". I need to look at the extreme cases, because that is how we ensure we can comply all of the time. Because I guarantee, at some point, the “worst case” scenario will arise, and a registrar will either lose an accreditation or face a massive fine.
Second, the registrars are really looking
for protection against harassment or penalty if they haven’t responded
quickly. Whether the response time is 24
hours or several days due to vacations is probably not relevant for Urgent
Requests. It will be too late. Instead, the purpose of this specification is
to protect registrars from having to maintain a standing army of lawyers and to
protect themselves from a flood of bogus requests.
Which should I tell my boss we should risk: a multimillion dollar fine, or losing our ability to do business? I cannot tell him to do either. We need to have a reasonable timeframe for disclosure request that is indeed measured in business days because that is what the policy stated.
Much clearer wording would help.
********************
CAUTION:
This email originated from outside the organization. Do not click
links unless you can confirm the sender and know the content is safe.
********************
_______________________________________________
IRT.RegDataPolicy mailing list
IRT.RegDataPolicy@icann.orghttps://mm.icann.org/mailman/listinfo/irt.regdatapolicy_______________________________________________
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.