FW: Updated Language Regarding Purposes
Ugh—suggestions for dealing with this? From: Amr Elsadr <aelsadr@icannpolicy.ninja> Reply-To: Amr Elsadr <aelsadr@icannpolicy.ninja> Date: Wednesday, October 9, 2019 at 4:34 AM To: Margie Milam <margiemilam@fb.com> Subject: Re: Updated Language Regarding Purposes Hi Margie, Thanks for this. I’m still having trouble with the reference to Article 5.1.b, and its applicability here. The ICO guidance on the purpose limitation principle has only reinforced this (https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/purpose-limitation/<https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorganisations_guide-2Dto-2Ddata-2Dprotection_guide-2Dto-2Dthe-2Dgeneral-2Ddata-2Dprotection-2Dregulation-2Dgdpr_principles_purpose-2Dlimitation_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=P8kQ3-cLXhICChBb4qTjEHvguZpoj0OFN7pjdIfsH6Y&s=Td_uk-yaqqcmbo600dsEJnKGVuVC7WiAsX-Kk43iavg&e=>). The explanation of what the principle is, as well as the checklist associated with it all indicate to me that it is applicable to the Data Controller, not a 3rd party/Requestor for disclosure/access. My thinking is that if we are to proceed as you have suggested in your email below, the process needs to loop in the Data Controller, somehow. Some reasons why this might be necessary: 1. It shouldn’t be up to the 3rd party to determine what additional purposes are or are not compatible. Ultimately, the Data Controller and Processor will be held accountable by the data subject, and possibly liable by a DPA for errors in judgment on this, so should be looped in. 2. If the Controller is not (at a minimum) informed of additional purposes for which the personal data will be processed, I’m not sure how the Controller will track and keep records of how the data that was disclosed will be or was processed. 3. If the Data Subject requests access to a report on how its personal data has been processed, it would need to make this request to the Controller with which it is familiar (likely the registrar). If the Controller is not involved in the decision to process the personal data for additional compatible purposes, it will not be in a position to provide the Data Subject with a complete report on how the data was, or is being, processed, at least not until (or if) an audit is conducted. So let’s say there is a scenario where a Requestor has been granted disclosure/access to the personal data for a specific purpose, then discovers that there is(are) additional purpose(s) for which the personal data needs to be processed further. This could be for compatible purposes, or other unrelated ones (but still fulfilling the requirements of a legitimate interest of the Requestor and supported by a legal basis). It’d make sense to me, that in this kind of scenario, some follow-up to the original request for disclosure be available where the Requestor communicates the need for further processing in the SSAD, and that there is some need for the Controller to make a decision on wether to grant permission for this additional processing. Also, since this would be a follow-up to a previously approved disclosure request, it might make sense that the follow-up is flagged for a quicker response time of the request for additional processing of the personal data for additional purposes (compatible or unrelated). This could possibly be reflected in Building Blocks G and K? I know this adds an administrative layer, and slightly slows things down, but it provides more certainty in the process as a whole, doesn’t it? I believe it would be necessary in order to protect the rights of all parties involved, as well as provide the transparency in processing that you referred to in your proposed amendment to subsection C of Building Block D. If you agree with any of this, in principle, we can try some wordsmithing of the proposed amendment. If you have concerns, let’s try to address them first. Thanks again, Margie. Amr On Oct 8, 2019, at 6:53 PM, Margie Milam <margiemilam@fb.com<mailto:margiemilam@fb.com>> wrote: Hi Amr – Following up on today’s homework – here’s a link to information from the UK Information Office that can help guide the drafting of this section: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/purpose-limitation/<https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorganisations_guide-2Dto-2Ddata-2Dprotection_guide-2Dto-2Dthe-2Dgeneral-2Ddata-2Dprotection-2Dregulation-2Dgdpr_principles_purpose-2Dlimitation_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=P8kQ3-cLXhICChBb4qTjEHvguZpoj0OFN7pjdIfsH6Y&s=Td_uk-yaqqcmbo600dsEJnKGVuVC7WiAsX-Kk43iavg&e=> Here’s what I suggest: The building block should use this language: “not incompatible with the original purpose, provided the new purpose is fair, lawful and transparent.” The policy recommendation would also need to include specific disclosures to the registrant, describing the common purposes for 3rd party access, so that the transparency requirement is met. Margie
We’re just going to create omnibus-type purposes that we declare at the time of disclosure request. I think I mentioned this 2 weeks ago. I doubt it is lawfully required, but I will discuss with our data protection attorneys. Margie said: “My purpose is Investigation of Trademark Infringement. But sometimes such an investigation results in Investigation of Phishing. Those are compatible, I don’t need to ask again.” Amr sez: “Nope, ya gotta ask again.” Instead, I propose: “My purpose is to investigate the use of a domain name in the commission of a crime. The crimes I am investigating are trademark infringement, phishing and malware distribution.” Of course there will be objection to this, but I am fairly certain it’s lawful. From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Margie Milam Sent: Wednesday, October 9, 2019 11:37 AM To: Mark Svancarek (CELA) via Gnso-epdp-team <gnso-epdp-team@icann.org>; King, Brian <Brian.King@markmonitor.com>; alexATcolevalleyconsulting.com <alex@colevalleyconsulting.com>; sdelbiancoATnetchoice.org <sdelbianco@netchoice.org>; Jennifer Gore <Jennifer@winterfeldt.law> Subject: [Gnso-epdp-team] FW: Updated Language Regarding Purposes Ugh—suggestions for dealing with this? From: Amr Elsadr <aelsadr@icannpolicy.ninja<mailto:aelsadr@icannpolicy.ninja>> Reply-To: Amr Elsadr <aelsadr@icannpolicy.ninja<mailto:aelsadr@icannpolicy.ninja>> Date: Wednesday, October 9, 2019 at 4:34 AM To: Margie Milam <margiemilam@fb.com<mailto:margiemilam@fb.com>> Subject: Re: Updated Language Regarding Purposes Hi Margie, Thanks for this. I’m still having trouble with the reference to Article 5.1.b, and its applicability here. The ICO guidance on the purpose limitation principle has only reinforced this (https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/purpose-limitation/<https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorganisations_guide-2Dto-2Ddata-2Dprotection_guide-2Dto-2Dthe-2Dgeneral-2Ddata-2Dprotection-2Dregulation-2Dgdpr_principles_purpose-2Dlimitation_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=P8kQ3-cLXhICChBb4qTjEHvguZpoj0OFN7pjdIfsH6Y&s=Td_uk-yaqqcmbo600dsEJnKGVuVC7WiAsX-Kk43iavg&e=>). The explanation of what the principle is, as well as the checklist associated with it all indicate to me that it is applicable to the Data Controller, not a 3rd party/Requestor for disclosure/access. My thinking is that if we are to proceed as you have suggested in your email below, the process needs to loop in the Data Controller, somehow. Some reasons why this might be necessary: 1. It shouldn’t be up to the 3rd party to determine what additional purposes are or are not compatible. Ultimately, the Data Controller and Processor will be held accountable by the data subject, and possibly liable by a DPA for errors in judgment on this, so should be looped in. 2. If the Controller is not (at a minimum) informed of additional purposes for which the personal data will be processed, I’m not sure how the Controller will track and keep records of how the data that was disclosed will be or was processed. 3. If the Data Subject requests access to a report on how its personal data has been processed, it would need to make this request to the Controller with which it is familiar (likely the registrar). If the Controller is not involved in the decision to process the personal data for additional compatible purposes, it will not be in a position to provide the Data Subject with a complete report on how the data was, or is being, processed, at least not until (or if) an audit is conducted. So let’s say there is a scenario where a Requestor has been granted disclosure/access to the personal data for a specific purpose, then discovers that there is(are) additional purpose(s) for which the personal data needs to be processed further. This could be for compatible purposes, or other unrelated ones (but still fulfilling the requirements of a legitimate interest of the Requestor and supported by a legal basis). It’d make sense to me, that in this kind of scenario, some follow-up to the original request for disclosure be available where the Requestor communicates the need for further processing in the SSAD, and that there is some need for the Controller to make a decision on wether to grant permission for this additional processing. Also, since this would be a follow-up to a previously approved disclosure request, it might make sense that the follow-up is flagged for a quicker response time of the request for additional processing of the personal data for additional purposes (compatible or unrelated). This could possibly be reflected in Building Blocks G and K? I know this adds an administrative layer, and slightly slows things down, but it provides more certainty in the process as a whole, doesn’t it? I believe it would be necessary in order to protect the rights of all parties involved, as well as provide the transparency in processing that you referred to in your proposed amendment to subsection C of Building Block D. If you agree with any of this, in principle, we can try some wordsmithing of the proposed amendment. If you have concerns, let’s try to address them first. Thanks again, Margie. Amr On Oct 8, 2019, at 6:53 PM, Margie Milam <margiemilam@fb.com<mailto:margiemilam@fb.com>> wrote: Hi Amr – Following up on today’s homework – here’s a link to information from the UK Information Office that can help guide the drafting of this section: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/purpose-limitation/<https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorganisations_guide-2Dto-2Ddata-2Dprotection_guide-2Dto-2Dthe-2Dgeneral-2Ddata-2Dprotection-2Dregulation-2Dgdpr_principles_purpose-2Dlimitation_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=P8kQ3-cLXhICChBb4qTjEHvguZpoj0OFN7pjdIfsH6Y&s=Td_uk-yaqqcmbo600dsEJnKGVuVC7WiAsX-Kk43iavg&e=> Here’s what I suggest: The building block should use this language: “not incompatible with the original purpose, provided the new purpose is fair, lawful and transparent.” The policy recommendation would also need to include specific disclosures to the registrant, describing the common purposes for 3rd party access, so that the transparency requirement is met. Margie
Actually, the purposes you list are too generic and do not allow the disclosing party to verify the complaint. Instead, a requester should give as much detail as possible to allow the disclosing party to make a balancing test in their favor. So instead of "Trademark Infringement", the requester should detail specifically which trademark he believes to have been infringed and how the domain name registration is infringing on this trademark. This goes beyond stating that the two strings match. Instead of "in the commission of a crime" the crime at hand and how the domain name is used in it should be detailed. Simply put, the requester should be held to provide the specific evidence he has that triggered the request in the first place. It should not require the discloser to try and figure this out themselves. The request should allow the discloser to check the evidence and conclude that "Yep, this requester has made a sufficient case that warrants discloser". Volker Am 09.10.2019 um 22:58 schrieb Mark Svancarek (CELA) via Gnso-epdp-team:
We’re just going to create omnibus-type purposes that we declare at the time of disclosure request. I think I mentioned this 2 weeks ago. I doubt it is lawfully required, but I will discuss with our data protection attorneys.
Margie said: “My purpose is Investigation of Trademark Infringement. But sometimes such an investigation results in Investigation of Phishing. Those are compatible, I don’t need to ask again.”
Amr sez: “Nope, ya gotta ask again.”
Instead, I propose: “My purpose is to investigate the use of a domain name in the commission of a crime. The crimes I am investigating are trademark infringement, phishing and malware distribution.”
Of course there will be objection to this, but I am fairly certain it’s lawful.
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Margie Milam *Sent:* Wednesday, October 9, 2019 11:37 AM *To:* Mark Svancarek (CELA) via Gnso-epdp-team <gnso-epdp-team@icann.org>; King, Brian <Brian.King@markmonitor.com>; alexATcolevalleyconsulting.com <alex@colevalleyconsulting.com>; sdelbiancoATnetchoice.org <sdelbianco@netchoice.org>; Jennifer Gore <Jennifer@winterfeldt.law> *Subject:* [Gnso-epdp-team] FW: Updated Language Regarding Purposes
Ugh—suggestions for dealing with this?
*From: *Amr Elsadr <aelsadr@icannpolicy.ninja <mailto:aelsadr@icannpolicy.ninja>> *Reply-To: *Amr Elsadr <aelsadr@icannpolicy.ninja <mailto:aelsadr@icannpolicy.ninja>> *Date: *Wednesday, October 9, 2019 at 4:34 AM *To: *Margie Milam <margiemilam@fb.com <mailto:margiemilam@fb.com>> *Subject: *Re: Updated Language Regarding Purposes
Hi Margie,
Thanks for this. I’m still having trouble with the reference to Article 5.1.b, and its applicability here. The ICO guidance on the purpose limitation principle has only reinforced this (https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-g... <https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorgani...>). The explanation of what the principle is, as well as the checklist associated with it all indicate to me that it is applicable to the Data Controller, not a 3rd party/Requestor for disclosure/access.
My thinking is that if we are to proceed as you have suggested in your email below, the process needs to loop in the Data Controller, somehow. Some reasons why this might be necessary:
1. It shouldn’t be up to the 3rd party to determine what additional purposes are or are not compatible. Ultimately, the Data Controller and Processor will be held accountable by the data subject, and possibly liable by a DPA for errors in judgment on this, so should be looped in.
2. If the Controller is not (at a minimum) informed of additional purposes for which the personal data will be processed, I’m not sure how the Controller will track and keep records of how the data that was disclosed will be or was processed.
3. If the Data Subject requests access to a report on how its personal data has been processed, it would need to make this request to the Controller with which it is familiar (likely the registrar). If the Controller is not involved in the decision to process the personal data for additional compatible purposes, it will not be in a position to provide the Data Subject with a complete report on how the data was, or is being, processed, at least not until (or if) an audit is conducted.
So let’s say there is a scenario where a Requestor has been granted disclosure/access to the personal data for a specific purpose, then discovers that there is(are) additional purpose(s) for which the personal data needs to be processed further. This could be for compatible purposes, or other unrelated ones (but still fulfilling the requirements of a legitimate interest of the Requestor and supported by a legal basis).
It’d make sense to me, that in this kind of scenario, some follow-up to the original request for disclosure be available where the Requestor communicates the need for further processing in the SSAD, and that there is some need for the Controller to make a decision on wether to grant permission for this additional processing.
Also, since this would be a follow-up to a previously approved disclosure request, it might make sense that the follow-up is flagged for a quicker response time of the request for additional processing of the personal data for additional purposes (compatible or unrelated). This could possibly be reflected in Building Blocks G and K?
I know this adds an administrative layer, and slightly slows things down, but it provides more certainty in the process as a whole, doesn’t it? I believe it would be necessary in order to protect the rights of all parties involved, as well as provide the transparency in processing that you referred to in your proposed amendment to subsection C of Building Block D.
If you agree with any of this, in principle, we can try some wordsmithing of the proposed amendment. If you have concerns, let’s try to address them first.
Thanks again, Margie.
Amr
On Oct 8, 2019, at 6:53 PM, Margie Milam <margiemilam@fb.com <mailto:margiemilam@fb.com>> wrote:
Hi Amr –
Following up on today’s homework – here’s a link to information from the UK Information Office that can help guide the drafting of this section:
https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-g... <https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorgani...>
Here’s what I suggest:
The building block should use this language:
“not incompatible with the original purpose, provided the new purpose is fair, lawful and transparent.”
The policy recommendation would also need to include specific disclosures to the registrant, describing the common purposes for 3^rd party access, so that the transparency requirement is met.
Margie
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@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.
-- 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 Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Hi Mark, Taking in to account the nuances in Volker’s last email, I’d say that your proposal sounds good (so no objections that I can think of on my end). Requestors should provide as much detail as they can regarding their legitimate interests in seeking disclosure of personal information, and what purposes they have in processing this information, how it will be processed and by whom. If all of the purposes can be identified at the time of the submission of the request, then great. If a requestor discovers that it has additional purposes for which it needs to process the data, which were unanticipated at the time of the disclosure request being submitted, then all I am proposing is that there be some streamlined process to amend the initial request, and have the amendment evaluated by the disclosing party. I understand if this might seem burdensome and undesirable, but we are attempting to create policy recommendations that comply with regulations that are meant to place control of a natural person’s data in his/her control. Remember that this data is not the property of the requestor. The requestor has no de facto entitlement to it. Parties other than the data subject that process it must do so in compliance with regulations that protect the rights of the data subject. Thanks. Amr
On Oct 9, 2019, at 10:58 PM, Mark Svancarek (CELA) via Gnso-epdp-team <gnso-epdp-team@icann.org> wrote:
We’re just going to create omnibus-type purposes that we declare at the time of disclosure request. I think I mentioned this 2 weeks ago. I doubt it is lawfully required, but I will discuss with our data protection attorneys.
Margie said: “My purpose is Investigation of Trademark Infringement. But sometimes such an investigation results in Investigation of Phishing. Those are compatible, I don’t need to ask again.”
Amr sez: “Nope, ya gotta ask again.”
Instead, I propose: “My purpose is to investigate the use of a domain name in the commission of a crime. The crimes I am investigating are trademark infringement, phishing and malware distribution.”
Of course there will be objection to this, but I am fairly certain it’s lawful.
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Margie Milam Sent: Wednesday, October 9, 2019 11:37 AM To: Mark Svancarek (CELA) via Gnso-epdp-team <gnso-epdp-team@icann.org>; King, Brian <Brian.King@markmonitor.com>; alexATcolevalleyconsulting.com <alex@colevalleyconsulting.com>; sdelbiancoATnetchoice.org <sdelbianco@netchoice.org>; Jennifer Gore <Jennifer@winterfeldt.law> Subject: [Gnso-epdp-team] FW: Updated Language Regarding Purposes
Ugh—suggestions for dealing with this?
From: Amr Elsadr <aelsadr@icannpolicy.ninja> Reply-To: Amr Elsadr <aelsadr@icannpolicy.ninja> Date: Wednesday, October 9, 2019 at 4:34 AM To: Margie Milam <margiemilam@fb.com> Subject: Re: Updated Language Regarding Purposes
Hi Margie,
Thanks for this. I’m still having trouble with the reference to Article 5.1.b, and its applicability here. The ICO guidance on the purpose limitation principle has only reinforced this ([https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/purpose-limitation/](https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorganisations_guide-2Dto-2Ddata-2Dprotection_guide-2Dto-2Dthe-2Dgeneral-2Ddata-2Dprotection-2Dregulation-2Dgdpr_principles_purpose-2Dlimitation_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=P8kQ3-cLXhICChBb4qTjEHvguZpoj0OFN7pjdIfsH6Y&s=Td_uk-yaqqcmbo600dsEJnKGVuVC7WiAsX-Kk43iavg&e=)). The explanation of what the principle is, as well as the checklist associated with it all indicate to me that it is applicable to the Data Controller, not a 3rd party/Requestor for disclosure/access.
My thinking is that if we are to proceed as you have suggested in your email below, the process needs to loop in the Data Controller, somehow. Some reasons why this might be necessary:
1. It shouldn’t be up to the 3rd party to determine what additional purposes are or are not compatible. Ultimately, the Data Controller and Processor will be held accountable by the data subject, and possibly liable by a DPA for errors in judgment on this, so should be looped in.
2. If the Controller is not (at a minimum) informed of additional purposes for which the personal data will be processed, I’m not sure how the Controller will track and keep records of how the data that was disclosed will be or was processed.
3. If the Data Subject requests access to a report on how its personal data has been processed, it would need to make this request to the Controller with which it is familiar (likely the registrar). If the Controller is not involved in the decision to process the personal data for additional compatible purposes, it will not be in a position to provide the Data Subject with a complete report on how the data was, or is being, processed, at least not until (or if) an audit is conducted.
So let’s say there is a scenario where a Requestor has been granted disclosure/access to the personal data for a specific purpose, then discovers that there is(are) additional purpose(s) for which the personal data needs to be processed further. This could be for compatible purposes, or other unrelated ones (but still fulfilling the requirements of a legitimate interest of the Requestor and supported by a legal basis).
It’d make sense to me, that in this kind of scenario, some follow-up to the original request for disclosure be available where the Requestor communicates the need for further processing in the SSAD, and that there is some need for the Controller to make a decision on wether to grant permission for this additional processing.
Also, since this would be a follow-up to a previously approved disclosure request, it might make sense that the follow-up is flagged for a quicker response time of the request for additional processing of the personal data for additional purposes (compatible or unrelated). This could possibly be reflected in Building Blocks G and K?
I know this adds an administrative layer, and slightly slows things down, but it provides more certainty in the process as a whole, doesn’t it? I believe it would be necessary in order to protect the rights of all parties involved, as well as provide the transparency in processing that you referred to in your proposed amendment to subsection C of Building Block D.
If you agree with any of this, in principle, we can try some wordsmithing of the proposed amendment. If you have concerns, let’s try to address them first.
Thanks again, Margie.
Amr
On Oct 8, 2019, at 6:53 PM, Margie Milam <margiemilam@fb.com> wrote:
Hi Amr –
Following up on today’s homework – here’s a link to information from the UK Information Office that can help guide the drafting of this section:
Here’s what I suggest:
The building block should use this language:
“not incompatible with the original purpose, provided the new purpose is fair, lawful and transparent.”
The policy recommendation would also need to include specific disclosures to the registrant, describing the common purposes for 3rd party access, so that the transparency requirement is met.
Margie
participants (4)
-
Amr Elsadr -
Margie Milam -
Mark Svancarek (CELA) -
Volker Greimann