Privacy Violation: Keyboard Caching

O campo identificado não trata as informações confidenciais devidamente, permitindo a entrada confidencial sem tomar também as medidas adequadas para desativar o mecanismo de cache de teclado do iOS.

O campo identificado não desabilita o mecanismo de cache de teclado do iOS. Como resultado, qualquer informação confidencial inserida no campo recentemente será armazenada em cache pelo iOS em um esforço para melhorar a funcionalidade de correção automática.

Exemplo 1: A entrada inserida em um campo de texto confidencial é armazenada no cache de teclado do sistema:

ViewController.h
...

@property (nonatomic, retain) IBOutlet UITextField *ssnField;

...

O código no Example 1 indica que o aplicativo utiliza um controle de entrada projetado para coletar informações confidenciais. Como o iOS armazena entradas de campos de texto em cache para melhorar o desempenho da respectiva funcionalidade de correção automática, todas as informações inseridas recentemente nesse controle de entrada podem ser armazenadas em cache em um arquivo de cache de teclado salvo no sistema de arquivos. Uma vez que o arquivo de cache do teclado é armazenado no dispositivo, se o dispositivo for perdido poderá ser recuperado, revelando assim quaisquer informações confidenciais contidas nele.

Dados privados podem entrar em um programa de várias maneiras:

- Diretamente do usuário em formato de senha ou informações pessoais.

- Acessados a partir de um banco de dados ou outro repositório de dados pelo aplicativo.

- Indiretamente de um parceiro ou de terceiros.

- Recuperados de repositórios de dados móveis, entre eles: catálogo de endereços, fotos tiradas, geolocalização, arquivos de configuração, mensagens SMS arquivadas, etc.

Às vezes, os dados que não tenham sido rotulados como privados podem ter uma implicação de privacidade em um contexto diferente. Por exemplo, números de identificação de aluno geralmente não são considerados privados, pois não há um mapeamento explícito e publicamente disponível para as informações pessoais de um aluno individual. No entanto, se uma escola gerar números de identificação de alunos com base em números de segurança social de alunos, esses números de identificação deverão ser considerados privados.

Preocupações de segurança e privacidade muitas vezes parecem competir umas com as outras. Sob o ponto de vista da segurança, você deve registrar todas as operações importantes para que qualquer atividade anormal possa ser identificada mais tarde. No entanto, quando dados privados estão envolvidos, essa prática pode gerar riscos adicionais.

Embora existam muitas maneiras de manipular dados privados sem segurança, um risco comum está relacionado a equívocos de confiança. Os programadores muitas vezes confiam no ambiente operacional em que um programa é executado e, portanto, julgam aceitável armazenar informações privadas no sistema de arquivos, no registro ou em outros recursos localmente controlados. No entanto, mesmo se o acesso a determinados recursos for restrito, isso não garante que os indivíduos que possuem esse acesso possam receber certos dados com confiança. Por exemplo, em 2004, um funcionário sem escrúpulos da AOL vendeu cerca de 92 milhões de endereços de email privados de clientes para um remetente de spam que comercializava um site de jogatina em atividade fora do país [1].

Em resposta a tais explorações notórias, a coleta e o gerenciamento de dados privados estão se tornando cada vez mais regulamentados. Dependendo da sua localização, do tipo de negócios administrado e da natureza de quaisquer dados privados que ela manipule, uma organização pode ser obrigada a cumprir uma ou mais das seguintes normas federais e estaduais:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Apesar dessas normas, violações de privacidade continuam a ocorrer com uma frequência alarmante.