[IRT.RegDataPolicy] Re. 18 9.5.4.2

Wed Oct 23 08:38:26 UTC 2019

Morning Sarah,

I agree with you, we could do without it.

Luc

From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces at icann.org> on behalf of Sarah Wyld <swyld at tucows.com>
Organisation: Tucows
Date: Monday, 21 October 2019 at 17:19
To: "King, Brian" <Brian.King at markmonitor.com>, Theo Geurts <gtheo at xs4all.nl>, "irt.regdatapolicy at icann.org" <irt.regdatapolicy at icann.org>
Subject: Re: [IRT.RegDataPolicy] Re. 18 9.5.4.2

Good morning all,

I'm happy with a more general "if the request is denied, there needs to be an explanation" type of requirement -- which is exactly what we have in 9.5.4 itself. It seems to me like 9.5.4.2 was written specifically to accommodate an example provided in the Rec 18 text, but it is unnecessarily specific and can be removed entirely without losing anything valuable from our Policy text.

Thanks,

--

Sarah Wyld

Domains Product Team

Tucows

+1.416 535 0123 Ext. 1392

On 10/20/2019 4:33 PM, King, Brian wrote:
How about simply, “If the Registrar or Registry Operator denies a request, the Registrar or Registry Operator MUST…” ?

An explanation is warranted for any given denial, and every other grounds for denial would actually be much easier to articulate than 6.1.f.

Brian J. King
Director of Internet Policy and Industry Affairs

T +1 443 761 3726
markmonitor.com<http://www.markmonitor.com>

MarkMonitor
Protecting companies and consumers in a digital world

From: IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org><mailto:irt.regdatapolicy-bounces at icann.org> On Behalf Of Theo Geurts
Sent: Thursday, October 17, 2019 8:42 AM
To: Sarah Wyld <swyld at tucows.com><mailto:swyld at tucows.com>; irt.regdatapolicy at icann.org<mailto:irt.regdatapolicy at icann.org>
Subject: Re: [IRT.RegDataPolicy] Re. 18 9.5.4.2

I agree with most of your points, Luc.

I also think that the current language could result in a request bomb by automated systems.

Regarding the less professional actors who will use the balancing act to game the system, that is pure criminal behavior, and we have laws to deal with such "actors."

@Sarah very valid points. I like the changes.

I am not sure how this all will work with resellers and wholesale registrars. At the moment I leave the disclosure requests to the resellers who act as the data controller for the registrant data.

Theo

On 17-10-2019 14:27, Sarah Wyld wrote:

Thanks Luc for putting this in writing, it's a good explanation.

I would support a change like the proposed one, indicating that the explanation should be limited such that it does not infringe on the data subject's rights.

Related -- it does seem a bit odd to refer to one specific Article of the GDPR and then also say "or other privacy legislation". The balancing test is only from 6(1)f, not from other legislation also. Personally I would say that we should try to be regulation-agnostic instead of referring to the GDPR specifically, but since I think many IRT members wouldn't support removing that sentence entirely, perhaps we can remove the "or other privacy legislation" bit?

With both Luc's and my changes, we'd end up with:

9.5.4.2 If the Registrar or Registry Operator denies a request under Article 6(1)(f) of GDPR, the Registrar or Registry Operator MUST explain to the fullest extent possible how the balancing test was applied, without infringing upon the data subject's right to privacy.

Looking forward to feedback, thank you.

--

Sarah Wyld

Domains Product Team

Tucows

+1.416 535 0123 Ext. 1392

On 10/17/2019 5:59 AM, Luc SEUFER wrote:
Hi Brian, Susan et alia,

As I don’t think I was quite eloquent in my explanation regarding my concerns as to the current wording of 9.5.4.2, please allow me to have a second try in writing.

Recommendation 18 states that

“Responses where disclosure of data (in whole or in part) has been denied should include: rationale sufficient for the requestor to understand the reasons for the decision, including, for example, an analysis and explanation of how the balancing test was applied (if applicable)”

The current wording states

“If the Registrar or Registry Operator denies a request under Article 6(1)(f) of GDPR or other privacy legislation, the Registrar or Registry Operator MUST explain how the balancing test was applied.”

My issue with this wording -asides from the fact that it goes a tad astray from the recommendation - is that it would require us to be too detailed in our explanation of the balance test failure.

The disclosure constitutes a data processing act between the data controller (CPH) and a third party (the requestor). Asides from the guarantees the requestor will have to give and the obligations they will have to accept to become a processor; the first element to examine is the lawfulness of the processing.
In this case, the legal basis is the legitimate interest of the requestor, which shall be subject to strict scrutiny. (This also why I said in regards to 9.3.2 that the CPH will always need to know the jurisdiction of the requestor.)

The outcomes of the balancing test will depend on several elements, which, if explained in too much detail to the requestor, will prove problematic.

For example, in the case of a blogger criticizing a government, a  political party, government, religion...  the fact that the requestor is based in a country where such critics could lead to a death sentence  would definitely lead to a failed test. As you can imagine going in so much details would go against the right to privacy of the registrant.

Similarily in case, a registrant would have registered a domain name for a future business venture, and the requestor is one of their competitors, the reason for the balance test failure cannot be disclosed.

Those are just two examples I have encountered and we are only a medium-size registrar. I am sure other CPs would have many similar ones.

This being said, I suppose you fear that modifying this provision could open a door for some "less professional" actors to automatically reply that the balance test failed without even conducting one.  Howevever, I think this can be averted by modifying the clause as follows:

"If the Registrar or Registry Operator denies a request under Article 6(1)(f) of GDPR or other privacy legislation, the Registrar or Registry Operator shall explain the reasons for the denial as much as possible without breaching its obligations vis-a-vis the privacy rights of the Registrant."

Luc

______________

Luc Seufer
Chief Legal Officer
Namespace

21, rue Léon Laval
L-3372 Leudelange
Luxembourg

Tel.: +352 27 220 166
Mobile: +352 691 600 417
Fax.: +352 20 300 166
Mailto: lseufer at namespace.com<mailto:lseufer at namespace.com>

_______________________________________________

IRT.RegDataPolicy mailing list

IRT.RegDataPolicy at icann.org<mailto:IRT.RegDataPolicy at icann.org>

https://mm.icann.org/mailman/listinfo/irt.regdatapolicy<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_irt.regdatapolicy&d=DwMDaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=TKn_SBXpvb-EKwigl8XoeBI3Z9irIEPMeZaSt3z_zts&s=Fqs3p1ymQqHTiViP2PVFPohjJY4GLn2YWSGzuX0O_5w&e=>

_______________________________________________

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://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMDaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=TKn_SBXpvb-EKwigl8XoeBI3Z9irIEPMeZaSt3z_zts&s=9cntesqDYPevlqG3idcrvLZu5XURM_e2_mGQQ7swtoM&e=>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMDaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=TKn_SBXpvb-EKwigl8XoeBI3Z9irIEPMeZaSt3z_zts&s=kLxuBkPiXx23L_xzuqRZGWQH_yNginYKXkEbuveiMYw&e=>). 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.

_______________________________________________

IRT.RegDataPolicy mailing list

IRT.RegDataPolicy at icann.org<mailto:IRT.RegDataPolicy at icann.org>

https://mm.icann.org/mailman/listinfo/irt.regdatapolicy<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_irt.regdatapolicy&d=DwMDaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=TKn_SBXpvb-EKwigl8XoeBI3Z9irIEPMeZaSt3z_zts&s=Fqs3p1ymQqHTiViP2PVFPohjJY4GLn2YWSGzuX0O_5w&e=>

_______________________________________________

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://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMDaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=TKn_SBXpvb-EKwigl8XoeBI3Z9irIEPMeZaSt3z_zts&s=9cntesqDYPevlqG3idcrvLZu5XURM_e2_mGQQ7swtoM&e=>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMDaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=TKn_SBXpvb-EKwigl8XoeBI3Z9irIEPMeZaSt3z_zts&s=kLxuBkPiXx23L_xzuqRZGWQH_yNginYKXkEbuveiMYw&e=>). 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/irt.regdatapolicy/attachments/20191023/016421d2/attachment.html>