[IRT.RegDataPolicy] Developing language for REDACTED FOR PRIVACY

Thu Feb 27 17:45:34 UTC 2020

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 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/64fb0bb9/attachment.html>