[Gnso-epdp-team] On the proposed guidance

Stephanie E Perrin stephanie.perrin at mail.utoronto.ca
Fri Apr 16 22:19:03 UTC 2021


Bird and Bird is offering arguments for protection in the event of 
complaint.  While that protection is welcome and reassuring in terms of 
risk, I am not certain that we have adequately explained to 2Birds how 
registration actually takes place.  It would have been beneficial to 
walk them through a range of different ways to register a domain name.  
As we have discussed in the calls, very often non-savvy non-commercial 
users or small business/home workers use resellers of various kinds to 
register their domains. Additional risk creeps in here, WRT whether or 
not a positive consent has been obtained from relevant employees.  
Further risk creeps in when we look at automatic renewals, where the 
contact data may not be updated.  If updated, have the steps been taken 
to get consent from new employees?  To me this is key, non-savvy users, 
and I count myself among them, are not likely to check what an 
intermediary is doing with respect to the domain renewal or updating.

Now, of course the argument is that they SHOULD be more diligent and 
they SHOULD pay attention to the accuracy requirements, but lets deal in 
facts here.....are they?  As the data controller who is pre-emptively 
disclosing personal data, allegedly with consent, to unknown (to the 
contracted party) third parties, the responsibility still rests with the 
controller.  As I have mentioned, a Facebook or a Google or a Microsoft 
can get away with treading roughshod over their consent 
arrangements....not too many folks are going to give up free or 
necessary services over quibbles in a consent form, even if it is 75 
pages long.  However the registrars (and to a lesser extent, the 
registries) are operating in a highly competitive market.  Once losing 
my trust, perhaps over a trifling inattention to the accuracy of my 
data, and I am transferring my domains to another company. Policing a 
complex reseller market is also rather a difficult matter that we have 
not discussed at length in our debates on this issue.  I know that the 
data commissioners as a group do not understand how the accountability 
for the handling of personal information is transferred in that market, 
and it would not be surprising if 2Birds did not either.  Bottom line:  
accredited registrars are shouldering the risk here, it is their risk, 
and they would know best whether they can trust the accuracy of the 
designation of legal personhood.  This is why I think that this 
designation, in my opinion, should always permit an override by the  
contracted parties to treat the data as personal.  I have suggested many 
many times that commercial organizations should operate on an 
accreditation basis and be linked to their official registration numbers 
(business, corporation, municipal licence etc).  Noone ever responds to 
that idea....if it is totally ridiculous I would certainly like to know 
why, I am offering it in good faith and I think it would do something 
useful to stop fraudulent registrations in their names.  However, small 
business and non-commercial organizations, even if incorporated or in 
possession of a registration # of some kind have different needs and 
circumstances, and they are frequently treated differently under data 
protection law.

One final point that I have raised a few times.....we tend to focus on 
enforcement fines and Court costs.  Even if noone ever complains to a 
DPA or takes a case to Court, where the advice of 2 Birds gives us some 
comfort that the risk is manageable, and the results would exonerate the 
contracted parties.....what about reputational damage in the meantime?  
Court costs?  Who actually wants to have customers complaining about the 
practices?  Employee morale, if it is employees who are objecting to the 
practices?

I support focusing on whether the data submitted is personal or not, 
with a fulsome definition and description of same, and full flexibility 
for contracted parties to err on the side of caution and consider the 
possibility of  some data being personal after all.  After all, much 
data is still being disclosed, and noone has adduced strong evidence 
that the delay in requesting the data (as opposed to getting it from the 
published data) will have huge repercussions.  What is actually at play 
here is who is doing the extra work....the requesting party, or the data 
controller.

Stephanie Perrin


On 2021-04-15 10:42 p.m., Mueller, Milton L via Gnso-epdp-team wrote:
> *EXTERNAL EMAIL:*
>
> Further legal support from TwoBirds
>
> 14.2If personal data is erroneously included in published Registration 
> Data, it would in this scenario occur despite substantial (VSC) steps 
> taken by the Contracted Parties, and would be primarily attributable 
> to the actions/omissions of the Registrant.  This is likely to be 
> taken into account by data subjects, data protection supervisory 
> authorities, and courts.
>
> 14.3The data in question is likely to be low sensitivity.  The 
> scenario being envisaged here (mistaken inclusion of personal data in 
> published Registration Data) seems to be most likely to occur when a 
> legal entity (e.g. a company or non-profit organisation) is 
> registering / maintaining its own domains.  In those scenarios, we 
> assume the personal data that could be disclosed would ordinarily 
> relate to an employee’s work details (e.g. a company email address), 
> not an individual’s private life.  Although the GDPR confers 
> protection even in the workplace, the data in question here may 
> arguably be less capable of causing harm to an individual than data 
> relating to the data subject’s private life.[1] <#_ftn1>
>
> 14.4In more sensitive cases (e.g. disclosing that a person works for a 
> company in a sensitive or “embarrassing” sector), a Registrant would 
> be putting itself at serious risk of complaints from its own 
> employees.  Registrants are therefore already incentivised to avoid 
> errors that could have serious consequences for their own staff.
>
> *From:*Mueller, Milton L
> *Sent:* Thursday, April 15, 2021 10:34 PM
> *To:* gnso-epdp-team at icann.org
> *Subject:* RE: [Gnso-epdp-team] On the proposed guidance
>
> Some legal support for my argument below from Bird & Bird:
>
> There may even be an argument, based on EU Court of Justice (“CJEU”) 
> caselaw, that this is a situation where Contracted Parties should 
> generally only be liable should they fail to properly address a 
> complaint about the data – i.e. only once they are put on notice about 
> the alleged illegality and thereby have an opportunity to “verify” the 
> merits of the complaint.[1] <#_ftn2>  This bears some parallels to 
> other EU liability regimes for operators of services online that 
> process – unwittingly – content that violates EU law.[2] <#_ftn3>  As 
> discussed at footnote 6 below, this is arguably recognised in (at 
> least some) decisions of GDPR supervisory authorities.
>
> In other words, if personal data finds its way into a published 
> registration record that should not be there, an objection can be 
> lodged with the registrar and they can verify the merits and remove 
> the data.
>
> Dr. Milton L Mueller
>
> Georgia Institute of Technology
>
> School of Public Policy
>
> Internet Governance Project <https://internetgovernance.org/>
>
> *From:*Mueller, Milton L
> *Sent:* Thursday, April 15, 2021 9:14 PM
> *To:* gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>
> *Subject:* FW: [Gnso-epdp-team] On the proposed guidance
>
> >" Everyone who is named in a role in a registration must have already 
> been informed
>
> > and consented to all of the conditions involved in the role. " This 
> is the ideal. Sadly, this ideal
>
> > is very often not the case.
>
> Whoa.
>
> Of course, Volker, it is possible that a person making a registration 
> for a legal person won’t do it properly. But it is absurd to expect a 
> registrar to be legally responsible for that. How can the registrar be 
> liable for privacy breaches made by the registrant? Indeed, I can’t 
> understand why gaining the consent of the administrative assistant of 
> the xyz department to have their name listed in the whois is a matter 
> for DNS/ICANN policy at all. ICANN policy simply needs to inform 
> registrants that under certain conditions the data will be published.
>
> Let’s take an extreme case – suppose a nasty IT manager in a major 
> corporation puts the name, email address and (what the heck) a revenge 
> porn photo of her ex-husband in her company’s registration record. Are 
> you telling me the registrar would be considered responsible for that 
> breach of privacy? Not the nasty IT manager?
>
> Show me a legal case in which that kind of liability has been 
> assigned. I doubt you can, but I await the data from CP lawyers who 
> have been involved in these cases. I do know of several cases in which 
> agents for a corporation wrongly listed themselves as the technical 
> and administrative contact, making it possible for them to hijack the 
> name. The registrar was NEVER held liable for that.
>
> Reminder: We had to reform Whois/RDS policy because ICANN, *as a 
> matter of contractual obligation, required registrars to publish 
> sensitive PII of any and every Registrant*. Once we have removed that 
> obligation, and once we have given registrants knowledge of the 
> conditions under which the data in the record should be published, I 
> don’t see why registrars need to worry about some corporation listing 
> the personal email address of someone in their IT department.
>
> So if this alleged risk is being cited to scare us away from allowing 
> registrants to self-designate as legal or natural, it is a pretty weak 
> case, imho.
>
> --MM
>
> *From:*Gnso-epdp-team <gnso-epdp-team-bounces at icann.org 
> <mailto:gnso-epdp-team-bounces at icann.org>> *On Behalf Of *Volker 
> Greimann via Gnso-epdp-team
> *Sent:* Thursday, April 15, 2021 10:10 AM
> *To:* Steve Crocker <steve at shinkuro.com <mailto:steve at shinkuro.com>>
> *Cc:* gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>
> *Subject:* Re: [Gnso-epdp-team] On the proposed guidance
>
> Employees are named by other employees without their knowledge, or 
> remain named long after they leave. From the experience as a registrar 
> dealing with registrants every day, this ideal is an assumption that 
> does not survive contact with reality.
>
> -- 
> 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 <http://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: Oliver Fries and Robert Birkner
>
> Part of the CentralNic Group PLC (LON: CNIC) a company registered in 
> England and Wales with company number 8576358.
>
> This email and any files transmitted are confidential and intended 
> only for the person(s) directly addressed. If you are not the intended 
> recipient, any use, copying, transmission, distribution, or other 
> forms of dissemination is strictly prohibited. If you have received 
> this email in error, please notify the sender immediately and 
> permanently delete this email with any files that may be attached.
>
> On Thu, Apr 15, 2021 at 3:36 PM Steve Crocker via Gnso-epdp-team 
> <gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>> wrote:
>
>     Laureen,
>
>     Thanks for your note.  With respect to the details under legal
>     person, we believe the issue of consent should be moot.  Everyone
>     who is named in a role in a registration must have already been
>     informed and consented to all of the conditions involved in the
>     role.  This is a prerequisite for having a working system and is
>     not specific to meeting a privacy regulation.  The fact that this
>     requirement is not specified in the existing contractual
>     documentation is an error and needs to be rectified.
>
>     Steve
>
>     On Thu, Apr 15, 2021 at 6:28 AM Kapin, Laureen via Gnso-epdp-team
>     <gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>> wrote:
>
>         I think we share common ground on many key issues and I would
>         like to build on the many helpful inputs received as to what
>         would be advisable.
>
>         *Goal*: publish non-personal, non-protected data to the
>         greatest extent permissible under the GDPR and within low
>         legal risks to data controllers and processors.  Note, the
>         description below does /not /fully detail the advised
>         safeguards which B&B has documented and which we’ve adopted in
>         our prior input because my impression is that we generally
>         agree that the safeguards are prudent.  This description
>         merely seeks to identify the key steps that must be taken to
>         ensure that personal data is identified and protected and
>         non-personal data is published.  I also highlight the addition
>         of a potential additional safeguard – Confirmation.  I think
>         this process incorporates what we’ve discussed and inputs
>         received and could form a useful framework for discussion.
>
>         *Note:*
>
>         **
>
>         n*New Registrations: *This process applies to new
>         registrations (Steve C. has some useful thoughts on how to
>         deal with existing Registrations)
>
>         n*Publish: *When I use the word “publish,” I mean made public
>         directly; not via the SSAD.
>
>         n*Flexibility: *Based on input from our Registrar colleagues,
>         we should permit flexibility for how these steps are
>         implemented to account for the varied business models in place.
>
>         n*Timing: *All identifications need to take place at the time
>         of registration or shortly thereafter (w/in the 13-day
>         accuracy verification window) and no registration data should
>         be published until the identification, consent, and
>         confirmation process concludes
>
>         *Process:*
>
>         1.A threshold identification of the registrant as a natural or
>         legal person;
>
>         a.If natural, registration info redacted
>
>         b.If legal, further inquiries and advisories (safeguards):
>
>         i.if the legal person identifies that it has a protected
>         status under the GDPR
>
>         1.registration info redacted
>
>         ii.If the legal person registration contains personal data,
>         advise of consequences (publication)
>
>         1.Obtain necessary consents
>
>         2./Possible additional safeguard/: /Ask Registrant to Confirm
>         any identification that will result in publication of contact
>         data /(akin to confirming a flight reservation or stock trade)
>
>         a.Publish
>
>         3.If no consent
>
>         a.Redact
>
>         2.Provide quick and easy opportunity to correct any mistakes
>
>         I hope this is useful.
>
>         Kind regards,
>
>         Laureen Kapin
>
>         Counsel for International Consumer Protection
>
>         Federal Trade Commission
>
>         (202) 326-3237
>
>         *From:*Gnso-epdp-team <gnso-epdp-team-bounces at icann.org
>         <mailto:gnso-epdp-team-bounces at icann.org>> *On Behalf Of
>         *Volker Greimann via Gnso-epdp-team
>         *Sent:* Thursday, April 15, 2021 8:35 AM
>         *To:* Hadia Abdelsalam Mokhtar EL miniawi <Hadia at tra.gov.eg
>         <mailto:Hadia at tra.gov.eg>>
>         *Cc:* gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>
>         *Subject:* Re: [Gnso-epdp-team] On the proposed guidance
>
>         I think we need to be cognisant of the current status quo and
>         use that as the basis for our thoughts on the matter:
>
>         1) There is no differentiation between legal or natural contacts.
>
>         2) The redaction of all contacts is permitted and has become
>         the de-facto standard.
>
>         3) We allow consent-based disclosure.
>
>         4) NIS 2 may at some point in the future require publication
>         of non-personal information.
>
>         This leads to two very simple follow-on questions:
>
>         a) How do we identify such non-personal information? What is
>         really necessary for this end?
>
>         b) What would publication entail?
>
>         For a) we and Twobirds identified voluntary self-declaration
>         of the data submitted. As all data is redacted by default, the
>         differentiation of the data subject category is irrelevant as
>         it ultimately only boils down to the declaration of the data
>         subject thatthe data contains no personal information.
>
>         For b), the term "publish" is undefined. For all we know, it
>         could mean publication in a physical print edition (it doesn't
>         mean that though). But publication within SSAD can very well
>         be sufficient for that definition. There is no reason
>         whatsoever to assume differently.
>
>         -- 
>         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 <http://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: Oliver Fries and Robert Birkner
>
>         Part of the CentralNic Group PLC (LON: CNIC) a company
>         registered in England and Wales with company number 8576358.
>
>         This email and any files transmitted are confidential and
>         intended only for the person(s) directly addressed. If you are
>         not the intended recipient, any use, copying, transmission,
>         distribution, or other forms of dissemination is strictly
>         prohibited. If you have received this email in error, please
>         notify the sender immediately and permanently delete this
>         email with any files that may be attached.
>
>         <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>
>         	
>
>         Virus-free. www.avast.com
>         <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>
>
>         On Thu, Apr 15, 2021 at 1:52 PM Hadia Abdelsalam Mokhtar EL
>         miniawi via Gnso-epdp-team <gnso-epdp-team at icann.org
>         <mailto:gnso-epdp-team at icann.org>> wrote:
>
>             Dear Milton,
>
>             Thank you for your constructive thoughts. I believe we
>             have a lot to build on. In relation to principle one, I
>             think we all agree that some legal data subjects would
>             want to publish their data in the RDDS, but without your
>             first principle they can only do this through consent. The
>             legal memo received lately from Bird & Bird explains that
>             if CPs publish the data of legal persons based on consent
>             they are at a higher risk than if they publish the data of
>             legal persons based on self-designation. In the latter
>             case CPs might only be liable if they fail to address a
>             complaint. So the question always was: what is the benefit
>             of labeling the data as belonging to a natural or legal
>             person? Of course we all know that GDPR protects the data
>             of natural persons and not legal persons, but the
>             important answer now is that the distinction significantly
>             reduces the liability of CPs. In addition, the distinction
>             is helpful in performing the balancing test in case the
>             data is not published and I am sure if we look into
>             individual use cases we can find much more benefits.
>             Moreover, it could prove to be useful regarding possible
>             upcoming regulations. I would also add that the level of
>             protection assigned to the data elements suggested by
>             Steve provides additional safe guards and flexibility in
>             the implementation.
>
>             Finally, I join you in being optimistic about our ability
>             to finish this.
>
>             Kind regards
>
>             Hadia
>
>             *From:*Gnso-epdp-team
>             [mailto:gnso-epdp-team-bounces at icann.org
>             <mailto:gnso-epdp-team-bounces at icann.org>] *On Behalf Of
>             *Mueller, Milton L via Gnso-epdp-team
>             *Sent:* Wednesday, April 14, 2021 10:12 PM
>             *To:* gnso-epdp-team at icann.org
>             <mailto:gnso-epdp-team at icann.org>
>             *Subject:* Re: [Gnso-epdp-team] On the proposed guidance
>
>             Colleagues:
>
>             I have only gotten time to review the latest Guidance
>             document and the surrounding debate today. Apologies, but
>             there is a lot going on in my day job.
>
>             I am disappointed to see that we seem to be going
>             backwards. I see divergence rather than convergence on the
>             way we are approaching the problem.
>
>             I see no point in adding more noise to the current
>             document via the Comments function. What I would like to
>             try to do is articulate some broad principles about how to
>             deal with the legal/natural distinction. If we can agree
>             on those principles, it will be relatively easy to
>             complete the document. If we cannot/do not agree on those
>             principles, additional wordsmithing and debates over terms
>             will not get us anywhere.
>
>             So here are the broad principles that I would offer up for
>             debate:
>
>             1.The legal/natural distinction is relevant and we need to
>             find a way make it in RDDS without compromising privacy
>             rights.
>
>             2.Registrants should be able to self-designate as legal or
>             natural, with no burden of authentication placed on
>             registrars or registries
>
>             3.To protect small home offices or NGOs who are
>             technically Legal persons but whose registration data may
>             include Personal data, we need an additional check in the
>             process.
>
>             4.As long as they conform with the above 3 principles,
>             registrars/ries (CPs) should be given maximum flexibility
>             to choose the way to differentiate.
>
>             Principle 1 discussion:
>
>             If we cannot agree on this (or agree to abandon this
>             principle), _/nothing else will fall into place/_. Ever.
>             So let’s settle that. Steve and Volker I suspect will
>             disagree with this principle. Steve has argued that the
>             L/N distinction is “not a central concern” and all that
>             matters is whether the registrant’s data is to be made
>             available to anyone. If he is right, we can discard the
>             guidance altogether, because we already have a
>             recommendation to allow the RNH to consent to the
>             publication of their data. Volker has also suggested that
>             it is personal data we need to differentiate, not L/N . I
>             disagree with Steve and Volker on this and so do most of
>             the rest of the group. L/N distinction is a central
>             concern to certain stakeholder groups in the EPDP, because
>             a) GDPR and other data protection laws do not protect it
>             and this process is all about bringing RDS into compliance
>             with privacy law; b) Legal person data could be published
>             and it would provide easier access to their registration
>             data. As a NCSG member I can find no basis for objecting
>             to the publication of WalMart’s, Kroger’s or the local
>             hardware store’s registration data. Any concerns about PII
>             are addressed by principles 2 and 3. Steve is approaching
>             this as an engineer, but this is a policy process, and we
>             will not obtain agreement on a solution unless certain
>             stakeholders are satisfied. If they think it is a central
>             concern, it’s a central concern, that’s how
>             policy/politics work.
>
>             Principle 2 discussion
>
>             This is the key principle that keeps NCSG and CPH
>             satisfied. Registrants are in control of how they are
>             designated. Yes, this means that some people will lie.
>             That is just something we will have to accept. One cannot
>             erase that possibility without creating a system that is
>             too burdensome and costly as to outweigh any benefits.
>
>             Principle 3 discussion
>
>             This is something everyone seems to agree on already. But
>             it is good to make it explicit, then we can work out how
>             specific our guidance can get, so as to conform to …
>
>             Principle 4
>
>             Avoid being overly prescriptive, but ensure that the other
>             3 principles are honored. So yes, Volker, we give you
>             maximum flexibility to implement in accordance with
>             different business models, but you can NOT make a
>             designation for a RNH, because it violates principle 2.
>
>             I truly believe that if we can come to agreement on these
>             4 principles and use them as the basis for drafting
>             guidance, we can actually finish this.
>
>             _______________________________________________
>             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>
>             _______________________________________________
>             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
>             <https://www.icann.org/privacy/policy>) and the website
>             Terms of Service (https://www.icann.org/privacy/tos
>             <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.
>
>         <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>
>         	
>
>         Virus-free. www.avast.com
>         <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>
>
>         _______________________________________________
>         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>
>         _______________________________________________
>         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
>         <https://www.icann.org/privacy/policy>) and the website Terms
>         of Service (https://www.icann.org/privacy/tos
>         <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.
>
>     _______________________________________________
>     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>
>     _______________________________________________
>     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
>     <https://www.icann.org/privacy/policy>) and the website Terms of
>     Service (https://www.icann.org/privacy/tos
>     <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.
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> [1] <#_ftnref1> As explained above, we have understood this question 
> to be asking about scenarios where Registrants are legal persons, as 
> per the EDPB quote at paragraph 1.  In respect of individual (natural 
> person) Registrants, the issues will be largely similar: if a natural 
> person incorrectly states that their data is not personal data, then 
> (i) the verification measures should prevent the data from being 
> published, since they will give the data subject an opportunity to 
> correct their mistake; (ii) the mitigating factors and legal arguments 
> described at paragraphs 11.7 and 11.8 and paragraphs 14.1 - 14.6 here, 
> should confer reasonable legal protection for Contracted Parties.
>
> [1] <#_ftnref2>In its judgement in Case C‑136/17 /GC and Others/, the 
> CJEU explained that GDPR obligations relating to an erasure (“Right to 
> Be Forgotten”) request apply “/to the operator of a search engine in 
> the context of his responsibilities, powers and capabilities as the 
> controller of the processing carried out in connection with the 
> activity of the search engine, on the occasion of a verification 
> performed by that operator, under the supervision of the competent 
> national authorities, following a request by the data subject”/.  As 
> the Advocate General explained in that case, “/such an operator can 
> act only within the framework of its responsibilities, powers and 
> capabilities. In other words, such an operator may be incapable of 
> ensuring the full effect of the provisions of [EU data protection 
> law], precisely because of its limited responsibilities, powers and 
> capabilities. . . An ex ante control of internet pages which are 
> referenced as the result of a search does not fall within the 
> responsibilities or the capabilities of a search engine/.”  It could 
> not know, from the moment it indexed a webpage, that the content of 
> that page was (for example) out of date (as in the original /Google 
> Spain / Costeja/ ruling), or (in the /GC and Others/ case/) / “special 
> category” or “criminal offence” data for which it required consent.
>
> [2] <#_ftnref3>See, for example, Article 14 
> <https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=celex%3A32000L0031> 
> of the e-Commerce Directive 2000/31/EC and its transposition into the 
> national laws of EU/EEA Member States and the UK.
>
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20210416/93cd9c09/attachment-0001.html>


More information about the Gnso-epdp-team mailing list