
Ask Jake
Project Jake is named after Elizabeth “Jake” Feinler.
Elizabeth “Jake” Feinler was born in 1931 in Wheeling, West Virginia, and has left an indelible mark on the development of the Internet and online information. She received a BS in Chemistry from West Liberty University and later went on to do graduate work at Purdue. In 1960, Feinler joined the Stanford Research Institute (now SRI) in Menlo Park, California, as an information scientist. At the time, Doug Engelbart’s Augmentation Research Center (ARC) was pioneering many of the features of modern computing with his interactive, hyperlinked, mouse-driven oNLine System (NLS). The possibility of using these tools to deliver information drew Feinler to join ARC in 1972. In 1973, Feinler became the principal investigator for the ARPANET Network Information Center and later the Defense Data Network Network Information Center. Under her leadership, the NICs developed an online query system for users, published important network documents like the [Internet?] Protocol Handbook, managed the site liaisons that kept users across the networks informed, and ran the first Internet Naming Authority—the technical function that allows host computers to be added to and referenced on the network.
In that role, Feinler’s team assisted in the transition of the internet to the Domain Name System (DNS). She was also instrumental in choosing the generic top-level domain names (TLDs) of .com, .edu, .gov, .mil, .org, and .net. Both the DNS and the generic TLDs are still in use today. After leaving SRI, she helped to bring the NASA Science Internet (NSI) NIC onto the internet at NASA Ames.
Feinler was a mentor and advocate for women in technology. At a time when the field was overwhelmingly male, she served as a role model and inspiration for aspiring female technologists. Throughout her career, she received numerous accolades and awards for her work. In 2012, she was inducted into the Internet Hall of Fame and in 2013 received the Jon Postel Internet Service Award in recognition of her role in shaping the internet’s development. She was also inducted into the Women In Technology International (WITI) hall of fame.
After retirement, Feinler turned her interest to Internet history, or as she claimed, “While everyone else is going forward, I am going backward.” She donated her extensive networking archives to the Computer History Museum and wrote a comprehensive finding aid to this keystone collection for future researchers. Recently, she and Internet pioneer John Vittal coauthored an extensive bibliographic timeline on electronic mail, also at CHM. Feinler has left an indelible legacy as an inspiring trailblazer in the field of computer networking.
When you register a domain, you’re entering a maze of over 100 data fields. This information, initially meant for basic administrative tasks, has grown into a trove of data that can be misused. The old WHOIS protocol used to manage this, but it failed to keep up with evolving privacy laws, complex business models, and conflicting regulations. The result? An outdated system where personal data is exposed or hidden without proper control, leading to misuse and unnecessary headaches for everyone involved.
The collection and disclosure of DNS registration data evolved in an unplanned fashion over several decades. The disclosure function was implemented via the Whois protocol.
Whois data was used by a wide variety of requestors for an equally wide variety of purposes. Some of these purposes were troublesome to registrants, e.g. spam, harassment, fraud attempts, etc. In response, many registrants submit fake contact data or used privacy or proxy services to cloak their contact data. The resulting system served all parties poorly.
In the last several years, several jurisdictions have imposed general privacy regulations. The EU’s General Data Protection Regulation (GDPR) is the most visible and the most stringent of these. In response, most DNS Registrars have severely limited the data they make available publicly, and each Registrar has established its own procedures for evaluating requests for non-public data.
Although the current situation has improved privacy protection for Registrants, it is far from satisfactory. The broad emphasis on privacy has enabled bad actors to hide their identity. Further, the current system is expensive for Registrars and Registries, and it is chaotic and often ineffective for Requestors with legitimate needs for registration data.
In Project Jake we have been developing a framework designed to help all parties develop and implement policies which protect Registrant privacy and meets the needs of the Registrars, Registries and Requestors with legitimate needs.
The guiding principles behind this work are:
- Separation of mechanism from policy
- Support for multiple policies
- Clarity and predictability of Policies
- Efficiency
Whether or not you’ve ever registered a domain, the rules around this data impact you. They shape the privacy, security, and accountability of the entire internet. Today’s processes for accessing domain registration data are slow, inconsistent, and often frustrating. We need a system that’s reliable, fair, and cost-effective. Project Jake steps in where previous attempts have fallen short.
The main hurdle is nnbalancing. the needs of three key groups:
1. Registrants: The people or companies registering domains.
2. Requestors: Those needing access to registration data (e.g., law enforcement, researchers, anti abuse workers).
3. Data Holders: The organizations that store this data, such as registrars, registries, and privacy service providers.
________________________________________
The Data Holders’ Dilemma
Data Holders must find a balance among their many responsibilities. They handle DNS records that are public while guarding private data for their clients. When they receive a data request, they need to figure out if it’s legitimate, legal, and safe to fulfill it—while avoiding liability. They also want to be reassured that, if they do share the data, the Requestor handles it responsibly.
________________________________________
The Requestors’ Frustrations
Many Requestors have an important role in holding people accountable online, but they often run into dead ends. They face long, complex processes, only to be denied access to data because of privacy protections, proxy services, or inaccuracies. This creates a lot of frustration when their needs are legitimate.
________________________________________
Registrants expect their privacy and security to be respected. When their data is shared, they deserve to know why, how, with whom, and under what conditions. Special protections should be in place for vulnerable groups.
________________________________________
Understanding the Core Challenge
The main hurdle is aligning the needs of three key groups:
1. Registrants: The people or companies registering domains.
2. Requestors: Those needing access to registration data (e.g., law enforcement, researchers).
3. Data Holders: The organizations that store this data, such as registrars, registries, and privacy service providers.
________________________________________
The Data Holders’ Dilemma
Data Holders must balance many responsibilities. They handle DNS records that are public while guarding private data for their clients. When they receive a data request, they need to figure out if it’s legitimate, legal, and safe to fulfill it—while avoiding liability. They also must ensure that, if they do share the data, the Requestor handles it responsibly.
________________________________________
The Requestors’ Frustrations
Requestors have an important role in holding people accountable online, but they often run into dead ends. They face long, complex processes, only to be denied access to data because of privacy protections, proxy services, or inaccuracies. This creates a lot of frustration when their needs are legitimate.
________________________________________
Registrants expect their privacy and security to be respected. When their data is shared, they deserve to know why, how, and under what conditions. Special protections should be in place for vulnerable groups.
________________________________________
The collection and disclosure of DNS registration data evolved in an unplanned fashion over several decades. The disclosure function was implemented via the Whois protocol.
Whois data was used by a wide variety of requestors for an equally wide variety of purposes. Some of these purposes were troublesome to registrants, e.g. spam, harassment, fraud attempts, etc. In response, many registrants submit fake contact data or used privacy or proxy services to cloak their contact data. The resulting system served all parties poorly.
In the last several years, several jurisdictions have imposed general privacy regulations. The EU’s General Data Protection Regulation (GDPR) is the most visible and the most stringent of these. In response, most DNS Registrars have severely limited the data they make available publicly, and each Registrar has established its own procedures for evaluating requests for non-public data.
Although the current situation has improved privacy protection for Registrants, it is far from satisfactory. The broad emphasis on privacy has enabled bad actors to hide their identity. Further, the current system is expensive for Registrars and Registries, and it is chaotic and often ineffective for Requestors with legitimate needs for registration data.
In Project Jake we have been developing a framework designed to help all parties develop and implement policies which protect Registrant privacy and meets the needs of the Registrars, Registries and Requestors with legitimate needs.
The guiding principles behind this work are:
- Separation of mechanism from policy
- Support for multiple policies
- Clarity and predictability of Policies
- Efficiency
Project Jake goal is to bring stakeholders together to rethink how domain registration data is managed. Guided by principles of transparency, collaboration, and open standards, Project Jake offers a new foundation for data collection and disclosure. Here’s how Project Jake envisions his goals can be reached:
- Standardized Data and Sensitivity Levels: We classify domain registration data into standardized elements. Some data is public (low sensitivity), while other data is personal and protected (high sensitivity).
- Clear Disclosure Levels: Who you are and why you need the data determines what you can access. For example, a researcher might have low access, while law enforcement can get high-level data for serious investigations.
- Verified Identities: The identity of a Requestor should be verified through trusted identity providers, who issue tokens for anonymous but verified requests.
- Responsible Data Handling: Requestors must show they can protect the data they receive, avoiding misuse and unauthorized disclosure.
- Accuracy and Validation: The accuracy of registration data needs to be validated.
Project Jake presents a flexible system that adapts to different laws and local policies. Stakeholders organize into groups—like law enforcement agencies, registries, and consumer protection bodies—who work together on common standards and automated processes. The system is designed to be transparent, efficient, and scalable.
After extensive research and planning, Project Jake is entering its implementation phase. We’re focused on setting up working groups, establishing common standards, and supporting the development of tools that make this system a reality.
Not every player in this ecosystem has the same rules. Our model allows each party—like Registrars and Registries—to set ranges of acceptable values for things like data collection and sensitivity. This flexibility ensures that different policies can coexist while still working together.
- Research and Insights: Project Jake’s research findings on data privacy, protection, and governance likely inform ICANN’s policy discussions, especially in balancing privacy concerns with the need for transparency in domain ownership.
- Policy Influence: If Project Jake involves studying the impact of regulations like GDPR on domain data policies, its insights could directly impact how ICANN approaches policy changes, including the design and implementation of frameworks like the Registration Data Access Protocol (RDAP).
- Stakeholder Collaboration: Both Project Jake and ICANN involve multi-stakeholder approaches, bringing together researchers, policymakers, and industry players. The outputs of Project Jake could be used by stakeholders within ICANN to advocate for specific policy positions.
In summary, the relationship lies in the intersection of research (Project Jake) and policy-making (ICANN’s PDP), particularly concerning the regulation of domain registration data in an era of increasing privacy concerns.
Toggle Content