GDPR Archives - Enom BlogEnom Blog |

Do Privacy Shield Rulings Impact Enom?

November 3, 2020

GDPR, Industry Insight, News, Uncategorized

Like

Views: 902
If you follow data privacy news, you may have heard that the EU-US Privacy Shield was invalidated recently, and as an Enom reseller, you might be wondering how that affects our services. TL;DR: It doesn’t.

We’ll get into the details of Privacy Shield, what it was used for, and what happens now that it’s been invalidated, but essentially, it let U.S.-based businesses lawfully transfer the personal data of EU individuals to the US by signing on to a series of privacy and data protection commitments.

Now that the EU-US Privacy Shield is no longer an option, companies transferring data will have to look into the other possibilities remaining to them under the GDPR. This is something you may already be looking at for your own business; for your Enom domain reseller services, we’ve got it covered.

What does the GDPR say about cross-border data transfer?

When we think about the GDPR and other data privacy laws, we tend to think they restrict or entirely prevent the use of personal data in the name of privacy. That’s not entirely incorrect—a big part of protecting personal data is limiting its use—but it’s also not the whole story. Another aim of the GDPR is to allow or even enable the transfer of personal data, as long as the data remains protected. When the data remains within the EU, it stays under the direct purview of the GDPR, and so ensuring that it remains protected is fairly straightforward, since the same rules apply both before and after the transfer. But what about when sending data out of the EU?

The GDPR offers three basic options for how to transfer data to a “third country” outside the EU.

Option 1: an “adequacy decision”

The European Commission can review a country’s data protection laws and determine that they offer an adequate level of protection for personal data. The Commission maintains a list of countries with adequacy status; Canada is included, but only for data protected under Canadian privacy law (which does not cover personal data being processed by the government! Oh, Canada—room for improvement!)

Option 2: appropriate safeguards

The second option for transferring data is referred to as “appropriate safeguards,” which includes the Standard Contractual Clauses, a pre-approved contract provided by the European Commission which can be appended to any agreement.

Option 3: derogations

Derogations are exceptions for certain circumstances, which should only be used rarely and as a last resort.

What was the EU-US Privacy Shield? What happened to it?

The EU-US Privacy Shield was a special type of adequacy decision, a framework set up by the European Commission and the US Department of Commerce which US-based businesses could commit to follow. It provided assurances related to data protection and data subject rights that are similar to what we are familiar with from the GDPR; once a business signed on to those commitments, they became legally binding and enforceable. These commitments included:
- providing transparent information to individuals about rights related to their data
- providing dispute resolution for individuals who brought complaints related to how their data is handled
- meeting purpose limitation and data retention obligations and requirements around accountability
Now that the EU-US Privacy Shield has been invalidated, businesses can no longer rely on it as an adequacy decision. Instead, any transfer of data from the EU into the US needs to be protected by some other method—either appropriate safeguards or derogations. We know that derogations are limited, generally to be used for one-time transfers or exceptional circumstances.

So where does that leave businesses who need to transfer data, including domain providers? They will have to add the proper assurances into their contracts, typically by use of standard contractual clauses—which is what we have done since 2018.

How does Enom handle cross-border data transfer without the Privacy Shield?

Lucky for us, it’s not a problem. We don’t have to make any changes to how we protect data when transferring it to the US because we don’t rely on the EU-US Privacy Shield framework.

The Privacy Shield framework was only available to American companies, which right away excludes two of Tucows’ (our parent company) main domain businesses. Enom is American, but OpenSRS is a Canadian company, and Ascio is European. Enom could have signed on to the Privacy Shield framework, but Tucows wanted a single approach to apply to all their businesses.

When we built out our processes for GDPR compliance, we adopted Standard Contractual Clauses provided by the European Commission to govern how we protect personal data.

The Standard Contractual Clauses have been incorporated into our contracts with our resellers, vendors, and other service providers via a Data Processing Addendum. This means that when domain registration data is sent to registries or data centers in the US these contractual commitments can be relied on to govern how the data is handled and to ensure that each data subject’s rights are always respected. Specifically, through the Data Processing Addendum, we commit to complying with GDPR obligations, including confidentiality and information security controls, cooperation with supervisory authorities, and appointing a Data Protection Officer. The Addendum also documents our obligations related to ongoing testing and review of security measures, the reasons we process data, and what third-party providers we work with. We closely watch for any updates to the Standard Contractual Clauses, as we want to remain current with any standards provided by the European Commission.

What do I need to do as a reseller?

For the data processed related to our services, absolutely nothing! You’ve already accepted our Reseller Agreement, so it’s all handled. If you want to learn more, though, you can look for yourself to see the Standard Contractual Clauses in our Data Processing Addendum (which is incorporated into our Reseller Agreement by reference), and you can compare them to the version published by the Commission.

You can also consult your own data protection counsel. This blog post is intended to be helpful and to share with you how we view data protection at Enom, but it is not intended as legal advice and should not be seen as a replacement for independent legal counsel.
Read More
Whois History and Updated Tiered Access Statistics

September 17, 2020

GDPR, Industry Insight

Like

Views: 1935
The Internet as we know it may be fairly new, but that short history doesn’t mean it’s not also filled with cycles and repetition.

Back in 2003, ICANN convened the Whois Task Force, intended to improve the ability of Whois services to contribute to the stability and security of the Internet while balancing the need to protect the privacy of the personal data involved. The Task Force’s goals of defining the purposes of Whois services overall—and of specific points of contact—as well as determining what data should be public and how to provide access as needed to nonpublic data, is remarkably similar to the work done in the EPDP, which was recently tasked with updating ICANN policy to adhere to the GDPR and other relevant privacy and data protection legislation while ensuring lawful disclosure of registration data where necessary.

In 2005, in that same Task Force, the RrSG proposed the creation of an “Operational Point of Contact” to help address a specific issue:

the amount of data that ICANN requires registrars to display in the Whois is facilitating all sorts of undesirable behaviours like renewal scams, data-mining, phishing, identity theft, and so on.

The RrSG proposal was intended to enable contact with the relevant person responsible for the domain while also maintaining the privacy of personal data—again, similar to what the EPDP would later attempt—but other groups on the Task Force focused instead on limiting data protection to only a small subset of domain owners in order to retain as much access as possible.

The Final Task Force Report on Whois Services, from 2007, gained support from the registrar and registry stakeholder groups (RrSG) and the non-commercial stakeholder group, but did not receive the business or intellectual property constituencies’ support. The policy development world seems stuck in a loop, with the EPDP’s final report likely fated to end identically, despite our hopes that the ICANN Community will be able to break that cycle.

Abusive use of publicly-available domain registration data, which RrSG members call out regularly, including in the early ‘00s and again in the EPDP, takes many different forms. Although it’s been some time since they’ve popped up in the news, those who follow the domain industry will know of Brandon Gray Internet Services, also known as NameJuice or Domain Registry of America. Their history of gathering Whois data to spam registrants with emails disguised as domain name renewal notices is well-documented¹, as is the damage done to domain owners and other Internet users. Typical complaints centered around registrants not knowing who their domain provider is or why a domain has been transferred away from their preferred registrar, paying for services that were unnecessary or nonexistent, and inability to manage domains after the transfer was completed. This began early in our Internet history, when domain owners were less experienced in managing services and had fewer data privacy and protection rights—or at least lower awareness around how to exercise those rights. In recent years, NameJuice has managed to stay under the radar, carefully crafting their solicitations to remain within the bounds of “marketing” and to avoid legal and compliance action.

Abusive use of domain registration data took the form of bulk scraping of publicly-available data from the Whois system; this data was then packaged and sold by enterprising cybercriminals to both security researchers with valid purpose and those seeking to use it for purely commercial purposes. Because security researchers benefited from this arrangement, they kept their heads in the sand about the accumulation of the data—one of the first instances of cybercrime tools for hire.

When unrestricted access to Whois data was terminated in May 2018, these data aggregators continued to sell previously-collected data. This mass processing of historic and ongoing registration data is illegal. Even data that is public may only be processed in a manner compliant with data protection regulations, including the GDPR; this means that the organization doing the processing must have a legal basis to do so and make sure the data subject (the registrant) is fully informed.

Scraping is specifically prohibited in registrars’ terms of service for Whois data, yet security researchers, commercial litigators, and other parties seem eager to use such illicitly-obtained personal data while continuing to fight for access to information that was obtained through cybercrime.

Tucows is not blameless; we should have more aggressively prosecuted these “WhoWas” service providers² while they were at the peak of their scraping and selling of this data, instead of merely implementing technical means to attempt to prevent their criminal activity (including rate limiting and requiring CAPTCHAs for lookups). While we did send cease and desist letters on multiple occasions, when these were ignored we did not take any additional action. We regret not having done so, especially as these companies continue to sell access to customers’ personal data to their complicit clients.

At this point, since registration data is mostly redacted unless and until the domain owner decides to make it public, bulk gathering up of registration data is a decreasing concern but is still very much on our radar.

This history should be kept in mind when reviewing this or any of our prior blog posts³ discussing the reasonable disclosure of previously-public Whois data. It is within the context of this profligate access to and abuse of Whois data that the flood of access requests registrars have received must be understood.

Responses to Denial Requests

Recently, the rhetoric from professional data requestors has shifted toward allegations of incorrect denials. Since we began tracking requests over two years ago, Tucows has denied only 241 requests, or 7% of all requests. We do not count abandoned requests as denials, as others do. Since May 2018, 51% of all requests are abandoned following our reasonable requests for additional information; this rate has dropped with each period.

Most often, requests ask for all data we have, including information that was never publicly available and information that relevant courts have deemed to be illegal to share. When we respond to a request for “Registrant, Admin, Tech-C, Billing, and all other domains owned by the registrant”, we consider that to be a request for “previously-public Whois data”. Billing information would require a subpoena and reverse Whois lookups have never been a function of the Whois database, despite the criminal services discussed above.

Of those 241 denials, vanishingly few of them have been disputed by the requestor—the handful of times it has happened, when our Legal team discussed the concern with the requestor, the end result was no disclosure. This tells us that our request review process is working properly, allowing us to filter out invalid requests and ensure that only those requestors who actually demonstrate a legitimate need for the data and commit to handling it with appropriate protections are able to obtain personal data.

More complaints have been about the data we disclose being inaccurate. We do not specifically track this, but this type of response has been coming in often enough that we are working on providing an easy way of reporting a Whois inaccuracy to us—rather than having to report to ICANN to then convey to us. This will be available from within our TACO system, since only people with access to non-public personal data would be able to indicate that the information may be incorrect; this will include the standard process of suspension of the domain in the event of no response from the registrant within the ICANN-mandated time frame.

Recent Tiered Access Statistics

The statistics provided below are for the period beginning 1 March 2020 and ending 31 August 2020 (Period 4).

Requests for Data Disclosure

In Period 4, Tucows received 527 disclosure requests; our overall total since we began tracking this in May 2018 is 3,400⁴.

75% of requests resulted in disclosure of domain registration data

This represents an increase of 13% compared to Period 3, which itself was double the rate of Period 2. As we discussed in the Period 3 report, this indicates improvement in the quality of the requests that we receive.

9% of requests were incomplete and, when we asked for additional information, the request was abandoned

This is a drop from the previous period and can likely be attributed to our ongoing outreach efforts and each requestor’s increasing familiarity with the process. We are beginning to see new requestors who already know to follow the RrSG-Recommended Minimum Required Information for a Whois Data Request. The part of the request most frequently missing is an assurance to only use the data for lawful purposes and to destroy the data after it is no longer needed.

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

This remains concerningly high. Unlike abandoned requests, where asking for additional information results in the requestor deciding not to follow up with the request, denied requests represent a failure of the requestor to adequately evaluate the legal implications of their request. As discussed in our Privacy and Lawful Access to Personal Data blog post, the primary reason that requests get denied is that no human reviewed the requests before they were submitted. The requests are for domains that may match all or part of a trademark but represent no threat to the mark for a variety of reasons. Our job is to balance the rights of the requestor—usually an intellectual property owner or its representative—against the data protection and privacy rights of the registrant. Where a review of the domain—even the content hosted on it—results in confirmation that there is no danger to the mark, the balance favors privacy.

4% of requests were for domains with an active Whois Privacy service, so only the publicly-available privacy service data were disclosed

While we are pleased to see this number reduced compared to the last period, we see some repeat requestors regularly asking for data they know to be behind one of our Whois Privacy services. This seems to be an attempt at “checking a legal box”: they are not asking for data they don’t know to be concealed, but rather, they are specifically not asking for the concealed data in the manner that they know will result in its disclosure, allowing them to indicate to their customers that they’ve gone through the process of requesting data but were “denied” without having to take the time and expense to file the actual paperwork that would result in its disclosure. We continue to reserve the right to blocklist requestors that regularly abuse our request process.

Requested vs. Disclosed

As mentioned above, the increase in disclosure rates for this reporting period shows improvement in the quality of the requests that we receive.

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 our Tiered Access platform:

The number of requests appears to have stabilized, concurrent with the increase in quality of requests, a positive trend indicative of the industry as a whole settling into the new data protection landscape.

Disclosure Request Outcomes, Compared

We are pleased to note that the rate of incomplete and abandoned requests continues to drop.

Duplicate Requests

Duplicate requests have decreased, which we like to see, but an interesting new type of duplicative request that we have begun to see is that the owner of the intellectual property is reaching out to request data disclosure months or even years after the same data were already disclosed to a party claiming to be a representative of that owner. This is not tracked and currently remains rare but is an interesting insight into the relationships between professional data aggregators and the intellectual property owners they purport to represent.

Categories of Requestors

As readers of this blog series will know, we have grouped requestors into four main categories for tracking purposes. 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; and
- other, which includes Certificate Authorities, resellers, private individuals, and sometimes even the registrants themselves.
At 84% of total requests, commercial litigation remains overwhelmingly the most frequent requestor type and, within that requestor type, professional data aggregators are the largest part. We are seeing a slight increase in Law Enforcement requests, up to 12% in Period 4.

We look forward to continuing to provide legally permissible access to non-public domain name registration data, including tracking the statistics for future review and insight into our industry.

¹ Further reading:
²DomainTools has the dubious distinction of being the most well-known of these PII-aggregators but is by no means the only. WhoisXMLAPI, who.is, and WHOXY also sell current and former personal data to their customers and, in some cases, operate an extortion scheme whereby a registrant can request exemption from this illegal sale.

³You can find data for Period 1 in Enom’s Tiered Access Directory: eight months later, for Period 2 in Tiered Access Data Disclosure Update, and for Period 3 in Privacy and Lawful Access to Personal Data at Tucows.

⁴“Total” numbers for a period may change after the period is reported because, although we have mostly successfully educated requestors about how to submit requests, we sometimes find requests that were misrouted—we deal with these when they are discovered but we count them as of the date of request, potentially changing numbers after we have reported them in a blog post. The impact is minor, so we do not feel the need to update prior posts but felt it prudent to indicate why the numbers might be slightly different if you’re comparing across posts.
Read More
Privacy and Lawful Access to Personal Data at Tucows

March 13, 2020

GDPR, Industry Insight

Like

Views: 1367
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.
Read More
Highlights from ICANN66 Montreal

November 25, 2019

GDPR, Industry Insight, News

Like

Views: 3004
Montreal in November is not as bad as it sounds; the weather is crisp and clear, the snow isn’t too deep yet, and it doesn’t get dark until a reasonable time in the evening. It’s still not my top choice for a travel destination at this time of year, but the ICANN conference definitely made it all worthwhile. For those who couldn’t make it out to Montreal, here are the highlights.

How best to handle DNS abuse

While changes necessitated by the GDPR were a hot topic at ICANN66, we were pleased to see a lot of discussion about DNS Abuse and how best to address it. Front and centre in these conversations was the “Framework to Address Abuse”, a document signed by Tucows and other major registrars and registries hoping to standardize our industry’s approach to DNS Abuse. In that Framework, Tucows and our co-signatories proposed a definition of DNS Abuse that we believe is correct and appropriately limited, while also describing a set of non-DNS Abuse categories on which we would, nonetheless, take action. The plenary session on DNS Abuse was the most well-attended session at any ICANN meeting so far.

It’s impossible to summarize such a broad topic and intense discussion (you can, however, watch the whole thing online!), but here are the key takeaways:
- DNS Abuse is a topic that the community is working to address
- There’s concern around who should respond to Abuse and how to do so in a proportional manner
- There are already tools in place that ICANN Compliance could use to help in this effort
We’re committed to working within our space to address Abuse, and we look forward to collaborating with other groups in the domain name industry as this work continues.

You guessed it… the GDPR

The impact of the GDPR and other data privacy regulations on the Domain Name System remained a primary focus for ICANN66. Both the Expedited Policy Development Process (EPDP) team (the group that works to determine what the permanent replacement to ICANN’s Temp Spec must include and address) and the Implementation Review Team (the group responsible for transforming the EPDP’s Phase 1 recommendations into Consensus Policy) made good use of the opportunity for face-to-face meetings.

Work from the EPDP team

The EPDP team is in Phase 2 of their work, developing a System for Standardized Access and Disclosure (SSAD) by which third-parties can obtain non-public gTLD registration data. It’s a large project, and the work is divided up into a series of “building blocks,” each examining different aspects of this system, such as accreditation (for third-parties in search of data), data retention requirements, and auditing.

We think this is a useful approach, but some core questions remain unanswered, including the fundamental one: who is the entity making the disclosure decision?

When a third-party requests access to registration data, will that be relayed to the relevant registrar or registry operator, or will the SSAD operator make that determination? Could a standalone SSAD operator have all the relevant information needed to appropriately decide if the request should be fulfilled or denied? Could a registrar or registry operator provide data to be disclosed via the SSAD while remaining compliant with data protection laws? As the building blocks get finalized these underlying open issues are brought to the forefront, and we’re getting closer to the point where the EPDP can’t continue its work without these answers.

To that end, ICANN has set up a “Strawberry Team,” a group of ICANN staff working in parallel to the EPDP team. Just before ICANN66, they sent a proposed model for registration data disclosure to the European Data Protection Board, asking for feedback.

There’s a general sense of frustration among EPDP members around the lack of communication about this; the team had asked ICANN to share any proposals or models with them before sending it out to groups like the Data Protection Board, and that didn’t happen here. There’s also concern that this work should be happening within the multistakeholder model rather than alongside it.

Ultimately, if the European Data Protection Board (EDPB) provides advice, that can only be a good thing. However, as we wrote following ICANN64 in Kobe, it’s important to remember that any statement by the EDPB that the model is acceptable could easily be retracted in the future; it’s not a guarantee of legality. Instead, decisions around how to update ICANN contracts and Consensus Policies should be made by the ICANN Community, who are able to take relevant local laws and regulations into account while considering the policies our industry needs.

Work from the Implementation Review Team

Alongside the EPDP’s Phase 2 work, the Implementation Review Team (IRT) is in the midst of transforming the EPDP’s Phase 1 Recommendations into a “gTLD Registration Data Policy.” Once complete, this gTLD Registration Data Policy will replace the Temp Spec and permanently modify ICANN’s Registrar Accreditation Agreement (as well as other ICANN policies) to bring them into compliance with the GDPR and other data protection laws.

This new policy will cover:
- data collection
- transfer of data from registrar to registry
- transfer of data to data escrow provider
- publication of registration data
- logging
- data retention requirements
This gTLD Registration Data Policy will also include a section on “Reasonable Requests for Lawful Disclosure of Non-Public Registration Data.” You may be wondering how this ties into the EPDP team’s Phase 2 work developing a System for Standardized Access and Disclosure (SSAD): would they not go hand in hand? The difference is that the IRT’s Policy will govern how requests for data are handled when made directly to individual registrars or registry operators, while the SSAD is intended to be a standalone unified system with a single point of contact and operator.

There is not yet an expected date for when the new gTLD Registration Data Policy will become effective, but we will keep you posted as things develop.

Tucows’ involvement in the ICANN Community

The Tucows team also presented on panels and attended sessions on a variety of other topics. We discussed expectations for RDAP, the successor to the Whois protocol, based on outcomes of the EPDP and IRT; we worked with the joint registrar and registry “TechOps” team on a set of topics, including best practices for transfer authorization codes.

ICANN meetings are a unique combination of exhausting and exhilarating. Participants from all around the world come together to work on specific topics, with hundreds of sessions to choose from, and the public forums are always fascinating. We continue to work hard to make sure that the concerns of our customers and their registrants are represented at this important venue.
Read More
Tiered Access Data Disclosure Update

October 30, 2019

GDPR, Industry Insight

Like

Views: 3252
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.
Read More