[ALAC] EPDP Early input

Wed Aug 29 13:35:40 UTC 2018

While ICANN's situation is unusual, GDPR doesn't care. The greatest benefit
as a nonprofit is that ICANN can assert "legitimate interest" more readily
than a for profit. However, as I mentioned, legitimate interest rests on a
balancing test between the interests of a PII subject and the data
controller. There are many cases where where individual interests outweigh
ICANN's.

On Wed, Aug 29, 2018, 2:06 AM Seun Ojedeji <seun.ojedeji at gmail.com> wrote:

> Sent from my mobile
> Kindly excuse brevity and typos
>
> On Wed, 29 Aug 2018, 03:35 Alan Greenberg, <alan.greenberg at mcgill.ca>
> wrote:
>
>> I'm not at all sure that our situation is comparable. It is certainly far
>> more atypical than a standard business or nonprofit.
>>
>> Most people who have more knowledge of GDPR that I do deem ICANN to ba a
>> controller, although perhaps a join controller. But an unusual one in that
>> unlike most controllers, we do not actually have custody of the data.
>>
>> Regarding where we are going on this, I am not prepared to roll over an
>> just play dead. I think we need to put up a fight to get where we need to
>> be. For instance, there are those who are saying (and using the data
>> commissioners words to "prove" it, that we must not consider any needs
>> other than our own. I differ on this. ICANN is not just responsible for
>> making sure that the DNS records are orderly. We also have a responsibility
>> to ensure that the DNS is usable and trusted. Although the ICANN mission
>> does not use that word in this context, I believe that an untrusted DNS may
>> as well not be there and be replaced with some other mechanism. GPDR DOES
>> allow us to consider the needs of others. Article 6.1(f) explicitly says
>> so. It is not unlimited but it is there and should allow us to make the
>> case for ensuring that law enforcement and cyber security workers can get
>> access. That is part of our job in this game.
>>
>> And like some of the SAC101 recommendations, we need to not only make
>> sure that the data is there, and accessible, but that it can in practice be
>> accessed (such as recommendations on RDAP and rate limiting).
>>
>
> SO: Agree
>
>>
>> The Temporary Spec is overreaching in that it says we are responsible for
>> the entire framework for such activities and that is nonsense,
>>
>
> SO: By "we" I believe that ICANN is referred here, my question to you then
> is if ICANN is not who else should responsible for that? (at least on high
> level basis)
>
>
> but I believe that we do have a responsibility to ensure that we support
>> that framework and ensure that some types of data are available.
>>
>
> SO: While I agree with the principle of support from ICANN, may I know who
> you believe should prepare the framework?
>
> Regards
>
>
>> If that is not why we are on the EPDP, then I hope someone will tell me
>> that so I can save myself an awful lot of work.
>>
>> Alan
>>
>>
>> At 28/08/2018 08:44 PM, Holly Raiche wrote:
>>
>> Thanks John
>>
>> It’s really helpful hearing from someone who has to implement GDPR - and
>> can bring those insights to the table.
>>
>> I think we all struggle to work through - first - whether ICANN is the
>> data processor or controller, and from there, what information is actually
>> required by whom, used by whom and accessed by whom.
>>
>> * If there were an easy answer, I think we’d be there.  But none of this
>> is easy, so this insight is really welcome.*
>>
>> Thank you
>>
>> Holly
>> On 29 Aug 2018, at 10:37 am, John Laprise <jlaprise at gmail.com> wrote:
>>
>> So in my day job I was one of the GDPR implementation leads and we’ve
>> just wrapped up the initial work. We were assisted by an external
>> consultancy. That said, if anything SSAC did not go far enough.
>>
>> ICANN has a contractual basis for data collection related to the
>> contracts it signs. The claim of legitimate interest is stretched well
>> beyond it’s intent and in fact the EU has opined on the balancing test
>> required. My understanding of the balancing test would call into question
>> even legitimate law enforcement requests where the PII was of an individual
>> or organization known to be persecuted. In that case, couldn’t exert
>> legitimate interest if it fails the balance test.
>>
>> I am sympathetic to the needs of security researchers and law enforcement
>> but ICANN data collection does not exist for them, though it is used by
>> them. The proper scope is identifying what data SSAC and RSAC need and use
>> to advance ICANN’s mission.
>>
>> While rationale for data collection is one pain point, another that my
>> org discover was in terms of data transfer/processing. Legitimate interest
>> is not recognized rationale there. Moreover as a US nonprofit ICANN is
>> ineligible for PrivacyShield which could give it some cover.
>>
>> Finally and perhaps to make matters worse, the technical spec instruct
>> registries on data collection. I confess that at this point I’m not sure
>> whether ICANN is acting as a data controller or a data processor. In a
>> sense, the registries are data controllers and ICANN is the data processor,
>> thrusting the onus of compliance upon registries.
>>
>> I’m at the limits of my GDPR for the day so additional thoughts would be
>> welcome.
>>
>> Best,
>>
>> John
>>
>> *From:* ALAC < alac-bounces at atlarge-lists.icann.org> *On Behalf Of *Holly
>> Raiche
>> *Sent:* Tuesday, August 28, 2018 2:17 PM
>> *To:* Marita Moll <mmoll at ca.inter.net>; ALAC <
>> alac at atlarge-lists.icann.org>
>> *Cc:* Alan Greenberg <alan.greenberg at mcgill.ca >
>> *Subject:* Re: [ALAC] EPDP Early input
>>
>> Thanks Marita
>>
>> I like your wording.  Ys it is a big document and I like your wording as
>> to wha it is in the report that we endorse.
>>
>> Holly
>> On 29 Aug 2018, at 1:18 am, Alan Greenberg <alan.greenberg at mcgill.ca >
>> wrote:
>>
>> Marita, I am not sure that your synopsis is all that different from
>> endorsing the entire paper when you start examining the rationales, but I
>> would be happy to accept that if we can get closure on it quickly. Time is
>> our enemy in this overall EPDP process.
>> Alan
>>
>> At 28/08/2018 10:38 AM, Marita Moll wrote:
>>
>>
>> Sorry to have missed the call -- still confusing midnight Monday with
>> midnight Tuesday -- I guess I will get used to the format.
>> I just read this really well done SSAC report which is clear and
>> thorough. But there is a lot in there. I wonder if we should do a blanket
>> endorsement of everything without careful analysis.
>> Could we not have a more nuanced position? For example, we could say
>> that, in line with our mandate to support end-users, we support SSAC's
>> position on ensuring that security professionals and law enforcement have
>> adequate access to WHOIS/RDS data.
>> If that is the point we want to make.
>>
>> Marita
>> On 8/28/2018 2:23 AM, Alan Greenberg wrote:
>>
>> As I mentioned on the ALAC call that has just completed, all EPDP
>> participant groups have been given the opportunity to provide "early input"
>> into the EPDP.
>> So far, the SSAC and the NCSG has done so. Their input can be found at
>> https <https://community.icann.org/x/Ag9pBQ>
>> ://community.icann.org/x/Ag9pBQ <https://community.icann.org/x/Ag9pBQ>.
>> The SSAC's input consisted of their recent report SAC101. A copy is
>> attached for your convenience.
>> I would like to suggest that the ALAC submit a statement saying that we
>> support SAC101, as it is in line with our stated position of trying to
>> ensure that security professionals and law enforcement have adequate access
>> to WHOIS/RDS data.
>> I open the floor for discussion and will initiate a Consensus Call later
>> in the week.
>>
>> Alan
>>
>>
>>
>> _______________________________________________
>>
>>
>>
>>
>>
>> ALAC mailing list
>>
>>
>>
>>
>>
>>
>>
>>
>> ALAC at atlarge-lists.icann.org
>>
>>
>>
>>
>>
>>
>>
>>
>> https://atlarge-lists.icann.org/mailman/listinfo/alac
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> At-Large Online:
>>
>>
>>
>>
>>
>>
>> http://www.atlarge.icann.org
>>
>>
>>
>>
>>
>> ALAC Working Wiki:
>>
>>
>>
>>
>>
>>
>>
>>
>> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
>>
>>
>> _______________________________________________ ALAC mailing list
>> ALAC at atlarge-lists.icann.org
>> https://atlarge-lists.icann.org/mailman/listinfo/alac
>> At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki:
>> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC
>> )
>>
>> _______________________________________________ ALAC mailing list
>> ALAC at atlarge-lists.icann.org
>> https://atlarge-lists.icann.org/mailman/listinfo/alac
>> At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki:
>> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
>>
>> _______________________________________________
>> ALAC mailing list
>> ALAC at atlarge-lists.icann.org
>> https://atlarge-lists.icann.org/mailman/listinfo/alac
>>
>> At-Large Online: http://www.atlarge.icann.org
>> ALAC Working Wiki:
>> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/alac/attachments/20180829/a0338db3/attachment.html>