[gnso-rds-pdp-wg] Joint Controller / Article 26 / Hamilton Memo

[Paul Keating]

I agree  Michael,

However, I am not sure how this moves the ball anywhere since I believe that
liability attaches to the processor as well.  A case in point is the actual
display of WHOIS data to the public ­ whether or not it is WHOIS pertaining
to a registrant/customer.

>From my point of view I consider WHOIS to be a necessary data set for any
number of reasons.  My goal is to find a methodology that allows WHOIS data
to be collected and made available with appropriate protections for privacy
concerns. By appropriate I mean a system that balances the privacy concerns
against the needs of the general public.

Paul


From:  <gnso-rds-pdp-wg-bounces at icann.org> on behalf of theo geurts
<gtheo at xs4all.nl>
Date:  Thursday, October 26, 2017 at 8:29 AM
To:  <michael at palage.com>, 'RDS PDP WG' <gnso-rds-pdp-wg at icann.org>
Subject:  Re: [gnso-rds-pdp-wg] Joint Controller / Article 26 / Hamilton
Memo

>     
>  You are right Michael.
>  
>  Though there is a chance that this is covered more in-depth in part 2?
>  
>  Theo 
>  
>  
> On 25-10-2017 23:55, michael at palage.com wrote:
>  
>  
>>     
>>  
>> 
>> Hello All, 
>>  
>>  
>>  
>> I must admit it has been hard to keep up with the flood of recent list
>> traffic.  However, I would like to interject a legal issue raised in the
>> Hamilton Memo which I do not believe has been properly discussed to date.
>> Specifically, Hamilton¹s determination that both ICANN and Registration
>> Authorities (Registries and Registrars) are Joint Controllers, see Paragraph
>> 3.4.4 of Hamilton Memo.
>>  
>>  
>>  
>> Article 26 of the GDPR on the issue of Joint Controller states that ³Where
>> two or more controllers jointly determine the purposes and means of
>> processing, they shall be joint controllers.²  For the purpose of this
>> analysis I will focus exclusively on Registries as well as the fact that
>> there seems to have been a lot of list traffic in connection with the recent
>> actions of .AMSTERDAM and .FRL.  Prior to ICANN, the legacy gTLDs were thin
>> registries. Over the years ICANN has mandated through various RFPs/Applicant
>> Guidebooks the requirement that a TLD be operated in a thick format.   But
>> for a Consensus Policy mandating VeriSign to convert .COM and .NET from thin
>> to thick there was no desire or need for Verisign to have access to this
>> data. How can parties be ³joint² controllers, when one party has the
>> unilateral right to impose its will on the other?
>>  
>>  
>>  
>> I am puzzled why Hamilton made this legal determination and whether it knew
>> of these historical data points. I am also puzzled why Hamilton believes that
>> ICANN as a Joint Controller can unilaterally undertake a DPIA without
>> consultation with the other joint controllers.  I would submit that history
>> and this action, point toward ICANN being the sole Data Controller, and
>> ³most² registries being a Data Processor. As evidenced by VeriSign, most gTLD
>> registries do not need thick data to perform their core business functions.
>> They are only deemed a Joint Controller because ICANN has mandated that they
>> collect and process the PII of registrants.
>>  
>>  
>>  
>> I would welcome any additional insight on this Article 26 issue.
>>  
>>  
>>  
>> Best regards,
>>  
>>  
>>  
>> Michael
>>  
>>  
>>  
>>  
>>  
>>  
>>   
>>  
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> 
gnso-rds-pdp-wg at icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-w>>
g
>>  
>  
>  
> _______________________________________________ gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20171026/259e49ff/attachment.html>