Tucows provides reasonable, lawful access to non-public registration data; this means constantly working to balance the privacy rights of registrants against the rights of third parties, most of which, in our experience, are related to intellectual property rights (90% of all requests). In addition to the usual statistics, this update also includes a deep dive into actual examples of some problematic disclosure requests, a discussion of the reasoning behind denials, and what this means for the industry conversation about disclosure requests.

These ongoing updates are intended to provide insight into the disclosure requests Tucows receives and to serve as useful data for discussion as our industry moves toward a holistic policy governing the disclosure of private data.

Tiered Access Statistics

The statistics discussed below include data through the end of February 2020 (“Period 3”). Each request is a request for personal data regarding the registrant of a domain where that information is not publicly available. A member of the Compliance and Legal team reviews every request individually to balance the rights of the data subject and the legitimate interests of the requestor to determine whether and how much data should be disclosed; this includes consideration of Tucows’ contractual requirements as well as applicable laws—both privacy laws and intellectual property laws. This work is time-consuming and intense but there’s no other way to make sure that we’re making the right decisions about when to disclose the personal data we’re entrusted with.

Requests for Data Disclosure

Tucows received 238 requests for data in Period 3 (from mid-October 2019 to the end of February 2020), and 2,864 requests in total since the Tiered Access portal went live in May 2018.

Previously, data for Period 1 was discussed in Tucows’ Tiered Access Directory: a look at the numbers and for Period 2 in Tiered Access Data Disclosure Update.

Disclosure Request Outcomes – Period 3

62% of requests received in this period resulted in registration data being disclosed to the requestor

This rate of disclosure is about double what it was in the previous two periods (24% in Period 1 and 36% in Period 2), indicating higher quality requests. This is likely related to the use of the RrSG Minimum Required Information for Whois Data Requests, which was drafted by ICANN’s Registrar Stakeholder Group (RrSG) to help standardize requests for domain data disclosure. Requests that use this format are easier to review (all of the required information is included in a predictable format) and deficiencies are simple to communicate to the requestor. It may also be due to Tucows’ outreach efforts to educate requestors about this format. This higher rate should be considered illustrative of success and a positive movement toward appropriate disclosure of personal data to parties with a legitimate purpose.

17% of requests were incomplete and the requestor did not respond to our followup for further information, so no data were disclosed

Despite formal outreach and personalized responses to each request, a significant number of requests are incomplete and responses seeking further information are ignored by the requestor. This is because either there is no party on the other end to review responses that do not include data (the request is automated and not appropriately monitored) or there was no reason to make the request in the first place and pushback had the correct effect of preventing unnecessary disclosure of personal data.

6% of requests for data were denied, following a determination that the requestor did not have an adequate lawful basis

This represents a decrease from the previous period but is level with Period 1 and the overall rate of denied disclosure requests.

12% of requests resulted in “disclosure” of Whois privacy information—that is, the same placeholder information already publicly available to a requestor

Parties experienced with our data disclosure request process have recently begun to specifically request data for domains clearly indicated in the public Whois as using Tucows’ Whois privacy services. In some cases, this has been accompanied by a dropoff in requests for the personal data of registrants without Whois privacy. In other cases, there has been no dropoff in requests for non-Whois privacy domains but the format of the request has changed, indicating that the requestor is aware of the fact that there is Whois privacy on the domains but is attempting to get the underlying data without submitting a subpoena, as is Tucows’ current process.

Requested vs. Disclosed

Compared Against Previous Reporting Periods

Requests Over Time

Here’s an illustration of the total volume of requests Tucows has received since the launch of Tiered Access:

The number of requests appears to have stabilized, concurrent with the increase in quality of requests. Again, this is a positive trend as both requestors and the Tucows family of registrars have acclimated to the new privacy legal landscape.

Disclosure Request Outcomes, Compared

It may seem counterintuitive but an increase in disclosure rates means that request quality overall is improving and signals a positive move toward appropriate disclosure.

Duplicate Requests

Additional information on duplicate requests can be found in Tucows’ Tiered Access Directory: a look at the numbers (for Period 1) and Tiered Access Data Disclosure Update (for Period 2).

Categories of Requestors

As noted above and in previous blog posts, disclosure of registration data is only granted when the requestor has demonstrated a legal basis to access the data. While requestors can be categorized into a few broad groups, inclusion in a certain group does not determine if and which data are disclosed. Each request is—and must be—evaluated on its individual merits. Requestors therefore are grouped below solely for analysis’ sake. The main tracked requestor types are:

• commercial litigation, which request disclosure of personal data in order to bring a legal claim of rights against the registrant
• law enforcement, carrying out an investigation or otherwise in the course of their work
• security researchers, who use certain aggregate data to identify trends in digital abuse
• other, which includes Certificate Authorities, resellers, private individuals, and sometimes even the registrants themselves.

Requests by Requestor Type

As you can see, Commercial Litigation has made up the bulk of requests since Tucows began tracking this data. Typically, these requestors are either companies that are created specifically to request this type of information on behalf of large corporate clients or are lawyers hired or employed primarily to request this type of information.

Also included in this category, however, are individual rights holders attempting to protect their rights (sometimes intellectual property, sometimes personal privacy rights) without the advantage of a company or a lawyer devoted to that purpose. Especially in light of the Preliminary Recommendations found in the EPDP Phase 2 Team’s Initial Report, it is important to ensure that individual rights holders continue to have a reasonable means of requesting the information necessary to protect their rights.

The rate of requests by Security Researchers is deceptively low because it is counted differently. Most requests are counted by the number of domains requested; when a request is received for the entire database, however, that is counted as just one request, not millions. Some Law Enforcement requests fall into this category, as do nearly all requests from Security Researchers. We currently do not allow unfettered access to our database to anyone and are working with representatives of both groups to come up with a means of providing the data necessary to conduct their investigations while protecting the privacy rights of individuals.

The Importance of Human Review

We regularly receive requests for disclosure of registration data which we deny after reviewing the request, the requestor, and the relevant data (including the domain name itself and any content that may be hosted there). In the interests of transparency and advancing industry discussion on this topic, we’ll share some real-life examples of denied requests along with the reasoning behind our decision below. For some of these, the domain names in question are relevant and therefore the requestor may become evident. We should emphasize that, due to the sheer volume of requests from certain requestors, a trademark or corporation may appear more than once. This should not be taken to mean that all requests from these requestors are invalid or are treated differently than any other requestor; the domain names are simply used as examples.

It is concerning that these invalid requests which, upon meaningful review, are readily apparent as invalid even to a layperson, continue to be submitted. This underscores the fact that any attempt at automation will result in numerous false positives and that meaningful human review is essential prior to disclosure.

These requests fall into three broad categories: duplicates, an issue with the allegedly infringed trademark, or fair use. As the majority of disclosure requests Tucows has received to date are for alleged trademark infringement, the examples below may fall primarily into that category; again, it should not be assumed that this is the only type of invalid request.

Duplicate Requests

Prior posts (Period 1 and Period 2) have addressed the matter of duplicates and, as there has been a statistically-significant dropoff in duplicate requests, it will not be discussed here.

Issues with the Request

Many disclosure requests include a list of all trademarks potentially infringed by a specific domain or set of domains; this is not ideal as the domain name must be compared to the list rather than to a single trademark that is being infringed and it is often not apparent to the reviewer which trademark is the issue. This lack of specificity also suggests that the request originates from an automated system.

A shocking number of disclosure requests relate to domains not registered with the Tucows family of registrars—sometimes these domains are not registered at all. We have even received a disclosure request alleging trademark infringement for a domain that predated the trademark’s registration. These issues point to the limitations of automation and the necessity of meaningful human review, which we’d like to see more of on the requestors’ side.

Fair Use

The final category, fair use, includes multiple examples that are obvious to a layperson as non-infringing. Not included here are edge cases that ought to be adjudicated by a competent authority (whether at UDRP or in a local court).

petrolexcompany.com
Here, the domain includes the full trademark “Rolex” but is in use by a different company whose registered name (Petrolex) includes that trademark.

instantmonogram.com
letsfacethebook.com
In each of these cases, the domain name contains the whole trademark separated by additional characters (“Insta[…]gram” or “Face[…]book”) but bears no relation to any infringement of it. While these domains no longer have any hosted content, at the time of review, they were in use by a company specializing in personalized t-shirts and other apparel and by a biblical outreach group, respectively. Both of these are clearly fair use and should never have resulted in a request for data disclosure.

boucheriefacedeboeuf.com
lincolnstainedglass.com
zharfambook.com
These do not contain the full trademark but only portions of it or portions of misspellings previously adjudicated at UDRP (here, “f…bo” and “insta”). The domains boucheriefacedeboeuf.com and zharfambook.com remain active, in use by a butcher and what appears to be a literacy site. While lincolnstainedglass.com no longer has any hosted content, at the time of review, a small stained glass company was using it for their business. Again, these are clearly fair use upon meaningful human review.

addictedtofacebook.org
banned-by-facebook.com
divestfacebook.com
facebooksucks.org
protestfacebook.org
saynotoinstagram.com
While each of these domains uses the full trademark (“Facebook” or “Instagram”), they nevertheless evince an indication that the domain is or will be used to discuss grievances with the company in question. Tucows takes no position on the merits of these discussions but notes that trademark use should not be used as a cudgel against speech.

The Tucows process for disclosing data remains aligned with industry best practices and we continue to be actively involved at ICANN both to closely align our processes with expected policy outcomes and to ensure that the rights of all individuals are respected in those policies. We look forward to continuing to share these statistics on a regular basis to contribute to broader industry understanding of the registration data disclosure landscape.

It has been more than a year since Tucows, Enom’s parent company, launched our Tiered Access Compliance & Operations portal, sometimes called “Gated Whois,” and it’s been around six months since we shared our first set of statistics on how and by whom this platform is being used. Today’s update brings our statistics current through mid-October 2019. We hope that this data will provide insight into how we handle requests for non-public personal data.

It’s important to remember that these statistics represent disclosure requests by a third party asking for personal data which is not publicly available. Each request is examined by a member of our legal team, who reviews the request and decides what data, if any, should be disclosed based on applicable law and our ICANN obligations. This review can be intensive and time-consuming but is essential to processing the data we’re entrusted with in accordance with our commitment to the protection of personal data.

Data disclosure requests

We received 467 requests for data in the period from February to mid-October 2019 and 2617 requests total to date.

• 36% of requests received in this period resulted in registration data being disclosed to the requestor
• 45% were incomplete and the requestor did not respond to our followup for further information, so no data were disclosed
• 10% were denied, following a determination that the requestor did not have an adequate lawful basis
• 9% of requests resulted in “disclosure” of Whois Privacy information—that is, the same information already publicly available to a requestor

Disclosure request outcomes – Period 2

We are pleased to note that we did not find significant spikes in requests during this reporting period, unlike our previous report where request volumes increased around ICANN meetings, suggesting that some portion of those requests were submitted in order to skew the data towards an argument that disclosure requests are not being processed in a timely or appropriate manner.

Here’s an illustration of the volume requests over time since we’ve launched Tiered Access:

Compared against our last report

Perhaps more interesting than the overall numbers is how the current reporting period compares to the previous one: comparing request and response statistics as users become more accustomed to the new system and have learned how to effectively request data; the comparisons below are percentages.

Disclosure request outcomes compared

• Increase in disclosure of non-public data from 25% to 35% and decrease in incomplete requests from 69% to 45%
  These changes are likely a result of our efforts to work with high-volume requestors to improve the quality of their requests
• Increase in denied requests from just under 5% to just over 11%
  We attribute this to small-volume and single requestors who recently discovered our Tiered Access portal and do not yet understand how to submit a request that allows us to adequately evaluate their legitimate rights against the privacy rights of the registrant. We will work to better describe the request process at the point of access.
• Increase in requests for data where the domain has Whois Privacy enabled from 3% to 9%
  When a domain uses one of our Whois Privacy services, we instruct requestors to submit legal process before disclosing the underlying personal data. We also, however, provide the privacy data, as the email address can be used to contact the registrant directly.

Duplicate requests

We continue to see a significant rate of duplicate requests. These include requests from the same source and from multiple requestors, each purporting to represent the same interests.  When we receive a second request from the same requestor, we refer them to our prior correspondence—whether that included a request for more information (most often the case) or disclosed personal data. When we receive a request for the same domain’s data from a different party, we encourage the two parties to work together to determine which one represents the legitimate purposes for the data disclosure. We do this whether the data were previously disclosed or not.

As before, a statistically-significant amount of all requests come from the same single requestor mentioned in our previous report; this is the largest individual requestor using our Tiered Access system. However, their requests have dropped by half—last time we shared stats, this requestor represented nearly 65% of all requests, while for period 2 they make up 30% of all disclosure requests submitted to our Tiered Access system. We have worked with this requestor to refine and improve the quality and type of their requests, which has resulted in a decrease both in requests sent and requests denied.

Although it makes up only a very small percentage of overall requests (1.5%), requests for access to our entire registration database have doubled from period 1 to period 2. The majority of these types of requests come from security researchers.

Who wants data?

As stated above, users of our Tiered Access Compliance & Operations system are vetted by our legal team, and disclosure is limited to those with a demonstrated legitimate legal interest. There are a few broad categories of requestors who typically have a legitimate purpose that would allow us to disclose the data—for example, while we do receive requests that are unsolicited offers to purchase a domain, this is not a legitimate purpose for disclosure, as there are other ways to accomplish the same goal without necessitating disclosure of personal data.

The main tracked requestor types are “commercial litigation”, who need access to personal data in order to bring a legal claim of rights against the registrant; law enforcement, carrying out an investigation or in the course of their work; and security researchers, who use certain aggregate data to identify trends in digital abuse. In the chart below, “other” indicates all other requestors, including Certificate Authorities, resellers, and unaffiliated individuals.

Requests by Requestor Type

Despite recent concerns raised by security researchers—who comprise the bulk of requests for access to our entire database—the significant majority of all disclosure requests continue to come from commercial litigation interests. We continue to work with security researchers to develop ways for them to access the information they need while protecting the personal data of our customers.

Since law enforcement historically had unrestricted access to the entire registration database, when a law enforcement officer from a jurisdiction we operate in indicates a need for data that would previously have been public, we do disclose the data to them. Law enforcement officers from other jurisdictions must still show legitimate purpose.

Ongoing work

The attitude we have seen throughout this process indicates a culture of entitlement to private personal data and a frustration about the requestor’s obligation to prove that they have a legitimate basis to access personal registrant data.

In February 2019, the Registrar Stakeholder group published recommended minimum requirements for requesting non-public registration data. This valuable resource has been slow to gain traction in the community of requestors, though we continue to educate requestors individually. Our follow-ups, asking for information sufficient to show legitimate purpose, continue to be ignored, indicating to us that our responses to disclosure requests are unmonitored and that those disclosure requests themselves may be spurious or automated.

We work on an ongoing basis both with trade groups and individual requestors to emphasize the importance of balancing rights—the requestor’s right to personal data necessary to defend their legitimate rights against our customers’ right to privacy. Our work includes participation in the EPDP, an effort at ICANN to solidify the rules surrounding how disclosure of personal data should proceed.

We believe that we have developed a viable disclosure model—an opinion shared by trade groups who have indicated that the Tucows Tiered Access Compliance & Operations platform is an industry standard—and are happy to share additional details with other data custodians and with requestors to improve and harmonize the process across the industry. I will be at ICANN 66 in Montreal and available to discuss.

ICANN’s Inter-Registrar Transfer Policy (IRTP) defines the procedures and rules for domain name transfers. When it was first introduced in 2004, the Policy was limited to inter-registrar transfers. Over the years, it has been revised by Policy Development Process (PDP) Working Groups and expanded to include governance of domain ownership transfers and a transfer dispute process. But the original rules for inter-registrar transfers remained mostly unchanged until May 2018, when the Temp Spec came into effect, modifying the process for a post-GDPR world where Whois data, which had long been the primary means of transfer verification, was no longer publicly available.

But the Temp Spec is temporary. So what’s the long-term plan?

The last few months have been interesting. First, we’re now in the gap between the Temp Spec’s expiration and any formal update to the Transfer Policy. ICANN’s Expedited Policy Development Process (EPDP) team has recommended continuing to use the process outlined in the Temp Spec in the interim. The EPDP team also made several recommendations as to how the Transfer Policy should be modified, which we can expect to see reflected in those updates.

Secondly, and much to the delight of domain policy enthusiasts (we exist!), the Transfer Policy came due for review by the GNSO Council. This is a standard practice for all ICANN Consensus policies: once a policy has been in place for a number of years, ICANN Staff compiles a report on its effects, which the GNSO Council uses to decide if the policy needs to be modified. This time around, the decision is a pretty clear one—the fact that we’re still following the Temp Spec method instead of the pre-GDPR transfer process points to the need to update the Policy. The Revised Inter-Registrar Transfer Policy Status Report is almost a formality, given the circumstances, but it includes some findings and related suggestions which will hopefully spark data-driven improvements to the Transfer Policy alongside the necessary GDPR-motivated updates.

Recent Transfer Policy changes

It’s been just over a year since Enom made necessary changes to our domain transfer process, and domains are still moving into and out of our platform smoothly. The biggest difference between our pre- and post-GDPR transfer process is that we are no longer able to use a “Form of Authorization” to confirm a domain owner’s transfer request. Instead, the authcode is used to verify that the request is valid and to initiate the inbound transfer within the registry system. We also now direct all transfer-related messaging to the registrant contact, since we no longer use an administrative contact for gTLDs.

These changes are in keeping with the Temp Spec and with what we anticipate to be the future of the Transfer Policy. They’re also aligned with the work being done by the registrar and registry joint TechOps team: developing a more streamlined, user-friendly transfer process that remains secure against domain theft.

Transfer Policy Status Report

The Report discusses the impact that the Temp Spec had on the inter-registrar transfer process, but its overall scope is broader, with a focus on three main goals that transfer-related PDP working groups have been considering since they first began exploring how to improve the transfer process in 2005:

– Portability

– Preventing abuse

– Providing information¹

The related central questions are:

– Can registrants easily transfer their domain names?

– Are processes standardized and efficient for registrars?¹

Takeaways from the Report

The Report shows ICANN Compliance has noted a steady decline in the rate of transfer-related Compliance tickets, suggesting that there are fewer overall concerns about the process, perhaps because domain owners have gained experience with it. However, ICANN’s Contractual Compliance metrics do show that transfer issues remain the second-most common reason for people to contact ICANN Compliance, following only Whois inaccuracy concerns. This suggests that there’s room for simplification and further education around the transfer process.

Another takeaway from the Report is that there was a significant spike in inter-registrar transfers in late 2016, likely caused by registrants changing their registrar just before the new Change of Registrant (COR) process and related lock came into effect. The Report also notes that immediately following the introduction of the COR lock requirement, ICANN Compliance began to receive a significant number of complaints about it.² This tracks with our own customer service data which indicates frustration and confusion about COR locks generally, and we will be interested to see how COR lock complaint numbers change over time.

As acknowledged in the Report, ICANN cannot directly track abusive transfers, as such situations are not reported consistently and cannot be independently verified.

ICANN’s suggestions for improvement

ICANN provides four suggestions for how to enhance the Transfer Policy moving forward, and we have some thoughts on each of them.

ICANN Suggestion 1: Require registrars to log when a domain owner obtains their transfer authorization code.²

Our perspective: Logging when an authorization code is retrieved by an end-user is a great idea, although implementation would be complicated. In many domain management interfaces, this code is visible by default on the domain name details page—there is no affirmative request to retrieve the code. So for many resellers and registrars, this requirement would involve significant development work, but that work is well worth doing.

ICANN Suggestion 2: Provide a process or options to remove the 60-day COR transfer lock to better serve registrants’ needs.²

Our perspective: The 60-day transfer lock has indeed proven to be a nuisance to both registrars and registrants, and there is some confusion as to whether and how it may be removed after it has been applied. We welcome clarification of the requirements but expect it to be a long process including consideration of whether alternative verification safeguards would become necessary.

ICANN Suggestion 3: Clarify the Transfer Policy section about when a transfer can be denied due to non-payment.²

Our perspective: This change would be a useful clarification. The section of the Policy where this is laid out can be confusing and difficult to parse, so making it more straightforward should help registrars more easily understand their rights and obligations in this regard.

ICANN Suggestion 4: Clarify if the Change of Registrant process is applicable when the real underlying contact info is updated on a domain with an active Whois Privacy service.²

Our perspective: This has been a topic of discussion between us and ICANN for quite some time. We believe that, if the underlying ownership data on a privacy-protected domain changes, that’s a Change of Registrant. If the purpose of the COR process is to protect domain owners against hijacking, this is just as important for domains using Whois privacy as it is for those without. ICANN, however, argues that privacy-protected domains are effectively owned by the privacy service, and so COR is not applicable. We want this issue to be clarified, but at this point it’s a question of contractual interpretation, which always needs to be approached with care.

We appreciate that ICANN’s Contractual Compliance team has provided these suggestions and, if the GNSO Council decides that the Transfer Policy needs to be updated, which certainly seems to be the case, we look forward to working with the multistakeholder community to review these and other possible changes to the Policy.

The future of the IRTP

We always advocate for processes that keep things simple for the registrant while maintaining a high level of security and accountability. Tucows (our parent company) staff are part of the TechOps team, participating in the group’s efforts towards streamlining the transfer process to make domain transfers easier for domain owners while maintaining security against unauthorized transfers. Our hope is that the transfer process in use today under the Temp Spec will simply be turned into official policy. After all, it’s been in effect for over a year with no demonstrable detriment to domain owners.

Our Support metrics show that domain transfers make up a significant portion of Support interactions, with most questions focused either on ccTLDs with special processes, or general transfer status requests (“When will my transfer be complete?”). We’re working on providing more information to our customers and resellers via our Knowledge Base, which we hope will help support you through this process.

The work that we do in the ICANN community is complex, as is its impact on registrants and resellers. It’s important to make sure the decisions we’re making are data-driven, rather than based on gut feelings that could turn out to be incorrect or only accurate for a small portion of users. This report is a great start; we’re glad to see critical review and engagement with the process and hope that the data provided in the Inter-Registrar Transfer Policy Status Report will be taken into consideration as part of future efforts towards updating the Transfer Policy.

1. ICANN Org. “Revised Inter-Registrar Transfer Policy Status Report .” Icann.org, ICANN, Mar. 2019, 4.
2. ICANN Org. “Revised Inter-Registrar Transfer Policy Status Report .” Icann.org, ICANN, Mar. 2019, 31-32.

Remember, although we have a great legal team working at Enom, none of what we share here can or should be taken as legal advice.

Among the world’s leading registrars, Tucows, our parent company, is the only one that has redacted all personal data from the public Whois and announced a data use consent management process for registrants worldwide. In making these changes, we’ve disrupted the status quo and encountered resistance from other industry members who would prefer a more conservative solution. But with our nearly two decades’ experience operating as an accredited domain registrar and supporting a large reseller network, we’ve learned that it is imperative to choose proactive solutions and remain focused on how the industry will develop long-term, rather than default to the most simple or convenient option.

We’ve said many times before that we believe individuals around the world have a right to the privacy and protection of their personal data. We’ve also made the more practical argument that while the GDPR may apply only to EU-local individuals, other governments have also passed data protection laws, and we expect more to follow suit. Today, we want to talk about why we remain confident in our approach and place it within the necessary context of worldwide data privacy regulations.

Comparing Regional Privacy Laws

The GDPR has received a lot of attention not because it’s the only law of its kind, but because of its wide scope of applicability and, perhaps first and foremost, the severity of the penalties for non-compliance. There are other, less well-known laws in countries outside of the EU that establish similar data privacy protections. We’ve looked at a few important examples—Canada’s PIPEDA, California’s new Consumer Privacy Act of 2018, and the 2000 Argentina Personal Data Protection Act—to see how they stack up against the GDPR. You can jump to our summary table, which compares their fundamental concepts and relates them back to Enom’s data-processing practices, or continue on below for a high-level overview of each law.

California

The California Consumer Privacy Act of 2018 (AB 375) was signed into law by the state’s Governor on June 29, 2018. This new legislation takes effect in 2020, and many of the protections it extends to Californians will sound familiar to anyone who’s read up on the GDPR. At a high level, the CCP Act aims to ensure:

1. The right of Californians to know what personal information is being collected about them.
2. The right of Californians to know whether their personal information is sold or disclosed and to whom.
3. The right of Californians to say no to the sale of personal information.
4. The right of Californians to access their personal information.
5. The right of Californians to equal service and price, even if they exercise their privacy rights (s.2.i).

The CCP Act has an interesting fundamental difference to the GDPR: the GDPR protects the data, while the CCP Act protects the consumer. The GDPR sets out rights and obligations for Data Controllers, Data Processors, and Data Subjects, while the CCP Act focuses on the rights a consumer has in relation to businesses that process their data. Even with this scope of applicability in mind, it’s very clear that we can expect to see a heightened level of transparency and consumer control over data in California.

These rights under the California Consumer Privacy Act will, of course, be subject to limitations, and the finer details will no doubt shift as government officials and private interest groups work to tighten up data privacy practices in a way that is not detrimental to the Californian businesses that rely on consumer data, including tech giants like Google and Facebook.

It’s both fitting and encouraging that California, a hub for technological innovation, is leading the U.S. movement to protect individual privacy in our digital age. And while there may not be policy in development at the federal level just yet, other American states are well on their way to passing modernized data privacy legislation—check out this handy, albeit, slightly outdated, map for more details. It seems likely that some of the important provisions in California’s Consumer Privacy Act will serve as a template for other state governments looking to establish stricter data privacy laws.

Canada

Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA) has been in place since 2000, but an accompanying document, “Guidelines for obtaining meaningful consent,” was just released in its final form on May 24, 2018, shortly before the GDPR came into effect. PIPEDA shares a number of similarities with the GDPR, which these new guidelines serve to highlight.

PIPEDA may not explicitly mention “data minimization,” but it does state that “an organization may collect, use or disclose personal information only for purposes that a reasonable person would consider are appropriate in the circumstances” (Division 1.3). This idea is echoed and expanded in later sections, including “Principle 5 — Limiting Use, Disclosure, and Retention,” which declares that data “shall not be used or disclosed for purposes other than those for which it was collected, except with the consent of the individual or as required by law.” Much like the GDPR, PIPEDA has a clear aim to curb deceitful or indiscriminate data collection.

In addition to restricting what data is processed, PIPEDA also calls for a high level of transparency around how and why data is processed. Its “Openness” principle affords individuals the right to request information about an organization’s data processing policies and practices, such as “a description of the type of personal information held by the organization, including a general account of its use” (Sched. 1 4.8.2). PIPEDA also requires organizations to obtain an individual’s consent before processing personal data, and specifies that this consent is “only valid if it is reasonable to expect that an individual to whom the organization’s activities are directed would understand the nature, purpose and consequences of the collection, use or disclosure of the personal information to which they are consenting” (Div.1, 6.1).

Does this allow for service providers to bury the “nature, purpose and consequences” in the fine print? The word “reasonable” always invites a high degree of subjectivity. But the Office of the Privacy Commissioner of Canada (the “OPC”) released a related document, “Guidelines for obtaining meaningful consent,” which addresses any confusion. It states that “in order for an organization to demonstrate that it has obtained valid consent, pointing to a line buried in a privacy policy will not suffice.” Pretty clear.

These Guidelines (well-summarized here) also put forth an idea quite reminiscent of the GDPR’s distinction between the legal bases of consent and contract. In Canada, individuals must be offered a clear “yes or no” option to consent to data processing. However, an exception to this rule is the collection or disclosure of personal information that’s required, or to quote directly, “integral to the product or service.” The collection or disclosure of such essential data are referred to as “conditions of service,” and can’t be opted out of without opting not to use the service at all. This is very similar to how contract-based data, those data elements which are required in order to provide the service for which they are collected, do not require explicit consent under the GDPR.

The OPC also acknowledges that while some individuals may be content with a quick overview of what personal data is being collected, others will want a greater level of detail about their provider’s privacy and data use practices before making a consent choice. Organizations are encouraged to meet the needs of all users by presenting information in a “layered-format”, or some other method that provides the user with control “over how much detail is provided to them.” Our consent management process embodies this idea. We’ve clearly outlined the how, what, and why of our data collection practices, in a manner that avoids bombarding the reader with inaccessible legalese. Those looking to dive deeper can review our Data Use Information page, which we’ve also designed to be accessible to the average reader.

Argentina

Argentina’s Personal Data Protection Act is also an older data protection law, in effect since 2000. Argentina was the first Latin American nation designated by the EU as having an “adequate level of data protection” as compared to EU requirements.

Argentina’s Data Protection Act is easily comparable to the GDPR, particularly in regard to the latter’s data minimization principle and distinctive treatment of consent- and contract-based data. The Argentine law requires that data collected must be “certain, appropriate, pertinent, and not excessive with reference to the scope within and purpose for which such data were secured” (Chapter 2, s.4.1). In addition to restricting what data can be collected, the Act also states that data must only be kept while it is necessary and relevant to the purposes for which it was initially collected—if it ceases to fulfill these requirements, it must be “destroyed” (s.4.4.7).

These obligations go hand-in-hand with consent requirements: data processing is not permitted without the consent of the individual whose data is being processed, except in certain defined circumstances. The most notable exception to this requirement is the processing of data that arises “from a contractual relationship,” and which is necessary to develop or fulfill that contract. Here again, the consent request cannot be buried in the fine print. It must appear in a “prominent and express manner” (s.5.1).

Argentina is currently working to create updated data protection regulations, which will be “heavily based upon the GDPR.” Thus far, we’ve only been able to locate a Spanish-language version of the updated draft bill, so we are relying on secondary sources for insight into how it compares to its EU equivalent. In a 2017 IAPP article, GDPR matchup: Argentina’s draft Data Protection Act, Pablo A. Palazzi and Andres Chomczyk provide a solid overview of the changes being made in an effort to bring the Argentine Law in line with the EU Regulation. Their review of the draft bill notes the introduction of “new legal bases” for data processing, including, “legitimate interest,” and the addition of “sections on child consent, data breaches, accountability, privacy by design, the duty to have a data protection officer and mandatory impact studies,” all of which closely resemble the GDPR’s data protection methods.

It seems we can expect the updated Argentine law to mirror many of the GDPR’s fundamental components and, according to Palazzi and Chomczyk, even its scope of applicability; the draft outlines “new ways to determine whether an entity or certain data processing is subject to Argentine Law, quite similar to the criteria found in the GDPR.”

We’re eager to view the new law in its final form and learn when it will take effect. The law in place at this time already includes many safeguards to ensure a high level of transparency and individual control around data collection, so in some ways, we don’t expect anything truly surprising from its successor, especially if the new version does indeed follow closely the GDPR. Our GDPR implementation efforts will likely prove sufficient to meet any updated Argentine requirements as well.

Evolving Global Data Privacy Standards

The policy revision efforts underway in Argentina speak to the GDPR’s global impact. Not only do the Regulation’s data processing requirements apply to organizations outside the EU that process the data of EU locals, the GDPR also serves as a standard, perhaps particularly for countries who wish to maintain or establish adequacy status with the EU.

Just before this blog post went to “print,” India took a major step toward data privacy reform with the release of a report, “A Free and Fair Digital Economy Protecting Privacy, Empowering Indians,” that’s to serve as a draft data protection bill. In a recent Data Protection Committee press conference, Ravi Shankar Prasad, Union Minister for Law and Justice & Information Technology, Government of India, noted that India’s Supreme Court “would like Indian’s data protection law to become some kind of model for the…world…” (4m20s).

For those interested, France’s Commission Nationale de l’Informatique et des Libertés maintains a global map existing privacy law (check it out!), which may look quite different even five years from now.

A Comparison of Data Privacy Laws and Enom’s GDPR Changes

To contextualize our recent changes in relation to the GDPR, California’s Consumer Privacy Act, Canada’s PIPEDA, and Argentina’s Personal Data Protection Act, we’ve put together this comparison chart. As you’ll see, many of the core concepts remain the same across borders. This confirms our position that our recent updates demonstrate a proportionate and forward-thinking approach to the rapidly-shifting landscape of global data privacy regulation.

Reflecting on Our GDPR Changes

We could have applied our GDPR processes to EU-locals only, allowing resellers who don’t offer services to clients in the EU to proceed with business as usual, unconcerned with the GDPR. But that solution would not only have put our resellers and us at risk of improperly processing the personal data of EU-local individuals, it was also not a viable long-term option. Data privacy standards around the world are evolving and not in a direction that supports the unnecessary collection of personal data or the continued display of unredacted personal data in the public Whois directory without the data subject’s clear and specific consent. If the laws we reviewed today are any indication of where things are headed, Enom and our reseller partners can feel confident that our GDPR implementation work has positioned us all to meet and adapt to changing data privacy requirements.

Our decision to redact data from the public Whois, even before ICANN confirmed this as an appropriate response to the GDPR, was part of larger move towards a gated Whois solution. In designing our “Tiered Access Directory”, we’ve done our best to balance individual privacy and the rights of registrants with those of law enforcement and other community members. Our consent management process establishes a high level of transparency about what data we collect and why and provides registrants an easy means of revoking consent and submitting data use disclosure requests. These changes may cause some friction in the short term but we are confident they will help us meet the long-term needs of our resellers and ensure we’re protecting their businesses as well as our own.

On a less practical note, our parent company, Tucows, maintains a long-time commitment to “lobby, agitate, and educate to promote and protect an open Internet around the world.” Part of ensuring that the Internet remains free and open is ensuring that basic individual rights, including control over one’s personal information, continue to be protected as personal data becomes more ubiquitous and easy to share than ever before. The laws we’ve looked at here take varied approaches to addressing this challenge but also share some important similarities and reflect values that are becoming more and more universal: greater transparency on the part of organizations and greater control for individuals.