[Gnso-epdp-legal] definitions

[Becky Burr]

yes Matt,

you are correct - that is what we agreed on our Tuesday call.  On Thursday
morning, however, several members of the legal committee expressed a desire
to retain the notion that under certain limited circumstances third parties
would not have access to information needed to make the information
identifiable, making the data "anonymous" in some sense to those third
parties.  Although this approach is arguably inconsistent with a straight
reading of the GDPR definition of anonymous, I think we've discussed the
fact that the ECJ has issued decisions that could be read to suggest that
context is a meaningful distinction in determining whether or not data is
personal data.  (Here, with respect to context, Bird & Bird has already
opined that no registration data should be considered "anonymous" under the
GDPR because anyone with a legitimate and proportionate interest will have
access to data (redacted registration data) that would link the
pseudonymous email address to an identifiable person.)

Nonetheless, several members of the Legal Team noted that this concept of
"anonymous in context" was discussed extensively in previous phases of the
epdp and that it should be retained as a valuable indication of the group's
thinking.  These participants were uncomfortable with dropping the
anonymity concept altogether given its history in the epdp context. This is
somewhat complicated by the fact that Bird & Bird itself used the labels
provided by the epdp, including the

Of course, whatever is "intended" in any particular situation, the question
of whether or not data is anonymous (and therefore not personal data) is a
question of fact to be determined, ultimately, by European courts.  The
substituted terms and associated definitions are, IMHO, a significant
improvement over the previous "anonymous email" phrase and attempt at
compromise in order to facilitate the plenary discussions.

b



On Fri, Feb 19, 2021 at 12:59 AM Crossman, Matthew <mmcross at amazon.com>
wrote:

> Hi everyone,
>
>
>
> I’m having trouble understanding the “which is intended to be anonymous
> data when processed by non-contracted parties” revision. I thought we
> agreed (based on the legal advice already received from Bird & Bird) that
> because a link is maintained between the email address and the data
> subject, this does not meet the legal definition of anonymous data even
> from the perspective of a third party (“Looking at the "reasonably likely
> means" test, as interpreted in *Breyer*, the data would still seem to be
> personal from the perspective of a third party.  This is particularly the
> case since the third parties will use the masked e-mail address to contact
> the data subject, and/or (in option (a)) to find other domain names
> associated with that data subject (see also *Nowak*'s reference to data
> being considered "related to" a particular data subject by reason of its "*purpose
> or effect*"). This seems like we are introducing a concept that the legal
> advice has already opined is likely not possible, which I’m afraid may lead
> to further confusion in the plenary. I would be fine mirroring the language
> in the first revision (pseudonymous rather than anonymous) as I think that
> more accurately captures the status of that data.
>
>
>
> Let me know if I’m misunderstanding the purpose of that revision.
>
>
>
> Thanks,
> Matt
>
>
>
> *From:* Gnso-epdp-legal <gnso-epdp-legal-bounces at icann.org> *On Behalf Of
> *Becky Burr
> *Sent:* Thursday, February 18, 2021 9:11 AM
> *To:* gnso-epdp-legal at icann.org
> *Subject:* RE: [EXTERNAL] [Gnso-epdp-legal] definitions
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
>
>
> As discussed, the following is being circulated to the Legal Team based on
> our discussion this morning.  Absent objection (accompanied by an
> explanation of the objection), these definitions will be forwarded to the
> plenary at COB PST tomorrow (Friday).
>
>
>
> The Legal Team proposes replacement of the phrase "Pseudonymous email
> contact with the phrase "Registrant-based email contact", defined as:  “`an
> email for all domains registered by a unique registrant [sponsored by a
> given Registrar] OR [across Registrars], which is intended to be
> pseudonymous data when processed by non-contracted parties.
>
>
>
>
>
> The Legal Team proposes replacement of the phrase "Anonymous email
> contact" with the phrase "Registration-based email contact", defined as “A
> separate  single use email for each domain  name registered by a unique
> registrant, which is intended to be anonymous data when processed by
> non-contracted parties.”
>
>
>
> The Legal Team notes that the question of persistence over time (i.e., are
> the emails changed on a periodic basis) is a policy question for the
> plenary.
>
>
>
> B
>
>
>
> On Tue, Feb 16, 2021 at 10:34 AM Becky Burr <becky.burr at board.icann.org>
> wrote:
>
> Team,
>
>
>
> Thanks. for a productive call this morning.  Please review the following
> definitions:
>
>
>
> The Legal Team proposes replacement of the phrase "Pseudonymous email
> contact with the phrase "Registrant-based email contact", defined as:  “A
> pseudonymized email for all domains registered by a unique registrant
> [sponsored by a given Registrar] OR [across Registrars].
>
>
>
>
>
> The Legal Team proposes replacement of the phrase "Anonymous email
> contact" with the phrase "Registration-based email contact", defined as “A
> separate  single use pseudonymized email for each domain  name registered
> by a unique registrant”
>
>
>
> The Legal Team notes that the question of persistence over time (i.e., are
> the emails changed on a periodic basis) is a policy question for the
> plenary.
>
>
>
> Please raise any objections over email in the next 24 hours.
>
>
>
> Best,
>
> Becky
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-legal/attachments/20210219/996204cd/attachment.html>