Privacidad del usuario

Mary Kirtland

Microsoft Corporation

14 de febrero de 2001

En mi última columna, he analizado la definición de la visión del primer proyecto de ejemplo del equipo de orientación de servicios web, el servicio Favoritos. Disculpe por el largo retraso entre columnas; He estado fuera por la mejor parte de un mes con un frío desagradable. Espero que las cosas vuelvan a la pista ahora para columnas semanales regulares durante los próximos dos meses.

Para volver a resumir, el objetivo del servicio Favoritos es proporcionar una manera de que las aplicaciones almacenen los vínculos favoritos de los usuarios finales a los sitios web en una ubicación segura, segura y central, para que un usuario pueda acceder a sus favoritos a través de estas aplicaciones, independientemente de la máquina que el usuario esté usando. Desde una perspectiva técnica, esto parece un servicio bastante sencillo de implementar. Básicamente, es simplemente un almacén de datos especializado.

Al mismo tiempo que empezamos a examinar el Servicio favoritos, hubo una gran cantidad de artículos de noticias sobre la privacidad del usuario, específicamente sobre la información que terceros podrían recopilar a través de anuncios en páginas web. Esto nos lleva a pensar: todo el modelo de servicios web se basa en una página web que usa servicios de terceros, lo más probable es que sin el conocimiento del usuario final. ¿Hay problemas de privacidad de los que preocuparse?

Incluso sin una buena definición de privacidad del usuario, pudimos plantear algunos escenarios posibles que nuestro servicio favoritos propuesto habilitaría que parecía interrogable. En función de nuestra investigación inicial sobre los problemas, decidimos implementar el servicio Favoritos en fases, aplazando los escenarios interrogables a fases posteriores. En esta columna, analizaré lo que descubrimos durante nuestra investigación inicial, los problemas difíciles que hemos diferido, los problemas de privacidad que permanecen en la fase uno del proyecto y el impacto de estos en nuestro diseño e implementación.

Privacidad definida

Empecemos por ver lo que queremos decir por la privacidad del usuario. Nos centraremos en nuestra discusión sobre la privacidad del usuario y la Web. Cada vez que use la Web, hay tres tipos de información que se pueden intercambiar entre la aplicación que está usando (por ejemplo, un explorador web) y los sitios web a los que está conectada la aplicación (como las páginas que se muestran en el explorador):

Información que creas con alguna combinación de aplicaciones, como el correo electrónico que escribes, tus fotos de vacaciones, tus registros financieros, etc.
Información sobre usted, como su nombre, dirección, intereses personales, etc., recopilados por una solicitud para proporcionar servicios a usted.
Información sobre la máquina o la conexión de red que está usando, como una dirección IP, recopilada por una aplicación para proporcionar servicios a usted.

El problema con la privacidad del usuario es cómo se recopila, usa y distribuye esta información. Si compra un libro de una librería en línea, por supuesto deberá proporcionar su nombre, dirección y número de tarjeta de crédito para que la librería complete el pedido. Pero, ¿qué ocurre si la librería volca esta información en una base de datos, junto con los registros de los libros específicos que ha comprado? Por un lado, podría usar la información para proporcionar servicios útiles, como notificarle cuando se publiquen nuevos libros de sus autores favoritos. Por otro lado, podría vender su información personal, lo que da lugar a una inundación de correo no deseado no deseado. ¿Qué constituye un uso justo de esta información por parte de las empresas que proporcionan las aplicaciones que utiliza?

Desafortunadamente, no hay respuesta única a esta pregunta. Lo correcto es difícil de determinar, especialmente porque la percepción pública y las regulaciones gubernamentales están en flujo (y pueden variar de una jurisdicción legal a otra). La práctica estándar para los sitios web hoy en día es publicar una directiva de privacidad que informe a los usuarios de qué información se recopila y cómo se puede usar y distribuir. Sin embargo, no hay ningún estándar sobre si el usuario debe leer la directiva de privacidad antes de recopilar información o antes de que el usuario pueda acceder al sitio web.

La situación se vuelve aún más incierta con los servicios web. Es probable que el usuario final no sepa ni siquiera que se use ningún servicio web. Si un servicio web recopila información que se puede asociar a un usuario final específico (conocido como información de identificación personal), ¿cómo informa el proveedor de servicios al usuario sobre qué información se recopila y cómo se puede usar o distribuir? ¿Las aplicaciones que distribuyen la información personal a los servicios web deben revelarla a los usuarios finales? Tradicionalmente, las empresas no han revelado que externalizan aspectos concretos de sus procesos empresariales. Por ejemplo, es posible que una empresa no revele que el suministro de pedidos o el soporte al cliente están subcontratados, aunque tanto la empresa de suministro de pedidos como la organización de soporte al cliente tienen acceso a información personal sobre los clientes. Pero las reglas pueden ser diferentes en línea. Sólo el tiempo dirá...

Prácticas de información justa

Las prácticas de información justa mantienen a los clientes informados y en control de su información personal. Esta información está protegida contra el uso, el acceso o la distribución no deseados, de modo que los clientes estén seguros y satisfechos al usar los productos de una empresa. Nuestro primer paso para comprender lo que la privacidad del usuario significaba para el servicio Favoritos era leer las prácticas de información justas de Microsoft. El grupo de privacidad corporativa de Microsoft define cinco elementos de prácticas de información justas:

Aviso. Su empresa debe definir una directiva clara sobre la recopilación, el uso y la distribución de información personal. Esta directiva debe incluir el uso principal y secundario de los datos, la distribución de datos entre divisiones empresariales dentro de la empresa, el uso compartido de datos con empresas afiliadas y no afiliadas y obligaciones contractuales con proveedores que admiten transacciones comerciales. La empresa debe establecer directrices para los cambios de directiva y el impacto de los cambios en los datos recopilados antes del cambio. Querrá trabajar con sus asesores legales para asegurarse de que la directiva es algo que puede aplicar en sus sitios web y servicios web. Poner la directiva a disposición de los clientes y usuarios a través de varios canales de distribución, incluidos en línea y sin conexión.
Consentimiento. Debe proporcionar mecanismos flexibles y accesibles para que los usuarios administren sus preferencias para la recopilación, el uso y la distribución de datos. Tendrá que clasificar la información en agrupaciones razonables y significativas para que los usuarios puedan averiguar a qué dan su consentimiento y, por lo tanto, no tarda demasiado tiempo en configurar las preferencias. Es importante pensar en los valores predeterminados de las preferencias del usuario. ¿El usuario necesita habilitar explícitamente un uso determinado de la información personal (conocida como participar) o deshabilitar explícitamente el uso (conocido como no participar)?
Acceso. El usuario debe poder ver o editar cualquier información personal que almacene, para asegurarse de que se mantiene actualizada y para administrar las preferencias de uso. Deberá averiguar qué información puede editar el usuario y qué información solo se puede ver. Por ejemplo, es posible que el usuario no pueda editar un identificador de usuario único, pero podría tener permiso para editar una contraseña. Idealmente, las herramientas para administrar la información personal estarían disponibles para los usuarios en línea y sin conexión.
Seguridad. Debe implementar las medidas de seguridad adecuadas para proteger la información personal de los usuarios. Esto incluye mecanismos de autenticación y autorización para proteger el acceso a los datos almacenados. También puede incluir mecanismos para proteger los datos durante la transmisión entre máquinas. Las medidas de seguridad deben ser proporcionales a la sensibilidad de la información. Por ejemplo, estará mucho más preocupado por la seguridad si está trabajando con la cuenta bancaria o los registros médicos de un usuario que si está trabajando con una lista de sus autores favoritos.
Cumplimiento. No hace nada bueno tener una directiva de privacidad si no la sigue. Su empresa debe definir (y seguir) procedimientos para supervisar los sistemas de información para el cumplimiento de las directivas de privacidad. Defina los procesos de resolución de controversias para todos los servicios de información del cliente y mantenga relaciones de puerto seguro con organizaciones de certificación de terceros. Aunque la aplicación es en gran medida externa al sitio web o al propio servicio web, debe considerar qué tipos de información de auditoría se deben mantener para admitir los procesos de cumplimiento. Por ejemplo, es posible que desee realizar un seguimiento de si y cuándo los usuarios han leído la directiva de privacidad, cuándo y cómo un usuario modificó las preferencias de usuario, etc.

Prácticas de información justa y favoritos

Todo esto suena razonable en teoría, pero todavía no estaba completamente claro para nosotros cómo se aplica a nuestro servicio web, o cómo implementaría todos estos elementos para los servicios web en general. Así que pasé unas horas discutiendo los problemas con un miembro del grupo de directivas corporativas. Hemos empezado con una lista de escenarios que el servicio Favoritos podría habilitar (en función de nuestra instrucción de visión inicial):

Un usuario instala algún complemento en Internet Explorer que proporciona un conjunto de opciones de menú como favoritos de Internet Explorer, excepto que los favoritos se almacenan realmente en coldrooster.com. (Si lee la última columna, sabe que definimos un escenario empresarial en torno a una empresa de consultoría. Ahora podemos revelar que el nombre de esta firma de consultoría ficticia es Cold Rooster Consulting, en honor del gallo que ha estado colgando de nuestro edificio en el campus de Microsoft. Por lo tanto, coldrooster.com).
Coldrooster.com proporciona una aplicación web que permite a los usuarios administrar sus favoritos.
Un sitio web, por ejemplo, msdn.microsoft.com, proporciona un botón en cada una de sus páginas en la que un usuario puede hacer clic para agregar esa página al favorito del usuario almacenado en coldrooster.com.
Msdn.microsoft.com proporciona una página web que muestra los favoritos de un usuario, que originalmente almacenó msdn.microsoft.com en nombre del usuario.
Msdn.microsoft.com proporciona una aplicación web que permite a un usuario administrar los favoritos almacenados originalmente por msdn.microsoft.com en nombre del usuario.
Cold Rooster Consulting toma periódicamente todos los favoritos almacenados, quitado de cualquier información que los vincule a un usuario determinado y los volca en una base de datos independiente para su análisis.
Msdn.microsoft.com proporciona una página web que muestra todos los favoritos almacenados por un usuario, independientemente del sitio web que originalmente almacenó el favorito en nombre del usuario.
Msdn.microsoft.com proporciona una aplicación web que permite a los usuarios administrar todos sus favoritos.
Cold Rooster Consulting proporciona un servicio web independiente que msdn.microsoft.com puede tener licencia. Este servicio permite que las licencias recuperen información como "favoritos" o "personas que guardaron esta página también guardaron estas páginas", pero solo para el dominio de msdn.microsoft.com.
Cold Rooster Consulting proporciona el servicio web descrito en el escenario 9, salvo que las recomendaciones devueltas a msdn.microsoft.com pueden incluir favoritos de otros dominios.

Puesto que tendríamos que vincular los favoritos de un usuario a su identificación personal, como una dirección de correo electrónico o un identificador de Microsoft Passport, con el fin de que todos los favoritos del usuario estén disponibles a través de cualquier aplicación y cualquier máquina, los datos favoritos del usuario definitivamente se encuentran dentro de la categoría de información de identificación personal. Si nos bloqueamos con esta definición del servicio Favoritos, tendríamos que implementar prácticas de información justas mediante una combinación de directivas, procedimientos y código.

En el momento de nuestra discusión, no había ninguna ley que requiera notificar al usuario antes de almacenar información en su nombre. Por lo tanto, podríamos implementar el elemento de aviso publicando una directiva de privacidad en coldrooster.com. ¿Cómo sabrían los usuarios que necesitaban leer la directiva? Hemos llegado a dos opciones: cualquiera de los usuarios tendría que registrarse con coldrooster.com antes de poder almacenar favoritos a través de nuestro servicio, o las aplicaciones cliente necesitarían notificar a sus usuarios que se estaba usando el servicio favoritos de Cold Rooster Consulting, con un puntero a nuestra directiva de privacidad.

Desde el punto de vista de la seguridad , los favoritos del usuario no entran en la misma categoría que los registros médicos, pero un usuario seguirá teniendo algún control sobre quién puede acceder a ellos. Por ejemplo, mirando los favoritos que he almacenado en mi máquina doméstica, podría averiguar a qué equipos deportivos apoyo, qué tipos de libros me gusta leer, qué tipos de música me gusta escuchar y dónde tengo mis cuentas bancarias, no la información a la que quiero que todos los usuarios del mundo tengan acceso. Y si alguien podría modificar mis favoritos, podrían reemplazar los vínculos que he seleccionado por otros sitios (posiblemente con fines nefariosos, como interceptar información confidencial) o agregar nuevos vínculos a mis favoritos. Por lo tanto, definitivamente queremos proteger el acceso a los favoritos del usuario. Y es probable que deseemos permitir a los usuarios especificar qué aplicaciones podrían leer o escribir qué favoritos. Por ejemplo, podría permitir que MSDN modifique mis favoritos para el dominio de msdn.microsoft.com, pero no querría que MSDN ni siquiera vea los vínculos de mis equipos deportivos favoritos. ¿Por qué debería preocuparSE por MSDN?

Para permitir a los usuarios controlar qué aplicaciones podrían leer o escribir qué favoritos, tendríamos que implementar los elementos de consentimiento y acceso de prácticas de información justas. Probablemente también queremos implementar código de auditoría para admitir el elemento de cumplimiento .

De repente, nuestro simple servicio web no suena tan simple! ¿Qué nivel de control debemos proporcionar a los usuarios? ¿Deberíamos permitirles especificar exactamente qué aplicaciones pueden leer o escribir favoritos de cada dominio? ¿O se deben agrupar aplicaciones y dominios en zonas para simplificar la configuración? ¿Y cuál de los escenarios enumerados anteriormente debe habilitarse de forma predeterminada?

Nuestro experto en privacidad no tenía ningún problema con los escenarios 1 a 5. La directiva de privacidad típica cubriría estos escenarios. Sin embargo, en el escenario 2, tendríamos que considerar si coldrooster.com debería poder administrar todos los favoritos de un usuario, independientemente de la aplicación que almacenase los favoritos del usuario, o simplemente los favoritos que agregaron las aplicaciones de Cold Rooster Consulting. Probablemente se equivocaría por precaución y diríamos que las aplicaciones de Cold Rooster Consulting solo podían administrar los favoritos de los usuarios agregados a través de esas aplicaciones, a menos que el usuario especificara explícitamente que las aplicaciones se podían usar para ver o editar todos los favoritos almacenados en nombre del usuario.

Incluso el escenario 6 no es demasiado problemático, siempre y cuando la directiva de privacidad indique que podemos usar los favoritos del usuario almacenado para su posterior análisis. De nuevo, es necesario tener en cuenta si los datos deben particionarse (ya sea por dominio o por la aplicación que originalmente proporcionó los datos) antes de analizarlos. Y dado que muchas personas tienen cuidado con la generación de perfiles de datos, es posible que deseemos dar a los usuarios la posibilidad de no tener sus favoritos incluidos en los datos agrupados usados para el análisis.

Los escenarios restantes se vuelven cada vez más dados desde una perspectiva de privacidad. No es decir que no deben implementarse, solo que sería más difícil escribir una declaración de directiva precisa y comprensible, y es posible que los usuarios no estén familiarizados con los escenarios, por lo que probablemente deberían deshabilitarse de forma predeterminada (el usuario debe participar).

El escenario 7 inicialmente suena bastante inocuo, pero lo que realmente significa desde la perspectiva de un servicio web es que una aplicación puede obtener una copia de todos los favoritos de un usuario del servicio Favoritos. Una vez que la aplicación tiene una copia de los datos, puede hacer lo que quiera con ellos. Si proporcionamos un servicio web que admita este escenario, es probable que deseemos restringir el acceso al servicio web a clientes conocidos con directivas de privacidad que cumplan algunos criterios mínimos.

El escenario 8 es aún más problemático. Una vez que una aplicación tiene la capacidad de modificar los favoritos de un usuario, ¿qué es evitar que la aplicación agregue páginas aleatorias a la lista del usuario o elimine un favorito que apunte al sitio de un competidor? En otras palabras, ¿cómo puede el servicio web distinguir las solicitudes de servicio válidas realizadas por una aplicación en nombre de un usuario final de las solicitudes de servicio realizadas por una aplicación que el usuario final no sabe? Los mecanismos de seguridad disponibles que funcionan con HTTP y XML no admiten realmente este tipo de escenario de cliente, servidor o servicio directamente; tendríamos que implementar alguna solución de seguridad personalizada. Incluso con el mecanismo de seguridad personalizado, probablemente habrá trabajo adicional necesario para proporcionar una manera para que los usuarios especifiquen qué aplicaciones podrían editar qué favoritos.

Por último, los escenarios 9 y 10 se amplían aún más en el ámbito de la generación de perfiles en línea que el escenario 6. Los problemas técnicos no son realmente diferentes de los ya mencionados, pero el nivel de molestia del usuario sería aún mayor.

En función de este análisis de los escenarios, decidimos retroceder y replantear la visión de la entrega inicial del servicio Favoritos. La nueva visión de la fase uno se centra en los escenarios 3 a 5 anteriores. Básicamente, cada aplicación tiene su propia tienda privada para favoritos del usuario. Si voy a msdn.microsoft.com y almacena un vínculo a esta columna, solo puedo ver o editar ese vínculo a través de la interfaz de usuario msdn.microsoft.com proporciona.

Este enfoque elimina varios problemas difíciles. De hecho, elimina todo el problema de privacidad del usuario, ya que se relaciona con los favoritos del usuario. Puesto que cada aplicación que usa el servicio Favoritos tiene eficazmente un almacén independiente de favoritos de usuario, no es necesario un esquema de identificación de usuario global que el servicio Favoritos entienda. Cada aplicación puede usar cualquier tipo de identificador que quiera. El servicio Favoritos no tiene ninguna manera de interpretar estos identificadores ni correlacionar la información almacenada por diferentes aplicaciones. Dado que solo se puede acceder a los datos mediante una sola aplicación (o, más precisamente, un único licenciatario del servicio Favoritos), no es necesario preocuparse por proporcionar una manera de que los usuarios opten o no por varios escenarios. Hemos delegado eficazmente el problema de privacidad del usuario a la aplicación que realiza la llamada.

No es decir que no nos importa resolver los desafíos técnicos que se plantean en nuestro análisis de los escenarios anteriores. Queremos abordarlos en una fase futura del servicio Favoritos. Solo queremos tomar un poco más de tiempo para pensar en las cosas y encontrar una solución que nos sentimos cómodos recomendando a la comunidad de desarrolladores.

Entonces, ¿qué ocurre si necesita resolver el problema hoy? No puedo ver ninguna manera de implementar un mecanismo de licencias para usuarios y aplicaciones. Los usuarios tendrían que registrarse para obtener una cuenta con el servicio. Esto significa que tiene un sitio web donde pueden leer su directiva de privacidad, registrarse en la cuenta y administrar sus preferencias. Las empresas que desarrollan aplicaciones también tendrían que registrarse para obtener una licencia para usar el servicio web. El contrato de licencia debe especificar cómo las licencias notifican a sus usuarios el uso del servicio web. Tendrá que averiguar si puede confiar en las licencias para que solo usen el servicio web de forma adecuada. Si es así, es probable que pueda salir de permitir que el sitio web recopile las credenciales de usuario y páselas al servicio web. Si no es así, deberá proporcionar código que las licencias pueden usar para proporcionar un mecanismo seguro para recuperar las credenciales de usuario y pasarlas al servicio web. En cualquier caso, habrá una cantidad considerable de trabajo implicado.

Los problemas de privacidad restantes

Aunque no es necesario preocuparnos por la privacidad del usuario con respecto a los favoritos del usuario en la fase uno, todavía hay algunos problemas de privacidad que se deben considerar. Decidimos conceder licencia al servicio Favoritos. Esto significa que tendremos que mantener cierta información de contacto sobre las licencias. Esa información se encuentra en la categoría de información de identificación personal. Por lo tanto, tenemos los problemas de privacidad estándar a los que se enfrenta cualquier aplicación que mantenga la información de la cuenta.

Hemos solucionado estos problemas mediante una combinación de directivas y código. En el diagrama siguiente se proporciona una vista general de la arquitectura del sistema:

Figura 1. Arquitectura del servicio Favoritos en la fase uno

Nuestro servicio se implementa con una arquitectura superpuesta y se implementa en dos niveles físicos, la granja de servidores web y el clúster de datos. La información de la cuenta de licencia se almacena en una base de datos del clúster de datos. Nuestro servicio web y el sitio web a través del cual las licencias administran su información de cuenta se implementan en la granja de servidores web. Hay varias capas de protección para la información del licenciatario:

El clúster de datos no es accesible desde máquinas fuera de Cold Rooster Consulting.
El servicio Favoritos no necesita acceder a la información de contacto del licenciatario, por lo que usa un componente de inicio de sesión para autenticar licencias. El componente Logon solo recupera la información que necesita.
Por otro lado, el sitio web de administración de licencias necesita acceder a la información de contacto del licenciatario. ¿Cómo puede permitir que el licenciatario edite los datos? El sitio web realiza todo el acceso a los datos a través del componente de licencias. Los controles de acceso en el componente de licencias impiden que no sea el sitio web de administración de licencias llame al componente.
Los controles de acceso de la base de datos de licencias impiden que cualquier otro componente que no sea el componente de inicio de sesión y el componente de licencias accedan a la base de datos.
Los correos electrónicos de confirmación se envían a las direcciones especificadas en la información de contacto cada vez que se modifica la información de contacto.

Efecto neto: debe ser muy difícil que los usuarios no autorizados accedan o modifiquen la información de contacto del licenciatario, a menos que el identificador y la contraseña de un licenciatario estén en peligro. Incluso en esa situación, si alguien intentó cambiar la información de contacto, se informará al contacto actual.

Además, publicaremos una política de privacidad en nuestro sitio web. También podríamos proporcionar la directiva de privacidad junto con otra documentación que proporcionamos a nuevas licencias, como documentación sobre cómo escribir aplicaciones que usan el servicio Favoritos.

Conclusión

La privacidad del usuario es un problema espinoso para los desarrolladores de servicios web y las aplicaciones que los usan. Nuestro análisis del problema del servicio Favoritos nos hizo replantear todo el objetivo del servicio. Incluso con el ámbito reducido, se agregó un número significativo de requisitos para asegurarse de que la información del usuario estaba protegida frente a un uso inadecuado. El requisito más importante era la necesidad de restringir el acceso a las aplicaciones con licencia. La próxima semana veremos con más detalle las licencias: los modelos de negocio que consideramos, el modelo seleccionado y el impacto del modelo en nuestro diseño e implementación.

Si el servicio web necesita mantener información de identificación personal, tiene mucho trabajo que hacer más allá de implementar la funcionalidad básica de su servicio. Debe abordar los cinco elementos de prácticas de información justa: aviso, consentimiento, acceso, seguridad y cumplimiento. Deberá determinar cuándo debe solucionarlos directamente con los usuarios y cuándo puede aplazar los problemas de privacidad a las aplicaciones que usan el servicio web. Recomiendo encarecidamente involucrar a sus asesores legales en discusiones sobre estos problemas para asegurarse de que está actualizado con respecto a las leyes de privacidad de los usuarios dondequiera que se encuentren los usuarios. Los siguientes recursos proporcionan información adicional sobre la privacidad del usuario:

Last updated on 2007-02-02

Compartir a través de