TL;DR: Much of the ICANN 63 conference focused on the GDPR’s effects on our industry. We’ve recapped the EPDP team’s work, focusing on the possible policy outcomes that could most significantly affect our resellers and registrants: should admin and tech contacts continue to be collected and published? Should domain providers be required to differentiate between different registrant types? What happens next in this policy creation process?

The last full week of October saw a group of Tucows staff attend the ICANN 63 conference in Barcelona. Our team participated in the ICANN policy development process, advocating for industry-wide policies and standards that will benefit our registrants and reseller partners.

Our summaries of the conference may not bring the sights and sounds — or delicious foods — of Barcelona to you, but they will help ensure you’re up-to-date on important developments in the ICANN community. ICANN has also released their own post-meeting policy report, so be sure to take a few minutes to check that out when you’re done with this post.

Resolving the conflicts between ICANN policy and the GDPR is a pressing challenge, and, as expected, the Expedited Policy Development Process (EPDP) team captured most of the attention during the week. Their work will also be our topic of focus for this post; our next will focus on the Unified Access Model.

Background on ICANN’s Temporary Specification and EPDP

We’ve written previously about ICANN’s Temporary Specification, the modifier to the 2013 Registrar Accreditation Agreement (RAA) which aims to close the gap between the GDPR and the RAA’s contractual requirements. The “Temp Spec” is valid only for one year, expiring in May 2019, at the end of which it must be replaced with a permanent policy. A year may sound like plenty of time to complete the necessary updates to ICANN’s contracts, but the typical turnaround time for a Policy Development Process is more like three to five years; the EPDP team has a very tight timeframe.

Why does this matter to us, our resellers, and domain owners?

ICANN has put together an Expedited Policy Development Process (“EPDP”) team, consisting of members from each of ICANN’s stakeholder groups, to work through the Temp Spec and confirm it (or some modified version of it) as a full Consensus Policy. This is crucially important for domain owners, as well as registrars, registries, and other industry participants, because the policy that emerges from the EPDP will define how people’s personal data are used for domain registrations moving forward. Domain owners may have new requirements for what information they need to provide when buying a domain, and how their data is shared or even published could depend on what they provide at the time of registration — more on that later. Registrars and registries will certainly have changes to make, but the full scope of these changes will only become clear as the EPDP team works through their open issues.

As an ICANN-accredited registrar, we’re in a potentially difficult situation. We have an obligation to adhere to ICANN’s Registrar Accreditation Agreement and Consensus Policies. However, if we don’t believe that the policy resulting from the EPDP work is fully compliant with the GDPR, we’d have to forgo some of our ICANN obligations in order to follow the law — similar to how we currently ignore a few of the Temp Spec’s requirements to ensure we’re compliant with the GDPR.

EPDP work at ICANN 63

At ICANN 63, there were several meetings during which the EPDP members went through a series of data elements workbooks to define purposes for each piece of registrant data that ICANN currently requires registrars to collect; this work began in virtual meetings in early October. Under the GDPR, there must be a legal basis (purpose) for each instance of data collection and processing, so the EPDP team needs to come to agreement about ICANN’s legal basis for requiring the data outlined in the Temp Spec. The workbooks help to accomplish this in a structured manner.

There were also presentations to the broader community, including open meetings where team members presented updates on the project and closed meetings where important groups at ICANN provided input towards the development of a final policy.

In these open presentations, the EPDP team updated the community at large about their work. They recapped the goal of establishing the list of data elements we work with, and the importance of following each element through its whole life (from collection to deletion) and analyzing the legal basis, or purpose, of everything that happens to it, which must be within ICANN’s defined mission. Each of those purposes was documented in a workbook, which the team then debates until the purpose can be accepted by everyone. As one team member described it, each workbook is like performing a Data Protection Impact Assessment for that specific data use, an exercise required under the GDPR for fully-compliant data processing. The team’s initial report is available on their wiki page in draft format, and when it’s updated to be a final (non-draft) version it will either include a policy recommendation itself or open questions that will then lead to a policy recommendation.

Debate over technical and administrative contacts

One of the most-debated topics in EPDP working meetings was the continued collection and publication of technical and administrative contacts for domains, which we have a significant interest in due to the litigation between EPAG (another Tucows-owned registrar) and ICANN.

Some EPDP members argue that this data should be collected. The domain owner may want to designate an alternate contact point, or a reseller may want to list themselves as the tech contact in order to help the registrant to more easily identify their service provider. And, as we know, ICANN has been pushing hard to maintain the requirement to collect the full pre-GPDR set of Whois data.

As they worked through the Purpose C Workbook, the admin contact was quickly agreed to be no longer necessary, and the EPDP team focused their debate on a proposal that registrars should be required to allow domain owners to designate a technical contact. The registrant could then decide whether they want to name an alternate contact point; if they do not, their own data would be copied to that other contact set.

Although this may appear to be a straightforward solution, it brings with it other issues. The purpose of having a tech contact is to provide an alternate point of contact, so we expect that most registrants who opt to do so would be supplying a third party’s info. In these cases, the registrar does not have a valid legal basis on which to process that data, as the alternate contact person would not be party to the registration contract, and the registrar has no clear way to obtain this contact’s specific, informed consent.

Ultimately, the EPDP team has tentatively agreed on a minimized tech contact data set, which the registrar would be required to allow, but would be optional for the registrant to provide. The specific data elements that would be included are yet to be determined, but will rely on the “legitimate interest” legal basis (Art. 6 1(f) of the GDPR), as they are not needed for performance of the contract, but a third party may have a legitimate interest in the data.

Beyond the not-so-simple collection of tech contact data, there is also debate about whether this information should be published. Right now, there is no consensus among the EPDP team as to whether the technical contact data must be provided (unredacted) in public Whois results. But if it is to be displayed, registrants will need to be made fully aware of that fact, because either the alternate contact info or their own registrant data would be published. And if an alternate contact’s data is to be published, finding a way to obtain consent from that individual is all the more important. Otherwise, we’d see situations where personal data is published unexpectedly, a huge privacy concern.

This is a complex situation, where different interests conflict, and there are no easy answers. We don’t see a good legal basis to require that the tech contact be published. If it is required, the registrant’s only choice is between publishing their own info or someone else’s — the “option” to provide a tech contact no longer seems optional.

Our reading of the legal requirement to provide data upon a showing of legitimate interest is that this legitimate interest must be demonstrated in each case. Anyone who has a legitimate interest to know the tech contact of a particular domain must be given that information, but that person doesn’t automatically get access to all other tech contacts, too. This is why we created a gated Whois: so that personal data can be provided when there is a legal basis but protected in situations where there isn’t.

Collecting different data in different situations

Another significant area of discussion among the EPDP members was to which registrants the GDPR protections should be applied. Should registrars differentiate by legal type, providing data protection to natural persons (i.e. actual people) but not to legal persons (i.e. corporations)? Then there’s the question of geographic location — should users local to the EU get GDPR protections while those outside the EU do not? We’ve shared our opinions on the location question already, and we have a similar position regarding the registrant type — we apply our GDPR protections uniformly to all registrants.

It was gratifying to hear our concerns echoed by other registrars and EPDP members. Differentiation by registrant type creates a lot of risk and uncertainty. How do we know if the registrant is a person or a corporation, should we simply rely on the presence or absence of data in the Registrant Organization field? If so, what happens when a natural person puts their own name in the Organization field, perhaps thinking that it must not be left blank, and their personal data is then published? Would we instead need to add a new “person type” field to the registration requirements, and depend on that to determine if the Whois data should be published or redacted? That sounds like a good solution on the surface, but it would be a significant change for our resellers to implement and would make the registration process more cumbersome and confusing for registrants.

Differentiating based on location is also more complicated than it might seem. If the address provided is in the EU but the IP geolocation shows North America, where do we consider them to be? Furthermore, this isn’t just about compliance with the GDPR and the rights of EU-locals. What about data handling laws from other jurisdictions, which may have similar requirements to the GDPR? Would we need to identify the various laws in each jurisdiction and apply them to the clients who we think come from those places?

Minimizing our data collection for all registrant types and keeping things consistent across the board naturally places us more in line with other laws and evolving standards. And, since we use processors in the EU, even if both we and the registrant are located outside the EU the GDPR’s requirements still apply to our data processing practices.

Even if the largest registrars have the resources to accommodate for all these intricacies in an accurate and automated manner, smaller businesses will likely struggle to implement such complex differentiation practices, and the liability risk for publishing personal data that should be redacted is significant enough to concern registrars of every size.

So far, the registrar representatives in the EPDP team have held firm and pushed for only optional differentiation, performed only with the consent of the data subject. In this case, we could continuing applying GDPR protections to all registrants by default, unless the registrant specifically requests otherwise. So, if things go as they have been, we think we’ll be able to accept the part of the policy that comes out of the EPDP.

Next steps for the EPDP

Like other PDPs, the EPDP will include a public comment period, which is the best time for all members of the ICANN community (including interested resellers and domain owners) to give their feedback on the EPDP team’s recommendations. There were questions around the ‘unified access model’ that ICANN has mentioned, (see our upcoming blog post on the topic), but the EPDP team continues (correctly) to focus on determining the legal basis for processing the data ICANN requires to be collected, which must be established before access to that data can be granted.

Work on a unified access model, “the definition and framework for reasonable access to registration data,” is part of what the EPDP is chartered to accomplish, but it must follow the completion of the EPDP’s Initial Report (mentioned above) and their eventual Final Report, which is due to be submitted to the GNSO Council by February 1, 2019. In the end, as Stephanie Perrin said in Barcelona, access itself is not a valid purpose under which to process data. Access may be provided, but the data is not collected specifically because someone might later want access to it.

Moving towards a future policy

Across the industry, there’s a shared commitment to the timely modification of policies and practices that place all ICANN requirements within the bounds of applicable law. In the first public forum of ICANN 63, our own CEO, Elliot Noss, talked about what he views as an encouraging level of collaboration. He said that at this ICANN meeting he’s seen more cooperation towards trying to resolve issues around Whois than he has seen on this issue in the year and a half that it’s been live, and perhaps on any issue this community has taken on. Elliot added that we have a unique opportunity here to demonstrate what the multistakeholder model can achieve.

The GDPR’s impact on our industry is not only about Whois data and the rules governing its disclosure. It’s also about ensuring that people maintain control over how their data is used, that when personal data is entrusted to a service provider it remains secure, and that the data subject’s rights are respected at all times throughout a domain name’s lifecycle. As a registrar, we are committed to these principles; as a community, we need to find a way to move forward with them in mind.

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.