[IRT.RegDataPolicy] Re. 18 9.5.4.2

Sarah Wyld swyld at tucows.com
Thu Oct 17 12:27:09 UTC 2019


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
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
>
> _______________________________________________
> 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/irt.regdatapolicy/attachments/20191017/1a8fe0a0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20191017/1a8fe0a0/signature.asc>


More information about the IRT.RegDataPolicy mailing list