[Gnso-epdp-team] Legal vs Natural and Redactions

Alan Woods alan at donuts.email
Thu Nov 15 11:19:23 UTC 2018


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.


[image: Donuts Inc.] <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> 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
>
>
>
> *From:* Gnso-epdp-team <gnso-epdp-team-bounces at icann.org>
> <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
> *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> 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
> 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
>
> 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
> 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/7105909e/attachment-0001.html>


More information about the Gnso-epdp-team mailing list