Addressing Beacon re-identification attacks: quantification and mitigation of privacy risks

Abstract

The Global Alliance for Genomics and Health (GA4GH) created the Beacon Project as a means of testing the willingness of data holders to share genetic data in the simplest technical context—a query for the presence of a specified nucleotide at a given position within a chromosome. Each participating site (or “beacon”) is responsible for assuring that genomic data are exposed through the Beacon service only with the permission of the individual to whom the data pertains and in accordance with the GA4GH policy and standards.While recognizing the inference risks associated with large-scale data aggregation, and the fact that some beacons contain sensitive phenotypic associations that increase privacy risk, the GA4GH adjudged the risk of re-identification based on the binary yes/no allele-presence query responses as acceptable. However, recent work demonstrated that, given a beacon with specific characteristics (including relatively small sample size and an adversary who possesses an individual’s whole genome sequence), the individual’s membership in a beacon can be inferred through repeated queries for variants present in the individual’s genome.In this paper, we propose three practical strategies for reducing re-identification risks in beacons. The first two strategies manipulate the beacon such that the presence of rare alleles is obscured; the third strategy budgets the number of accesses per user for each individual genome. Using a beacon containing data from the 1000 Genomes Project, we demonstrate that the proposed strategies can effectively reduce re-identification risk in beacon-like datasets.

A Community Effort to Protect Genomic Data Sharing, Collaboration and Outsourcing

“…In our previous work, 35 three different mitigation models were proposed: (S1) Beacon alteration strategy; (S2) Random flipping strategy; and (S3) query budget per individual strategy. However, we only include the results of the S2 models as our baseline performance for the 0.2 and 0.18 flip probabilities.…”

“…S3 was not chosen as a baseline in Track 2 because we assumed the beacon service does not keep track of the queries per individual. The performance of our baseline 35 and performance of the top two teams, the first from Vanderbilt University 36 and the second from the University of Manitoba, 37 are depicted in the Fig. 1.…”

Privacy-preserving biomedical database queries with optimal privacy-utility trade-offs

“…Yet despite the limited scope of allowed queries and the fact that only aggregate-level information is shared, query-answering systems can still leak sensitive information about the underlying individuals [8][9][10][11]. One could, for example, ask for the number of 25-year-old females on a certain medication who do not have a particular disease.…”

“…If the answer returned is zero, we know that any 25-year-old female patient in the database who is on that medication has that disease, a fact the patients might wish to keep private. Moreover, given access to an individual's genotype, a small number of queries to a beacon server would be sufficient to reveal whether the individual is included in the database [10,11]. This information could potentially be detrimental to the individual if the underlying cohort represents a group of individuals with sensitive characteristics (e.g.…”

Reconstructing Genotypes in Private Genomic Databases from Genetic Risk Scores

“…For instance, such attacks have already been developed for summary statistics about the frequency of single nucleotide polymorphisms (SNPs) [2,5,15]. Membership inference attacks have also been developed for the case where a person is allowed to repeatedly query a database to learn if at least one individual contains a particular SNP [13,14,16]. These kinds of aggregate statistics about the frequency or presence/absence of a particular SNP might be useful to release to the broader research community, but it is not an essential output of the research process.…”