Privacidade do usuário

Artigo
02/02/2007

Mary Kirtland

Microsoft Corporation

14 de fevereiro de 2001

Na minha última coluna, discuti a definição da visão do primeiro projeto de exemplo da equipe de diretrizes dos Serviços Web, o Serviço de Favoritos. Peço desculpas pelo longo atraso entre colunas; Eu estive fora durante a maior parte de um mês com um resfriado desagradável. Espero que as coisas estejam de volta aos trilhos agora para colunas semanais regulares para os próximos meses.

Para recapitular, o objetivo do Serviço de Favoritos é fornecer uma maneira de os aplicativos armazenarem os links favoritos dos usuários finais para sites em um local seguro, seguro e central, para que um usuário possa acessar seus favoritos por meio desses aplicativos, independentemente de qual computador o usuário esteja usando. Do ponto de vista técnico, isso parece um serviço bastante simples de implementar. É basicamente apenas um armazenamento de dados especializado.

Ao mesmo tempo em que começamos a examinar o Serviço de Favoritos, houve uma enxurrada de artigos de notícias sobre privacidade do usuário— especificamente sobre as informações que terceiros poderiam coletar por meio de anúncios em páginas da Web. Isso nos fez pensar: todo o modelo de Serviços Web é baseado em uma página da Web que usa serviços de terceiros, provavelmente sem o conhecimento do usuário final. Havia problemas de privacidade com os quais se preocupar?

Mesmo sem uma boa definição de privacidade do usuário, conseguimos criar alguns cenários possíveis que nosso Serviço de Favoritos proposto permitiria que parecesse questionável. Com base em nossa pesquisa inicial sobre os problemas, decidimos implementar o Serviço de Favoritos em fases, adiando os cenários questionáveis para fases posteriores. Nesta coluna, discutirei o que descobrimos durante nossa pesquisa inicial, os problemas difíceis que adiamos, as questões de privacidade que permanecem na fase um do projeto e o impacto deles em nosso design e implementação.

Privacidade definida

Vamos começar examinando o que queremos dizer com privacidade do usuário. Vamos concentrar nossa discussão sobre a privacidade do usuário e a Web. Sempre que você usa a Web, há três tipos de informações que podem ser trocadas entre o aplicativo que você está usando (como um navegador da Web) e os sites aos quais o aplicativo está conectado (como as páginas exibidas no navegador):

Informações que você cria usando algumas combinações de aplicativos, como o email que você escreve, suas fotos de férias, seus registros financeiros e assim por diante.
Informações sobre você, como seu nome, endereço, interesses pessoais e assim por diante, coletadas por um aplicativo para fornecer serviços a você.
Informações sobre o computador e/ou a conexão de rede que você está usando, como um endereço IP, coletadas por um aplicativo para fornecer serviços a você.

O problema com a privacidade do usuário é como essas informações são coletadas, usadas e distribuídas. Se você comprar um livro de uma livraria online, é claro que precisará fornecer seu nome, endereço e crédito cartão número para que a livraria conclua o pedido. Mas e se a livraria despejar essas informações em um banco de dados, juntamente com os registros dos livros específicos que você comprou? Por um lado, ele pode usar as informações para fornecer serviços úteis, como notificá-lo quando novos livros de seus autores favoritos são publicados. Por outro lado, pode vender suas informações pessoais, resultando em uma enxurrada de lixo eletrônico indesejado. O que constitui o uso justo dessas informações pelas empresas que fornecem os aplicativos que você usa?

Infelizmente, não há uma resposta única para esta pergunta. A coisa certa a fazer é difícil de determinar, especialmente porque a percepção pública e as regulamentações governamentais estão em fluxo (e podem variar de uma jurisdição legal para outra). A prática padrão para sites hoje é postar uma política de privacidade que informe aos usuários quais informações são coletadas e como elas podem ser usadas e distribuídas. No entanto, não há nenhum padrão sobre se o usuário deve ler a política de privacidade antes que as informações sejam coletadas ou antes que o usuário possa acessar o site.

A situação se torna ainda mais incerta com os Serviços Web. O usuário final provavelmente nem sabe que nenhum Serviço Web está sendo usado. Se um Serviço Web coletar informações que podem ser vinculadas a um usuário final específico (conhecidas como informações de identificação pessoal), como o provedor de serviços informa ao usuário sobre quais informações são coletadas e como elas podem ser usadas ou distribuídas? Os aplicativos que distribuem as informações pessoais para os Serviços Web precisam divulgar isso aos usuários finais? Tradicionalmente, as empresas não divulgaram que terceirizam aspectos específicos de seus processos de negócios. Por exemplo, uma empresa pode não divulgar que o atendimento ao pedido ou o atendimento ao cliente são terceirizados, embora a empresa de atendimento ao pedido e a organização de suporte ao cliente tenham acesso a informações pessoais sobre os clientes. Mas as regras podem ser diferentes online. Só o tempo dirá...

Práticas de informações justas

Práticas de informações justas mantêm os clientes informados e no controle de suas informações pessoais. Essas informações são protegidas contra uso, acesso ou distribuição indesejados, para que os clientes estejam confiantes e satisfeitos ao usar os produtos de uma empresa. Nosso primeiro passo para entender o que a privacidade do usuário significava para o Serviço de Favoritos foi ler sobre as práticas de informações justas da Microsoft. O Grupo de Privacidade Corporativa da Microsoft define cinco elementos de práticas de informações justas:

Aviso. Sua empresa deve definir uma política clara em relação à coleta, ao uso e à distribuição de informações pessoais. Essa política deve incluir o uso primário e secundário de dados, a distribuição de dados entre divisões de negócios dentro da empresa, o compartilhamento de dados com empresas afiliadas e não afiliadas e obrigações contratuais com fornecedores que dão suporte a transações comerciais. A empresa deve estabelecer diretrizes para alterações de política e o impacto das alterações nos dados coletados antes da alteração. Você desejará trabalhar com seus consultores jurídicos para garantir que a política seja algo que você possa impor em seus sites e serviços Web. Disponibilize a política para clientes e usuários por meio de vários canais de distribuição, incluindo online e offline.
Consentimento. Você deve fornecer mecanismos flexíveis e acessíveis para que os usuários gerenciem suas preferências de coleta, uso e distribuição de dados. Você precisará categorizar as informações em agrupamentos razoáveis e significativos para que os usuários possam descobrir o que estão consentindo e, portanto, não demorou muito para que o usuário configure as preferências. É importante pensar nos valores padrão para as preferências do usuário. O usuário precisa habilitar explicitamente um uso específico de informações pessoais (conhecido como aceitação) ou desabilitar explicitamente o uso (conhecido como recusar)?
Acesso. O usuário deve ser capaz de exibir e/ou editar quaisquer informações pessoais armazenadas, para garantir que elas sejam mantidas atualizadas e para gerenciar as preferências de uso. Você precisará descobrir quais informações o usuário pode editar e quais informações só podem ser exibidas. Por exemplo, o usuário pode não ter permissão para editar um identificador de usuário exclusivo, mas pode ter permissão para editar uma senha. Idealmente, as ferramentas para gerenciar informações pessoais estariam disponíveis para usuários online e offline.
Segurança. Você deve implementar medidas de segurança apropriadas para proteger as informações pessoais dos usuários. Isso inclui mecanismos de autenticação e autorização para proteger o acesso aos dados armazenados. Ele também pode incluir mecanismos para proteger dados durante a transmissão entre computadores. As medidas de segurança devem ser proporcionais à confidencialidade das informações. Por exemplo, você ficará muito mais preocupado com a segurança se estiver trabalhando com a conta bancária ou os registros médicos de um usuário do que se estiver trabalhando com uma lista de seus autores favoritos.
Imposição. Não adianta ter uma política de privacidade se você não a seguir. Sua empresa deve definir (e seguir) procedimentos para monitorar seus sistemas de informações para conformidade com suas políticas de privacidade. Defina processos de resolução de controvérsias para todos os serviços de informações do cliente e mantenha relações de porto seguro com organizações de certificação de terceiros. Embora a imposição seja amplamente externa ao site ou ao próprio serviço Web, você deve considerar quais tipos de informações de auditoria devem ser mantidas para dar suporte a processos de imposição. Por exemplo, talvez você queira acompanhar se e quando os usuários leram a política de privacidade, quando e como um usuário modificou as preferências do usuário e assim por diante.

Práticas de informações justas e favoritos

Tudo isso parecia razoável em teoria, mas ainda não estava completamente claro como isso se aplicava ao nosso serviço Web ou como você implementaria todos esses elementos para serviços Web em geral. Então passei algumas horas discutindo os problemas com um membro do Grupo de Políticas Corporativas. Começamos com uma lista de cenários que o Serviço de Favoritos poderia habilitar (com base em nossa instrução de visão inicial):

Um usuário instala algum suplemento na Internet Explorer que fornece um conjunto de opções de menu, como favoritos do Explorer da Internet, exceto que os favoritos são realmente armazenados em coldrooster.com. (Se você ler a última coluna, sabe que definimos um cenário de negócios em torno de uma empresa de consultoria. Agora podemos revelar que o nome desta empresa de consultoria fictícia é Cold Rooster Consulting, em homenagem ao galo que tem andado em torno de nosso prédio no campus da Microsoft. Portanto, coldrooster.com.)
Coldrooster.com fornece um aplicativo Web que permite que os usuários gerenciem seus favoritos.
Um site da Web, por exemplo, msdn.microsoft.com, fornece um botão em cada uma de suas páginas em que um usuário pode clicar para adicionar essa página ao favorito do usuário armazenado em coldrooster.com.
Msdn.microsoft.com fornece uma página da Web que exibe os favoritos de um usuário, que foram originalmente armazenados por msdn.microsoft.com em nome do usuário.
Msdn.microsoft.com fornece um aplicativo Web que permite que um usuário gerencie os favoritos que foram originalmente armazenados por msdn.microsoft.com em nome do usuário.
A Cold Rooster Consulting periodicamente pega todos os favoritos armazenados, despidos de qualquer informação que os vincula a um usuário específico e os despeja em um banco de dados separado para análise.
Msdn.microsoft.com fornece uma página da Web que exibe todos os favoritos armazenados por um usuário, independentemente do site que originalmente armazenou o favorito em nome do usuário.
Msdn.microsoft.com fornece um aplicativo Web que permite que os usuários gerenciem todos os seus favoritos.
A Cold Rooster Consulting fornece um Serviço Web separado que msdn.microsoft.com pode licenciar. Esse serviço permite que os licenciados recuperem informações como "favoritos favoritos" ou "pessoas que salvaram essa página também salvaram essas páginas", mas apenas para o domínio msdn.microsoft.com.
A Cold Rooster Consulting fornece o Serviço Web descrito no cenário 9, exceto que as recomendações retornadas para msdn.microsoft.com podem incluir favoritos de outros domínios.

Como precisaríamos vincular os favoritos de um usuário à sua identificação pessoal, como um endereço de email ou identificador do Microsoft Passport, para disponibilizar todos os favoritos do usuário por meio de qualquer aplicativo e qualquer computador, os dados de favoritos do usuário definitivamente se enquadravam na categoria de informações de identificação pessoal. Se ficarmos com essa definição do Serviço de Favoritos, precisaremos implementar práticas de informações justas por meio de uma combinação de política, procedimentos e código.

No momento da nossa discussão, não havia leis que exigissem notificar o usuário antes de armazenar informações em seu nome. Portanto, poderíamos implementar o elemento de aviso postando uma política de privacidade em coldrooster.com. Como os usuários saberiam que precisavam ler a política? Descobrimos duas opções: os usuários precisariam se inscrever com coldrooster.com antes de poderem armazenar favoritos por meio do nosso serviço, ou os aplicativos cliente precisariam notificar seus usuários de que o Serviço de Favoritos da Consultoria cold rooster estava sendo usado, com um ponteiro para nossa política de privacidade.

Do ponto de vista da segurança , os favoritos dos usuários não se enquadram na mesma categoria que os registros médicos, mas um usuário ainda desejará ter algum controle sobre quem pode acessá-los. Por exemplo, olhando para os favoritos que armazenei na minha máquina doméstica, você pode descobrir quais equipes esportivas eu apoio, que tipos de livros eu gosto de ler, que tipo de música eu gosto de ouvir e onde eu tenho minhas contas bancárias — não informações que eu quero que todos no mundo tenham acesso. E se alguém pudesse modificar meus favoritos, poderia substituir os links que selecionei por outros sites (possivelmente para fins nefastos, como interceptar informações confidenciais) ou adicionar novos links aos meus favoritos. Portanto, gostaríamos definitivamente de proteger o acesso aos favoritos dos usuários. E provavelmente gostaríamos de permitir que os usuários especifiquem quais aplicativos poderiam ler ou escrever quais favoritos. Por exemplo, posso permitir que o MSDN modifique meus favoritos para o domínio msdn.microsoft.com, mas não gostaria que o MSDN sequer visse os links para minhas equipes esportivas favoritas. Por que a MSDN deve se preocupar com isso?

Para permitir que os usuários controlem quais aplicativos poderiam ler ou gravar quais favoritos, precisamos implementar os elementos de consentimento e acesso de práticas de informações justas. Provavelmente também gostaríamos de implementar o código de auditoria para dar suporte ao elemento de imposição .

De repente, nosso simples serviço Web não parece tão simples! Que nível de controle devemos dar aos usuários? Devemos permitir que eles especifiquem exatamente quais aplicativos podem ler ou gravar favoritos de cada domínio? Ou devemos agrupar aplicativos e domínios em zonas para simplificar a configuração? E quais dos cenários listados acima devem ser habilitados por padrão?

Nosso especialista em privacidade não tinha nenhuma preocupação com os cenários 1 a 5. A política de privacidade típica abrangeria esses cenários. No entanto, para o cenário 2, precisamos considerar se coldrooster.com deve ser capaz de gerenciar todos os favoritos de um usuário, independentemente de qual aplicativo armazenou os favoritos para o usuário ou apenas os favoritos que os aplicativos da Cold Rooster Consulting adicionaram. Provavelmente, erraríamos no lado da cautela e diríamos que os aplicativos da Cold Rooster Consulting só poderiam gerenciar os favoritos do usuário adicionados por meio desses aplicativos, a menos que o usuário especificasse explicitamente que os aplicativos poderiam ser usados para exibir ou editar todos os favoritos armazenados em nome do usuário.

Mesmo o cenário 6 não é um grande problema, desde que a política de privacidade indique que podemos usar os favoritos do usuário armazenado para análise posterior. Novamente, precisamos considerar se os dados precisam ser particionados, seja pelo domínio ou pelo aplicativo que originalmente forneceu os dados, antes de serem analisados. E como muitas pessoas são cautelosas com a criação de perfil de dados, talvez queiramos dar aos usuários a capacidade de recusar a inclusão de seus favoritos nos dados em pool usados para análise.

Os cenários restantes tornam-se cada vez mais arriscados de uma perspectiva de privacidade. Isso não quer dizer que eles não devem ser implementados, apenas que seria mais difícil escrever uma declaração de política precisa, mas compreensível, e os usuários podem não estar confortáveis com os cenários, então eles provavelmente devem ser desabilitados por padrão (o usuário deve aceitar).

O cenário 7 inicialmente parece bastante inócuo, mas o que realmente significa de uma perspectiva de Serviço Web é que um aplicativo pode obter uma cópia de todos os favoritos de um usuário do Serviço de Favoritos. Depois que o aplicativo tiver uma cópia dos dados, ele poderá fazer o que quiser com ele. Se fornecermos um Serviço Web que dê suporte a esse cenário, provavelmente gostaríamos de restringir o acesso ao Serviço Web a clientes conhecidos com políticas de privacidade que atendam a alguns critérios mínimos.

O cenário 8 é ainda mais problemático. Depois que um aplicativo tiver a capacidade de modificar os favoritos de um usuário, o que é impedir que o aplicativo adicione páginas aleatórias à lista do usuário ou exclua um favorito que aponte para o site de um concorrente? Em outras palavras, como o Serviço Web pode distinguir solicitações de serviço válidas feitas por um aplicativo em nome de um usuário final de solicitações de serviço feitas por um aplicativo que o usuário final desconhece? Os mecanismos de segurança disponíveis que funcionam com HTTP e XML realmente não dão suporte a esse tipo de cenário de cliente/servidor/serviço diretamente— precisamos implementar alguma solução de segurança personalizada. Mesmo com o mecanismo de segurança personalizado, provavelmente haveria trabalho adicional necessário para fornecer uma maneira de os usuários especificarem quais aplicativos poderiam editar quais favoritos.

Por fim, os cenários 9 e 10 vão ainda mais longe no reino da criação de perfil online do que o cenário 6. Os problemas técnicos realmente não são diferentes daqueles já mencionados, mas o nível de desconforto do usuário seria ainda maior.

Com base nessa análise dos cenários, decidimos recuar e repensar a visão para a entrega inicial do Serviço de Favoritos. A nova visão da fase um se concentra nos cenários 3 a 5 acima. Essencialmente, cada aplicativo tem seu próprio repositório privado para favoritos do usuário. Se eu for para msdn.microsoft.com e armazenar um link para esta coluna, só poderá exibir ou editar esse link por meio da interface do usuário msdn.microsoft.com fornece.

Essa abordagem elimina vários problemas difíceis. Na verdade, elimina todo o problema de privacidade do usuário no que se refere aos favoritos dos usuários! Como cada aplicativo que usa o Serviço de Favoritos tem efetivamente um repositório separado de favoritos do usuário, não há necessidade de um esquema de identificação de usuário global que o Serviço de Favoritos entenda. Cada aplicativo pode usar qualquer tipo de identificador desejado. O Serviço de Favoritos não tem como interpretar esses identificadores ou correlacionar informações armazenadas por aplicativos diferentes. Como os dados só podem ser acessados por um único aplicativo (ou, mais precisamente, um único licenciado do Serviço de Favoritos), não precisamos nos preocupar em fornecer uma maneira de os usuários aceitarem ou desativar vários cenários. Delegamos efetivamente o problema de privacidade do usuário de volta ao aplicativo de chamada.

Isso não quer dizer que não nos importemos em resolver os desafios técnicos levantados em nossa análise dos cenários acima. Queremos abordá-los em uma fase futura do Serviço de Favoritos. Só queremos ter um pouco mais de tempo para pensar nas coisas e encontrar uma solução que nos sintamos confortáveis em recomendar para a comunidade de desenvolvedores.

E se você precisar resolver o problema hoje? Não consigo ver nenhuma maneira de implementar um mecanismo de licenciamento para usuários e aplicativos. Os usuários precisariam se inscrever em uma conta com seu serviço. Isso significa que você tem um site onde eles podem ler sua política de privacidade, inscrever-se na conta e gerenciar suas preferências. As empresas que desenvolvem aplicativos também precisariam se inscrever para uma licença para usar seu Serviço Web. Seu contrato de licença deve especificar como as licenças notificam seus usuários sobre o uso do serviço Web. Você precisará descobrir se pode confiar nos licenciados para usar apenas o Serviço Web adequadamente. Nesse caso, você provavelmente pode se safar de permitir que o site colete as credenciais do usuário e passe-as para o serviço Web. Caso contrário, você precisará fornecer algum código que os licenciados possam usar para fornecer um mecanismo seguro para recuperar as credenciais do usuário e passá-las para o Serviço Web. De qualquer forma, haverá uma quantidade considerável de trabalho envolvido.

Os problemas de privacidade restantes

Embora não precisemos nos preocupar com a privacidade do usuário em relação aos favoritos dos usuários na fase um, ainda há alguns problemas de privacidade para pensar. Decidimos licenciar o acesso ao Serviço de Favoritos. Isso significa que precisaremos manter algumas informações de contato sobre licenças. Essas informações se enquadram na categoria de informações de identificação pessoal. Portanto, temos os problemas de privacidade padrão que qualquer aplicativo que mantém as informações da conta enfrenta.

Resolvemos esses problemas usando uma combinação de política e código. O diagrama a seguir fornece uma exibição de alto nível de nossa arquitetura do sistema:

Figura 1. Arquitetura do Serviço de Favoritos na fase um

Nosso serviço é implementado com uma arquitetura em camadas e é implantado em duas camadas físicas, o farm da Web e o cluster de dados. As informações da conta de licença são armazenadas em um banco de dados no cluster de dados. Nosso Serviço Web e o site por meio do qual os licenciados gerenciam suas informações de conta são implantados no farm da Web. Há várias camadas de proteção para informações de licença:

O cluster de dados não está acessível em computadores fora da Cold Rooster Consulting.
O Serviço de Favoritos não precisa acessar as informações de contato do licenciado, portanto, ele usa um componente logon para autenticar licenças. O componente Logon recupera apenas as informações necessárias.
Por outro lado, o site de gerenciamento de licenças precisa acessar as informações de contato do licenciado. De que outra forma ele pode permitir que o licenciado edite os dados? O site executa todo o acesso a dados por meio do componente Licenciamento. Os controles de acesso no componente Licenciamento impedem que qualquer outra coisa que não seja o site de gerenciamento de licenças chame o componente.
Os controles de acesso no banco de dados licenciado impedem que qualquer coisa que não seja o componente logon e o componente licenciamento acessem o banco de dados.
Os e-mails de confirmação são enviados para endereços especificados nas informações de contato sempre que as informações de contato são modificadas.

Efeito líquido: deve ser muito difícil para usuários não autorizados acessar ou modificar as informações de contato do licenciado, a menos que o identificador e a senha de um licenciado sejam comprometidos. Mesmo nessa situação, se alguém tentasse alterar as informações de contato, o contato atual seria informado.

Além disso, publicaremos uma política de privacidade em nosso site. Também podemos fornecer a política de privacidade junto com outras documentações que damos a novos licenciados, como documentação sobre como escrever aplicativos que usam o Serviço de Favoritos.

Conclusão

A privacidade do usuário é um problema espinhoso para os desenvolvedores de Serviços Web e os aplicativos que os usam. Nossa análise do problema para o Serviço de Favoritos nos fez repensar todo o objetivo do serviço. Mesmo com o escopo reduzido, um número significativo de requisitos foi adicionado para garantir que as informações do usuário fossem protegidas contra uso inadequado. O requisito mais importante era a necessidade de restringir o acesso a aplicativos licenciados. Na próxima semana, examinaremos o licenciamento com mais detalhes: os modelos de negócios que consideramos, o modelo selecionado e o impacto do modelo em nosso design e implementação.

Se o Serviço Web precisar manter informações de identificação pessoal, você terá muito trabalho a fazer além de implementar a funcionalidade principal do seu serviço. Você precisa abordar todos os cinco elementos de práticas de informações justas: aviso, consentimento, acesso, segurança e imposição. Você precisará determinar quando deve lidar com eles diretamente com os usuários e quando pode adiar os problemas de privacidade para os aplicativos que usam seu Serviço Web. É altamente recomendável envolver seus consultores jurídicos em discussões sobre essas questões para garantir que você esteja atualizado sobre as leis de privacidade do usuário onde quer que seus usuários estejam localizados. Os recursos a seguir fornecem informações adicionais sobre a privacidade do usuário:

Partilhar via