Violación de la privacidad incluso cuando las consultas con muy pocos resultados son rechazadas

Creo que lo que dice el libro es que si puede realizar una consulta tan específica que solo haya unos pocos resultados, puede identificar un objetivo en particular en la base de datos.

Por ejemplo, si un concesionario de automóviles tuviera una base de datos de clientes y "anonimizaran" la base de datos para incluir solo el código postal, marca, modelo, año, color y salario, podría encontrar el salario de su vecino si sabe que compró un coche de ese distribuidor.

Por ejemplo, podría ejecutar una consulta que seleccione el salario de todas las personas que poseen un Chevy Volt verde 2012 en su código postal. Si solo tiene un puñado de registros que muestran salarios de 20K 30K 40K y 300K y sabe que su vecino es un abogado exitoso, puede adivinar que tiene el salario de 300K.

Pero si el sistema se negó a mostrar menos de 100 resultados, es más difícil encontrar el objetivo en tal conjunto de resultados.

Respuesta simple:

Si se permite cualquier consulta SQL, también puede aumentar artificialmente el recuento de registros haciendo algo como un UNION SELECT myKnownRecord al final.

Respuesta más general:

Este problema forma parte de una gran familia de estrategias conocidas como desanonización. Uno de los métodos para evitar la divulgación no intencionada cuando otros métodos como la aplicación del anonimato k, la agregación, el redondeo y el desenfoque o engrosamiento de los datos no funcionan es la supresión de resultados para grupos pequeños.

La principal razón por la que este método de restricción de consultas que resulta en rangos pequeños no funciona de manera universal es que hay muchas otras formas de obtener una imagen completa de lo que está sucediendo, incluso si no observa los resultados con menos de 5 entradas.

Supongamos que tenemos diferentes criterios a, b y c. El conjunto A es el conjunto de todos los registros que coinciden con los criterios a, el conjunto A ∩ B es el conjunto de todos los registros que coinciden con los criterios a y b (correspondientes a un SQL JOIN o una operación similar), etc.

Supongamos que A ∩ B ∩ C es un conjunto lo suficientemente pequeño como para identificar los registros de nuestro objetivo (A ∩ B ∩ C tiene menos de cinco elementos). Sin embargo, un criterio de registro mínimo nos impide ver directamente A ∩ B ∩ C. Sin embargo, podríamos ver A ∩ B, A ∩ C y A ∩ B, luego hacer una unión de dos de ellos para obtener una unión. queremos A ∩ B ∩ C. Sin embargo, suponiendo que el resultado que desea es único. Si los registros no son únicos (digamos que son calificaciones de letras, categorías de ingresos, respuestas de sí / no o un promedio basado en los registros devueltos), no puede hacer uniones manuales y no puedo pensar en una forma universal de obtener los valores exactos.

Los sindicatos (uniones externas) también podrían usarse en ocasiones para crear esta estrategia de protección. Si sabe que su objetivo es uno de los pocos miembros del conjunto A (tal vez porque los resultados para A estaban ocultos) podríamos ver los resultados agregados para el AUC y cualquier resultado cercano al 0% o al 100% se aplicaría a nuestro objetivo en A.

Otra forma en que se puede eludir esta protección es mediante el uso de otros resultados para restar nuestro camino al resultado que deseamos. Si sabemos que hay 120 de 160 personas tienen calificaciones aprobatorias en el conjunto A, y 120 de 157 calificaciones aprobatorias en A ∩ B, entonces incluso si A ∩ B '(A y no B) está oculto debido a que tiene muy pocas resultados ya sabemos que nadie está pasando en ese grupo. Por lo general, esto se puede evitar si evitamos revelar cuántas entradas hay en cada conjunto, al redondear los porcentajes de manera agresiva, o agrupar los porcentajes en categorías ("< 5%" o 3% en lugar de 3.1%).

Para usar un ejemplo (modificado de el proporcionado por el Centro Nacional de Estadísticas de la Educación), digamos una escuela revela que solo un estudiante indio americano / nativo de Alaska se inscribió en 2010. Si la escuela revela el índice de graduación de este grupo demográfico, la privacidad de la persona se ha visto comprometida. La privacidad del estudiante también podría violarse si se pueden usar grupos complementarios para obtener una imagen completa del estudiante, como que la tasa de graduación sea del 0% para los indios americanos / nativos de Alaska o que todos los demás datos demográficos sumen hasta el 100% de los graduados.

Para proporcionar un contexto, L. Sweeney en Carnegie Mellon realizó estudio que concluyó: "Se encontró que Las combinaciones de pocas características a menudo se combinan en poblaciones para identificar de forma única o casi única a algunos individuos. Claramente, los datos publicados que contienen dicha información sobre estos individuos no deben considerarse anónimos. Sin embargo, los datos de salud y otros datos específicos de las personas están disponibles públicamente en este formulario. hay algunos resultados sorprendentes que utilizan solo tres campos de información, a pesar de que los lanzamientos de datos típicos contienen muchos más campos ... incluso a nivel de condado, es probable que {condado, género, fecha de nacimiento} identifiquen de manera única al 18% de la población de EE. UU. En general, se necesitan pocas características para identificar de manera única a una persona ". Se ha comprobado la identificación personal análoga y la anonimización para una base de datos de transacciones con tarjeta de crédito que habían sido ingenuamente anonimizados. Así que incluso las consultas simples como "todos los registros con este género, fecha de nacimiento y área geográfica" o "personas que visitaron estas cuatro tiendas recientemente y gastaron alrededor de $ 50" probablemente comprometan seriamente la privacidad. Debido a que este tipo de registros, como la fecha de nacimiento y la ciudad, se pueden combinar para desanonizar los datos, HIPAA, FERPA y estándares similares se escriben para limitar estrictamente cualquier tipo de divulgación de esta información.

En resumen, como Anupam Datta de CMU dijo , "Los mecanismos de anonimización ingenuos no funcionan"

Seleccionándolo solo a través de una consulta SQL, podría consultar la sugerencia a esta pregunta . Ambas respuestas son más o menos iguales ( JOIN , cuando no se especifica su tipo, el valor predeterminado es INNER JOIN en la mayoría de RDBMS de todos modos).

Sin embargo, esta es una forma altamente ineficiente de producir resultados con un número mínimo de registros. Sería mucho más fácil, pero también más rápido, verificar el número requerido de registros antes de mostrar los resultados en su código de generación de aplicaciones y luego decidir si enumerar los registros coincidentes o mostrar un mensaje de error no revelador.

Esto es más fácil porque no tiene que cambiar sus consultas SQL existentes para adaptarse a este nuevo requisito, más rápido porque no hay una vinculación interna para agregar conjuntos de resultados, y también es más conveniente ya que se le pedirá que maneje ambos casos en su código de inicio de generación de todos modos.

Básicamente, todo lo que tendrías que hacer es mostrar el mismo mensaje (o similar) cuando la consulta devuelve menos de n registros, como antes con conjuntos de resultados vacíos.

Ejemplo de lenguaje agnóstico:

query.run;
if (query.recordcount >= 6) {
  display_results(query);
} else {
  error(minimum_not_reached);
}

que reemplaza:

query.run;
if (query.recordcount > 0) {
  display_results(query);
} else {
  error(no_results);
}

Por supuesto, el mensaje de error devuelto no debe revelar los registros mínimos requeridos, y probablemente sea mejor mantener minimum_not_reached igual a no_results . Lo que sucede es mucho más conveniente si está modificando un código existente, ya que apenas requiere ningún cambio (de query.recordcount > 0 a query.recordcount > 5 ).

Según el RDBMS en uso, esto también podría lograrse con procedimientos almacenados ;)