Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en

Members and alternates replacing members, when using chat, please select all panelists and attendees in order for everyone to see chat.

Hello Philippe

Hi Hadia, Hi everyone.

One update since intro: Owen Smigelski will replace James Bladel today

Yes +1 Margie

I'm here to build a consensus policy

(Council questions): i. Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“);ii. What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons.

Members and alternates replacing members, when using chat, please select all panelists and attendees in order for everyone to see chat

Thanks Berry - that instruction allows us to revisit the EPDP Phase 1 policy on legal/natural purpose

My hand was up to make the point that Berry shared above. Our instruction is to determine whether updates are needed, given that "optional" is the status quo.

Happy to be constructive. To be clear, we're looking to build consensus policy.

@Volker just to note we are not trying to get what we want - we are trying to work on solving your concerns, so that we end up with a consensus policy we are all happy with and that serves the entire Internet community.

@Volker, of course, but that is why we need to further investigate.

+1 Brian

+1 Brian

Can the link to this doc please be shared here in chat? (I'm on a tiny screen so I can't read it). Thanks

https://docs.google.com/document/d/1QlM4O_vwx7cQ11DJ_Lx2kqhyyRgDkMXG/edit#heading=h.gjdgxs

Thanks Manju

anytime :)

Thank you :-)

Note, staff is taking notes in the background and will send along with meeting minutes vs. real time edits/updates to the goog doc.

Thanks Berry

Thanks, Berry and staff.

I would urge us to consider the concept of Privacy by default. The need for correction and considering the need to ‘put the genie back in the bottle’ is where the Privacy by default or indeed by design begins to get troublesome in practical terms.

Yes it is

the proposal 3.1 specifically says verifying corporate ID#

exactly. silence means that it is not required

by GDPR

SIlence means it is not required to redact.

Good point Volker

Alan, no one said it is required to redact legal person data. But it is not required to publish either. As Volker is saying, some registrations for legal persons might contain data that should by GDPR be redacted.

@ Keith -- I would like to respond to some of the concerns raised at the right time in our discussion.

Sure thing, Laureen.

Do take note of Rec#12 from Phase 1:

The EPDP Team recommends that:• The Organization field will be published if that publication is acknowledged or confirmed by the registrant via a process that can be determined by each registrar. If the registered name holder does not confirm the publication, the Organization field can be redacted or the field contents deleted at the option of the registrar.• The implementation will have a phase-in period to allow registrars the time to deal with existing registrations and develop procedures.• In the meantime, registrars will be permitted to redact the Organization Field.• A registry Operator, where they believe it feasible to do so, may publish or redact the Org Field in the RDDS output.

For new registrations, beginning with the “date certain”:1) New registrations will present some disclosure, disclaimer or confirmation when data is entered in the Organization field. Registrars are free to develop their own process (e.g., opt-in, pop-up advisory or question, locked/grayed out field).2) If the registered name holder confirms the data and agrees to publication:a) The data in the Organization field will be published,b) The Organization will be listed as the Registered Name Holder.c) The name of the registered name holder (a natural person) will be listed as the point of contact at the Registrant Organization.

@Keith Legal entities have no protection under the GDPR and are considered out of scope.

Thank you, Chris

If at all possible, it would be great to hear from the ICANN Org reps how they see ICANN Org’s liability risk with this as the org will enfore such policy. The risk for a registry is for 1 zone, for ICANN, the risk is likely for thousands of contracted parties.

only a few seconds? :-(

Yes but if we are building into our process a safety valve that ‘where we get it wrong we can change it’ It means that privacy was not by default - the breach has occurred by default. The position which we need to be at that if we get it wrong the privacy of data subject has not been affected and no impact is possible.

Also, past experiences show that differentiations between old and new registrations tends to get attacked as time passes, right Alan?

GDPR requires privacy by design and by default. My concern is that requiring publication will lead to publication and other processing of natural person's data

Suddenly demands pop up starting to demand to treat everything equally

(Alan W said it better, thanks!)

GRINDR was just fined for a third of their turnover by the norvegion DP board

I'd like for us to focus on the merits of the proposals, please.

We need a process that is scalable, and that allows adherence to data privacy laws including but not limited to the GDPR. If we set a process for new registrants and don't consider how that will expand to existing registrants, that doesn't seem very sustainable to me

I"m not aware of any technical tools we could use to review email addresses or other data fields for personal data. Do you have examples?

+1 Laureen: the risks to distinguish between legal/natural are probably smaller than the risk on getting consent right, where you can have discussions as to whether consent was free or not. That is not the case in legal vs. natural, where we are speaking about non-personal data vs. personal data

There can be personal information in fields other than email- so checking for personal information is a lot more complicated than review of an email address

You are right, Brian.

We are building a system that is not, per se, necessary. In order to do that, we must consider cost issues. If, as Volker has pointed out, legal risk management requires a great deal of research and effort on the part of contracted parties, the system becomes instantly unaffordable. Since taxing the RNH is the only way ICANN gets money, putting the price of domain names up in order to build this system is not acceptable.

@Volker. Reports I have seen say 10% of turnover for releasing all sorts of personal info (far more than just contact) - All without any consent.

No, it requires the disclosure

We do that.

On request

Yes, I checked. It was a third of profit, q0% of turnover. Nice margin, actually

EU Directive requires legal info to be published (n/just disclosed): Member States shall ensure that the TLD registries and the entities providing domain nameregistration services for the TLD publish, without undue delay after the registration of adomain name, domain registration data which are not personal data.

Actually, it currently requires nothing at all. Since it does not exist yey

+1 Margie with new legislations in place new processes are unavoidable

NIS2 is not in place and it does not override GDPR, so you can lay aside that false hope

EU requires companies to publish all sorts of information on different platforms, such as ultimate beneficial owners

Already today

The Grindr scenario involved conduct that is not comparable to the discussion at hand : The agency said the app had transmitted users’ precise locations, user-tracking codes and the app’s name to at least five advertising companies, essentially tagging individuals as L.G.B.T.Q. without obtaining their explicit consent, in violation of European data protection law. Grindr shared users’ private details with, among other companies, MoPub, Twitter’s mobile advertising platform, which may in turn share data with more than 100 partners, according to the agency’s ruling.

Not saying that the circumstances are different, just that fines can be significant, which was disputed

This community ignored pending and existing data protection law for far too long. Let's not repeat that mistake vis-à-vis the NIS2 Directive.

To be fair, the Grindr case involves extremely sensitive data. Puts it up a notch. Nevertheless, we do not at present have a good sense of whether any sensitive data might be released in contact data.

@Stephanie, And they did not bother asking for consent!

@Alan cost is something we need to discuss further - maybe we could brainstorm his together

*this

I meant cost is something this group should discuss further

Indeed. And who is on that customer list? Not to pound on my favourite theme, the human rights implications in some countries of releasing sensitive data, but designation as LGBTQ can still get you killed, on my continent extrajudicially, in others through force of existing law.

Re: NIS2 - We spent a lot of time in earlier phases to "future proofing". That is, be prepared for where legislation is heading.

It is not a legal nothing. That is ignoring the role of the EU Commission under EU law.

@Volker now is the time to be "future ready"

Oh, and finally, the proposal of the NIS2 does not talk about contacts, but data… as I have been all along

@Hadia- it is unreasonable to require contracted parties to implement proposed laws/regulations. It will be too costly, and what happens when they’re not implemented?

Or implemented differently

@Milton, the EPDP was to allow RDS data publication to comply with GDPR. GDPR does not apply to legal person information so the distinction is relevant.

natural persons who consent to the publication of their data can withdraw their consent anytime. Legal persons data is not protected and thus their is no need to go into an unnecessary process of consent/withdraw of consent

You’re kind of missing my point, Hadi and Alan. Why is it ICANN and the registrar’s job to determine who is legal and who is natural? If there is indeed a legal obligation to publish legal person data in RDS (which is debatable) then that obligation applies to the registrant, not the registrar

however the risk which contracted parties bear with consent is almost similar to the risk they bear with differentiation

We have already established that a legal person’s registration data could include personal data, @Chris.

That was established as fact long ago.

OK, but when we do our data protection impact assessment and it finds that this requirement introduces a risk and there is no way to mitigate it while still fulfilling that requirement, what do we do?

we should not proceed with the risky unmitigated activity

I don’t disagree with either Laureen or Chris - but if we are publishing knowing there remains a risk of breach, that is not privacy by default in our design. That is my point - we need to be mindful that if we need to ‘roll back breaches’ that is not compatible with privacy by design.

Ugh .. sorry privacy by default!!!

I would like to respond please

But the measures will show that we had this conversation, identified the risks, and published data anyways

That is why companies have been fined that have already fixed the issue the fine is for

Right?

+1 Jan ignoring today's obvious direction serves no one well.

Regarding the speed of implementation - one example is the EU Copyright Directive — adopted on April 17 2019 and France implemented the directive on July 24 2019

@Alan the mere fact that you are collecting personal data puts you at risk

Not talking about collection had … we are talking about publication.

@Hadia - right, so we should minimize what data we collect, as well as not requiring unnecessary processing activities such as publication

*Hadia (apologies I typo-ed)

It is a bridge to cross at a later time

@sarah the personal data we are collecting has already been agreed upon in phase one.

The point is there is no zero risk because you are already processing PI.

Is ICANN or Microsoft willing to indemnify us agains this possibility, Marc?

with correct safeguards in place the risk could be near zero

+1 Mark

@hadia no we are talking about the risk of publication. The collection and all that discussion has been fixed and agreed by Phase I

Our risk of processing data remains ….. our risk of publication remains potentially zero

+1000 Christian

@Sarah no mistakes can still happen

@Hadia I'm not sure what specifically that's in response to, but yes, mistakes can happen, which is why we should default to data protection (not publication) and allow publication on an opt-in basis only

and that's why what really matters is the safeguards and implementation guidelines

And we're saying there are not appropriate safeguards if the publication is mandatory by default

To Milton’s point, my hairdresser friend would understand the risks associated with her being asked whether she wanted her data published more than the implications behind simply figuring out that she is a “Legal Person” and understanding the implications of what disclosures that then requires of her

We need to consider a broad range of service models. My registrar operates primarily through resellers, so although we can require resellers to have certain info on their websites and in the Terms of Service that we require to be accepted by the RNH, it's very disruptive to require disclosure and information in the signup process. I don't want to put a barrier to sales.

Allowing users to buy domains and then afterwards asynchronously opt in to publication of data makes much more sense

@sarah and why is the risk associated with consent very different than that with differentiation - again technical tools could be used to ensure data of legal person does not include PI of natural persons

@Hadia I'm sure the risks could be comparable if the processes are comparable (asynchronous, explanatory content, etc). But I would love to see examples of these technical tools you mention. I've never heard of any tools that can do this reliably

How would a script (or an AI?) know that Christian's hairdresser friend has personal data in her business info? It wouldn't, and so it brings a big risk

If the hairdresser herself can opt in to publication, that's much better

So @ Volker - you should translate the terms in the language of your customers

No way to do that. Not even Facebook does all languages …

Again, please let's ensure that if people are suggesting that we use tools or services to accomplish this goal that they provide specifics for review.

the technical tools are mentioned in both the legal memo and the study conducted by ICANN

I reviewed the legal memo and didn't find any technical tools that seemed sufficient/appropriate

Thanks, Keith, for mentioning that point again.

How efficient they are needs to be further explored

which at this point no one is willing to do

Thank you all!

Margie, maybe you could tell us something about facebooks fines?

bye for today - thanks all