Logo

Julie Bisland's Personal Meeting Room - Shared screen with speaker view
Caitlin Tubergen
21:35
We are getting the question up - one moment.
Becky Burr (Chair and ICANN Board Liaison)
27:12
Could you scroll down to scenario 1 language please
Tatiana Tropina (NCSG)
32:40
Thomas, thanks a lot for bringing the issue of what could be considered as abusive behaviour by various jurisdictions
Margie Milam (BC)
35:20
+1 Brian
Thomas Rickert (ISPCP)
35:46
Happy to add a footnote. And thanks for adding this, Brian!
Stephanie Perrin (NCSG - alternate)
36:12
Reverse lookup is a threshold. Not as high as it use to be perhaps, but still there. I do not agree with Bryan that one misdeed (which has not been proven) would permit an automated reverse lookup. Different if we are talking about malware abuse, I would suggest, but trademark violation is different.
Becky Burr (Chair and ICANN Board Liaison)
37:35
what about other indicia of problems, as opposed to just number of domains? e.g., one domain name with claims about consumer fraud and obviously falsified contact information (e.g., address is an empty lot)
Stephanie Perrin (NCSG - alternate)
38:24
Indeed that would do it for me….
Thomas Rickert (ISPCP)
38:31
Question for the group: If 1 domain name did suffice for kicking-off a reverse lookup. Would every alleged abuse / disclosure scenario justify a reverse lookup? If not, what additional safeguards would you suggest?
Stephanie Perrin (NCSG - alternate)
38:46
Just need to guard against potential market curiosity
Stephanie Perrin (NCSG - alternate)
39:01
(I am thinking about potential prospective registrations)
Thomas Rickert (ISPCP)
39:04
Agreed, Stephanie. That was my point.
Thomas Rickert (ISPCP)
41:13
Right, Becky: We are asking whether the scenario is compliant (including the proposed approach and safeguards)
Brian King (IPC)
41:37
Right, Thomas and Becky.
Brian King (IPC)
41:57
I'd be ok with Margie/Stephanie's suggested approach for asking the question.
Thomas Rickert (ISPCP)
42:08
yep
Stephanie Perrin (NCSG - alternate)
42:26
even if the registrant is not the perpetrator of the malware attack, it is warranted to check and see if other domains owned by that registrant had also been infiltrated. I for instance am clueless in guarding my domains, if the registrar fails me I could be running all kinds of crap.
Tatiana Tropina (NCSG)
43:22
illegal abusive conduct of course will depend on the national legislation
Thomas Rickert (ISPCP)
43:41
Hadia, there might be a misunderstanding. WE are talking about alleged illegal activity or conduct that is used as a justification for starting the reverse lookup.
Thomas Rickert (ISPCP)
43:54
That might differ vastly from jurisdiction to jurisdiction.
Tatiana Tropina (NCSG)
43:58
what we mean won’t matter for the law enforcement who sends the request
Tatiana Tropina (NCSG)
44:07
Thomas plus million
Stephanie Perrin (NCSG - alternate)
44:21
+ another million
Thomas Rickert (ISPCP)
44:36
Hooray, I’m a millionaire
Tatiana Tropina (NCSG)
44:54
lol
Hadia Elminiawi (ALAC)
44:57
@Tatiana the balancing test is for sure required.
Thomas Rickert (ISPCP)
45:43
Right
Thomas Rickert (ISPCP)
45:50
Becky
Margie Milam (BC)
45:50
right
Volker Greimann (RrSG)
46:15
Can we really delay much longer on this?
Volker Greimann (RrSG)
46:32
We are still shooting for a report in the next two months, right?
Becky Burr (Chair and ICANN Board Liaison)
46:49
right@Volker, why we should close down on list quickly
Hadia Elminiawi (ALAC)
48:21
@Thomas but you need first to provide an example of an illegal action associated with a domain name to the disclosing entity which in light of this and its own definition of illegal actions would determine whether to take this forward or not
Brian King (IPC)
49:44
Ok Becky we can do that
Thomas Rickert (ISPCP)
50:06
@Hadia - ok- But that means that EVERY misconduct established for one domain name entitles you to start a reverse lookup. I for one think that goes to far. +
Berry Cobb
50:27
It might be easier to follow along in the goog sheet here: https://docs.google.com/spreadsheets/d/1umn9jbxGCQLLVwtw-nW8L73M4oHoxBfHm_ynW2c5hyc/edit#gid=0
Volker Greimann (RrSG)
51:51
It was basically an update of guidelines published a year ago
Margie Milam (BC)
52:36
yes
Stephanie Perrin (NCSG - alternate)
52:55
I don’t quite understand the focus on this right to be forgotten decision. I realize Goran thinks it is important, but I have yet to see how it departs from previous guidance
Hadia Elminiawi (ALAC)
53:16
@Thomas I understand your point, however again we are talking about spammers, computers trying to get into firewalls, etc.. for sure we should make sure that no mistakes are done
Tatiana Tropina (NCSG)
54:37
@Hadia the problem is that whatever we are talking here would mean nothing to those who send requests for something that is illegal in their country but freedom of speech in another
Thomas Rickert (ISPCP)
54:37
@Hadia - are we talking about spammers? „Computers trying to get into firewalls“? I have not heard any such qualifications to narrow down the eligibility for requests.
Tatiana Tropina (NCSG)
54:52
there is no such qualification:)
Tatiana Tropina (NCSG)
55:17
illegal is illegal and it varies in jurisdictions no matter what we think of it here
Tatiana Tropina (NCSG)
55:41
and we don’t want to empower such requests by absence of safeguards
Brian King (IPC)
58:55
Thanks, Matt. That would make me feel a lot better about 1. And appreciate what you did in 2.
Laureen Kapin (GAC)
59:12
+1 @ Bryan. The nature of the legal advice is necessarily qualified and based on certain assumptions. While I generally support making things more concise, we do need to be very careful about how summarize the advice to avoid misunderstandings.
Volker Greimann (RrSG)
01:02:35
Really?
Becky Burr (Chair and ICANN Board Liaison)
01:02:55
@Volker, really what?
Volker Greimann (RrSG)
01:03:15
Do we have to question everything our chosen counsel has told us if we do not like the result?
Stephanie Perrin (NCSG - alternate)
01:03:20
This stems from a failure on the part of ICANN/us to explain the complexity of data sharing to both the DPAs and the registrants. For instance, internal security arrangements with third parties have not been mapped, as the would in a DPIA and attendant risk assessment.
Volker Greimann (RrSG)
01:03:37
We chose the counsel, now we take their advice and move on
Laureen Kapin (GAC)
01:04:03
Apologies -- I need to drop off due to another commitment.
Volker Greimann (RrSG)
01:04:20
Or we can circle around their advice and pick at the bits we like and don’t like forever
Tatiana Tropina (NCSG)
01:04:24
all, am dropping off, Stephanie takes over from now :) thanks all
Stephanie Perrin (NCSG - alternate)
01:04:38
Also the reseller market and the close relationships with ISPs (and where the dotted line for controllership falls) has not been well explained.
Becky Burr (Chair and ICANN Board Liaison)
01:04:41
Thanks Laureen and Tatiana
Brian King (IPC)
01:05:31
but not in the summary. Ok
Brian King (IPC)
01:05:35
I'll hold my peace
Volker Greimann (RrSG)
01:06:11
Brian, please look at the letters European DPAs have sent to ICANN over the years. Every single one assumes some form of controllership (and therefore liability) with the CPs
Brian King (IPC)
01:07:46
@Volker, right. But we have the opportunity to build something new and different here, where that does not have to be the case.
Hadia Elminiawi (ALAC)
01:09:51
@Volker if the model proposed by ICANN to the EDPB assumptions are found to be true CPs will be responsible as controllers only with regard to the transfer of the data to the gateway ( with regard to the disclosure other responsibilities associated with other activities would still exist)
Volker Greimann (RrSG)
01:11:39
@Brian: In what time? You read Janis’ mail about the planned report deadline, right?
Matthew Crossman (RySG)
01:16:17
Sounds good
Volker Greimann (RrSG)
01:17:34
I can do a balancing test in under a minutes in some cases
Brian King (IPC)
01:20:11
@Volker, ASAP! :-)
Volker Greimann (RrSG)
01:22:21
+1 Marc
Volker Greimann (RrSG)
01:22:33
This is not relevant, delete it
Volker Greimann (RrSG)
01:28:44
Sorry, I cannot follow this argument
Volker Greimann (RrSG)
01:28:53
What are you trying to say?
Volker Greimann (RrSG)
01:29:34
The accuracy requirements of the GDPR are rights of the data subjects, not of third parties
Volker Greimann (RrSG)
01:30:11
The only accuracy requirements were need to consider are the rights of the data subject to review and update the data
Volker Greimann (RrSG)
01:30:20
And that is taken care of by policy
Thomas Rickert (ISPCP)
01:31:42
Accuracy means that the processor or controller must accurately input and maintain data in their systems AS PROVIDED by the data subject.
Stephanie Perrin (NCSG - alternate)
01:32:00
+ a million Voler
Volker Greimann (RrSG)
01:32:03
Do we have to dance this dance every single time
Stephanie Perrin (NCSG - alternate)
01:32:07
Volker
Hadia Elminiawi (ALAC)
01:33:42
the data must be accurate having regard to the purposes for which they are processed
Volker Greimann (RrSG)
01:36:05
Well, there is an obligation to not change the data without consent of the data subject
Hadia Elminiawi (ALAC)
01:37:03
Principle 5(1)d says personal data shall be accurate and where necessary kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate having regard to the purposes for which they are processed are erased or rectified without delay
Volker Greimann (RrSG)
01:37:59
Yes Hadia, but that is intended to protect the data subject, not third partioes
Volker Greimann (RrSG)
01:38:20
Inaccurate means not what the data subject provided
Volker Greimann (RrSG)
01:39:00
Amen, Thomas
Stephanie Perrin (NCSG - alternate)
01:39:16
Amen Thomas
Hadia Elminiawi (ALAC)
01:39:57
GDPR does not define accuracy but data protection act 2018 says inaccurate means misleading or incorrect
Brian King (IPC)
01:41:28
That is indeed the question, Becky.
Matthew Crossman (RySG)
01:42:01
Wasn't that was the question posed in the original memo?
Hadia Elminiawi (ALAC)
01:42:05
@Volker accurate data benefits data subject - so why do we not care about it
Stephanie Perrin (NCSG - alternate)
01:42:21
In a regulatory environment you could impose obligations on the data controller to verify accuracy/identity. There are in my opinion no reasons to take this step under GDPR.
Volker Greimann (RrSG)
01:43:00
We care about it. So we ask them every year if the data is still correct and allow them the opportunity to correct THEIR data
Becky Burr (Chair and ICANN Board Liaison)
01:43:12
@Matthew - is that the question that was asked?
Stephanie Perrin (NCSG - alternate)
01:44:05
You would for instance as an insurance agent have a duty to inform you data subject that failure to answer the health questionnaire truthfully could result in a failure to receive benefits. They might do their own verification with doctors and other health care providers. I cannot see how you could apply this kind of thinking in the RDDS situation
Volker Greimann (RrSG)
01:45:06
And if we do not like the answer then, we can ask another followup and another, and another
Brian King (IPC)
01:45:32
I'm happy to do that
Volker Greimann (RrSG)
01:52:19
Precedent is much less important over here
Volker Greimann (RrSG)
01:56:57
Do we really need to spend money on that? I could tell you
Margie Milam (BC)
02:01:27
I need to drop off -
Brian King (IPC)
02:05:10
Thank you, Thomas! I'm happy to help
Matthew Crossman (RySG)
02:05:12
Thanks everyone
Brian King (IPC)
02:05:15
Thanks, all.
Hadia Elminiawi (ALAC)
02:05:17
bye