[IRT.RegDataPolicy] Developing language for REDACTED FOR PRIVACY

[King, Brian]

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 at icann.org> On Behalf Of Theo Geurts
Sent: Thursday, February 27, 2020 8:08 AM
To: irt.regdatapolicy at 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 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=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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20200227/b75e626b/attachment.html>