Hi,

 

I do agree that the need for privacy services seems to have reduced in some TLDs where RD redactions are in place by default, yet the services are still being used by many registrants that fear that their personal information may become public in some way. These services do provide a valid and functional way to enhance the security and privacy of those customers. I disagree on your point that registrants do not trust their registrar with their data as in many cases, it is the registrar that provides the service and holds their data. In fact, many large registrars and resellers offer privacy services by default for all their customers, and some even offer this service for free.

 

As there is no way to know how any given registrant may use their domain name, restricting such services from bad actors in the first place is nigh impossible, so the only remedy is that the entity offering the service should be bound by the same rules as other providers of registration services.

 

Fortunately, NIS2 does just that when it references the obligations not of registries and registrars, but of registries and “entities providing registration services”. This broad language covers all players in the ecosystem: registrars, resellers, privacy or proxy services, entities registering on behalf of others like law firms, etc. All will now bound by the same rules regarding the collection, verification and storage of the data of the ultimate registrant, as well as of the provision of responses to legitimate disclosure requests. Where these legal requirements are in place, no need for further policy exists. To the contrary, any diverging policy only introduces chaos and potentially conflicting obligations of the parties involved.

 

 

 

From: pimo via Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl@icann.org>
Date: Wednesday, 24. July 2024 at 09:35
To: PPSAI IRT members, including observers <gdd-gnso-ppsai-impl@icann.org>
Cc: Dennis Chang <dennis.chang@icann.org>, Steve Crocker <steve@shinkuro.com>, pimo <pimonit@gmail.com>
Subject: [Gdd-gnso-ppsai-impl] Re: P/P services vs Accuracy and Disclosure rules for registrars

In my view, there is a fundamental paradox in the use of privacy and proxy services in domain name registration that perhaps should be addressed.

On one hand, these services offer an additional layer of anonymity and protection from spam and unwanted solicitations for domain owners operating in good faith. By ensuring that personal information is not accessible in the WHOIS database, these services enhance the security and privacy of registrants.

However, on the other hand, these services can be exploited by fraudsters to obstruct investigations. This is particularly effective when the registrar, privacy protection provider and proxy service have different policies to verify and/or disclose personal information, making it challenging to identify and take action against bad actors.

The paradox lies in the fact that if we were able to establish a data protection standard in domain name registration, the need for separate privacy and proxy services would become redundant. A unified standard would ensure that all registrars adhere to strict privacy protocols, thereby providing a consistent and reliable layer of protection for all registrants.

The existence of privacy and proxy services highlights a fundamental issue: registrants, whether acting in good or bad faith, do not fully trust the registrar to serve as the sole guardian of their privacy. This lack of trust drives the demand for additional layers of protection, which, while beneficial in some cases, can also be manipulated for nefarious purposes.


Thanks,
Paola

 

On Tue, 23 Jul 2024 at 23:45, Steve Crocker via Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl@icann.org> wrote:

Dennis,

 

Thanks for your note.

 

This working group is the restart of the IRT process for the Privacy and Proxy Services Accreditation policy.  Quite a bit of time has passed since that policy was passed.  There were some serious issues with the policy when it was adopted, and the situation has become worse.  Accordingly, I am raising some questions about where we're going.

 

This is a first draft of what I expect will become a more complete memo intended for wider distribution.  It feels appropriate to share these thoughts first within this working group.

 

Privacy and proxy services are intended to protect the identity of and restrict access to registrants.  The fact that they have become widely used is a strong indication that registrants feel the need for such protection.  (And, I think it needs to be said, their widespread use is also due in part to active sales efforts.  People are spending a noticeable amount of money on these services, so this is an important source of revenue.)

 

Privacy Services

 

Let me address Privacy services first.  When a registrant uses a Privacy service, the name of the registrant is provided to the registrar, but the registrant's address, email and phone number are not.  Instead, the address, email and phone number of the Privacy service is provided to the registrar.  If the registrant makes those data elements available to a requestor, the requestor will be able to contact Privacy service.  The requestor will also know the name of the registrant and may be able to find other ways to contact the registrant.

 

The troubling aspect of a Privacy service is the requestor has no explicit way of knowing whether the address, email and phone number are associated with the registrant or with a Privacy service.  The intent of the Privacy and Proxy Service Accreditation policy is to make it clear to requestors that the data they are receiving is for a Privacy service.

 

>From my point of view, overloading the registrant's address, email and phone number fields with the Privacy service's data elements is unnecessarily confusing.  A simpler and more straightforward approach is to add a correspondence address, email and/or phone number to the registration data.

 

Of course, in order for this to accomplish the intended purpose, the registrant's address, email and phone number would NOT be easily available.  And that involves the rules for disclosure of non-public data.  More on this below.

 

Proxy service vs NIS2 and GDPR

 

A Proxy service differs from a Privacy service by hiding all data about the registrant.  The registrant has no data about the actual registrant.  Or, to be more precise, the registrant sees the Proxy service as the actual registrant, and the term that's often used to refer to the Proxy service's client is the "beneficial registrant."

 

Today, Proxy service providers operate outside the ICANN contractual structure.  With the exception of formal judicial processes, e.g. a government agent serving a warrant or subpoena, there is no way to compel a Proxy service to disclose the identity and other data about the beneficial registrant.  The intent of the Privacy and Proxy Accreditation policy is to require Privacy and Proxy services to:

  • register with ICANN,
  • agree to an accreditation process,
  • conform with whatever rules are adopted later regarding collecting accurate data, and
  • conform to whatever rules are adopted later regarding disclosing that data.

Meanwhile, ICANN is very, very, very slowly developing rules regarding the accuracy of the registration data and the disclosure of that data to appropriate requestors.  ICANN has spent an inordinate amount of time wrestling with the GDPR.  The sequence from SSAD to RDRS has been wasteful and ineffective.  NIS2 is going to require accurate data, and we have not yet begun to take that requirement into account.

 

The question that seems obvious to me is how these two sets of rules will interact.  For example :

  • If registrants achieve greater protection using a Proxy service than without, does that mean the protection provided by registrars is insufficient?
  • The other side of that same question relates to disclosure.  If a requestor has a legitimate need for registration data, but the data in its database is only the name of the Proxy service, doesn't that undermine the concept of providing registration to appropriate requestors for legitimate purposes?

There are other questions related to the creation of a new bureaucracy that deserve attention, but I think those questions should come after we have a sensible understanding of how the overall system is supposed to work.

 

Whither the PPSAI working group?

 

The PPSAI working is focused on implementing an accreditation process for Privacy and Proxy services.  What's missing in my view is clarity as to the purpose of this accreditation and clarity as to whether accrediting P/P Services will accomplish the purpose.  In brief, we don't have a policy that is fit for purpose.

 

=============================================

 

As I said at the top, this is a first draft.  I invite responses, and I am particularly interested in others who wish to join the effort to make sense of this effort.

 

Thanks,

 

Steve

 

sender

_______________________________________________
Gdd-gnso-ppsai-impl mailing list -- gdd-gnso-ppsai-impl@icann.org
To unsubscribe send an email to gdd-gnso-ppsai-impl-leave@icann.org
_______________________________________________
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.