opinião

Apple, o usuário, sua segurança e a estranheza de algumas ações

É obvio saber que todas as medidas que deixaram de ser tomadas para dar mais segurança ao usuário serão duramente criticadas. Mas o mais estranho é, no caso da Apple, ver essas mesmas medidas serem criticadas a mesma proporção.

Com as medidas tomadas pela Apple ficou claro que ele entendeu uma coisa, que é fato: segurança não é responsabilidade apenas da empresa que disponibiliza o Sistema Operacional, mas sim de todos. Desde a empresa que disponibiliza o Sistema Operacional, as empresas que disponibilizam as Aplicações e, não menos, do usuário.

A Apple conta com um sistema bem padronizado pela industria. Possui um Sistema Operacional com uma forte herança BSD Unix, o qual foi implementado o TrustedBSD, um projeto de segurança da DARPA (Agência de Pesquisas e Projetos Avançados de Defesa) e DoD (Departamento de Defesa dos EUA) dos EUA. Isso deu a Apple o certificado oficial da Unix v3, assim como a classificação de segurança TCSEC/B3.

PastedGraphic-7

Essa herança, assim como esses padrões de segurança trouxeram muitas características chaves que tornam o sistema uma “rocha”, entre eles:

  • MAC (Mandatory Access Control)
  • POSIX.1e ACLs
  • Firewall2
  • srm (Limpeza Segura de Lixeira)
  • Geli (FileVault2)

A Apple tem a habilidade de pegar ferramentas consagradas e populariza-la com um pacote de facilidades e um nome elegante. Esse é o caso do Geli (FileVault2) e do srm (Limpeza Segura de Lixeira), que são recursos BSD com interação Apple.

Seguindo essa característica e na busca de compartilhar a responsabilidade com o desenvolvedor e com o usuário, ela lançou dois recursos de segurança para o OS X, seguindo alguns características já implementadas no iOS. Eles são:

  • GateKeeper
  • SandBox

O GateKeeper serve para observar, verificar e bloquear o que está sendo instalado no seu Mac. Ele verifica se a Aplicação que será instalada tem código assinado por um programador conhecido por ela e se o código que foi compilado não foi alterado.

PastedGraphic-8

Ele é bem flexível, permitindo o total desligamento do recurso, assim como permite que apenas aplicativos da Mac App Store sejam instalados ou também um Aplicativo ao menos assinado.

Neste ponto podemos ver o total compartilhamento de responsabilidade, pois se a Apple não garante que aquele código é legítimo e que pode trazer problemas para seu Mac ou informação, se mesmo assim você instalar, será sob sua responsabilidade. Você, no lugar da Apple está garantindo que aquela Aplicação não irá lhe trazer dano.

O SandBox serve para isolar o processo de execução do Aplicativo, não permitindo acesso indevido deste a uma área crítica do sistema e nem a outra aplicação isolada. Isso ajuda a evitar, por exemplo, que uma aplicação maliciosa envie seus arquivos via internet para outra pessoa, pois um Aplicativo que deve ler fotos e exibir na tela não deve enviar uma foto para a Ethernet (Placa de Rede), salvo sob total solicitação do Usuário. Assim como também não pode pegar dados dos Contatos do Usuários e enviar por e-mail. Ele se restringe a ler, exibir e salvar fotos.

PastedGraphic-9

Este recurso tornou-se obrigatório a partir de 1º de junho de 2012, forçando os Desenvolvedores a colocar esse recurso em suas novas Aplicações e ou novas versões.

E neste ponto temos algo crítico a ser considerado. Obvio que com segurança algumas liberdades ficam mais restritas. É como cercar a sua casa com muros de 2 metros para lhe proteger de Leões. Você ficará protegido, mas não poderá mais correr pelo campo como outrora. Assim é a SandBox. Uma Caixa de Areia que limita até onde essa areia pode chegar.

Essa Caixa de Areia tem limites, mas com recursos de desenvolvimento, é possível contornar esse limite, solicitando ao usuário a possibilidade de gravar arquivos em outros lugares. Alguns lugares são totalmente restritos e portanto exigiria uma grande manobra para colocar o arquivo ali. Mas a pergunta que devemos fazer é: porque colocar um arquivo do Pages na pasta lib do sistema? E mais, porque o usuário precisa ver a pasta lib do sistema, se ela é restrita ao funcionamento do mesmo?

Vejam que estamos colocando a “liberdade” em cheque, mas são perguntas extremamente pertinentes. Ou seja, porque uma Aplicação quer acessar minha pasta de Certificados Digitais do sistema?

Sobre isso, existe um Aplicativo em especial que faz um tempo saiu da Mac App Store. Mas não satisfeito, o desenvolvedor se manifestou indignado com a postura da Apple no caso. Segundo ele, o Aplicativo MPlayerX perderia muitos recursos e se tornaria um outro “engessado” QuickTime.

Ele diz: “A Mac App Store é um grande canal para que mais pessoas conheçam o MPlayerX, mas há tantos recursos úteis à espera para serem implementados que eu não acho que deveria perder mais tempo com isso.”

Neste ponto eu me pergunto. O que ele quis dizer com o termo “isso”? “Isso” quer dizer Apple (que está prezando pela segurança do usuário) ou “isso” quer dizer segurança do usuário?

Outro termo levantado, que incomoda muito, é “necessário para o funcionamento do app”. Será que ler uma legenda automaticamente torna o Aplicativo tão diferente assim? Apenas pelo fato do Aplicativo não ler mais legendas automaticamente o torna “engessado”?

PastedGraphic-10

O que afinal é tão importante para o Aplicativo que faria tanta falta?

O desenvolvedor alega: “não poderá carregar legendas automaticamente, não poderá ir para o próximo episódio automaticamente, não conseguira salvar os snapshots onde você quer (???), e etc. Sem esses recursos, MPlayerX não passa de mais um QuickTime X manco, o qual eu não poderia aceitar.”

O que devemos chamar de ir para o próximo episódio automaticamente? Eu arrastaria os vídeos para dentro da Aplicação criando uma lista de arquivos e ele não passaria para próximo automaticamente? Estranho!

Agora, não há argumento mais confuso e furado do que o de não poder salvar os snapshots onde você quiser. Chega a ser incabível um desenvolvedor alegar isso. Talvez ele estava querendo dizer onde ELE quer, não onde o usuário quiser. Ou o Aplicativo dele dava snapshot automático sem a permissão do Usuário? Estranho!

Vamos apontar a crítica para o alvo correto. Vamos perguntar: porque um desenvolvedor não quer fazer a Aplicação mais segura e quer continuar tendo acesso às pasta de sistema?

Vamos fazer um teste? Abra um template no Omnigraffle 6 e tente salvar no diretório /. Veja o que ele diz:

pastedGraphic

Claro, pela regra você não pode salvar arquivos nessa pasta. É uma pasta crítica, raiz do sistema. Aliás, nem o Usuário deveria conseguir salvar algo ai.

Agora vamos criar uma pasta no diretório raiz:

pastedGraphic_1

Acabamos de criar uma pasta chamada TesteSandBox. Vamos agora tentar salvar o arquivo Omnigraffle nessa pasta:

pastedGraphic_2

Ok! Estamos no lugar correto, nomeamos o arquivo e… The document “Untitled” could not be saved as “Untitled.graffle”. You don’t have permission.

pastedGraphic_3

Claro, pela regra você continua não podendo salvar arquivos nessa pasta.

Agora faça o mesmo teste salvando em Desktop:

pastedGraphic_4

Ele consegue salvar!

Sendo uma pasta do usuário ele conseguiu salvar tranquilamente.

O Omnigraffle a partir da versão 6 está totalmente em SandBox. Mas como o Omnigraffle conseguiu salvar em Desktop?

É verdade que o SandBox traz uma certa inflexibilidade ao sistema e por isso a Apple implementou dois recursos para expandir esse acesso. Existem outros recursos chamados PowerBox e Marcação por Escopo de Segurança, que juntos dão ao desenvolvedor o poder de perguntar ao usuário se pode salvar em uma determinada pasta ou não.

PowerBox é uma tecnologia utilizada na comunicação com o usuário para expandir seu acesso, ou seja, sua Caixa de Areia. Através dele perguntamos ao usuário se podemos salvar determinado arquivo em outros lugar.

Após ser aprovado através do PowerBox salvar em outro lugar fora da pasta padrão do Aplicativo, podem ser usados os Marcadores. Existem dois tipo de Marcadares, um Marcador por Escopo de Aplicativo e um Marcador por Escopo de Arquivo.

O Escopo de Aplicativo determina que uma vez solicitado ao usuário o direito de escrever numa pasta, esse direito pode ser gravado e utilizado em outro momento. Exemplo, em um Download.

O Escopo de Arquivo determina que uma vez solicitado acesso a um arquivo a todos os seus correlacionados, esse acesso poderá ser gravado e utilizado em outro momento. Exemplo, em um projeto de vídeo, que tem um arquivo descritivo que aponta para vários vídeos.

Agora ficou claro como o Omnigraffle faz para salvar um arquivo no Desktop!

Outro Aplicativo interessante é o Infuse 2, da FireCore. Esse aplicativo do iOS, sistema muito mais restritivo do que o OS X, serve para exibir vídeos em formatos diversos. Ao colocar o Vídeo com sua legenda dentro através do iTunes ele carrega a legenda automaticamente.

pastedGraphic_9

Com o exemplo do Omnigraffle e do Infuse percebemos que as críticas apontadas pelo desenvolvedor são descabíeis.

Porém, isso nos leva a outra pergunta, porque o Omnigraffle consegue salvar seus arquivos na pasta escolhida pelo usuário e o MPlayerX não conseguiria? Estranho!

Com o mau exemplo MPlayerX, exponenciado pela mídia com notícias erradas e que trazem mais confusão do que esclarecimento, todos começam a criticar a Apple, dizendo que suas ações foram muito duras e que ela foi muito inflexível. A pergunta correta a se fazer é: porque o desenvolvedor do MPlayerX se importou tanto em deixar de usar as pastas de sistemas? O que ele queria tanto nas pastas de sistemas que a Aplicação dele não consegui mais ter acesso?

Estranho!

Botão Voltar ao topo