{'fraction_non_alphanumeric': 0.025875804207087107, 'fraction_numerical': 0.007563076054292802, 'mean_word_length': 5.327718223583461, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 6, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
The Problem of Zombie Datasets: A Framework For Deprecating Datasets

What happens when a machine learning dataset is deprecated for legal, ethical, or technical reasons, but continues to be widely used? In this paper, we examine the public afterlives of several prominent deprecated or redacted datasets, including ImageNet, 80 Million Tiny Images, MS-Celeb-1M, Duke MTMC, Brainwash, and HRT Transgender, in order to inform a framework for more consistent, ethical, and accountable dataset deprecation. Building on prior research [27, 35, 61], we find that there is a lack of consistency, transparency, and centralized sourcing of information on the deprecation of datasets, and as such, these datasets and their derivatives continue to be cited in papers and circulate online. These datasets that never die – which we term “zombie datasets” – continue to inform the design of production-level systems, causing technical, legal, and ethical challenges; in so doing, they risk perpetuating the harms that prompted their supposed withdrawal, including concerns around bias, discrimination, and privacy. Based on this analysis, we propose a Dataset Deprecation Framework that includes considerations of risk, mitigation of impact, appeal mechanisms, timeline, post-deprecation protocol, and publication checks that can be adapted and implemented by the machine learning community. Drawing on work on datasheets and checklists [29, 48], we further offer two sample dataset deprecation sheets and propose a centralized repository that tracks which datasets have been deprecated and could be incorporated into the publication protocols of venues like NeurIPS.


Introduction
A growing area of scholarship in the machine learning (ML) community shows that training datasets can contain data and labels that violate privacy, perpetuate bias, and intensify discrimination [27,35,62,47]. One common response to a dataset being found to be problematic has been to deprecate and officially remove it. For example, in mid-2019, Microsoft removed a widely-used training set of 10 million images of faces of public figures, known as MS-Celeb-1M. Published in 2016, the dataset was described at the time as the largest publicly available facial recognition dataset in the world [56]. But the dataset came under sustained criticism after an investigation revealed that it contained many images of private individuals whose pictures were included without their consent [35]. Microsoft took down the dataset, stating that it was removed "because the research challenge is over" [55]. This is just one prominent example of datasets that have been officially removed for legal, ethical, and technical reasons, including MIT's 80 Million Tiny Images, Duke University's MTMC, and Stanford's Brainwash. Others, such as ImageNet, have been severely redacted for similar reasons [83].
However, while these datasets have been officially deprecated, they continue to be used. For example, MS-Celeb-1M is hosted on multiple services. As we discuss in this paper, even after formal withdrawal, MS-Celeb-1M is still hosted at Academic Torrents. Similarly Tiny Images, Duke MTMC, and Brainwash are all circulating and continue to be cited in papers ( [15,86,45,46]). The result of continued circulation is that harms that researchers have highlighted -whether legal, technical, or ethical in nature -are perpetuated, an issue that we address at length in Section 3.
We term this problem of datasets that continue to circulate after deprecation "zombie datasets," though it has also been identified as "runaway data" [35,61]. Our choice of terminology relates to the phrase "zombie predictions" [42], which was coined to discuss the ongoing usage of pre-trial risk assessment models trained on pre-bail reform data after the implementation of reforms; the word "zombie" here is intended to convey the continued availability of a dataset after deprecation, as well as its propensity to infect additional datasets and models. Despite the serious concerns of dataset creators, the ML community, and often the wider public, zombie datasets continue to inform the design of industry software and services that can impact large populations. Zombie datasets can arise in multiple ways: sometimes a dataset is officially removed, but continues to circulate on what we call the gray data market on sites such as Academic Torrents. In other cases, a set has been remediated so that some of the most toxic images or labels have been removed, as is the case with ImageNet [28,83], but the previous, unredacted dataset still circulates, is cited in academic papers, and is used in industry applications. In some cases, multiple versions and derivatives of a dataset live on after deprecation and continue to do harm, despite their creators' intentions.
It is important to understand this largely unstudied dataset end-of-life in the ML model lifecycle. Therefore, we first outline how zombie datasets circulate and the implications of their continued use. We then propose a Dataset Deprecation Framework that includes a rationale for deprecation, an execution plan, what mechanisms of appeal are available, and what timelines are followed. Further, we suggest that researchers be able to continue to access deprecated datasets in order to study and understand the biases and errors of production systems; we assess how researchers could request such permissions in a carefully controlled manner. Finally, we propose a central repository that could be maintained by an ML community authority, like AAAI, ACM or NeurIPS, that could inform the research community about datasets that have been deprecated and explain why they should not be used.

Problem Outline
In this section we survey why and how several major computer vision datasets have been deprecated or remediated, to illustrate how datasets continue to live on past removal: ImageNet, Tiny Images, MS-Celeb-1M, Duke MTMC, Brainwash, VGGFace2, MegaFace, and HRT Transgender. Understanding how and why these datasets were deprecated shows the power of zombie datasets and the need for the Dataset Deprecation Framework presented later in this paper. Some of these datasets have recently been discussed in Peng et al. [61] as popular datasets within the machine learning community that have received significant public attention and fostered controversy. Datasets like these are both highly visible and powerfully illustrate some of the challenges of dataset deprecation. In each of these cases, deprecation or remediation was precipitated by external investigations finding the dataset to be problematic in some way, whether for containing offensive and harmful content or for violating expectations around privacy. However, the process of deprecation varied greatly amongst the datasets, with little consistency in what triggered their deprecation, how their removals were publicized, and how much of the technical details of deprecation were made transparent. We concur with Peng et al. that many of these deprecations show a "lack of specificity and clarity" as to why and how datasets are retracted and addressing that gap is a focus for this paper (p. 5) [61]. For example, while disclosing the specific reasons for deprecation may help downstream users address problems and concerns, it may also be unrealistic to expect such detail where disclosure exposes the creator to legal risks.
In Table 1, we summarize the reasons given for deprecation of each of these datasets, as well as what was done with the dataset by its creators.

External critique
Reason given for deprecation Actions taken

ImageNet
Excavating AI project publishes a critique of the classificatory logics of computer vision datasets, with a focus on ImageNet's problematic "Person" categories [27]; also releases the ImageNet Roulette app so people can test how their images would be labelled by a model trained on the "Person" subtree [49].
Yang et al. [83] found that of 2,832 subcategories in "Person" subtree, 1,593 are "potentially offensive." Of the remaining 1,239 categories, "only 158 are visual" and should be filtered for training. 2021 research team update attributes ongoing problems to object recognition transitioning to "real-world systems" [83].

Tiny Images
Prabhu and Birhane [62] publish critique of Tiny Images showing it contains harmful slurs and many offensive images.
Dataset authors formally withdraw the dataset, saying images are too small to identify and remove offensive content and that the dataset's biased and derogatory content violate the values and culture of inclusivity they seek to cultivate [79].
Dataset taken offline and formally withdrawn via a letter published on dataset's webpage [79]. The authors ask the community to refrain from using Tiny Images in future and to delete any downloaded copies.

MS-Celeb -1M
MegaPixels investigation by Adam Harvey and Jules LaPlace [34,56] reveals MS-Celeb-1M uses images of "celebrities" that are actually private figures and was scraped from the Internet without consent.
No explanation for deprecation is provided on dataset website. Microsoft tells Financial Times "the research challenge is over" [55].
Dataset deleted from website by Microsoft; the website simply says "testing" and "HI ALL." The Microsoft Challenge page has not been updated to mention that dataset has been deprecated [65].

Duke MTMC
MegaPixels investigation [34,56] spurs Duke University's Institutional Review Board investigation of the dataset. This reveals that researchers violated IRB requirements that the study be conducted indoors and data only accessible on request [73].
No explanation for deprecation is provided on dataset website. Clarification/apology published by lead author in Duke student newspaper The Chronicle [78].
Dataset deleted by authors; website cannot be reached.
Website says "This data was removed from access at the request of the depositor." Dataset deleted from Stanford Digital Repository.

VGGFace2 N/A
No reason specified. Github repo maintainer comment suggests liability considerations from the host university.
Website URL no longer works.

MegaFace
A New York Times investigation suggests use of Flickr images violates Illinois Biometric Information Privacy Act [36].
The dataset website states that the challenge's goals have been met and ongoing maintenance would be an administrative burden, so the dataset was decommissioned [80].
Statement on website says dataset has been decommissioned and is no longer being distributed.

HRT Transgender
Article on dataset in The Verge draws attention to YouTube data scraping issues and lack of YouTube video creator consent in data collection [82].
Lead researcher tells The Verge that the dataset only contained links to videos, not the videos themselves; it was never shared commercially, and he stopped giving access to it three years prior [82].
Dataset not linked to on research group's website, and the URL returns a 404 error. Lack of central directory of deprecated datasets. Our analysis has focused on the deprecation of highly visible and controversial datasets, but not all deprecated datasets receive public scrutiny. Projects such as the popular repository Papers With Code, and Exposing.ai (the successor to the MegaPixels project by Adam Harvey and Jules LaPlace [35]) offer a useful starting point for tracking datasets that have already been investigated and deprecated, but there remains a need for a centralized resource that aggregates the deprecation of datasets that the ML community has used, regardless of the dataset's role in a public controversy. To understand which datasets they should use -and why -researchers need to be able to see problematic datasets in one place.
No systematic re-evaluation of related datasets. Critical accounts [27,83,62] have highlighted the challenges of image datasets that rely on WordNet taxonomy, which contains many offensive and harmful categories. Yet while ImageNet and Tiny Images have been remediated or withdrawn, other datasets based on them, such as CIFAR-10 and -100 and Tencent ML-Images remain active. Meanwhile, some datasets sourced from Flickr, such as MegaFace, may potentially violate Creative Commons licensing and run afoul of privacy laws. But such datasets are only audited on an ad hoc basis. The decision to deprecate or not is left at the discretion of dataset creators and their institutions in ways that may perpetuate harms. And when a dataset is deprecated, copies and derivatives often persist, as Peng et al. [61] demonstrate.
Inconsistent public notice and transparency regarding rationale for withdrawal. While Ima-geNet, Tiny Images, and MegaFace provide some public notice of deprecation and remediation on their websites, MS-Celeb-1M, Duke MTMC, Brainwash, and HRT Transgender provide no explanation on their home pages for their removal; the datasets have simply vanished from their websites. The MegaFace website offers that the dataset was decommissioned due to its goals being met and cites the administrative burden of maintenance-though this explanation appears to have been given shortly after a New York Times investigation suggested that the dataset may violate privacy laws [36]. Meanwhile, a lead author of Duke MTMC published a clarification and apology in Duke's student newspaper The Chronicle explaining that the dataset was not collected for the purposes of recognizing individuals but had violated IRB protocols [78]. No explanation at all is provided by the Stanford Digital Repository for the retraction of Brainwash, beyond saying that the data was deleted at an author's request. And VGGFace2 appears to have been temporarily taken offline, with little indication of why; a comment buried within its Github Issues page suggests that the dataset was removed due to concerns from the host university's legal team.
Lack of explicit instruction not to use deprecated datasets. Tiny Images' authors offer guidance to researchers asking them not to use the dataset in future and to delete downloaded versions. No such public guidance is provided by the authors of other partially or fully deprecated datasets. This makes it difficult for ML researchers to know if or why they should stop using a dataset in their work.
Continued circulation of deprecated datasets. Despite the removal of a dataset from its original hosting location, deprecated datasets continue to circulate, are used to train models, and are cited in ML papers. Sometimes this research is published years after the deprecation. For example, MS-Celeb-1M's harms and deprecated status were well-documented in popular press accounts (e.g. [14,55,60]) when it was removed in April 2019. It is also noted as deprecated on Papers With Code, a retraction that proliferates across other nodes for finding datasets, like Google Dataset Search. Yet, as Peng et al. have noted, the underlying data for MS-Celeb-1M were used hundreds of times in published papers since its 2019 retraction [61]. Today, it continues to circulate on sites like Academic Torrents [51,61]. In fact, the dataset was uploaded there less than two months after its retraction by Microsoft [51]. MS-Celeb-1M is not the only deprecated dataset that follows this post hoc trajectory. Duke MTMC, Brainwash, and Tiny Images have all been deprecated but are still widely circulating, used, and cited (e.g [15,86,45,46]).
We approach the problem of zombie datasets with the good faith understanding that researchers continue to use these resources not out of malevolent intent but instead from limited discussion and oversight within the ML research community, making it extremely difficult to know which datasets have been deprecated and why. The use of zombie datasets is further sustained by the lack of documentation about when, why, and how a dataset (or parts thereof) was removed. MS-Celeb-1M is a case in point. Following the aforementioned privacy concerns, Microsoft told the Financial Times that the dataset had been removed not because of privacy concerns, but because the "research challenge is over" [55]. No explanation is given on the page that originally hosted the data [66]. There is little incentive for researchers to stop using datasets if there is little information offered about why they are deprecated. Poor documentation practices around dataset deprecation, along with their continued circulation and use within ML research communities, can perpetuate the harms that the deprecation often sought to address.
3 Why are zombie datasets a problem?
Zombie datasets are problematic in many ways. In the section below, we will address the technical, legal, ethical and organizational issues that arise from their usage, since we consider these issues as the most relevant and pressing.

Technical Issues
Different technical issues may arise when datasets fail to be deprecated appropriately, and at the appropriate time. Because datasets are static (i.e. they represent a sample of the world that is frozen in time at the moment the dataset is created) and the world surrounding them changes, datasets can quickly become unrepresentative of the world they were meant to describe. This can be caused by changes in the world being modeled-e.g., a word corpus like WordNet which originated in the 1980s does not include "iPhone" or "Internet" but does include words like "washwoman" and "chimneysweep". A neural language model trained on a dataset dating from 1988 or 2018 can therefore fail to perform adequately in tasks ranging from question answering to dialogue because the model is built on data that no longer represents current language. Several authors have studied the problems of semantic drift in Wordnet and other training sets [5,68,54] and proposed ways to address and mitigate it from a technical perspective [32,43], but these approaches are rarely incorporated in modern NLP models, which can be trained on large corpora reflecting decades of language data, including books from previous centuries [6].
Furthermore, while it is impractical to require that datasets evolve at the same pace as social realities (of which there are many), because data is so central to training ML models, it is important to trace the appropriateness and representativeness of social phenomena. It is important to detect failures of representation and deprecate datasets accordingly. For instance, several approaches have been proposed in recent years for 'machine unlearning', allowing to erase data from already trained models [19,9,12,76]. However, recent results have also shown that: 1) it is possible to reveal details from an initial dataset even when a model was subsequently retrained on a redacted version [85]; 2) adversarial querying of a trained language model can recover individual training examples [20] and 3) that "radioactive" data tracing is possible via imperceptible changes that make it possible to find the origins of data points [71]. While the broader impacts of deprecation are to be determined, researchers are often underestimating the influence of individual data points and overestimating the effect of fine-tuning on pretrained models. We see this as a further technical reason to support proper dataset documentation and deprecation, to avoid both malicious and inadvertent usage of data that is no longer relevant or is actively harmful.

Legal Issues
For most dataset creators, providers, and downstream users, there are also important legal considerations when assessing the appropriateness of deprecation. This includes potential violations of laws governing privacy, discrimination, data protection, intellectual property licenses, fair decisionmaking processes, consumer protection, and use of an individual's image or likeness, among numerous others. For example, in the United States, numerous legal actions have recently been brought against companies like Clearview AI and IBM for their facial datasets. Clearview has been sued under California law for commercial appropriation of individual faces within photographs, violations of California's constitutional privacy protections, and aiding and abetting illegal government surveillance efforts [64]. Another California lawsuit claims Clearview violated the new California Consumer Privacy Act [58]. It has also been sued under Illinois' Biometric Information Privacy Act (BIPA), where the legal complaint alleges that Clearview illegally "harvested" biometric facial scans from scraped photographs and then also illegally distributed this data to its law enforcement clients [4]. Outside the US, Clearview faces investigations and legal claims in the UK, EU, and Australia under various data protection laws, including the General Data Protection Regulation [57,50]. IBM's Diversity in Faces (DiF) dataset has also been the subject of litigation, including a lawsuit focused on violations of BIPA [67]. Facebook has also settled a case alleging BIPA violations for $550 million last year [21]. Claims of copyright infringement have also been brought against image dataset providers, however, they have yet to succeed, especially in the United States, in light of various fair use legal decisions that have created broad permission for mass digitization and analysis of creative works for machine learning purposes [1,3,2,44,18].
The landscape of potential legal issues applicable to datasets is complex and will vary based on content, jurisdiction, and application (e.g. [40]). Therefore, it will be important for dataset creators and providers to consistently assess them over time, especially during periods of dramatic changes in the law, such as when GDPR was implemented in May 2018, when the US-EU Privacy Shield replaced the data protection Safe Harbor Framework, or if, for example, the EU AI ACT becomes law [74,81]. Whether particular jurisdictional laws apply to the creation or distribution of particular datasets is a very fact-dependent question that may require consultation with legal advisors. Jurisdictional challenges also raise questions as to how deprecation would work across different jurisdictions with different legal regulations and restrictions. This is an important consideration, which we addressed below by suggesting the proposed repository note jurisdictional differences and, if applicable, support the use of geo-fence techniques to control access to the dataset going forward.
When legal actions involving datasets are successful, the result often impacts the dataset itself and even the derivative influence that the data has on algorithmic systems. For example, in a recent Federal Trade Commission settlement, Ever, Inc. deceived its customers when it collected their photos, failing to disclose how it used those photos to train facial recognition systems. As part of the remedy for these violations, the settlement requires the company "to delete the photos and videos of Ever app users who deactivated their accounts and the models and algorithms it developed by using the photos and videos uploaded by its users" [22]. As these and other legal issues continue to arise involving datasets, providers should monitor them and take them into consideration in their deprecation decisions. This will also impact downstream users, who may incur liability if they use deprecated datasets with legal issues, even unwittingly [67]. This further supports the urgent need for a deprecation framework, as well as the existence of an easily-accessible public repository so researchers can check which datasets present risks and may even cause legal liability if they use them. It is worth noting, however, that while one goal of the public repository is to promote transparency and understanding of the reasons for the deprecation, concerns over admissions of legal liability may limit or inhibit listing the specific legal analysis underlying the deprecation decision. Therefore, allowing for some flexibility in the specificity of legal reasons for deprecation is advisable.

Ethical Issues
A growing body of literature within ML has begun to consider the broader social implications of machine learning and artificial intelligence deployment. Such research introduces complex ethical, social, and political considerations with which the ML community and field at large are beginning to grapple [30,77,37]. For the datasets that we reviewed, the reasons provided for their deprecation were often linked to ethical concerns, ranging from issues of consent, privacy, offensive content, and the violation of values such as inclusivity and representation. This is due to the fact that datasets are not neutral; they represent particular representations and classifications of the world with particular social and political values embedded [26,13]. These politically laden systems produce both allocative harms (a system offering or withholding opportunities from certain groups) and representational harms (a system reinforcing the subordination of particular groups by virtue of identity) [8].
As numerous audits of datasets have shown, such harms tend to disproportionately affect marginalized groups along the intersecting axes of race, ethnicity, gender, ability, and positionality in global hierarchies (see, for instance, [75,17,27,39,62]).
Research on the ethical impacts of datasets tends to consider dataset creation, and to a limited degree, dataset maintenance [61]. While other scientific domains have addressed harmful afterlives in the form of redacted papers that continue to circulate [31,7], rarely are the deprecation and postdeprecation phases of a dataset lifecycle considered. Yet the deprecation phase is important when evaluating the ethical implications of datasets, because deprecation is often done in response to a dataset's harmful impacts. For instance, in a rare case of explanation about dataset deprecation, the creators of Tiny Images noted that the repository was taken offline because it contained "biases, offensive and prejudicial images, and derogatory terminology," in part due to automated data collection from WordNet [52], which threatened to "alienate an important part of our community" [79].
The deprecation notice for Tiny Images was posted in direct response to a critique by external researchers, who showed that the dataset contained racist and misogynist slurs and other offensive terms, including labels such as "rape suspect" and "child molester" [62]. These labels are attached to images of people downloaded from the internet who did not give their consent, constituting a clear form of representational harm [8]. Similarly, the creators of ImageNet [28] identified a total of 1,593 harmful labels in the dataset, and subsequently removed them [83]. However, because both Tiny Images and unredacted versions of ImageNet continue to circulate and can be used to train production-level systems, these problematic labels and logics could be embedded in ways that entrench harms while being hard to track and investigate: for instance, if an image classification model trained on ImageNet is used for predicting criminality based on nothing except an individual's perceived similarity to that of a 'rape suspect'. The continued circulation of "toxic" data collections threatens to reproduce both allocative harms and representational harms.
The deprecation of datasets can also change the dynamics of harm. When datasets are deprecated by their creators without disclosure or discussion of the types of harms they reproduce, this can create widespread uncertainty. Those responsible for the dataset have not acknowledged the potential for harm, while simultaneously relinquishing any control over the afterlife of the dataset. Rather than mitigating potential harms at the end of the dataset lifecycle, the creators have merely removed a single node for accessing the dataset while perpetuating a view of the data's supposed appropriateness for training models. Moreover, when deprecated datasets continue to be accepted and cited in ML conferences, the broader field implicitly condones their continuing circulation and possible harms.

Organizational Issues
While technical, legal, and ethical considerations are of primary importance to understanding the downstream effects of zombie datasets, organizational concerns also deserve attention because of the role these varied entities play in the stewardship of training data. As shown in Table 1, datasets are created and maintained by both industry research groups like Microsoft (e.g. MS-Celeb-1M) as well as by academic groups like the Stanford Vision Lab (e.g. ImageNet). While maintenance work is often devalued and rendered invisible [70], maintaining these datasets over time requires significant organizational resources, including human labor, technical infrastructure, and financial support. Organizational changes often necessitate the removal of data [25], because varied factors -from a shifting research team to non-renewed grant funding --may spell a decreased ability to maintain the dataset properly. In these cases, it may be better to deprecate conscientiously than to maintain poorly.
As we have shown here, however, dataset deprecation is often done hastily, spottily, and without adequate documentation. These faulty dataset deprecations can have potential downstream effects for the organizations in question, particularly in terms of reputation management. Scholars of organizational communication have shown that data maintenance-in the form of data breaches/data security-are important factors for organizational reputation today [11,23]. As the public increasingly becomes aware of the implications of machine learning data through media coverage (e.g. [55]), and even of the implications of zombie datasets [33], it is in the best interest of organizations to steward a dataset properly through its end of life. Additionally, this stewardship will need to be domainspecific and tailored to the needs and cultures of different organizations, professional communities, and historical traditions. We offer here a general, starting framework for dataset deprecation that will need to be interpreted and adapted to meet the needs of localized domains of knowledge and diverse organizational aims.

Dataset Deprecation Framework
As recent work on ML checklists [48], model cards [53], dataset datasheets [29], data licenses [10], data stewardship [61,59], and algorithmic audits [16,63,72] shows, there is need for transparently motivated, clearly articulated, and community-wide practices for active dataset governance and stew-ardship, and data management remains a challenge in the field. Part of dataset governance is dataset deprecation and a greater accountability for the afterlife of a dataset. To further the conversation about the governance of dataset deprecation and build on existing methods, we suggest a Dataset Deprecation Framework with six elements that could be adopted by dataset creators. We recognize that the rationales and motivations for deprecation will vary, especially given domain-specific issues, and that the circumstances leading up to deprecations may account for varying degrees of disclosure and explanation. For example, where the rationales for deprecation stem from legal considerations, dataset providers may not be in a position to share those details without risking legal liability. Or, similar to responsible vulnerability disclosure policies, when disclosure could result in additional harm, the timing and specificity of the disclosure may vary as well. Bracketing a full discussion of the legal and normative motivations for dataset deprecation (cf. [38]), and recognizing that each deprecation has contingencies and nuances that go beyond the scope of this paper, we offer these best practices as key dimensions of future dataset deprecations, aiming to create a framework that has value to both technical and public audiences, and that will further illuminate the normative and legal terrain of data deprecations: 1. Reasons for Deprecation: Using both technical language and publicly accessible explanations, those responsible for a dataset should clearly explain potential impacts of the deprecation. These risks should be enumerated with careful attention given to impacted communities that have historically lacked social power and institutional standing in computational and data science research.The discussion of risks could include which risks are being envisaged and to whom, and over what time frame risks were considered (such as identifying short, medium, and long-term risks if relevant).

Execution and Mitigation
Plan: Similar to how technology companies have approached deprecation of software and other technological tools [24], the parties implementing dataset deprecation should provide an Execution Plan, detailing in both technical and publicly accessible language, how the dataset deprecation will happen, and how any adverse impacts from its use will be mitigated. These should include how access to the dataset will be restricted or halted; how changes to access will be announced and maintained on a publicly accessible site; what steps are being taken to limit or prevent downstream uses; and which derivative datasets are impacted and should potentially also be deprecated.

Appeal Mechanism:
An appeal mechanism should be included that allows challenges to the deprecation. Appeals should have clear and fair processes, with a mechanism to contact a person responsible for the appeal process, including timely responses and explanations.

4.
Timeline: Deprecation announcements should give stakeholders adequate time to understand the deprecation's rationale, evaluate its impact, and launch any appeals. At a minimum, deprecation timelines should take into consideration an analysis of the dataset's ongoing harms and risks and the perceived impact on stakeholders, with consideration given of contexts that require action to mitigate harms versus those that can allow for more time.

5.
Post-Deprecation Protocol: Recognizing that deprecated datasets will continue to have value (e.g., as research objects, legal evidence, and historical records), deprecation protocols should also articulate methods for sequestering and accessing datasets postdeprecation, including what principles and procedures will be used to grant access to sequestered datasets. This protocol should be regularly re-evaluated in light of technical changes in data sequestration, new best practices for policy implementation, and any insights gained during the appeals process.
6. Publication Check: Leading technical conferences such as NeurIPS and ICML could include in their paper acceptance protocols a requirement that all authors affirm that their work does not use deprecated datasets, and their work follows the post-deprecation protocols sanctioned by the conference, or risk that their work be rejected. Additionally, those who are presenting new datasets at conferences should note in their paper that they will follow the conference's framework for dataset deprecation, in the event that their datasets require future removal or modifications.
Central Repository of Deprecated Datasets: Finally, we propose that a leading conference such as NeurIPS or a collegial entity such as AAAI, IEEE, or ACM act as the keeper of a public, centralized repository of deprecation decisions. This could take the form of a database of Dataset Deprecation Sheets and their accompanying documentation. This would give researchers a single site to visit in order to check if a dataset has been deprecated, thus protecting them from a range of technical, legal, and ethical problems. It would enable a transparent way of submitting, accessing, and disseminating up-to-date information regarding the current status of datasets, as well as notifying the ML community when a deprecation is necessary. This would also support jurisdictionspecific deprecations, such as when a dataset is illegal in one jurisdiction but allowed in others. The repository maintainer could address this by noting jurisdictional differences in the repository and, if applicable, supporting geo-fence techniques to control access to the dataset going forward.
As standard bearers in the ML research community, major technical conferences hosted by NeurIPS, ICML, and ACM are able to implement the deprecation publication check for paper submission that we have proposed here. This is an important step, as paper acceptance protocols are a powerful way to create norms across a research community. In this way, conferences can play a gatekeeping role that contributes to curbing the circulation and use of zombie datasets. We provide one concrete example of how this framework can be implemented by dataset creators in Table 4.1 below, and an additional one in the Appendix.
It is important to acknowledge the labor, in terms of time and effort, that would be required to host an up-to-date repository of deprecated datasets. It requires an ongoing institutional commitment to the maintenance of this infrastructure, which is why we see it as a task for prominent, well-established, and well-funded conferences and industry bodies [41]. This is another reason why our approach places the responsibility with dataset creators to complete the Dataset Deprecation Sheet and lodge it with the centralized repository, explaining why and when the dataset should no longer be used.

Example 1 -Dataset Deprecation Sheet: FaceFeels
Scenario: A research lab built a large dataset, FaceFeels. It contains six million images of people's faces scraped from the internet for the purposes of labelling facial expressions and training systems for emotion detection. The full FaceFeels dataset was made available on a web site but downloads were restricted to people who applied with a university email address. The lab kept a record of email addresses but did not require any details for what the data would be used for. After growing concerns about privacy and lack of consent from the people in the photographs, as well as methodological concerns about inferring emotion from facial expressions, the lab decided to deprecate the dataset. The company completes the Dataset Deprecation Sheet below and submits it to a centralized repository.

Reasons for Deprecation
We have deprecated the FaceFeels dataset due to concerns raised about the original context for scraping the photographs, the lack of scientific consensus about universal emotion detection, and the potential for harm in downstream implementations. We recognize that removing the dataset will potentially have commercial and scholarly impacts; however, we feel the risks outweigh any of those potential benefits and therefore are deprecating the dataset.

Execution & Mitigation Plan
We have attempted to contact via email all stakeholders who applied to download the dataset to request that they no longer use it. We have sent them this protocol, explaining all aspects of the deprecation plan, and provided them with a single point of contact within the lab who can answer their questions about the deprecation. We recognize that the deprecation will impact stakeholders on different timeframes and will make good faith efforts to work with stakeholders to ensure that the deprecation creates the least amount of disruption possible. Additionally, we have located the FaceFeels dataset on the CentralDataPlus repository. We have emailed the administrators of this repository, and asked them to remove the dataset within 30 days and publish the following note: Appeal Mechanism Appeals will only be allowed in limited cases. We give stakeholders 30 days from the date of outreach to inform us of any requests for ongoing use. Appellants should identify any disruptions caused by the deprecation, and can request modifications (e.g., timeline extensions) if needed. We will evaluate the appeal within 30 days of receipt, and communicate our decision via email. We will publicly update the protocol if there are any changes that affect all stakeholders. Appeals received more than 30 days after deprecation will not be considered.

Timeline
The dataset will be removed after 30 days of the public announcement to deprecate it. It will be removed from our site, and ideally from all repositories (assuming they agree to our request).

Post-Deprecation Protocol
Our lab will retain a complete copy of the FaceFeels deprecated dataset. It will not be available publicly, or to researchers without approved access. Access will only be given to researchers who are doing fairness and auditing work, such as understanding how the dataset is impacting production-level systems. Access will not be approved to train facial recognition or emotion detection tools. Researchers can apply at this email address <contact details> and they must stipulate a research rationale, use strict access protocols, and agree to our terms of access and timeline for use.

Publication Check
We ask all researchers to stop using the FaceFeels dataset, other than researchers who have been given post-deprecation approval. Researchers submitting conference papers that use the Face-Feels dataset with approval should include with their submissions a copy of the approved postdeprecation protocol.

Conclusion
Zombie datasets -those datasets that are deprecated or redacted but continue to circulate -pose problems for the ML research community and the wider public. In this paper we have proposed an approach to address these problems by offering a novel framework for dataset deprecation, which includes documenting the reasons for deprecation, an execution and mitigation plan, an appeal mechanism, a timeline, and a post-deprecation protocol. This framework was informed by our review of several major datasets that have been redacted or deprecated, where we observed that existing deprecations have been subject to poor documentation practices, leaving the ML research community with ongoing uncertainty and no clear rationale for stopping use. The continuing circulation of these datasets poses significant technical, legal, and ethical problems, as well as domain-specific issues. In combination with responsible data management practices like datasheets, checklists, and audits, the deprecation frameworks offered here provides a means for ML communities to practice responsible and ethical data management throughout a dataset's entire lifecycle.
Deprecation datasheets are one component for dealing with zombie datasets. Yet greater infrastructure is required to mitigate their use. In addition to datasheets, we have proposed the idea of a central repository where all deprecated datasets are listed, as well as a publication check for major conferences to ensure that emerging research no longer uses these data sources. We recognize that the maintenance of a centralized deprecation database is an administrative challenge, but it is also an important one; in addressing this to the ML research community, we have aimed to establish it in a culture of communal practice. Crucially, however, this work highlights what is inevitably a broader problem that proliferates in less transparent environments, including industry and personal contexts. For instance, not all deprecated datasets are stored on public online repositories, as datasets can be stored privately by an individual or company in perpetuity. Moreover, deprecated datasets may be used in industry applications, where models trained on these data are deployed in technological systems but leave no citation record for outside accountability. Additionally, zombie datasets highlight the urgent need to attend to relationships among datasets and, specifically, the challenge of tracing the impact of deprecations on derived and inherited datasets, a challenge the authors continues to work on. By addressing zombie datasets within the research community, we aim to make an intervention in this specific context, while raising awareness about what is inevitably a larger issue of the afterlives of deprecated datasets in industry and beyond.

Reasons for Deprecation
After reviewing the dataset, DataDriver realized that the dataset had gradually developed links to multiple data sources. Although its dataset contained no personal information (e.g., driver names, addresses, or license plate numbers), DataDriver was concerned that, when this dataset is combined with other datasets (e.g., those showing driving routes, traffic patterns, or travel times), users could be de-anonymized in ways that the company had not originally expected. DataDriver is deprecating the dataset out of abundance of caution, to protect against any unintentional identity disclosures.
Deprecating DataDriver creates risks to researchers who rely on the dataset for ongoing scholarly inquiry. Stakeholders may include researchers studying a variety of contexts-e.g., human driving behavior, ecological impacts of car travel, vehicle maintenance, safety procedures and collision conditions, and more. We recognize that removing the dataset will impact scholars' ability to design longitudinal studies and do comparative research. Additionally, stakeholders may include commercial developers doing market and product research for new businesses, service designs, and industry innovations. Deprecating the dataset may impact their market and product knowledge. Finally, the dataset may be informing public and private sector research on the car industry as a whole, so we recognize that deprecating the dataset may interrupt their knowledge of the automotive field, regulatory initiatives, and market trends. Tracing the DataDriver dataset on various dataset repositories (e.g., XXXXX), we have made considerable efforts to contact stakeholders we are aware of who have relied on the dataset and may continue to do so. We have sent them this protocol, explaining aspects of the deprecation plan, and provided them with a single point of contact within the company who can answer their questions about the deprecation. We recognize that the deprecation will impact stakeholders on different timeframes and will make good faith efforts to work with stakeholders to ensure that the deprecation creates the least disruption possible.

Execution & for Mitigation Plan
We have identified the DataDriver dataset on the following dataset repositories: X, Y, Z. We have contacted the administrators of each repository, identified ourselves as the originators of the dataset, and have requested that they remove the dataset from their sites within 30 days. Additionally, we have requested that they not only remove the dataset from their repository but that they also retain a repository entry with the following note: The DataDriver dataset was removed from this repository on <date> at the request of the DataDriver company. A complete account of the deprecation is contained in this Dataset Deprecation Sheet <linked> and further questions about the deprecation can be directed to DataDriver <contact information>. Additionally, we are placing a notification of deprecation on the Dataset Deprecation site, with a link to the full protocol. We have also made our best efforts to identify the authors of reports and papers that use the DataDriver dataset and have written to those individuals informing them of the deprecation, sharing a copy of the deprecation protocol, and asking them to add post-publication notifications where possible informing report/paper readers of the deprecation.

Appeal Mechanism
In each outreach to dataset stakeholders, we specified that stakeholders have 30 days from the date of outreach to appeal the deprecation. Appellants should clearly articulate the disruptions to them caused by dataset deprecation. Additionally, appellants can request changes to the deprecation process (e.g., timeline extensions) and propose any alterations to the protocol that they think would reduce deprecation disruptions. We commit to evaluating the appeal within 30 days of receipt, communicating our decision to appellants, and changing the protocol / deprecation execution plan, if appropriate. We will publicly update the protocol with any changes and inform all stakeholders of the modifications. Appeals received more than 30 days after deprecation will only be considered in extreme cases.

Timeline
Within 30 days of the deprecation's public announcement and communication to stakeholders, the dataset will be removed both from our website and the dataset repositories (subject to those repositories' responsiveness).

Post-Deprecation Protocol
We will retain, internally within our company and not through any publicly available repository, a complete copy of the deprecated dataset.
Researchers wanting access to the deprecated DataDriver dataset can apply to us <contact information> for access. Applicants must state a research rationale, complete our access training module that specifies access protocols, and agree to our terms of access. Researchers will not be given a copy of the dataset but will instead access/query the dataset through our process for accessing sequestered datasets.

Publication Check
We are submitting this protocol to the relevant Dataset Deprecation Site and ask all researchers submitting papers to NeurIPS to confirm that their submissions do not use the DataDriver dataset, with the exception of researchers who have followed our post-deprecation protocol. Researchers submitting NeurIPS papers that use the DataDriver dataset should include with their submissions a copy of the approved post-deprecation protocol.