Para evitar incidentes como este:
Fuga de datos de búsqueda de AOL – Wikipedia
O estos:
- ¿Qué tecnología tiene un futuro mejor, el aprendizaje automático o Node.js?
- ¿Es generalmente una buena idea entrenar en caso real, desarrollar y probar conjuntos de datos para la traducción automática?
- ¿Cuáles son algunos estudios de caso excelentes en el aprendizaje automático?
- ¿Cómo decidimos qué algoritmo usar en el aprendizaje automático?
- ¿Es el aprendizaje automático una mejor forma o técnica para comprender los datos y hacer pronósticos que las estadísticas?
Lista de violaciones de datos – Wikipedia
El breve formulario en el primer enlace: un investigador de AOL publicó registros de búsqueda de usuarios con fines de investigación. Solo el historial de búsqueda: nada para vincular los datos a los usuarios. Compartir datos en el mundo de la investigación suele ser de gran ayuda. Por ejemplo, hay conjuntos de datos comunes como muestras de escritura a mano MNIST, el texto de Wikipedia y varios otros tipos de datos que se comparten abiertamente y se usan como un corpus común para experimentar e informar resultados con el aprendizaje automático y similares. Entonces, compartir el historial de búsqueda de AOL es algo bueno, ¿verdad?
Bueno no. Resulta que las búsquedas a menudo contienen información de identificación personal, y simplemente “no adjuntarla a un usuario” no es suficiente para garantizar que no pueda identificar al usuario que la generó. Eso es exactamente lo que hizo el NY Times: analizaron los datos, encontraron un usuario que podían identificar a través de los registros, y IIRC (lo admitimos, esto fue hace una década) contactó al usuario para obtener sus comentarios sobre su historial de búsqueda que se comparte.
AOL retrocedió rápidamente (los datos solo estuvieron disponibles durante unos días) después de recibir una reacción violenta; después de todo, no es como si los usuarios optaran explícitamente por compartir su historial de búsqueda.
Moraleja de la historia: hay conjuntos de datos basados en datos de usuarios que son absolutamente valiosos para compartir, pero desea proteger la privacidad de los usuarios que crearon los datos.
Pero no es solo un intercambio externo. Para las empresas que manejan datos de usuarios, generalmente no desea que todos en la empresa tengan acceso a cada dato. Un ejemplo extremo, pero ¿hay alguna razón por la que necesite que el Conserje de su empresa tenga acceso a los números de teléfono y las direcciones de los usuarios? Probablemente no, ¿verdad?
Bueno, puede extender esa idea: si hay una persona trabajando en un motor de recomendación para su producto, ¿necesitan acceso a números de teléfono y direcciones? Posiblemente, pero por defecto, no. Por lo tanto, no les dé acceso a menos que vengan a usted con una razón convincente. Al restringir el acceso a datos sin procesar a un pequeño número de personas que tienen una razón comercial para acceder a los datos, lo que reduce en gran medida la posibilidad de fugas y el área de superficie para las infracciones de datos.
Pero, ¿qué pasa con las personas que trabajan en el motor de recomendación? ¿Qué deben hacer ellos? Bueno, resulta que a menudo puedes usar datos agregados o anónimos en su lugar. ¿Qué aspectos de un número de teléfono le interesan? Quizás pueda sobrevivir con funciones como: IsLandline o CountryCode, en lugar del número sin formato. Si tuviera que filtrar mi información, preferiría que filtre que tengo un teléfono fijo de EE. UU. Y que vivo en California y estoy en el rango de edad XX-YY vs. “mi número de teléfono es xxxxxx y mi dirección es aaaaaaaa y mi edad es zz ”
Tenga en cuenta que en una gran empresa puede haber docenas de proyectos que hacen uso de los datos del usuario de alguna forma. Si todos ellos tienen acceso total a los datos sin procesar, hay docenas de formas para que los datos sin procesar se filtren (cada proyecto adicional agrega la posibilidad de que alguien filtre datos o provoque una violación de datos inadvertidamente). Si solo tienen acceso a datos anonimizados, los riesgos siguen ahí, pero el daño se minimiza.
Además, a menudo los datos agrupados o agrupados son más útiles. Por ejemplo, en el aprendizaje automático, el “número de teléfono” es bastante inútil como característica, ya que sería exclusivo de un usuario. Pero podría usarse algo como “país de número de teléfono” o “estado de número de teléfono”, y permitir que un modelo se generalice. Entonces, a veces obtienes dos pájaros de un tiro haciendo lo correcto y protegiendo la privacidad.
