Dica de privacidade: não faça login no Gmail

10 de Abril de 2012, por Desconhecido - 22 comentários

Cada vez que você usa um serviço Google, você alimenta com dados um dossiê sobre você na internet.

Todos nós temos direito à privacidade (conforme as leis do lugar em que vivemos), mas é também nosso direito abrir mão da privacidade (novamente, conforme as leis locais).

Para as pessoas que decidem conservar sua privacidade online, tanto quanto possível, um grande problema é poder utilizar os serviços mais populares, como Gmail e Facebook, sem abrir mão completamente de sua privacidade.

Eu quero dar uma dica específica ao Gmail. O Google oferece vários serviços, em especial a conta de email gratuita Gmail e o buscador Google. Essa empresa obtém lucro através da venda de publicidade nas páginas gratuitas que oferece a você, junto com os serviços.

Para os publicitários, um anúncio "dirigido" - ou seja, que é apresentado somente para espectadores que têm certas características pré-definidas - é muito mais valioso que um anúncio para ser visto por todos. Por isso, o Google (e as empresas de internet em geral, que possuem esse modelo de negócios) procuram agregar informações sobre seus usuários, traçando seu perfil, e oferecem aos publicitários o serviço de publicar seus anúncios de forma dirigida.

Novamente, para quem aceita perder esse aspecto de sua privacidade - ou seja, para quem concorda em que exista um dossiê de suas atividades na internet - isso não é problema. Eu, pessoalmente, não gosto dessa perda, e estou procurando minimizar o prejuízo.

Para entender como o Google cria esses dossiês, é preciso entender que, do ponto de vista do buscador Google, há uma grande diferença entre um usuário logado e um não logado: para o usuário logado, o Google pode oferecer anúncios dirigidos, e pode adicionar as frases de busca usadas no dossiê da pessoa, permitindo dirigir anúnicos de forma mais focada, no futuro. Isso porque o login da pessoa permite ao Google consultar o dossiê correto para "dirigir" os anúncios. Já para o usuário não-logado, o Google só pode dirigir anúncios de acordo com as frases de busca da sessão atual, pois sem o login, ele não sabe associar o uso do buscador com um dossiê específico.

(Tecnicamente, o Google poderia correlacionar as frases de busca de um usuário não-logado com um perfil, a partir, por exemplo, do endereço IP do computador. Mas isso não é feito, atualmente. De modo que é possível explorar essa brecha e evitar que o Google adicione suas frases de busca ao seu dossiê pessoal, caso você use o Gmail, evitando logar no serviço através do navegador.)

Eu, por exemplo, utilizo o cliente de email Thunderbird. É gratuito e de código-fonte aberto. Eu tenho configuradas diversas contas de email nele, incluindo contas no Gmail. Ao mesmo tempo, uso o buscador Google cotidianamente. Apesar de o Google ter a possibilidade técnica de correlacionar meu uso do buscador com meu uso do Gmail, ele não faz isso: minhas buscas só mostram anúncios "dirigidos" de acordo com minha sessão atual, e de acordo com um serviço novo do Google chamado Account Acitivity (https://www.google.com/settings/activity/), que produz relatórios sobre o uso dos serviços do Google, eles acham que eu nunca uso o buscador deles.

Dessa forma, eu uso Gmail, e uso o buscador Google ao mesmo tempo, e no entanto o meu uso do buscador nunca alimenta o dossiê que o Google tem sobre mim.

Como eu disse antes, esta é apenas uma dica específica sobre como diminuir sua perda de privacidade ao usar o Gmail. Não creio que seja possível ter privacidade completa usando o Gmail, mas muitas outras medidas podem ser tomadas, como sempre apagar emails já lidos (ou seja, evite arquivar no próprio Gmail - grave uma cópia no seu disco rígido, se precisa guardar uma informação), ou encriptar suas mensagens sempre que possível. Assim que puder, eu detalho essas e outras maneiras de diminuir a perda de privacidade usando serviços online.



Quem joga tachinha nas ruas da USP???

14 de Agosto de 2011, por Desconhecido - 0sem comentários ainda

Segundo reportagem da Folha, há dois meses ocorre esse problema.

http://www1.folha.uol.com.br/cotidiano/959756-ciclistas-sao-sabotados-com-tachinhas-nas-ruas-da-usp.shtml

 



Que os apaixonados decidam!

26 de Outubro de 2010, por Desconhecido - 1111 comentários

Não vejo diferenças significativas entre os dois candidatos. Mas confio em muita gente que está convicta de algum candidato.

Conheço muita gente que acredita firmemente em alguma(s) diferença(s). Uma boa parte acredita que Dilma é melhor, outra boa parte acredita que Serra é melhor.

Procurei ouvir os argumentos, mas não me convenci que as diferenças apresentadas sejam mais importantes que a semelhança enorme entre os dois candidatos, e os dois partidos.

"Nada mais Saquarema do que um Luzia no poder", ou em palavras de hoje, 'nada mais PSDBista do que um PTista no poder".

O reverso da medalha vale, também: não creio que o Serra, se eleito, vá desmantelar o clientelismo construído pelo governo Lula. Vai ampliar e renomear tudo, tal como o atual governo fez com relação aos programas da era FHC. (Lembra das aulas de história, que no Egito antigo um faraó mandava apagar dos monumentos os nomes dos faraós anteriores? Pois é - a política brasileira está "no mesmo nível" que antigos egípcios).

Enfim, eu me percebo incapaz de ver diferença significativa entre os dois candidatos, ou os dois partidos, mas confio nos meus familiares, amigos e colegas que acreditam perceber alguma(s) diferença(s).

Me sinto como se estivesse vendo uma discussão entre torcedores de futebol apaixonadíssimos, ambos os lados tentando me convencer a torcer pelo time deles, só que se tratam de times de futebol dos cafundós da Estônia. Acostumado com futebol de qualidade, não posso deixar de me declarar igualmente aborrecido pelos dois times.

Mas respeito que hajam torcidas apaixonadas - afinal o futebol é muito mais sobre torcer do que sobre bom esporte. E quem sou eu para torcer o nariz para as torcidas dos cafundós da Estônia?

Não concordo que isso que propõem seja futebol, quero dizer, política, mas já que tem gente que faz tanta questão assim de uma opção ou outra, então vocês que estão apaixonados que decidam.

Vou votar de tal modo que a opinião dos que estão convictos seja mais evidente no resultado final.

Em tempo: hoje saiu a notícia de que o Brasil está na posição 69 dos países menos corruptos. (Link) A Estônia está na posição 26.



Alice Control Room

26 de Setembro de 2009, por Desconhecido - 0sem comentários ainda

Alice Detector

Olá!

Tal como eu escrevi no primeiro post a respeito deste treinamento que estou realizando aqui no CERN, a física relacionada ao experimento ainda me escapa, e por isso peço aos físicos que lerem este post que por favor me corrijam!

O Alice é um dos detectores do LHC. Talvez fosse mais adequado dizer que se trata de um "sistema de detecção", ao invés de simplesmente dizer que se trata de "um" detector.

O site relacionado especificamente com o Alice é o http://aliceinfo.cern.ch, aonde pode-se encontrar, por exemplo, a imagem abaixo, que indica os detectores que compõem o Alice.

Alice Detector Schematic

A imagem em detalhe é dos detectores mais centrais, que estão posicionados mais próximos do ponto aonde os feixes se cruzam. Esse subconjunto é chamado de ITS (Inner Tracking System).

Como pode ser visto na figura, o Alice é composto por diferentes detectores, que utilizam diferentes mecanismos para realizar suas medições. Além disso, cada detector tem uma finalidade específica.

A imagem no começo do post mostra o Alice "real".

O Alice é controlado a partir do ACR (Alice Control Room), que fica num prédio logo acima do detector, e que portanto também é o local a partir do qual pode-se ter acesso físico ao Alice. Na foto abaixo, o ACR fica atrás dos blocos de concreto à direita.

ACR

O ACR ele mesmo é composto por três salas, em geral bastante ocupadas e caóticas. Eu aproveitei uma noite em que não havia feixe, e tirei fotos das salas vazias, para mostrar melhor o local.

ACR Sala 1

 

Acima e abaixo: salas de controle de detectores individuais.

Sala de controle 2

Sala de controle 3

Acima: sala de controle dos sistemas de detecção.

Meu treinamento tem como foco o controle dos sistemas de detecção, e por isso irei falar um pouco sobre os três sistemas que eu já operei: DAQ, HLT e CTP. Eu irei explicar as coisas "de trás para frente", ou seja, vou mostrar os resultados e depois explicar como esses resultados são obtidos, pois me parece que assim aquilo que estou descrevendo não fica tão abstrato.

A imagem abaixo é a da tela de reconstrução de eventos online. Essa reconstrução é feita ao mesmo tempo em que a tomada de dados é feita, e ilustra o resultado de uma análise inicial dos dados, sendo que uma análise mais aprofundada deve ser realizada offline (online quer dizer ao mesmo tempo que a tomada de dados, e offline, independentemente da tomada de dados).

EVE

O que pode ser visto nesta imagem são os detectores, que são mostrados transparentes. Em opaco, temos bolinhas que indicam os pontos em que foram detectadas partículas, e as linhas que ligam esses pontos foram calculadas pelo reconstrutor de eventos. Essa imagem portanto é uma primeira reconstrução do estado do detector num certo instante, e que indica as trajetórias mais prováveis para certas partículas.

Quanto à física, essa imagem ilustra um evento de raios cósmicos, pois como se pode ver, as trajetórias das partículas apenas atravessaram o detector, não tendo se originado do centro, como é de se esperar numa colisão dos feixes. Esses eventos - chamados por aqui de cosmics - permitem calibrar diversas partes do sistema, na ausência de colisões reais de feixes de núcleos pesados.

Eu disse que os cosmics são um tipo de evento. As especificidades dos detectores que compõem o Alice fazem com que cada componente do Alice produza dados com frequência e quantidade de dados específicas. Mas esses dados, para que tenham relevância física, devem ser agregados no que se convencionou chamar de "eventos", e que descrevem o estado da matéria dentro do Alice num certo instante.

Mas como os detectores produzem dados em taxas diferentes, se estivéssemos "lendo" os dados de todos os detectores o tempo todo, seríamos sempre limitados a obter eventos de acordo com o detector mais demorado.

Essa limitação é incontornável, mas neste caso, "less is more". Tomar menos dados do que o máximo absoluto é uma estratégia muito interessante para aumentar a relevância física do experimento.

Isto é feito através do que é chamado de triggers (gatilhos). O princípio é o seguinte: ao invés de realizar a leitura sempre que o equipamento estiver livre, a leitura é iniciada apenas em certos detectores, os triggers. Se aquilo que for lido no trigger indica que ocorreu um evento relevante, só então os demais detectores são acionados. Dessa forma, são lidos menos dados - mas aumenta-se a taxa de leitura dos eventos interessantes, que por aqui são chamados de rare events (eventos raros).

A especificação de quais detectores serão triggers, e com que frequência, e com uma série de outros detalhes, é feita pelo operador do CTP, que trabalha na estação ilustrada abaixo.

CTP

Um conjunto de configurações feitos no CTP é chamado de "partition" (partição). Fundamentalmente, determina quais dados serão lidos, e com que taxa. Mas para que um evento possa ser reconstruído, também é necessário coordenar a leitura dos dados. Essa coordenação é feita pelo DAQ (Data Acquisition), que muitas vezes é realizado pelo operador do ECS.

A função do ECS é selecionar as partições que serão ativadas durante a execução da experiência (por aqui essa execução é chamada de run), e remover detectores individuais (que poderiam ser removidos no CTP, mas é bom que um sistema complexo tenha redundância!), e também indicar quais LDCs e GDCs serão utilizados para transformar os dados dos detectores em eventos. LDC significa Local Data Concentrator e GDC, Global Data Concentrator.

ECS

Acima, a estação de trabalho do operador ECS, que muitas vezes é chamado de DAQ. (Espera-se que essas duas tarefas sejam fundidas em breve. Aliás espera-se que o controle da experiência seja amplamente automatizado, assim que toda a calibragem e testes forem concluídos).

Obviamente, esta descrição é bastante simplificada e existem muitos detalhes que só poderiam ser apreciados vendo o sistema em funcionamento. Por exemplo, entre a leitura do detector e a gravação dos dados existe todo um subsistema, chamado de HLT (High Level Trigger).

HLT

Acima, a estação de trabalho do operador HLT.

A função do HLT é equivalente à do trigger: ambos recebem uma parte dos dados e decidem, com base nesses dados parciais, se o conjunto total dos dados tem relevância física, e então ativam (ou não) a próxima etapa da coleta de dados.

Os triggers, como expliquei acima, são os detectores "rápidos". Se sua leitura indica que eles detectaram alguma partícula, pode ser ou não o caso de que ocorreu um evento raro. Então a leitura de todos os detectores é feita, a menos que exista alguma contra-ordem.

Após a leitura dos dados dos detectores, esses dados devem ser armazenados em algum lugar. Os detectores do LHC irão gerar um volume de dados impressionante, e portanto não é possível armazenar todos esses dados num único local físico. Os dados são distribuídos para centros computacionais no mundo todo (inclusive para o Brasil).

Antes dessa distribuição, os dados são armazenados localmente, e como existe um intervalo de tempo entre uma leitura e outra que é ao menos igual ao intervalo de tempo que leva para o detector mais "lento" fornecer seus dados, é possível usar esse tempo para fazer uma análise superficial dos dados obtidos. Essa é a função do HLT.

HLT Cluster

Na foto acima, pode-se ver uma parte do cluster do HLT que é localizado nas proximidades do Alice, e que recebe os dados vindos do detector.

Quando eu digo "análise superficial" eu me refiro à impossibilidade de fazer uma análise que considere todas as quantidades físicas relacionadas a cada partícula, pois uma análise tão "profunda" exigiria muito mais cálculos, e portanto mais tempo, o que não é disponível - só temos o tempo entre uma tomada de dados e outra, algo da ordem de 1 milissegundo.

Atualmente, o HLT realiza, em especial, a reconstrução das trajetórias mais evidentes (tal como pode ser visto na ilustração do cosmic). Após essa reconstrução, um evento pode ser descartado ou gravado. Por exemplo, caso não possua ao menos X trajetórias, pode ser descartado.

Estes três sistemas de controle, CTP, DAQ, HLT, são os sistemas através dos quais é otimizada a probabilidade de que os dados efetivamente obtidos no Alice sejam de relevância física. Isto é feito levando em conta as restrições do mundo real, como dinheiro e tempo limitados, e com o objetivo de selecionar os eventos mais relevantes de acordo com certa configuração.

Eu creio que a pergunta que deveria ser feita nesse ponto é: como escolher uma configuração para o Alice? A resposta dessa pergunta exige uma compreensão clara da física relacionada à colisão de núcleos pesados em velocidades relativísticas, e eu não tenho essa compreensão, de modo que paro por aqui.

Numa nota mais pessoal, quero colocar uma foto de Genebra, que pude visitar duas vezes até agora. Pelo que pude perambular pela cidade, esses prédios são característicos de bairros residenciais.

Genebra, Rue des Eaux Vives

Assim como no CERN, ouve-se idiomas do mundo inteiro caminhando por Genebra. Eu tive a sorte de ir num dia em que ocorria uma feira em que as pessoas levaram todo tipo de coisa para vender ou trocar (comprei um livro sobre Switches Gigabit por 5 francos suíços : ) e havia nessa feira um certo ar de Brasil, com espetinhos feitos na calçada, rapaz com violão cantando MPB e muita gente falando e rindo.

As árvores nesta última semana mudaram de cor, e segundo o pessoal daqui, mais experimentados nesse negócio chamado outono, as folhas vão cair logo logo. Mas dizem que este ano o outono está demorando pra chegar. Deve ser sorte de brasileiro : )



Treinamento no LHC

5 de Setembro de 2009, por Desconhecido - 88 comentários

Olá!

Eu segurando um livro, sobre um gramado, com um arco-íris no céu.

Atualmente estou no CERN, que fica na fronteira entre a França e a Suíça, próximo a Genebra, realizando treinamentos com os sistemas do detector ALICE do LHC, e com a instalação e uso do middleware gLite. A foto acima foi tirada alguns dias atrás, dentro do CERN, logo após uma palestra do Bjarne Stroustrup (o livro que estou segurando é um "The C++ Programming Language, 3rd ed." autografado :)

Esta viagem é parte das atividades de pesquisa que desenvolvo sob orientação do Prof. Dr. Marcelo Gameiro Munhoz (http://www.dfn.if.usp.br/~munhoz/WWW/index.htm), do IFUSP. O objetivo deste blog é divulgar sobre o LHC em geral, o detector ALICE em particular, documentar minha viagem e com isso estimular outros alunos a iniciarem pesquisas relacionadas ao projeto.

Estou aqui no CERN desde o final de Agosto, e ficarei até o final de Novembro (num total de 3 meses). Estou hospedado numa cidade que é um brinco, e fica do lado francês do CERN, se chama Saint Genis Pouilly (http://www.saint-genis-pouilly.fr). Se alguém quiser informações práticas sobre a viagem até Genebra, acomodações, burocracias, etc., pode me enviar um email, terei prazer em ajudar no que puder.

A foto abaixo foi tirada na Rue de Gex, uma das principais vias de Saint Genis. É representativa da "parte nova" da cidade, que está surgindo, creio eu, devido ao estímulo econômico que a construção do LHC trouxe.

Uma rua com uma rotatória, árvores e prédios baixos, durante o dia.

Minha principal atividade em São Paulo, com relação ao ALICE, é administrar a parte do cluster Sampa do DFN que é dedicada ao projeto. Esta atividade exige, além do conhecimento de informática, algum conhecimento a respeito do experimento, em especial porque no futuro espero oferecer suporte aos usuários do Sampa que quiserem utilizar recursos do LCG. Neste post irei escrever um pouco sobre isso, e no próximo escreverei sobre o sistema de controle do ALICE, que é a outra atividade que estou realizando.

Uma breve introdução ao LCG

O LHC (Large Hadron Collider) é um acelerador de partículas com cerca de 27 km de circunferência (o maior já construído até hoje). Além de ser atualmente o maior acelerador de partículas do mundo, ele também é um dos mais recentes, e por isso tem características inovadoras no seu design. Uma delas, até onde sei, é a capacidade de ter raios que percorrem a circunferência em sentidos opostos utilizando o mesmo "tubo", sendo separados apenas pelo campo magnético dentro dos tubos que percorrem os 27 km do acelerador - sendo que estes campos são produzidos por meio de materiais supercondutores, resfriados a uma temperatura muito baixa, menor que 10 graus acima do "zero absoluto").

Essa, dentre outras características, permitirá que o LHC tenha grande luminosidade (http://en.wikipedia.org/wiki/Luminosity#In_scattering_theory_and_accelerator_physics), e isso fará com que ele produza uma quantidade muito, muito grande de informações: cerca de 15 PB ao ano!

Com as tecnologias computacionais de hoje, armazenar e analisar tantos dados em um único sistema é menos econômico do que fazer a mesma coisa de maneira distribuída, usando supercomputadores espalhados por todo o mundo. Um dos nomes que se dá a esse tipo de sistema é "grid". E por isso o armazenamento e análise dos dados do LHC é feita pelo LCG - LHC Computing Grid.

Até onde sei, existem três organizações brasileiras que fazem parte do LCG: UNICAMP, CBPF e USP. Na USP temos um cluster sob responsabilidade do prof. Sérgio Novaes, e o cluster Sampa, do DFN, do qual eu sou um dos administradores, sob supervisão do Prof. Dr. Alexandre Suaide (http://www.dfn.if.usp.br/~suaide/).

Um cluster é um certo tipo de supercomputador: chamamos de cluster um supercomputador que é composto por diversos computadores ligados entre si através de uma rede interna de alta velocidade (por exemplo, GigaEthernet ou Infiniband). Devido ao objetivo de ter a melhor eficiência possível, um cluster tem suas máquinas fisicamente próximas entre si, para facilitar administração física, segurança e evitar o uso de bridges ou longos cabos (devido à latência - http://pt.wikipedia.org/wiki/Lat%C3%AAncia).

Para que um cluster faça parte do LCG, além de uma série de burocracias (a mais importante sendo a MOU - Memorandum of Understandig, que especifica critérios de qualidade dos serviços que o cluster terá que prestar), deverá ser instalado no cluster um conjunto de softwares chamado gLite (http://glite.web.cern.ch/glite/), que efetivamente permitem a utilização do cluster como parte do LCG, e, de acordo com sua configuração específica, podem oferecer certos serviços e não outros. (Por exemplo, um cluster pode oferecer muito espaço de armazenamento, mas pouco tempo de CPU, mas com outra configuração do gLite poderia ser ao contrário - se o hardware permitir, é claro).

O gLite é classificado como "Middleware", pois ele intermedia o acesso ao sistema operacional, que detém os recursos de hardware da máquina, e o acesso aos recursos publicados no LCG.

De modo que tenho duas principais tarefas à minha frente, com relação ao gLite: configura-lo no Sampa de modo que esse cluster faça parte do LCG, e passe a oferecer seus recursos para o grid do LHC, e aprender a fazer requisições ao grid, para que este execute, em algum lugar do mundo, programas escritos pelos usuários do Sampa. Cabe um esclarecimento: o LCG não é, até onde sei, uma grid de uso "livre": os programas submetidos para execução (chamados de jobs), devem ser relacionados com os experimentos do LHC, por exemplo, reconstrução e simulação de eventos, análise de dados gerados pelos eventos, etc.

Estou dando andamento a essas tarefas no "prédio de TI", como é chamado por aqui.

Fachada de um prédio branco, 4 andares, com muitas janelas. Um carro branco na porta.

Logo na primeira semana, "flagrei" um rebanho passeando pelo CERN. Muito curioso, e creio que revelador do que se encontra neste pedacinho do mundo, atualmente: uma região que até pouco tempo era eminentemente rural, e que agora convive (de maneiras até inusitadas) com uma comunidade de cientistas vindos do mundo todo, mas em especial da Europa.

Alguns carneiros vistos num estacionamento de carros, atrás de uma persiana.

Ah, essa é a janela do lado da mesa em que estou trabalhando no gLite. Que lugar "feio", hein?

Espero escrever mais sobre o gLite e o LCG daqui a algumas semanas. O próximo post de divulgação que escreverei sobre o ALICE será sobre parte de seu sistema de controle (muitos screenshots, prometo :)

Até lá, e obrigado pela atenção!