[Accred-Model] Codes of conduct

Wed Jul 25 20:12:49 UTC 2018

Rod,

I hear your concerns, but I think Jonathan’s original comments about “ignoring these issues won’t make them go away” remains on point.

In reviewing the Version 1.7 there does not appear to have been any expansion on the Auditing and Penalties sections (Section IV, Paragraphs G & J respectively).

The bedrock of the GDPR is about empowering Data Subjects with the right to control the processing of their data and the latest model remains largely devoid of this right. Until the IPC/BC decide to incorporate some type of Data Subject “rights centric” approach into their model, I do not see how it will pass EDPB muster. 

Just my personal two cents as well. Perhaps with another 4 bucks we might be able to split a cup of Starbucks coffee while in Panama.

Best regards,

Michael

From: Accred-Model <accred-model-bounces at icann.org> On Behalf Of Rod Rasmussen
Sent: Wednesday, July 25, 2018 12:11 PM
To: jdm at riskiq.net
Cc: accred-model at icann.org; gdpr at icann.org
Subject: Re: [Accred-Model] Codes of conduct

Jonathan,

Thank you very much for your thoughts here!  To me, this analysis of yours screams for standards so that this can scale, otherwise we will end up with a system that is far too much dependent upon manual determination of issues by all parties to be useful in the real world of abuse that moves at automated speeds (i.e. the bad guys registering or compromising domains at scale (each using thousand of domains per day via automation).  My thesis is that you need a well-defined taxonomy of abuse types, domain abuse scenarios (e.g. abusively registered, compromised in-part, compromised in-full), and threat level (e.g. ongoing mass attack, ongoing targeted attack, potential attack).  From that you can build a matrix of what information is required, what information about requestors can be readily revealed, and who is requested to make what kind of actions and in what timeframe.  For example, for a wide-scale, current phishing attack using a compromised website, a very timely response (within minutes or hours) of a technical contact and registrant contact e-mail and phone number would facilitate solving both the phishing attack and the potential for the registrant to be exposing PII of its own users given that their website tied to a domain is compromised.  The identity of the requestor would not need to be confidential in such a scenario since they *want* the registrant to know that the registrant has a serious problem to solve that could put the registrant in dire straits vis-a-vis GDPR.  Separately, a detection of potentially malicious set of domain registrations that have a high probability that they will be used to launch various fraudulent and illegal scams based on prior observed behavior could result in a longer-term response (day/days) with full information about the registrant of the domain(s) and even other domains registered at near the same time, being provided with the requestor’s information not being revealed to the registrant without them going through process themselves.  The main thing is to agree on what information is appropriate to reveal and how long the responses should take. From there, all parties can build automated systems to create and accept responses for contact information requests, with attestation of the harms driving the actual process that ensues.

It’s all about proportionality and the ability for various harms to be balanced in a non-biased fashion.  I think that if we can approach the various scenarios dispassionately and scientifically, we could provide solid guidance on how any request for registration contact information is dealt with across all registrar/registry players *and* requestors.  The key is putting together a good matrix that all stakeholders can live with, and then making sure people involved in this in all roles understand how to work within the system properly and *do*so.  

The current ad-hoc situation on both the requestor and provider sides is untenable and is already on the path to major negative consequences for all.  Beyond the waste of manpower and unintentional abetting of crime that we’re already seeing, my major fear is that these negative consequences eventually draw the attention of various national governments whose citizens are being abused, who then decide how things should work instead of the parties actually involved.  That scenario historically doesn’t work out well for the affected parties.

My 2 cents.

Cheers,

Rod Rasmussen

Speaking personally and not on behalf of any organization I am part of.

On Jul 16, 2018, at 3:54 PM, jonathan m <jonathan.matkowsky at riskiq.net <mailto:jonathan.matkowsky at riskiq.net> > wrote:

All,

Any model that doesn’t take into account for transparency of processing that a data subject has the right to typically object and freeze the processing is not compliant with GDPR. I think the registrar as a controller must also have the right to object. That doesn’t mean that the processing won’t eventually continue if it is compelling and overrides the rights and freedoms of the individual but subject to Chapter 7 of the GDPR.

When safety is a concern, then as long as the data subject knows which supervisory authority is overseeing the code of conduct under which the request is being made, it’s possible to protect the identity of the requestor. This should be relatively rare. 

Not every legitimate interest outweighs the rights and freedoms of the data subject, and a privacy impact assessment is required. Not every legitimate interest is entitled to the same weight under GDPR, and the risks and severity of harm to the person must be considered especially when certain interests at stake aren’t the same as those of the controller. 

We need RDAP to accommodate these concerns. When law enforcement has legitimate interests, they can use the same RDAP tier of access, but when pursuing a criminal offense or investigation, a different model of access must be accommodated under the LED etc.

Ignoring these issues won’t make them go away.  I hope that truly consensus-building voices participate in the EPDP, because it’s time we stop trying to keep Whois to the greatest extent possible and instead design the next generation to be better—more accurate, with more accountability and integrity but also consistent with data protection laws and internationally recognized norms. It makes sense to generally treat all people — regardless of where they reside, with the same inherent rights and freedoms that European laws are attempting to protect.

Jonathan Matkowsky

VP - Cybersecurity, Privacy & IP

JD, CIPT, CIPP/EU

RiskIQ, Inc.

-- 

Jonathan Matkowsky

*******************************************************************
This message was sent from RiskIQ, and is intended only for the designated recipient(s). It may contain confidential or proprietary information and may be subject to confidentiality protections. If you are not a designated recipient, you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you.

*******************************************************************_______________________________________________
Accred-Model mailing list
Accred-Model at icann.org <mailto:Accred-Model at icann.org> 
https://mm.icann.org/mailman/listinfo/accred-model

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accred-model/attachments/20180725/2ca61eef/attachment.html>