BMC Genomics 2006, 7:93 http://www.biomedcentral.com/1471-2164/7/93 FGiegnuerPeIN6G health care provider filtered view GenePING health care provider filtered view. A doctor viewing a patient's records. Note how only one document shows up, and no information is available as to whether that document is filtered or not. Comparison with the patient's view reveals that it is indeed a filtered document, but a doctor would not learn this from his view on the data. like the previous use case, such an attack should yield no specific information concerning the absence or presence of a particular patient's record, the absence or presence of specific document types (e.g. genomic sequences) within the patients' records, or the absence or presence of specific datapoints (e.g. SNPs) within these documents. Out-of-scope threats Given today's practical constraints, we cannot assume a public-key infrastructure. Thus, we must place some trust in the GenePING server to administer permissions cor- rectly. We cannot defend against a corrupted GenePING server, though of course we attempt to fight off adversaries who wish to make the GenePING server corrupt. In partic- ular, while all raw storage is encrypted and the GenePING server will store the decryption key in memory only, we do not defend against an adversary clever enough to some- how steal the decryption key from a running GenePING server. Design principles The above threat outline helps define two immediate important design principles: the obfuscation of data in both content and presence, as well as limiting the Gene- PING server's capabilities to reduce the number potential attacks. Obfuscation of data content and presence Any data present in the system should be obfuscated, both in terms of content and even presence, unless a user is explicitly authorized to access such data. This is relevant to all levels of data storage: a patient's record as a whole, a Page 8 of 10 (page number not for citation purposes)