Prefiro construir pontes a muros
Vint Cerf, considerado um dos “pais da internet” e atualmente no Google, numa conversa de 45 minutos sobre a história da internet, tecnologia, Edward Snowden, a “internet das coisas”, segurança, política, privacidade e direitos humanos. Uma aula sobre história e muito mais.
Bônus: Vint Cerf e a venda de informação online no futuro
Quando o governo americano diz publicamente que está vigiando a comunicação de estrangeiros usando serviços como Facebook, Google, etc, é bom ficar esperto e dar atenção.
No e-mail de tanta (des)informação, o Cloudflare – serviço de roteamento de tráfego mundial, se manifestou sobre o assunto, afirmando jamais ter participado de tal programa pelo simples fato de não registrar muitas informações sobre os usuário e opinando sobre a gravidade, veracidade e características do programa e quais serviços tendem a ser tecnicamente mais seguros. Tecnicamente pois, não basta o serviço for seguro, é necessário que as empresas tenha um comprometimento com privacidade e direitos civis e estabelecer procedimentos para limitar a colaboração com programas como o PRISM e outras ordens judiciais que colocam em risco direitos.
Apesar de um um pouco técnico achei o post bem informativo e se você souber inglês, vale dar uma lida.
http://blog.cloudflare.com/cloudflare-prism-secure-ciphers
Destaco alguns trechos. Os grifos e comentários são meus:
When we determine that a request is too broad, we push back to limit the scope of the request. Whenever possible, we disclose to all affected customers the fact that we have received a subpoena or court order and allow them an opportunity to challenge it before we respond.
One of the ways we limit the scope of orders we receive is by limiting the data we store. I have written before about how CloudFlare limits what we log and purge most log data within a few hours. For example, we cannot disclose the visitors to a particular website on CloudFlare because we do not currently store that data.
To date, CloudFlare has never received an order from the Foreign Intelligence Surveillance Act (FISA) court. Moreover, we believe that due process requires court review of executive orders. As a policy, we challenge any orders that have not been reviewed and approved by a court. As part of these challenges, we always request the right to disclose at least the fact that we received such an order but we are not always granted that request.
While we understand the need for secrecy in some investigations, we are troubled when laws limit our ability to acknowledge that we have even received certain kinds of requests. CloudFlare fully supports the calls for transparency today by other web companies like Google, Microsoft, and Facebook. At a minimum, we request the law be updated to allow companies to disclose the number of FISA orders and National Security Letters (NSLs) they have received. We believe this is a modest request which does not harm the integrity of legitimate investigations while allowing for an informed public debate over the use of these measures.
[…]
Breaking a SSL key is hard, but not impossible. Doing so is just a matter of computational power and time. For example, it is known that using a 2009-era PC cranking away for about 73 days you can reverse engineer a 512-bit key. Each bit in a key’s length doubles the effective computational power needed to break the key.
[grosseiramente falando SSL são conexões mais seguras, pois são codificadas/criptografadas e é necessário que os dois lados tenham o código que tornam os dados csompreensíveis. Quantos mais bits tem a chave, mais difícil é quebra.]
[…]
So, if the key were 513 bits long, you’d expect the same modest PC 132 days to break the key. These tasks are highly parallelizable, so if you have two modest PCs then you’d expect the time to break the 513-bit key to drop down to 66 days again.
[novamente, em linhas gerais: quanto mais bits tem uma chave criptográfica, mais difícil decodificá-la]
[…]
Today many web companies have largely transitioned from 1024-bit SSL to significantly stronger 2048-bit keys…
Based on the SSL survey data, Twitter has led the way, shifting 100 percent of its HTTPS traffic to a 2048-bit key in mid-2010. By the end of 2012, the following websites had approximately the amount of requests in the parenthesis shifted to 2048-bit SSL:
- outlook.com (100%)
- microsoft.com (98%)
- live.com (90%)
- skype.com (88%)
- apple.com (85%)
- yahoo.com (82%)
- bing.com (79%)
- hotmail.com (33%)
Facebook is the laggard of the bunch and today is still using a 1024-bit key for all HTTPS requests.
Google is a notable anomaly. The company uses a 1024-bit key, but, unlike all the other companies listed above, rather than using a default cipher suite based on the RSA encryption algorithm, they instead prefer the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) cipher suites. Without going into the technical details, a key difference of ECDHE is that they use a different private key for each user’s session. This means that if the NSA, or anyone else, is recording encrypted traffic, they cannot break one private key and read all historical transactions with Google. The NSA would have to break the private key generated for each session, which, in Google’s case, is unique to each user and regenerated for each user at least every 28-hours.
Novamente, em linhas gerais e grosseiras: apesar do Google usar uma chave 1024 bits enquanto outras empresas usam 2048, pode ser mais seguro pois usa uma chave diferente a cada sessão enquanto outras empresas usam a mesma sessão por um tempão.
Em tese, se a NSA estiver gravando as conexões para decifrar depois, ao decifrar a chave SSL de um usuário no, digamos, Facebook, terá acesso a informações referentes a todo o longo tempo que daquele usuário usando a Chave Y. Já no caso do Google, como a chave muda frequentemente, a NSA teria informações de um espaço de tempo bem menor.
Em face estas informações e buscando mais privacidade, minhas sugestões são:
Finalmente comprei um smartphone com Android, e ando me assustando com alguns aplicativos pedindo acesso a algumas coisas que, ao meu ver, não fazem muito sentido pedirem. E levantam preocupações sobre segurança de informação e privacidade. Um em especial me chamou atenção: o Evernote, um serviço com várias ferramentas para produtividade no dia a dia, multiplataforma (iOS, PC, MacOs, Android, etc), que serve para fazer anotações, tarefas, lembretes, etc,inclusive na forma de áudio.
Para dar um pouco de contexto, a maioria dos apps que vi que pedem permissões estranhas são jogos ou aplicativos como o de chamada de táxis que desejam ver o registro de ligações, afinadores de violão que desejam ver seus contatos sociais, etc. Imagino que alguns usos sejam para poder divulgar o aplicativo, quando é de graça – como no caso do afinador. Mas não entendo por quê, por exemplo, um dos aplicativos de Táxis pede para ver todo meu registro de chamadas e contato, quando outros aplicativos dos mesmo tipo funcionam muito bem sem fazê-lo.
Já no Evernote, a maior parte das permissões que ele pedem são justificadas para seu uso: armazenamento, atalhos, câmera e áudio (você pode subir lembretes de áudio ou fotos junto com textos), uso da rede e por aí vai. Mas algumas me deixam muito preocupados, com podem ver na imagem que abre o post e na imagem abaixo:
Destaco, em português:
Ler eventos no calendário é essencial para o aplicativo, afinal, serve para guardar informações, mas até os confidenciais? E acessar arquivos protegidos?
Imagino que tenha gente que use – e bastante – o Evernote para guardar e gerenciar informação sensível, mas e quem não deseja fazê-lo, fica sem opção? Não seria possível fazer estas permissões opcionais? Na forma que está hoje, ou aceito tudo, ou não instalo. Talvez até tenha opção para gerenciar isto após instalação, mas resolvi não fazê-lo.
E, como sou novo com Android, não sei nem questionar a respeito, o time do Android no Google, ou o pessoal de desenvolvimento do Evernote. Mas de qualquer forma, ficam as sugestões: