[Accred-Model] Codes of conduct

[jonathan m]

I haven't had a chance to read this yet, but this looks like it will be
useful to read through for our work:

Comments
<https://www.huntonprivacyblog.com/wp-content/uploads/sites/28/2018/07/cipl_comments_on_edpb_draft_certification_guidelines__10_july_2018_-c.pdf>
by the Centre for Information Policy Leadership on the European Data
Protection Board’s “Draft Guidelines 1/2018 on certification and
identifying certification criteria in accordance with articles 42 and 43 of
the Regulation 2016/679” Adopted on 25 May 2018

On Wed, Aug 1, 2018 at 1:29 PM, jonathan m <jonathan.matkowsky at riskiq.net>
wrote:

> Theo, hope you are well.
>
> For the benefit of list, The EU Cloud COC I was referencing can be
> downloaded from here,
> https://eucoc.cloud/en/contact/request-the-eu-cloud-code-of-conduct.html
> - the latest version is May 2018. I thought the governance section is
> fairly useful for purposes of discussion only. See Section 7.
>
> Best regards,
> Jonathan
>
> On Sun, Jul 29, 2018 at 9:55 PM, Theo Geurts
> <theo.geurts at realtimeregister.com> wrote:
> > Correct, handling complaints is an important part. And I agree with the
> rest
> > also.
> >
> >
> > https://cispe.cloud/code-of-conduct/
> >
> >
> > https://www.twobirds.com/~/media/pdfs/gdpr-pdfs/43--
> guide-to-the-gdpr--codes-of-conduct-and-certifications.pdf?la=en
> >
> >
> > Best regards,
> >
> >
> > Theo Geurts
> >
> >
> > Compliance & Policy Officer | Realtime Register B.V.
> >
> >
> > Ceintuurbaan 32A
> >
> > 8024 AA - ZWOLLE - The Netherlands
> >
> >
> > T: +31.384530759
> >
> > F: +31.384524734
> >
> > U: www.realtimeregister.com
> >
> > E: legal at realtimeregister.com
> >
> > Skype: geurts.theo
> >
> >
> > ________________________________
> > From: Accred-Model <accred-model-bounces at icann.org> on behalf of
> jonathan m
> > <jonathan.matkowsky at riskiq.net>
> > Sent: Sunday, July 29, 2018 6:09:09 PM
> > To: Rod Rasmussen
> > Cc: accred-model at icann.org; gdpr at icann.org
> > Subject: Re: [Accred-Model] Codes of conduct
> >
> > The issue of scaling is critical. But scaling also raises special
> > considerations under GDPR as large-scale processing, and various use
> > cases present different degrees of risk to the data subject.
> >
> > In terms of eligibility for access, only a defined set of user groups
> > would be eligible for access, but only one of which would be
> > legitimate interest-based processing requestors (and only for those
> > types of requests for which legitimate interest-based processing is
> > permissible under GDPR without consent). For legitimate interest based
> > users (as opposed to other categories such as tasks carried out in the
> > public interest or exercising official authority vested in the
> > controller), they should be monitored by codes of conduct reflecting a
> > governance system that is transparent, building on input from relevant
> > stakeholders, and allowing organizations interested in being part of
> > the governance to be invited to express interest.  The EU Cloud CoC
> > can possibly be used as a model for organizational framework of a code
> > and its bodies – governance bodies and administration.  Without
> > prejudice to the tasks and powers of the competent supervisory
> > authority, the monitoring of compliance with a code of conduct may be
> > carried out by a body which has an appropriate level of expertise in
> > relation to the subject-matter of the code and is accredited for that
> > purpose by the competent supervisory authority. It must demonstrate
> > its independence and expertise in relation to the subject-matter of
> > the code to the satisfaction of the competent supervisory authority,
> > establish procedures and structures to handle complaints about
> > infringements of the code or the manner in which the code has been, or
> > is being, implemented by a controller or processor, and to make those
> > procedures and structures transparent to data subjects and the public,
> > and demonstrate to the satisfaction of the competent supervisory
> > authority that its tasks and duties do not result in a conflict of
> > interests. The competent supervisory authority will then submit the
> > draft criteria for accreditation of a body to the European Data
> > Protection Board pursuant to the consistency mechanism in Article 63.
> >
> > Best,
> > Jonathan
> >
> >
> > On Wed, Jul 25, 2018 at 11:42 PM, Rod Rasmussen <rod at rodrasmussen.com>
> > wrote:
> >> Michael,
> >>
> >> I don’t believe that codifying these issues and resulting disclosure
> >> requirements works against the principals you are referring to here.  On
> >> the
> >> contrary, I think that creating norms and standards around these issues
> >> resolves many things that are currently ambiguous at best.  I think one
> >> way
> >> of interpreting my remarks is that there are OTHER “ignoring these
> issues
> >> won’t make them go away” concerns as well.  :-)  We have to be able to
> >> balance the legitimate interests of registrants' (and other listed
> >> contacts’) rights to privacy with the need to keep the Internet running
> >> efficiently in a way that doesn’t Balkanize it based on policies set by
> >> individual network operators’ tolerance for abuse who don’t have the
> time
> >> to
> >> determine what domains or even TLDs are “baby versus bathwater”.
> >> Balkanization will only invite intervention by other more powerful
> parties
> >> that currently are not paying much attention and letting the ICANN
> >> community
> >> figure these things out on its own.  I think these challenges are both
> >> solvable and necessary to address how we mature Internet domain name
> >> policies from all perspectives.  I bring them up though so we don’t lose
> >> sight of the fundamental reality of how the Internet is actually
> working.
> >> The Internet is basically a network of networks that agree to cooperate
> >> with
> >> each other for the common good of all at a grand scale that is difficult
> >> for
> >> humans to comprehend rather than a discreet set of one-off decisions
> made
> >> by
> >> individuals that are relatively easy to discuss on a case-by-case basis.
> >> We
> >> have to do our best to think at scale when talking about making policy.
> >>
> >> I think we’ll need that $4 and more as Euros in Barcelona though to work
> >> this all out - perhaps over a good bottle of Garnache Tinta!
> >>
> >> Cheers,
> >>
> >> Rod
> >>
> >> On Jul 25, 2018, at 1:12 PM, Michael Palage <michael at palage.com> wrote:
> >>
> >> 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>
> >> 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
> >> https://mm.icann.org/mailman/listinfo/accred-model
> >>
> >>
> >
> >
> >
>



-- 
_____________________________
Jonathan Matkowsky
VP, Cybersecurity, Privacy & IP
JD, CIPP/EU, CIPT
PGP Fingerprint EB45 EF13 14B8 2A1A 1783  1154 B6B6 AE12 A604 D2EC

RiskIQ, Inc. | 22 Battery St. 10th Floor | San Francisco, CA 94111 |
1.888.415.4447


http://www.riskiq.com

-- 
*******************************************************************
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.


*******************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accred-model/attachments/20180801/e715d437/attachment-0001.html>