This is the third post in our series on the ICANN 63 conference that was held in Barcelona in October 2018. You can also take a look back at our recap of the EPDP team’s work leading up to and during the conference, and our discussion of the Unified Access Model, which will eventually govern how access to Whois data is provided.

Although it may seem that the GDPR is the only thing that matters in the domain industry right now, it wasn’t the sole focus of ICANN 63, and we don’t want to lose sight of the other valuable work that came out of the conference.

Tucows is an active participant in the ICANN community: the Chair of the Registrar Stakeholder Group (RrSG) is our Analytics and Policy Director; some of our staff are members of the RDAP Pilot Project and PPSAI Working Group, and observers of the EPDP; and Tucows representatives collaborate with the RrSG’s Compliance and TechOps sub-teams to help develop and implement policies and processes that will benefit our customers and the community at large.

Privacy and Proxy Service Accreditation

One significant work track within the ICANN community is around accreditation for providers of Privacy and Proxy services. Right now, any registrar can offer a Privacy or Proxy (“P/P”) service — our version is called Whois Contact Privacy —  for domains registered with them. However, one of the requirements in the 2013 RAA is that if ICANN adopts a policy establishing accreditation for P/P services, registrars must comply with that policy and become accredited to continue providing those services. Such a policy does not yet exist, but work towards one has been underway ever since that 2013 RAA requirement came into effect.

Back in December 2015, the Privacy & Proxy Services Accreditation Issues (“PPSAI”) PDP Working Group provided policy recommendations for how P/P Accreditation could work. Their Final Report included requirements for providers of P/P services and defined eligibility standards for users of P/P services.

An Implementation Review Team (IRT) was then convened in January 2016, in order to “assist [ICANN Org.] staff in developing the implementation details for the Privacy and Proxy Services Accreditation Program, to ensure the implementation conforms to the intent of the Final Recommendations” (reference). In the two and a half years that followed, the PPSAI IRT worked hard to transform the recommendations into actual accreditation agreement language.

One significant part of their implementation work was focused on the question of when underlying registration data is to be revealed. Another was related to the cost of accreditation; even now there remains unresolved conflict between the IRT members and ICANN staff resulting from ICANN setting the P/P accreditation fees extremely high — on par with ICANN’s actual registrar accreditation fee — without being able to justify this price-point.

We said this post would be focused on the non-GDPR meetings at ICANN 63, but the effects of that data privacy regulation are so far-reaching, it’s hard to avoid. Because of the GDPR, the ICANN community is now working to standardize how access to non-public Whois data will be provided. As a result, the PPSAI IRT work will be “slowed down” until the EPDP is complete and the full landscape of the GDPR’s effects on our Registrar Accreditation Agreement obligations is understood.

This is important for our resellers and registrants, because once the IRT resumes regular work and the Privacy/Proxy Accreditation Agreement is finalized, we’ll need to sign on and pass the requirements along to our resellers. The significant area of concern here is the fees that we mentioned previously, and so when the IRT reconvenes we’ll be pushing to understand the justification for those fees as well as reduce them as much as possible.

RDAP

RDAP, the Registration Directory Access Protocol, is the technical successor to Whois. As we’ve mentioned previously, Tucows is part of the RDAP Pilot Working Group, which met several times at ICANN63 in Barcelona to supplement the team’s regular weekly online meetings.

Since we’ve participated in the pilot project and already implemented an RDAP service (Tiered Access) for Tucows domain registration data, we’re a step ahead of many other registrars, who still operate solely on the Whois protocol. Using RDAP as the technical back-end allows us to define user access options at a very granular level. We can restrict access by the number of domains a user can query in a given time period, the data elements returned in response, and even which specific domains can be queried. We can also set the specific duration for which a user’s account remains active. These options were not available on the old Whois protocol, which would always return the same results to any query.

Participating in the RDAP Pilot has given us the unique opportunity to provide input towards the RDAP “profile,” which tells registrars and registries what an RDAP domain lookup response needs to look like from a technical perspective. Put another way, the RDAP profile is the technical underpinning that supports ICANN’s registration data policy requirements. We’re working to make sure the final required profile is aligned with what we believe to be legally compliant and appropriate, in accordance with ICANN policy. The draft profile has been released and the comment period is now complete. Currently, the RDAP team is analyzing the comments and considering modifications to the final RDAP profile.  

The other big piece of work remaining for the RDAP team is determining how users will authenticate. There are two main options: OAuth, or using an SSL Certificate to identify the user, although more consideration may determine that the ability to choose one or the other depending on the use case might make the most sense. Whatever option the Working Group settles on, it’s important to keep in mind that this team will not determine who gets access to what data, and when — that’s not within the RDAP Working Group’s scope. Instead, this group is focused on creating the technical mechanisms to facilitate that access, which will need to coordinate with the work from the EPDP and whatever Unified Access Model is ultimately adopted.

Transfer Policy Changes

The inter-registrar transfer process has changed significantly since personal data has been redacted from the public Whois. This change is formalized within the Temp Spec, and some of the work done at ICANN63 focused on this process.

The TechOps team is working on a proposed new transfer process, which is quite similar to what registrars are already doing post-GDPR. The general goal is to make transfers happen immediately instead of after the current 5-day waiting period, while also protecting the registrant with heightened security requirements. There are some very interesting open questions, such as: Who creates and controls the auth code, should it be the registrar or the registry? Should an auth code have a TTL, essentially a “use-by date”, or should it remain valid indefinitely? In what other ways can the strength and security of an auth code be improved? The team is also considering what an effective emergency transfer reversal process might look like.

In Barcelona, the group present at the TechOps meeting split into smaller work groups, each taking a section of the proposed new process to examine at a very granular level. I led the group working on how the losing registrar might verify the request to get the auth code. The proposal we reviewed allowed a third party other than the registrant to obtain the auth code, such as (for example) when an account holder wants to get the auth code for a domain that’s in their account but registered in someone else’s name.

Our team added in requirements to ensure that the requestor is verified sufficiently to prevent unauthorized transfers; we also opted to keep the notification to the registrant mandatory, ensuring they aren’t surprised by the transfer request and have a chance to contact their registrar if the request was improper. Our group agreed that even when bolstered with increased requirements around verification and notification to reduce the risk of domain hijacking, the option to allow someone other than the registrant to obtain the auth code should only be included in formal policy if there is an expedited transfer reversal process to go with it.

There was a shared dedication among participants in this session to ensuring that any new transfer policy is balanced — it needs to be a streamlined process that’s easy for the registrant to use, while also being secure enough to protect against domain theft.

ICANN Org has now put out a Policy Status Report and has solicited public comments on the transfer policy. Members of the TechOps group have submitted a comment, which will be included in the ICANN Staff Report that is due out on February 1 2019. We don’t yet know exactly how the changes to the transfer policy will unfold, but there’s certainly work to be done on how domain transfers are handled, and we’ll be a part of that work, representing our clients’ best interests.

We’ll keep our resellers posted as the various policy work we’ve discussed today progresses. Overall, we’re pleased with the level of cooperation we’re seeing among all those involved, and encouraged that our registrant-centric approach is being echoed by others working in policy development.

This is the second post in our series on the ICANN 63 conference that was held in Barcelona in October 2018. Before diving in, we recommend taking a look at our recap of the EPDP team’s work leading up to and during the conference. You can watch this space for the final post in the series, which will cover ICANN work unrelated to the GDPR.

ICANN’s Temporary Specification requires registrars to provide a means for third parties (such as law enforcement agencies) to access a registrant’s personal data when there is a legitimate legal reason to do so. Enom met this requiring by introducing our Tiered Access directory, but we remain hopeful that an industry-wide solution will be developed.  

Over the last several months, the idea of a unified access model, or “UAM,” has been floating around the ICANN community. With a UAM, the process for accessing registration data would be standardized, with a defined set of eligible users and rules for what data they may obtain. This could be handled at the credentialing level, with registrars and registries required to respect the accreditations provided by a central governing body, or it could go as far as to require that all Whois data is held by and accessed through ICANN itself.

The advantage to a unified model is that parties with legitimate reasons to access registration data could do so in a streamlined manner, and registrars would (in theory) be able to trust the credentials of any user working within this model.

This contrasts the current reality: today, in order to access registration data for domains, third parties must each independently obtain credentials from the appropriate registrar or registry.  There is no central authority that we can trust to accredit eligible users, and no single source that a third party can work with to obtain registration data for domains registered with different providers.

Ongoing discussions

Two ICANN stakeholder groups, the Intellectual Property Constituency (IPC) and the Business Constituency (BC), have been pushing the EPDP team to develop a UAM, as they are concerned that the current decentralized situation is confusing to users, wastes time, and ultimately hinders their constituents’ ability to protect and assert their legal rights. For example, let’s use the case of a commercial litigator trying to send a cease and desist letter for an instance of trademark violation. The IPC and BC groups claim that the attorney needs to start by using the Whois record to determine who owns the offending domain name, but navigating and managing credentials for various registrar portals is a nuisance.

The wider ICANN Community acknowledges the benefits of a unified access model, but also raised significant concerns about implementation. Holding all registrant personal data in a central repository creates a single point of failure for data breaches — if someone gains access to that central source, they can access the contact data for every gTLD domain. This may also put ICANN themselves at risk of liability if such a breach were to occur.

Even if the data itself were decentralized, remaining held by each individual registrar, we’re left with concerns about having a single organization (such as ICANN) control accreditation. Registrars and registries are legally accountable for how and why the data they hold is shared, but in using a UAM, they’d be relying on the credentialing body to require demonstration of legal basis for accessing registration data (hopefully every time data is requested for a given domain, since the legal basis must be specific to each piece of data). And, as illustrated by examples like our own litigation with ICANN over the collection of technical contact data, what is acceptable as a legitimate legal basis can be somewhat subjective. If ICANN’s new contractual requirements require participation in a UAM, registrars and registries may be obligated to provide registration data to third parties in cases where they are not satisfied that a sufficient legal basis has been demonstrated. This is similar to the difficult balancing of more general GDPR requirements against ICANN contractual obligations — the registrar or registry is put in the difficult position of needing to choose between breaching their contract or potentially violating the law.

What happens next?

One of the core requirements in the EPDP team charter is to create a system for providing access to registration data. There are “gating questions” laid out in the charter, which will allow the team to “establish a baseline set of data that is collected for each domain name registration,” determine who should hold this data, and how it can be shared and processed. These gating questions must be answered before the EPDP team can consider the question of how third-party access to data will be granted. So until recently, discussions about the “how” had been pushed down the road when they came up during EPDP meetings. But now the EPDP Initial Report is out and, unfortunately, there is no formal consensus on the answers to the gating questions. In light of this, some members of the team have resumed pushing to discuss access as soon as possible, specifically before the Final Report is issued.

The EPDP team will be meeting in person at the end of January 2019, and we’re eagerly watching to see what happens there, as well as how they respond to the feedback that we and other members of the ICANN community provide in response to their Initial Report. And as this post went to “press,” ICANN announced the assembly of a ten-man “Technical Study Group on Access to Non-Public Registration Data” (Domain Incite has a solid summary of this development). It’s unclear how ICANN selected the members of this team or how their work will fit into or align with the current technical work and in-progress policy development process. Both of these unknowns are extremely worrying. This type of group is unprecedented and their remit and charter are currently opaque. We remain committed to the multi-stakeholder process and will continue to hold ICANN Org accountable to it.

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.

If you’re looking for a short and sweet summary of the GDPR (well, as short and sweet as a summary of any legal policy can be), this is the video for you! Presented by one of our resident GDPR experts, our Reseller webinar explains the fundamental concepts of the GDPR, why it matters to service providers, and offers some tips on how to prepare. Created with Resellers in mind, it also provides a concise overview of the reseller-impacting changes we’re making at Enom.

If you’re looking for more info on one of the topics that we touch on here, check out our GDPR blog posts. We also provide a handy Reseller FAQ on our GDPR resource page.

Note: The information contained in this video is non-exhaustive and should not be considered legal advice. You should consult with your lawyer to determine the impacts of the GDPR on your business.

Learn more about the GDPR:

GDPR Updates – Understand Enom’s approach to the policy

• The GDPR’s Right to Be Forgotten (Published on Jan. 18, 2018)
• Consent and the GDPR (Published on Dec. 21, 2017)
• How will the GDPR impact Whois? (Published on Nov. 9, 2017)
• The GDPR Overview (Published on Oct. 30, 2017)

GDPR Resources – View third-party resources on a specific GDPR topic

• Right-to-be-forgotten-related resources (Published on Feb. 1, 2018)
• Consent-related resources (Published on Jan. 4, 2018)
• Whois-related resources (Published on Dec. 7, 2017)
• GDPR basics & best practices resources (Published on Nov. 9, 2017)