[Gnso-epdp-team] Legal vs Natural and Redactions
Benedict Addis
bee at theale.co.uk
Thu Nov 15 14:09:25 UTC 2018
Dear Matt, Alan, and Stephanie,
thank you very much for the constructive feedback.
I really appreciate that both of you have taken the trouble to write and frankly wonder when you manage to sleep!
I guess the problem is as follows:
- we on the ‘data supplicant’ side feel that we’re losing ALL of access to registration data, and that it’s not unreasonable to ask for the data of legal persons, which is (outside of edge cases) not covered by GDPR.
- whereas you on the CPH side (particularly registrars) feel that you’re being asked to do a new thing - distinguishing legal persons - which brings with it extra work and possible liability.
I feel your pain! However I would argue that we ALL benefit from a transparent ecosystem, and there is a systemic risk in redacting the org field that must be balanced with the individual legal risk.
I don’t think this is going round and round, I think this is the kind of argument we need to have. We are in the right place, right now, to fix this problem. Being honest with ourselves, we know that kicking the can down the road won’t produce anything better.
Best,
Benedict.
> On 15 Nov 2018, at 12:54, Matt Serlin <matt at brandsight.com> wrote:
>
> Benedict, Diane, Margie, et al.,
>
> I genuinely appreciate the time, energy and effort everyone has put into this subject…there’s documents and updates flying around left and right, so taking the time out to put something together isn’t a trivial task.
>
> Having said that, the RrSG representatives are growing increasingly frustrated by the fact our myriad objections (with plenty of justification) to this being included as a recommendation continue to be ignored. I’d refer everyone back to the e-mail James sent I believe it was last week. We have been consistent in our position on this.
>
> Not only do we not feel it’s required under the GDPR, we have repeatedly talked about this group’s desire to draft policy that is NOT solely GDPR specific but a global policy that can satisfy the multitude of privacy regulations we know exist around the world. Also, it’s not clear to me how we went from proposing further research on the topic to a full-blown policy recommendation to require it.
>
> We continue to go round and round on this subject with no real end in sight. If the initial report of this group includes this as a recommendation, the RrSG would like our strong objection noted in the report. Additionally (and to be completely transparent), public comments submitted by the RrSG to the initial report will continue to provide objection. We have also been clear that the RrSG GNSO reps could not support any policy recommendation that made this mandatory for registrars to implement.
>
> This is a subject I just don’t see us reaching consensus on.
>
> Again, appreciate that everyone is coming from a good place with their input, but this subject really does present a real risk of derailing all of our hard work to date. I don’t believe that’s in anyone’s best interest.
>
> Best regards,
> Matt
>
>
> From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org <mailto:gnso-epdp-team-bounces at icann.org>> on behalf of Alan Woods <alan at donuts.email <mailto:alan at donuts.email>>
> Date: Thursday, November 15, 2018 at 4:20 AM
> To: Stephanie Perrin <stephanie.perrin at mail.utoronto.ca <mailto:stephanie.perrin at mail.utoronto.ca>>
> Cc: GNSO EPDP <gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>>
> Subject: Re: [Gnso-epdp-team] Legal vs Natural and Redactions
>
> Benedict,
>
> Thank you for your proposal, and I'm always happy to see efforts to view the stated concerns, not as the simply concerns of a 'grouping' in the ePDP, but as concerns of actual compliance with the law, and the efforts that must be made in order to overcome specific legal barriers.
>
> I must, however agree with Stephanie and Lindsay on this and I again must reference my ask of leadership in my previous email, and again request that those who provide recommendations, must dig deeper and also address many of the issues we have.
>
> To conclude, I welcome the attempts, but again this process fails to address the immediate concerns that 1) the CPs have noted that we do not believe we have the systems or ability to make a proper delineation. 2) it does not address the concerns under Art 32 of enhanced likelihood of breach in delineation under the current system. It remains my opinion that the concerns of the CPs have yet been outweighed by any suggested path. The path of compliance, with the minimal impact to the Data Subjects and to the CPs to whom implementation rests, is wilt confirmation of the Temp spec, with some cosmetic drafting tweaks, time permitting,.
>
> I have gone through my own reactions to your proposal below, but this is meat as an illustration, and is extraneous to my above conclusion.
>
> Kind regards,
>
> Alan
>
>
>
> 1. Introduction of policy requiring registrant to make a legal / natural person declaration.
>
> This is not necessary to confirm the Temp Spec, especially where the Temp Spec allows compliance (which we argue is actually minimum compliance, considering the systems available, the state of the art, the nature of the data, and the likely impact to the data subject). All of which are concerns that are not addressed by the proposal.
>
> Regarding SCOPE: I had thought that we, as a group, had stated, and supported Thomas Rickert's helpful suggestion, that should we get an indication from the EDPB that self declaration is sufficient to allow us to escape liability for a data breach, then we would be happy to pursue this.
>
> regardless however, What you are asking for is another policy development, which is not actually in scope for OUR policy creation; (to Brian's point the gating questions do not indicate we must consider the questions, true, but they certainly do not bind us to creating that policy. I alwayswould haveassumed this is in furtherance of our second "power", i.e. to make recommendations to the GNSO for future policy development. [note: that the form of self declaration itself is probably the bulk of a policy effort on this and we have little precious time to waste in the ePDP to even consider what form this may take].
>
> 2. Declaration would be mandatory for registrars to implement within a reasonable time.
> As per 1, this is a conclusion of another PDP, not ours.
>
> 3. No obligation for registrars to verify accuracy of declaration.
> Except of course as per our legal obligations under the GDPR. In particular, Art 25 and Art 32. If a policy seemingly absolves the CPs from liability for not trying to ensure, to some level of reasonable certainty, that the declaration is vaild, this is hardly Privacy by Design or Privacy by Default- Let's be blunt here, what you are talking about is Privacy by Assumption and I cannot support that.
>
> 4. A declaration would only be required during ‘contact' with registrant, ie on registration, renewal, and transfer (by gaining registrar).
> Again the form of such a policy is a matter for another PDP.
>
> 5. Registrar may make declaration on behalf of registrant if it has reasonable knowledge of registrant’s status.
> No. A registrar should be wholly resistant to any suggestion that they can 'consent' on behalf of any registrant (natural or legal). it's not scalable, it's not realistic and likely illegal. But I digress as this is a conversation for another PDP.
>
> 6. Registrant may change their declaration at any time.
> Unless, of course, the Registrar disagrees with this as per 5, yes? I wonder how this tallies with Art 17 requests for those 'opt-in' persons, who have had their personal data published. How are the CPs to reverse this process, nothing the tendency of some to scrape and resell this data? Where are our controls against misuse of the data? This is exactly what the EDPB meant when they talk about 'not publishing to the world at large'. once the genie is out of the bottle, we will find it very hard to squish it back in. Again another point to be considered in the other PDP, with the luxury of time and without the unrealistic expectations of immediate implementation heaped upon it. I would also hazard a guess that there will be some Art 32 security issues regarding the lack of controls, and our continued inability to ensure inadvertent breaches occur.
>
> 7. Fail safe: the absence of a declaration results in assumption that the registrant is a natural person; i.e. default redaction of data.
> Again unless the Registrar disagrees (apologies, i'm being flippant but clearly I think 5 is not really a winner). I can see this is considering privacy by default, however where this concept runs into issues is with the process and procedure (i.e. the Design) that renders such a default as merely lip service. If the situation of 'default' privacy can be altered in a manner that does not fully vindicate the privacy rights of the individual, then the Art 25 tests will fail. But again, this is not a concern for our PDP, but certainly perhaps when making a recommendation for PDP on this, we can warn of the pitfalls.
>
> 8. No obligation to obtain retroactive declarations. (The average domain lifespan is 1.4 years so adoption will happen naturally.)
> Not for us to decide, but I do feel this would be pragmatic.
>
> 9. "edge case" legal persons - for example those trading from home (like me!) or in certain protected categories (as suggested by Stephanie) - may additionally declare that the registration data contained personal or sensitive information, so that it may be redacted.
> To clarify, is this an option to withdraw an assumed consent? This again would give me concern as to Art 25 and consent; if the system is designed to support privacy by both default and design, why would you need to also make a positive obligation to act in a certain manner, for those who wish to preserve their privacy. Surely designing a system which requires a person to perform additional actions to vindicate their 'default' right is not Privacy by either default or design. Also, we are likely encroaching on the realm of Data Subject Rights here (rectification, deletion, and objection) here, again all these should be available by default, not wrapped in policy as if we are somehow bestowing them upon a DS as an optional path.
>
> Also let's be clear, there is, as far as I can see, zero reasons for any processing of sensitive information. Disclosure of, for example, medical status, race, ethnicity, political opinion or sexuality etc. such things should never be ICANN requirements for the registration. Perhaps a (arguably foolhardy) Registry may think this is a good idea and own such a controllership of such a disclosure .... but that's up to them.
>
> 10. False declarations will be subject to the normal whois inaccuracy complaint process.
> I would hardly call this the "Normal" process; surely new process is necessary, designed and created to take into account that we are not merely talking about the registry/regsitrar's opinion as to accuracy but as to our disagreement with the data and 'consent' or lack thereof of a presumed or not presumed data subject (which is based on the declaration of that 'data subject') . Is the suggestion here that we can design a system whereby we are allowed to second-guess or overrule someones wishes to not have personal data published, because it is associated with a company? A bit of a minefield, but again thankfully this is something that should be reserved for another PDP and not us.
>
>
> <http://donuts.domains/>
> Alan Woods
>
> Senior Compliance & Policy Manager, Donuts Inc.
>
> The Victorians,
>
> 15-18 Earlsfort Terrace
> Dublin 2, County Dublin
> Ireland
>
> <https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc>
>
> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
>
>
> On Thu, Nov 15, 2018 at 12:33 AM Stephanie Perrin <stephanie.perrin at mail.utoronto.ca <mailto:stephanie.perrin at mail.utoronto.ca>> wrote:
> Excellent question Brian! My first suggestion on improved language would be that these questions (h3-5) are not in the right order. As we have demonstrated during our discussions, we have different interpretations of what h4 means. My Interpretation is not, "does the GDPR regulate the data of legal person?" It is, "does a legal basis exist in the registration data currently collected globally to satisfy current RDS contractual obligations/" (because we really do not have a valid RDS policy). Legal basis means in this situation, how can we know whether data submitted by a registrant pertains to a legal or natural person? the short answer is we can't, so we do not in fact have a legal basis to make the determination. so h4 = no. H3 would then logically follow, and the short answer to that one is No. H3 is a messy question combining two very separate ideas....should registrars be forced to determine, reliably as required by the privacy protections in the GDPR for natural persons, which is one question.....and then the second part of the question (which by the way assumes a negative answer to the first, in my view....) WHat mechanism would need to be established in order to reliably determine whether registrant data entered pertains to a legal person, or an individual, and if the latter, what consent or other mechanism needs to be implemented in order to mitigate risk? SO in my view BEnedict has provided a proposal as to how to answer that last half of h3, but in my view the answer to the first half is no. So out of scope.
>
> Now turning to h5, which arguably should come before the second half of h3 because it seeks to enumerate the risks, that the mechanism defined in the latter half of h3 must provide (i.e. lets hear the risks before we elaborate the cure). Now, in my view there are several risks, which I have brought up from time to time, also pointing out the fulsome discussion we had on this topic in the PPSAI working group.
>
> I can enumerate those risks again if you like, but I think the answer to the first two questions is no so the elaboration of a new policy and new mechanism should be left to whenever we get the temp spec ratified or altered. We are, as Cherine Chalaby points out in his letter to Drazek, running out of time......
>
> cheers Stephanie
>
>
>
> On 2018-11-14 17:58, King, Brian wrote:
> Hi Stephanie,
>
> I can clarify that this is in scope as we’re answering these charter questions:
>
> h3) Should Contracted Parties be allowed or required to treat legal and natural persons differently, and what mechanism is needed to ensure reliable determination of status?
> h4) Is there a legal basis for Contracted Parties to treat legal and natural persons differently?
> h5) What are the risks associated with differentiation of registrant status as legal or natural persons across multiple jurisdictions? (See EDPB letter of 5 July 2018).
> I would appreciate any suggestions you might have on ways to improve the proposed language?
>
> Per Diane’s note, IPC supports as we think it is a reasonable approach that could garner consensus.
>
> Brian J. King
> Director of Internet Policy & Industry Affairs
> MarkMonitor / Part of Clarivate Analytics
> Phone: +1 (443) 761-3726
> brian.king at markmonitor.com <mailto:brian.king at markmonitor.com>
>
> From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> <mailto:gnso-epdp-team-bounces at icann.org> On Behalf Of Stephanie Perrin
> Sent: Wednesday, November 14, 2018 5:48 PM
> To: gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>
> Subject: Re: [Gnso-epdp-team] Legal vs Natural and Redactions
>
> Given that Cherine Chalaby has just written to Keith Drazek (GNSO Council Chair) to express worry over whether we are going to finish this thing on time, perhaps we ought to stick to what is within scope. It is not clear to me how a new policy requiring that a distinction be made between legal and natural persons is within scope.
>
> Further to this general remark, I do not see any way a registrar or registry can evade responsibility for "accidently" collecting personal information. Consent has to be meaningful and informed. On accuracy....read the RDS reveiw Team II report which is doubling down on accuracy. I would certainly not sign on to this one, if I were a registrar.
>
> It's a good try though!
>
> STephanie Perrin
>
> On 2018-11-14 16:06, Benedict Addis wrote:
> Dear Alan, Hadia,
>
> I’ve discussed this with SSAC colleagues, and propose the following compromise:
>
> 1. Introduction of policy requiring registrant to make a legal / natural person declaration.
>
> 2. Declaration would be mandatory for registrars to implement within a reasonable time.
>
> 3. No obligation for registrars to verify accuracy of declaration.
>
> 4. A declaration would only be required during ‘contact' with registrant, ie on registration, renewal, and transfer (by gaining registrar).
>
> 5. Registrar may make declaration on behalf of registrant if it has reasonable knowledge of registrant’s status.
>
> 6. Registrant may change their declaration at any time.
>
> 7. Fail safe: the absence of a declaration results in assumption that the registrant is a natural person; i.e. default redaction of data.
>
> 8. No obligation to obtain retroactive declarations. (The average domain lifespan is 1.4 years so adoption will happen naturally.)
>
> 9. "edge case" legal persons - for example those trading from home (like me!) or in certain protected categories (as suggested by Stephanie) - may additionally declare that the registration data contained personal or sensitive information, so that it may be redacted.
>
> 10. False declarations will be subject to the normal whois inaccuracy complaint process.
>
> If the team thinks this proposal has merit, there may be an opportunity to run it past the EDPB for approval. Your thoughts welcome!
>
> Best,
> Benedict.
>
>
>
>
> On 14 Nov 2018, at 18:11, Alan Woods <alan at donuts.email <mailto:alan at donuts.email>> wrote:
>
> Dear Team,
> Thank you, Hadia and Alan for your statements. As the Ry reps (supported by the registrars) have already explained we believe the mandatory policy is unsuitable noting our assessment as to the reasons grounding that position. I believe it would be beneficial to the team, if the ALAC could similarly provide us with your grounding reasoning as to why you believe such a mandatory policy is appropriate, given the risks we have already noted to both the Data Subject AND, the CPs, both of whom will be impacted to the greatest extent by such a recommendation.
>
>
> To leadership Team:
> I think at this point, given the relatively small time left remaining in this process, that we need to set clear expectations for the provision of any such SO/AC/SG/C ‘recommendations’. At a minimum we should be insisting that SO/AC/SG/Cs who wish to make any recommendations must also provide their assessment/reasoning for such a conclusion, capable of grounding any such recommendation; more so specifically in cases such as this, where such views are at complete odds with strongly stated concerns and reservations of another SO/AC/SG/C already on record, of which they are reasonably aware of at the time of submission.
>
> Using this recommendation as an example, and my apologies, this is not aimed specifically at ALAC, but it is the example to hand. I’m fully sure that Hadia and Alan have not come to this conclusion lightly.
>
> That being said, if I may illustrate the point however by highlighting why grounding reasons are so vital in this particular recommendation. In my consideration of the proposal I would pose the following questions which immediately spring to mind.
>
>
> WHY
> is minimum mandatory policy considered suitable, given the concerns raised? What factors were considered that seem to outweigh such concerns?
>
>
>
>
> Given
> the representations on record as to the inability to implement a mandatory policy, how is the recommendation made compatible with Art 25 of the GDPR?
>
>
>
>
> Given
> that representations on record as to concerns regarding the security of personal data, should a mandatory policy be implemented?
>
>
>
> At
> the very least, any such recommendation must be accompanied by an assessment under Art 32?
>
>
> ·
> · Art
> · 32 (2) requires an assessment as to security and the preventive methods against breaches be undertaken. The ePDP recommendation must ultimately also include such an assessment, therefore for clarity, any party who makes such a recommendation, should also provide
> · a grounding assessment as to such a recommendation.
> ·
> ·
> · Again
> · this assessment must
> · take into account matters such as risk of breach, with due deference to the helpful headings as provided by Art 32 (1). It must also provide acceptable answers or at least provide reasons for dismissing to concerns raised.
> ·
> ·
> · So
> · given the strongly stated concerns the CPs have raised regarding the likelihood of a higher risk of breach of data, were a mandatory policy to be imposed, it is incumbent on those suggesting to disregard such a concern, to provide their reasoning for such
> · a decision.
> ·
>
>
> I appreciate we all have viewpoints (strong ones) on this, but without providing a reasoned supported argument for a certain recommendation to the group, we cannot possibly fairly assess such a recommendation. I must therefore urge and request leadership to be insistent going forward, that any such recommendations made by any SO/AC/SG/C (Registries included of course) MUST be accompanied by a full statement of the reasons grounding the recommendation, including, as we are talking about data subject rights, an assessment as to the impact the proposed policy recommendation may have on the privacy rights of the individual, or indeed on the ability of the CPs to implement.
>
> Kind regards,
> Alan Woods
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org <mailto:Gnso-epdp-team at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=rolD3tX41Ai1EOS1JrRTv6L5OrwvVrZf3YfALTFtIDM&s=TdWPeOiRPzppZQoG9VYYGMWfhTzc7SfWOq9dN8wJBp4&e=>
>
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org <mailto:Gnso-epdp-team at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=rolD3tX41Ai1EOS1JrRTv6L5OrwvVrZf3YfALTFtIDM&s=TdWPeOiRPzppZQoG9VYYGMWfhTzc7SfWOq9dN8wJBp4&e=>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org <mailto:Gnso-epdp-team at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://mm.icann.org/mailman/listinfo/gnso-epdp-team>_______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org <mailto:Gnso-epdp-team at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://mm.icann.org/mailman/listinfo/gnso-epdp-team>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20181115/611c27af/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20181115/611c27af/signature-0001.asc>
More information about the Gnso-epdp-team
mailing list