P/P services vs Accuracy and Disclosure rules for registrars
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
Folks, I signed up to serve on the PPSAI working group. I am serving as an independent participant, not as the official representative of either SSAC or the Business Constituency. I would have been happy to represent either, but there were other volunteers. I attended the first meeting in Kigali. The next meeting is this Thursday. I sent the following note to the working group. I expect to hear a variety of viewpoints, some supportive, some not. I'd like to work with others to expand my note and cover the competing viewpoints in a balanced and useful form. Thanks, Steve ---------- Forwarded message --------- From: Steve Crocker <steve@shinkuro.com> Date: Tue, Jul 23, 2024 at 6:44 PM Subject: P/P services vs Accuracy and Disclosure rules for registrars To: PPSAI IRT members, including observers <gdd-gnso-ppsai-impl@icann.org> Cc: Dennis Chang <dennis.chang@icann.org>, Steve Crocker <steve@shinkuro.com
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 -- Sent by a Verified [image: Sent by a Verified sender] <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y> sender
Hi Steve, Thanks for getting the ball rolling. However, before diving into the charter intricacies, I’d like to take a step back. Firstly, we need to remember that the IRT was paused to allow the Registration Data policy to be drafted and implemented. Ideally, I would wait for the industry to implement it before moving forward with the PPSAI. Currently, registrars are unsure how registries will implement it and what the RDDS will look like. Nevertheless, I understand the eagerness of some parties to move forward quickly. This group's initial step should be to ensure that the reasons for the IRT hiatus no longer exist. While doing so, we should consider both policy grounds and the actual state of the industry. Your email was based on the Charter definition, derived from the 2013 RAA Specification on proxy and privacy registrations. This specification was inserted into the RAA in 2009 to facilitate negotiations and amend the RAA with the LEA requests. A quick look at the industry reveals a discrepancy between the privacy and proxy definitions and reality. 1.2 “Privacy Service” is a service where a Registered Name is registered to its beneficial user as the Registered Name Holder, but alternative, reliable contact information is provided by the P/P Provider for display in the RDDS or equivalent services. 1.3 “Proxy Service” is a service where a Registered Name Holder licenses use of a Registered Name to the P/P Customer, and the Registered Name Holder's contact information is displayed in the RDDS or equivalent services instead of the P/P Customer’s contact information. This group should investigate further, but I believe a study will show the following: 1. Regardless of their name (proxy, privacy, etc.), service providers, often affiliated with registrars, offer to publish their name, address, and phone numbers in the RDDS instead of the registrant’s. The email address, like the postal address and phone number, acts as a forwarding service. Main providers like Domainbyproxy, Withheldforprivacy, Contact Privacy Inc., and Whois Proxy function as described. 2. Numerous domain names belong to registrants with different RDDS details. Registrants may use a law firm, web agency, holding company, domain leaser, or a tech-savvy person registering domain names for family and friends. These domain names are hard to identify easily due to various use cases. From your email and the charter, I understand that this group aims to regulate the first category without involving every law firm and holding company in the ICANN accreditation process. And I’ve not discussed the issues the Reg Data Policy might create when allowing or compelling registrars to redact certain information in the RDDS, leading to cases where published data after lifting privacy service is less than before... Happy to discuss those points further tomorrow. Best, Luc PS: I am the RrSG alternate but writing in my own capacity as a registrar and survivor of the PPSAI WG and IRT. From: Steve Crocker via Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl@icann.org> Date: Wednesday, 24 July 2024 at 00:52 To: SSAC <ssac@icann.org>, PPSAI IRT members, including observers <gdd-gnso-ppsai-impl@icann.org> Cc: Steve Crocker <steve@shinkuro.com> Subject: [Gdd-gnso-ppsai-impl] Fwd: P/P services vs Accuracy and Disclosure rules for registrars Folks, I signed up to serve on the PPSAI working group. I am serving as an independent participant, not as the official representative of either SSAC or the Business Constituency. I would have been happy to represent either, but there were other volunteers. I attended the first meeting in Kigali. The next meeting is this Thursday. I sent the following note to the working group. I expect to hear a variety of viewpoints, some supportive, some not. I'd like to work with others to expand my note and cover the competing viewpoints in a balanced and useful form. Thanks, Steve ---------- Forwarded message --------- From: Steve Crocker <steve@shinkuro.com<mailto:steve@shinkuro.com>> Date: Tue, Jul 23, 2024 at 6:44 PM Subject: P/P services vs Accuracy and Disclosure rules for registrars To: PPSAI IRT members, including observers <gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>> Cc: Dennis Chang <dennis.chang@icann.org<mailto:dennis.chang@icann.org>>, Steve Crocker <steve@shinkuro.com<mailto:steve@shinkuro.com>> 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 -- Sent by a Verified [Image removed by sender. Sent by a Verified sender]<https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y> sender
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.
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<mailto: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<mailto:gdd-gnso-ppsai-impl@icann.org> To unsubscribe send an email to gdd-gnso-ppsai-impl-leave@icann.org<mailto: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.
Volker, while I agree with much of what you said, " All will now bound by the same rules...." only applies to those subject to EU regulation/laws and there are many players who are not. Alan On Tue, Jul 23, 2024 at 9:08 PM Volker Greimann via Gdd-gnso-ppsai-impl < gdd-gnso-ppsai-impl@icann.org> wrote:
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.
_______________________________________________ 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.
participants (5)
-
Alan Greenberg -
Luc SEUFER -
pimo -
Steve Crocker -
Volker Greimann