[Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case

Volker Greimann vgreimann at key-systems.net
Mon Sep 2 09:16:35 UTC 2019


How many times does this have to be re-iterated? It does not matter 
whether the registrant is a legal or natural person. It just matters if 
their data contains data of a natural person. So even the data of a 
legal entity registrant can contain personal information that must be 
protected.

And as you are so fond of the law, the law states that the basic 
principle is privacy by design. That means, when in doubt, err on the 
side of privacy. Protecting the data of legal entity when in doubt is 
perfectly in line with legal requirements.

Can we end this debate now, please? We are wasting our cycles on re-runs 
here!

Best,

Volker

Am 02.09.2019 um 06:07 schrieb Alan Greenberg:
> And I will make one last attempt as well. Although I am not sure I 
> agree that "it is unlikely if not impossible to ever provide a 
> legitimate rationale for disclosure", but I agree it would not be 
> common. So your analysis is spot on. *IF* the registrant is a natural 
> person and protected by GDPR.
>
> Although the issue is still on our Phase 2 list, in Phase 1 we decided 
> that contracted parties are not obligated to differentiate between 
> legal and natural persons. That set what they may or may not put in 
> the public RDS. And it relieved contracted parties from having to 
> recognize legal persons and treat them differently at the time the RDS 
> information is set. _But it did not change the law!_
>
> If the registrar can tell (perhaps by looking at their customer 
> contact information) that the registrant is a legal person, and that 
> there is no personal information in the contact details, then there is 
> no balancing test that must be made.
>
> Alan
>
>
>
>
> At 31/08/2019 06:10 PM, Mueller, Milton L wrote:
>> Alan,
>> I think we are still talking past each other. I will make one last 
>> effort.
>>
>> The purpose of the use cases was to test our assumptions about what 
>> would lead to a successful request for disclosure, what kinds of 
>> legal bases would be used and what kind of safeguards would have to 
>> be in place.
>>
>> The ALAC use case we are debating was about disclosing the identity 
>> of a registrant because a random Internet user is curious about who 
>> the registrant is and thinks they need to know this before buying 
>> something from the registrant. I think our discussion of this case 
>> clearly demonstrated that this rationale will never pass the 
>> balancing test and does not even meet the threshold of 6.1.b. I say 
>> this because:
>> 1.       Curious users can easily, effectively and directly protect 
>> themselves from this uncertainty by not buying or interacting with 
>> unknown or untrusted sites/domains;
>> 2.       Curious users can find the needed information about the 
>> website from other potential sources besides Whois, including, in 
>> many jurisdictions, laws that require such info to be published;
>> 3.       The fact that this curiosity occurs before any harm has been 
>> done means that such a claim will always fail the balancing test 
>> (what is the legitimate interest of the requestor?)
>> 4.       Curiosity about who is behind a domain in the absence of any 
>> harm or demonstrable problem was the rationale behind the openness of 
>> the old Whois, which is known to be illegal.
>>
>> So Amr backed off from the notion of “rejecting this use case,” 
>> but I think his initial statement was valid. Our discussion of this 
>> proposed use case demonstrated that it is unlikely if not impossible 
>> to ever provide a legitimate rationale for disclosure. We appreciate 
>> your bringing it up as a possible use case, which as you note is what 
>> you were asked to do. Now that we have discussed it we are simply 
>> asking you and Hadia to recognize that it is not going to provide a 
>> sufficient rationale for disclosure of private info.
>>
>> --MM
>>
>> *From:* Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> *On Behalf 
>> Of * Amr Elsadr
>> *Sent:* Thursday, August 29, 2019 6:59 AM
>> *To:* Alan Greenberg <alan.greenberg at mcgill.ca>
>> *Cc:* gnso-epdp-team at icann.org
>> *Subject:* Re: [Gnso-epdp-team] Notes and action items from EPDP Team 
>> Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
>>
>> Hi Alan,
>>
>> I take your point on rejection of a use case, and perhaps I should 
>> have been more precise in what I was trying to say. I chose my words 
>> poorly, but I hope you understand what I’m getting at. I did, after 
>> all, acknowledge that discussing this use case has been helpful to 
>> our work.
>>
>> What I meant to say was that this use case should not result in 
>> recommendations resulting in granting disclosure of gTLD registration 
>> data to Internet users (not referring to TM holders here) upon 
>> request, with the aim of them identifying persons (natural or legal) 
>> conducting commerce online. The question of wether an ICANN Consensus 
>> Policy grants the same level of privacy protection to both the 
>> personal information of legal and natural persons is a separate issue 
>> of course, with its own set of arguments.
>>
>> Thanks.
>>
>> Amr
>>
>>
>>     On Aug 29, 2019, at 1:51 AM, Alan Greenberg
>>     <alan.greenberg at mcgill.ca <mailto:alan.greenberg at mcgill.ca> > wrote:
>>
>>     Amr, as few points.
>>
>>     1. This use case is NOT about content. It is true that the user
>>     request *MAY* have been triggered by content of a web site. But
>>     it could equally well have been triggered by an e-mail received.
>>     Or just the semantics of the domain name. A registrar *might*
>>     choose to use any web content as a basis for responding
>>     positively or negatively to such a request for access, but it
>>     could also use its own database of its customer information to
>>     determine if the registrant is a legal person. What the registrar
>>     does in resolving an access request will not be dictated by any
>>     ICANN policy and is purely up to its business practices.
>>
>>     2. I really do not understand the concept if us "rejecting" a use
>>     case. We were asked to identify potential use cases and we did.
>>     You captured the validity of the case at the end of your message:
>>     "there is still nothing preventing an Internet user from
>>     requesting information about a website they might do business
>>     with from a registrar". Any EPDP rejection notwithstanding, a
>>     user may still request access to information about a registrant
>>     that she believes may be a legal person. And a registrar/registry
>>     may ultimately agree to grant that access - or not. Therefore it
>>     *IS* a user case, albeit perhaps one you don't like.
>>
>>     Nothing in this use case presupposes that access will be granted,
>>     nor does it presume that such a use will be handled in anything
>>     but a manual mode with the registrar performing the "balancing"
>>     as dictated by GDPR.
>>
>>     Alan
>>
>>     At 28/08/2019 03:30 PM, Amr Elsadr wrote:
>>
>>         Hi Brian,
>>
>>         I'm not sure that it makes a difference - wether disclosure
>>         can or cannot be presupposed as an outcome. If we, as a Team
>>         developing gTLD policy recommendations, tackle an issue
>>         concerning web content, reach a conclusion (any conclusion)
>>         on it, send a recommendation to the GNSO Council, which is
>>         adopted and then sent to the ICANN Board, which adopts it yet
>>         again, then what is the outcome? To me, the answer to that
>>         question would be that the EPDP Team, the GNSO Council and
>>         the ICANN Board have all contributed to creating contractual
>>         obligations on Contracted Parties that ICANN should have no
>>         business creating.
>>
>>         To me, this is also a means of pulling topics out-of-scope of
>>         ICANN's mission in to it, because although this scope is
>>         defined by the Bylaws, there are also Bylaws granting the
>>         GNSO responsibility for developing gTLD policy. Would create
>>         a bit of a messy constitutional sort of situation, I think.
>>
>>         Also, at some point in the future, the Consensus Policy we
>>         are in the process of developing recommendations for will be
>>         reviewed, and amendments may be sought. Reviewing Consensus
>>         Policies could potentially be initiated by either the GNSO or
>>         GDD (if you're following the current Council conversation on
>>         reviews of implemented Consensus Policies). So even if we are
>>         not presupposing any outcome of disclosure in this use case
>>         now, we open the door to further policy development on this
>>         topic at some point in a future iteration. On a topic that
>>         should have been flagged as out-of-scope of ICANN's mission
>>         to begin with!!
>>
>>         Ideally, we would not submit any recommendations concerning
>>         web content at all. If we did, it'd be nice to know that
>>         there are checks and balances in place that initiate some
>>         kind of course correction. For instance, the GNSO Council or
>>         the ICANN Board would respond saying, wait a minute, why are
>>         you sending us a policy recommendation on a topic outside of
>>         ICANN's scope?! Speaking for myself, unfortunately, I very
>>         much doubt that would happen.
>>
>>         It's probably also noteworthy that even if we, as an EPDP
>>         Team, reject this use case, and do not address the topic in
>>         our recommendations, there is still nothing preventing an
>>         Internet user from requesting information about a website
>>         they might do business with from a registrar, as you suggest.
>>         Our use of these use cases should focus on helping
>>         respondents to disclosure requests understand how best to
>>         deal with whatever disclosure requests they receive. We can't
>>         cover every single potential use case anyway, so the ones we
>>         do work out should at least provide some guidance on how to
>>         deal with unforeseen circumstances. With that in mind, I
>>         believe there is value in addressing this use case, and
>>         rejecting it, as opposed to not looking at it at all.
>>
>>         This is my personal perspective, and apologies if it was
>>         slightly lengthier than it needed to be, but you asked. ;-)
>>
>>         Thanks.
>>
>>         Amr
>>
>>
>>         ‐‐†‐‐‐‐ Original Message
>>         ‐‐‐‐‐‐‐ 
>>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
> _______________________________________________
> 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.
-- 
Volker A. Greimann
General Counsel and Policy Manager
*KEY-SYSTEMS GMBH*

T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
W: www.key-systems.net

Key-Systems GmbH is a company registered at the local court of 
Saarbruecken, Germany with the registration no. HR B 18835
CEO: Alexander Siffrin

Part of the CentralNic Group PLC (LON: CNIC) a company registered in 
England and Wales with company number 8576358.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190902/2e9b27b5/attachment-0001.html>


More information about the Gnso-epdp-team mailing list