Developing language for REDACTED FOR PRIVACY
Hello IRT, I was personally a bit unclear on where we left this from today's call, so I wanted to close the loop on list. Phase 1 left it to implementation to decide what language would be substantially similar to REDACTED FOR PRIVACY, which must be returned where applicable. While I understand we have some hesitation about being too proscriptive, I think there is overriding value in being proscriptive here for two reasons: 1. There is actually value to implementers in knowing exactly how to treat these fields, as it makes implementation easier and less risky (otherwise how do implementers know if the language they want to use is sufficiently "substantially similar")? 2. Users of RDS data need to know clearly whether a privacy/proxy service is being used, or if the data is redacted by policy (REDACTED BY POLICY might actually be clearer substitute language). RDS users need to know whether to go to SSAD to request redacted data, or to the P/P service to request disclosure under the P/P policy. Ambiguity here not only harms those who need the data, but also those who would receive requests for the underlying data, or compliance complaints about not providing the data when this ambiguity leads to erroneous requests. Unless I'm missing something, the value of being proscriptive here, and the risk of not being proscriptive, really outweighs the minor convenience to implementers of choosing their own language. Thanks, team. 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
Just bear in mind that even though this may be a simple change for registrars, for all thick registries this would trigger a mass update from all affected registrars who will have to update the domain name records for all sponsored domain names at the registries. That can amount to significant load. I do agree that having unified language has a value of convenience, but there is an implementation concern to be considered. Best, Volker Am 26.02.2020 um 18:57 schrieb King, Brian via IRT.RegDataPolicy:
Hello IRT,
I was personally a bit unclear on where we left this from today’s call, so I wanted to close the loop on list.
Phase 1 left it to implementation to decide what language would be substantially similar to REDACTED FOR PRIVACY, which must be returned where applicable. While I understand we have some hesitation about being too proscriptive, I think there is overriding value in being proscriptive here for two reasons:
1. There is actually value to implementers in knowing exactly how to treat these fields, as it makes implementation easier and less risky (otherwise how do implementers know if the language they want to use is sufficiently “substantially similar”)? 2. Users of RDS data need to know clearly whether a privacy/proxy service is being used, or if the data is redacted by policy (REDACTED BY POLICY might actually be clearer substitute language). RDS users need to know whether to go to SSAD to request redacted data, or to the P/P service to request disclosure under the P/P policy. Ambiguity here not only harms those who need the data, but also those who would receive requests for the underlying data, or compliance complaints about not providing the data when this ambiguity leads to erroneous requests.
Unless I’m missing something, the value of being proscriptive here, and the risk of not being proscriptive, really outweighs the minor convenience to implementers of choosing their own language. Thanks, team.
*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
_______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@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.
-- 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.
That's a good catch, Volker. Thanks. Perhaps a phased, staggered, or otherwise gradual approach would be best. 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@icann.org> On Behalf Of Volker Greimann Sent: Thursday, February 27, 2020 4:57 AM To: irt.regdatapolicy@icann.org Subject: Re: [IRT.RegDataPolicy] Developing language for REDACTED FOR PRIVACY Just bear in mind that even though this may be a simple change for registrars, for all thick registries this would trigger a mass update from all affected registrars who will have to update the domain name records for all sponsored domain names at the registries. That can amount to significant load. I do agree that having unified language has a value of convenience, but there is an implementation concern to be considered. Best, Volker Am 26.02.2020 um 18:57 schrieb King, Brian via IRT.RegDataPolicy: Hello IRT, I was personally a bit unclear on where we left this from today's call, so I wanted to close the loop on list. Phase 1 left it to implementation to decide what language would be substantially similar to REDACTED FOR PRIVACY, which must be returned where applicable. While I understand we have some hesitation about being too proscriptive, I think there is overriding value in being proscriptive here for two reasons: 1. There is actually value to implementers in knowing exactly how to treat these fields, as it makes implementation easier and less risky (otherwise how do implementers know if the language they want to use is sufficiently "substantially similar")? 2. Users of RDS data need to know clearly whether a privacy/proxy service is being used, or if the data is redacted by policy (REDACTED BY POLICY might actually be clearer substitute language). RDS users need to know whether to go to SSAD to request redacted data, or to the P/P service to request disclosure under the P/P policy. Ambiguity here not only harms those who need the data, but also those who would receive requests for the underlying data, or compliance complaints about not providing the data when this ambiguity leads to erroneous requests. Unless I'm missing something, the value of being proscriptive here, and the risk of not being proscriptive, really outweighs the minor convenience to implementers of choosing their own language. Thanks, team. 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 _______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@icann.org<mailto:IRT.RegDataPolicy@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=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=5BXFjLLo0wCJhv5qC5BCtvMjUkQLioTE35WMJI9Pk8U&s=ddZcEX2DxbyWbk7PztNodkIJ6cdclu7yHBws9usXdiM&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=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=5BXFjLLo0wCJhv5qC5BCtvMjUkQLioTE35WMJI9Pk8U&s=_XVVogim2dJ1qRpamWhEti5Be7QeESvtkBvOXPef8S4&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=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=5BXFjLLo0wCJhv5qC5BCtvMjUkQLioTE35WMJI9Pk8U&s=RJNpzPWhfU2OMnqUbY950YeKh00zi7RTqSEFhsXjGwI&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. -- 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.key-2Dsystems.net&d=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=5BXFjLLo0wCJhv5qC5BCtvMjUkQLioTE35WMJI9Pk8U&s=_CBUdtjdSE2U-KQliMp2WsEDK3J41mQpU2UrdoSbfSY&e=> 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.
1 I see not much value in it. I got more hassles with lawyers claiming the data is incorrect because they cannot find the company called redacted for privacy in a company database/register. In addition we do not redact the data due to privacy, we redact data due to data protection laws. Redacted due to GDPR makes more sense to me or redacted due to whatever data protection law. We can come up with something better than redacted for privacy right? 2 I guess I never realized that when I put every domain name under our management on our privacy protect service I will never have to deal with SSAD? Theo On 26-2-2020 18:57, King, Brian via IRT.RegDataPolicy wrote:
Hello IRT,
I was personally a bit unclear on where we left this from today’s call, so I wanted to close the loop on list.
Phase 1 left it to implementation to decide what language would be substantially similar to REDACTED FOR PRIVACY, which must be returned where applicable. While I understand we have some hesitation about being too proscriptive, I think there is overriding value in being proscriptive here for two reasons:
1. There is actually value to implementers in knowing exactly how to treat these fields, as it makes implementation easier and less risky (otherwise how do implementers know if the language they want to use is sufficiently “substantially similar”)? 2. Users of RDS data need to know clearly whether a privacy/proxy service is being used, or if the data is redacted by policy (REDACTED BY POLICY might actually be clearer substitute language). RDS users need to know whether to go to SSAD to request redacted data, or to the P/P service to request disclosure under the P/P policy. Ambiguity here not only harms those who need the data, but also those who would receive requests for the underlying data, or compliance complaints about not providing the data when this ambiguity leads to erroneous requests.
Unless I’m missing something, the value of being proscriptive here, and the risk of not being proscriptive, really outweighs the minor convenience to implementers of choosing their own language. Thanks, team.
*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
_______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@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.
Hey Theo, 1. I think REDACTED BY POLICY is accurate, and better than the old language. The policy is, in fact, responsive to the law regardless of which privacy law might apply for a given domain name. For clarity, the value to the ecosystem is that when an IP owner identifies a large number of infringing domains, or a CERT identifies a large number of domains involved in a phishing attack or a botnet, they will do a bulk public RDS lookup on those domains. When they've pulled back the public data, the investigator then knows clearly where to go to get any unredacted information they need. Variations of fields that could look like "Privacy Redacted" or "Privacy Protected" would be ambiguous - those could either be a P/P service or arguably "substantially similar to" REDACTED FOR PRIVACY. If at least all the REDACTED BY POLICY domains can be grouped together, the investigator knows to go to the SSAD with those, and to approach the P/P service for anything different. 1. I love how you think. You'd probably still have to connect to SSAD, but you should not expect to receive (m)any requests, I suppose. Clever! 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@icann.org> On Behalf Of Theo Geurts Sent: Thursday, February 27, 2020 8:08 AM To: irt.regdatapolicy@icann.org Subject: Re: [IRT.RegDataPolicy] Developing language for REDACTED FOR PRIVACY 1 I see not much value in it. I got more hassles with lawyers claiming the data is incorrect because they cannot find the company called redacted for privacy in a company database/register. In addition we do not redact the data due to privacy, we redact data due to data protection laws. Redacted due to GDPR makes more sense to me or redacted due to whatever data protection law. We can come up with something better than redacted for privacy right? 2 I guess I never realized that when I put every domain name under our management on our privacy protect service I will never have to deal with SSAD? Theo On 26-2-2020 18:57, King, Brian via IRT.RegDataPolicy wrote: Hello IRT, I was personally a bit unclear on where we left this from today's call, so I wanted to close the loop on list. Phase 1 left it to implementation to decide what language would be substantially similar to REDACTED FOR PRIVACY, which must be returned where applicable. While I understand we have some hesitation about being too proscriptive, I think there is overriding value in being proscriptive here for two reasons: 1. There is actually value to implementers in knowing exactly how to treat these fields, as it makes implementation easier and less risky (otherwise how do implementers know if the language they want to use is sufficiently "substantially similar")? 2. Users of RDS data need to know clearly whether a privacy/proxy service is being used, or if the data is redacted by policy (REDACTED BY POLICY might actually be clearer substitute language). RDS users need to know whether to go to SSAD to request redacted data, or to the P/P service to request disclosure under the P/P policy. Ambiguity here not only harms those who need the data, but also those who would receive requests for the underlying data, or compliance complaints about not providing the data when this ambiguity leads to erroneous requests. Unless I'm missing something, the value of being proscriptive here, and the risk of not being proscriptive, really outweighs the minor convenience to implementers of choosing their own language. Thanks, team. 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 _______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@icann.org<mailto:IRT.RegDataPolicy@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=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=yK_TQEem1RFtC8UDDqgQTHb6qkNukmGNsWtsgAA95g0&s=snTTjpyWLp6n8PTG7yCqgUzDEZIdgRnLBdYH0c-3g9Q&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=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=yK_TQEem1RFtC8UDDqgQTHb6qkNukmGNsWtsgAA95g0&s=u1uEqHn49P2CeYuFcyMfLzASqxqQiQ2X3cbZRMReljE&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=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=yK_TQEem1RFtC8UDDqgQTHb6qkNukmGNsWtsgAA95g0&s=CJQ2i9xFz3gnPczD8KieyqMZ8yYree7WMhUxLT47zNg&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.
Redacted by policy might require some more thinking. Not really looking for people mailing/calling our support team with questions like : who created the policy or which policy? and get into senseless arguments over the phone. Every support ticket about a domain name is money lost and we will not make any money on that domain name for the next 3 years. But from what I understand from your email and that is somewhat I heard on the call also and I am framing it somewhat bluntly. Registrars can put in similar wording (as was recommended), as long it cannot be confused with privacy services. If that is the case I suggest we put that in the policy and the issue is solved. And perhaps we should come up with some examples that are confusing and perhaps add them to the implementation footnotes? Sounds reasonable to the IRT or are we now making policy and we are going out of scope of the recommendation? On 2, I am not sure if it is really clever, but then again if the number of disclosure requests stay as flat as they have been since 2018 than it might be an option. If for some reason unknown to me the number of requests go up, SSAD and automation might be a good option. Theo On 27-2-2020 17:54, King, Brian wrote:
Hey Theo,
1. I think REDACTED BY POLICY is accurate, and better than the old language. The policy is, in fact, responsive to the law regardless of which privacy law might apply for a given domain name.
For clarity, the value to the ecosystem is that when an IP owner identifies a large number of infringing domains, or a CERT identifies a large number of domains involved in a phishing attack or a botnet, they will do a bulk public RDS lookup on those domains. When they’ve pulled back the public data, the investigator then knows clearly where to go to get any unredacted information they need. Variations of fields that could look like “Privacy Redacted” or “Privacy Protected” would be ambiguous – those could either be a P/P service or arguably “substantially similar to” REDACTED FOR PRIVACY. If at least all the REDACTED BY POLICY domains can be grouped together, the investigator knows to go to the SSAD with those, and to approach the P/P service for anything different.
2. I love how you think. You’d probably still have to connect to SSAD, but you should not expect to receive (m)any requests, I suppose. Clever!
*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@icann.org> *On Behalf Of *Theo Geurts *Sent:* Thursday, February 27, 2020 8:08 AM *To:* irt.regdatapolicy@icann.org *Subject:* Re: [IRT.RegDataPolicy] Developing language for REDACTED FOR PRIVACY
1 I see not much value in it. I got more hassles with lawyers claiming the data is incorrect because they cannot find the company called redacted for privacy in a company database/register.
In addition we do not redact the data due to privacy, we redact data due to data protection laws.
Redacted due to GDPR makes more sense to me or redacted due to whatever data protection law.
We can come up with something better than redacted for privacy right?
2 I guess I never realized that when I put every domain name under our management on our privacy protect service I will never have to deal with SSAD?
Theo
On 26-2-2020 18:57, King, Brian via IRT.RegDataPolicy wrote:
Hello IRT,
I was personally a bit unclear on where we left this from today’s call, so I wanted to close the loop on list.
Phase 1 left it to implementation to decide what language would be substantially similar to REDACTED FOR PRIVACY, which must be returned where applicable. While I understand we have some hesitation about being too proscriptive, I think there is overriding value in being proscriptive here for two reasons:
1. There is actually value to implementers in knowing exactly how to treat these fields, as it makes implementation easier and less risky (otherwise how do implementers know if the language they want to use is sufficiently “substantially similar”)? 2. Users of RDS data need to know clearly whether a privacy/proxy service is being used, or if the data is redacted by policy (REDACTED BY POLICY might actually be clearer substitute language). RDS users need to know whether to go to SSAD to request redacted data, or to the P/P service to request disclosure under the P/P policy. Ambiguity here not only harms those who need the data, but also those who would receive requests for the underlying data, or compliance complaints about not providing the data when this ambiguity leads to erroneous requests.
Unless I’m missing something, the value of being proscriptive here, and the risk of not being proscriptive, really outweighs the minor convenience to implementers of choosing their own language. Thanks, team.
*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
_______________________________________________
IRT.RegDataPolicy mailing list
IRT.RegDataPolicy@icann.org <mailto:IRT.RegDataPolicy@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=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=yK_TQEem1RFtC8UDDqgQTHb6qkNukmGNsWtsgAA95g0&s=snTTjpyWLp6n8PTG7yCqgUzDEZIdgRnLBdYH0c-3g9Q&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=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=yK_TQEem1RFtC8UDDqgQTHb6qkNukmGNsWtsgAA95g0&s=u1uEqHn49P2CeYuFcyMfLzASqxqQiQ2X3cbZRMReljE&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=DwMD-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=yK_TQEem1RFtC8UDDqgQTHb6qkNukmGNsWtsgAA95g0&s=CJQ2i9xFz3gnPczD8KieyqMZ8yYree7WMhUxLT47zNg&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.
participants (3)
-
King, Brian -
Theo Geurts -
Volker Greimann