Posts com a tag: web
Twitter via linha de comando
2013-05-07 14:27 -0300. Tags: comp, unix, web, about, em-portugues
Por falta de coisa mais interessante para fazer, e já que RSS não é exatamente a tecnologia da modinha, estou disponibilizando experimentalmente um feed do blog no Twitter. A continuidade do "serviço" está sujeita à existência de usuários. [Update: Pensando melhor, provavelmente todo o mundo que tem interesse em seguir blogs usa RSS. Enfim, o feed está aí, por enquanto.]
A parte interessante da história é que eu descobri um bocado de clientes de linha de comando do Twitter no processo. Dos que eu experimentei, o que melhor me satisfez foi o t. (Eu experimentei mais outros dois clientes: o TTYtter, um cliente interativo pra lá de bizarro, mas com mil features e aparentemente fácil de estender; e o twidge, que aparentemente não suporta UTF-8. Existem dúzias de outros clientes, como uma pesquisa no Google revela.)
Os poderes mágicos do t derivam do fato de ele ser particularmente conveniente de usar em scripts. Um exemplo extraído da documentação:
Favorite the last 10 tweets that mention you
t mentions -n 10 -l | awk '{print $1}' | xargs t favorite
É possível instalar o t pelo RubyGems, através do comando gem install t. Antes de instalá-lo, certifique-se de que você tem instalado o Ruby e o RubyGems (pacotes ruby, ruby-dev e rubygems no Debian/Ubuntu; não ter o ruby-dev é um problema comum).
Uma vez instalado, é necessário executar t authorize, para realizar o processo de registro da aplicação no Twitter e de autorização do acesso da aplicação à sua conta. Você pode executar t sem argumentos para ver uma lista dos comandos disponíveis. Para mais informações, dê uma olhada no README na página do projeto.
(Quem me contou foi essa página.)
To tweet or not to tweet
2013-04-07 22:41 -0300. Tags: life, comp, web, privacy, em-portugues
Dracula: "I'm all screwed"
Richter: "I am the instrument of your doom"
Dracula: "Perhaps not... not yet"
Richter: "What!?!?!"
???: "Richter! You killed my father! Prepare to die!"
Richter: "ALUCARD!!!"
Alucard: "You can't know... you'll never know how it feels..."
* TUM *
Richter: "NOOOOOOOO!"
– Castlevania, Hélio's edition
Há pouco mais de um ano eu abandonei o Twitter (well, not quite; eu só parei de postar lá, na verdade) por conta de eles terem vendido o acesso à base de tweets para umas empresinhas de mineração de dados. Há pelo menos metade desse tempo eu venho remoendo essa decisão.
Assumptions
Na época eu usava o Twitter com "tweets protegidos", i.e., apenas as pessoas que eu autorizei que me seguissem podiam ver os meus tweets. Eu assumia assim que apenas uns poucos conhecidos veriam o que eu estava postando.
Não é bem assim que a coisa funciona. Embora tweets protegidos não sejam retweetáveis, nada impede alguém capaz de ler um tweet de copiá-lo e retweetá-lo na mão. Retweets são uma feature fundamental do Twitter; não faz muito sentido contar com que algo postado no Twitter não vá ser retweetado. Proteger os tweets não melhora muito a situação.
Abandonemos, pois, a noção de que existe "publicidade seletiva" no Twitter: assumamos que "o que você diz no Twitter pode ser visto no mundo inteiro instantaneamente" (palavras dos termos de serviço, as it happens). E por "o mundo inteiro", leia-se o mundo inteiro. Na época da matrícula da UFRGS nesse ano eu vi alguns retweets da @ufrgsnoticias que provavelmente não estavam nos planos dos indivíduos retweetados e que eu fiquei cogitando comigo mesmo se não poderiam causar algum problema para os mesmos. Essa "falta de privacidade" é, me parece, uma propriedade fundamental do serviço Twitter, não um erro da companhia Twitter que o fornece. Assim (me parece), não faz sentido condenar o Twitter por esse tipo particular de falta de privacidade, mas tão-somente aprová-la ou não (e utilizar ou não o serviço de acordo).
(Essa falta de privacidade na verdade é uma propriedade compartilhada com blogs e páginas pessoais. No Twitter isso é um pouco mais acentuado pela facilidade de retweetar posts alheios, mas não é fantasticamente diferente. Essa "publicidade fundamental" é diferente do vazamento de informações pessoais para terceiros que não é fundamental para o serviço e não é do interesse do usuário. Mais sobre isso adiante.)
Ok, tweets são públicos. "Tweet privado" é praticamente uma contradição em termos. Aceitemos esse fato e tomemos por princípio que o Twitter só serve para postar coisas que não nos importamos de compartilhar com o mundo (e.g., links para coisas interessantes, recomendações de filmes/livros, etc.). Entendido isto, podemos seguir usando o Twitter com a consciência limpa.
Heh, não
Faltam dois problemas a considerar. O primeiro é o uso que se faz dessa informação além da mera publicação mundial. Isso inclui a venda ao acesso da base de tweets para as empresinhas de data mining, que foi a causa original do meu desgosto pelo Twitter.
Na verdade, o Twitter sempre vendeu o acesso a tweets, mesmo antes desse incidente; a diferença é apenas que o Twitter costumava limitar o acesso aos tweets dos últimos trinta dias. (O fato de que eles já brincavam de vender tweets antes não torna o ato de vender o acesso à base inteira nem mais nem menos ético, mas vamos adiante.)
O segundo problema são as outras informações que caem nas mãos do Twitter além dos tweets, e que uso o Twitter faz delas. Vamos por partes.
A miserable little pile of non-secrets
Pois, o Twitter vende, e sempre vendeu, o acesso a (porções da) base de tweets. Esses tweets são públicos para início de conversa*. A diferença entre baixá-los você mesmo e comprar o acesso é que as APIs do Twitter impõem certos limites na busca de tweets (e.g., aparentemente existe um limite de 1500 tweets nos resultados de buscas por termos), e que provavelmente a base é oferecida em um formato mais conveniente de manipular. (* Tweets protegidos são outra história. Eles vivem em um limbo questionável: a política de privacidade jamais menciona "tweets protegidos", então pelo menos para mim não está claro se eles são considerados informação pública (e conseqüentemente comercializável), ou se estão inclusos entre os dados pessoais que o Twitter diz não vender (o que não impede que o Twitter seja comprado e com ele seus dados, but I digress).)
A possibilidade de data mining, assim, pode aumentar com o fato de que o acesso à base de tweets é comercializado, mas ela não deixa de existir sem essa comercialização. Na verdade, a Internet inteira é alvo de data mining. Google (a organização) e outros mecanismos de busca já podem facilmente explorar toda informação pública na Internet, independentemente do seu consentimento. A diferença de postar no Twitter é facilitar a vida do Twitter e parceiros, mas postar em qualquer outro local público da web (como o identi.ca, ou seu blog pessoal) tem o mesmo risco.
É uma propriedade da Internet que toda informação pública é (em geral) facilmente acessível. Uma conseqüência disso é que coisas que antes eram muito difíceis (e.g., catar todas as notícias sobre um certo tópico ou pessoa nos jornais dos últimos N anos) agora são viáveis, e, junto com todas as vantagens que isso proporciona, vêm certas conseqüências negativas para a privacidade das pessoas. A sociedade vai ter que dar um jeito de se adaptar a isso, mas não é um problema do qual se possa escapar trocando o serviço em que essas informações serão publicadas (assumindo que se pretenda publicar essas informações para quem quer que as queira ler).
Fica a questão de se é ok o Twitter ganhar dinheiros vendendo acesso aos meus posts sem me pagar nada. Essa questão é sugerida como um exercício para o leitor.
The actual secrets
O segundo problema são os outros dados além dos tweets. Esses dados podem ser divididos em duas classes: os dados "inevitáveis", i.e., aqueles que o Twitter necessariamente obtém a partir do uso do serviço; e os dados "evitáveis", i.e., aqueles que você pode evitar mandar com um pouco de cuidado.
Os dados inevitáveis incluem:
- Seu IP e horários de acesso. Isso não é uma particularidade do Twitter, e sim um problema de todo serviço Web. Esses dados são particularmente preocupantes se o serviço é acessado periodicamente, já que em tese eles permitem determinar onde você esteve em dados momentos (e.g., se você acessa o serviço por celular e o seu IP varia dependendo do lugar onde você está).
Pode parecer (e me parece) improvável que o Twitter esteja interessado nessa informação. Porém, vale lembrar que o Twitter se localiza nos Estados Unidos, e portanto esses dados podem ser solicitados pelo governo daquele país, coisa da qual você pode não gostar. Na verdade, entretanto, seu IP e horários de acesso são um dado visível por todos os roteadores entre você e o serviço, o que significa que eles estão disponíveis para muita gente. Como já mencionado, isso é um problema da infraestrutura da Internet existente. Uma solução seria usar algo como o Tor na Internet inteira, mas isso é assunto para outra discussão.
Um ponto é que esses dados são inevitavelmente mandados para o Twitter. O outro é o que o Twitter faz com eles. Segundo a política de privacidade, "Log Data" é mantida por 18 meses, e depois disso pode ser ou removida ou simplesmente "desidentificada" (o que pode não ser suficiente).
- Sua lista de seguidores e seguidos. Em parte, esse é o tipo de dado que faz de uma rede social o que ela é. That's a bug and a feature. Além das listas, é possível determinar com quais pessoas você se comunica mais através dos seus tweets.
Os dados evitáveis incluem:
- Por onde você esteve. Diversos sites possuem "widgets" que permitem compartilhar a página via Twitter (entre outras redes sociais). Esses widgets são escritos de tal maneira que o Twitter fica sabendo que você acessou a página. A princípio, "Widget Data" começa a ser "apagada ou agregada" até 10 dias após sua coleta.
Essa informação é usada, entre outras coisas, para sugerir pessoas a seguir baseado nas páginas que você visitou, desde que você tenha optado por ativar essa feature. Se você estiver com o Do Not Track ativado, o Twitter pára de coletar dados no que diz respeito a essa feature. Eles não deixam de receber os dados, e não deixam de mantê-los por dez dias, pelo que eu entendo. Além disso, nem os termos de serviço nem a política de privacidade fazem qualquer menção ao Do Not Track, como comentado no post linkado anteriormente; apenas as páginas de ajuda falam sobre o assunto.
De qualquer forma, você pode evitar mandar essa informação simplesmente bloqueando acesso de sites de terceiros ao Twitter. No Firefox, você pode usar o AdBlock Plus para isso; a maneira mais fácil é acessar qualquer página que contenha um widget do Twitter, clicar no ícone do AdBlock, selecionar "Open blockable items", achar o platform.twitter.com e dar dois cliques sobre o cidadão. Na janela que se abre, clique no botão "Advanced view", e selecione a opção "Third-party only" (i.e., o Twitter só deve ser bloqueado a partir de sites de terceiros). Uma solução mais drástica é usar o RequestPolicy, que bloqueia tudo por padrão, mas pode ser um tanto quanto inconveniente de usar.
- Para onde você vai. Links externos em tweets são "reduzidos" para uma URL do tipo http://t.co/..., mesmo que a URL "reduzida" não seja menor que a original, e mesmo que a redução não seja necessária para o tweet caber em 140 caracteres. O Twitter faz isso para poder trackear para onde você está indo.
Interessantemente, quando você pára o mouse sobre um link desse tipo, a URL original aparece como title-text (i.e., em um popup), ou diretamente como o texto do link se for suficientemente curta. Assim, você pode usar o Greasemonkey e criar um novo user script com este conteúdo para fazer com que o Firefox substitua os links t.co pelos links originais na página do Twitter.
Fica a questão de se é "certo" usar um serviço que coleta dados que você acha que ele não deveria coletar só porque você consegue burlar a coleta. A resposta depende de quão idealista você está se sentindo hoje.
Outros comentários
Uma desvantagem de usar um serviço centralizado para publicação de informações (e.g., Twitter, Blogger, Wordpress, Facebook (ok, o Facebook tem inúmeros outros problemas, but I digress)) é que os "dados inevitáveis", tais como logs de acesso, ficam concentrados com uma única organização. Mesmo na arquitetura atual da Internet, em que acessar um serviço implica contar-lhe onde você está e possivelmente outros dados, a situação não é tão ruim se os dados estão espalhados entre vários servidores, o que dificulta sua exploração. (Seu provedor de acesso continua com um bocado de informação, entretanto.)
Por outro lado, uma rede social é mais útil quando um grande número de pessoas a usa; essa é uma vantagem de "todo o mundo" usar o Twitter, ao invés de cada um "roll their own" microblog. Porém, em teoria nada impede que cada um rolle seu own microblog e todos funcionem de maneira integrada, desde que eles usem um protocolo comum de comunicação.
µ.
Conclusão
A conclusão é que talvez eu volte a usar o Twitter no futuro próximo. Ou não.
The tableless table
2013-03-01 23:13 -0300. Tags: comp, web, em-portugues
![[Pintura de Hasegawa Tōhaku de um mestre zen prestes a cortar um gato em dois]](img/cutting-cat-by-hasegawa.jpg "Pintura de Hasegawa Tōhaku, ou assim reza a lenda. E o sujeito depictado provavelmente é o Nansen, e não o Mumon, mas ninguém ia notar a diferença mesmo. (長谷川等伯『南泉斬猫図』)")
Mumon, membro do CSS Working Group
Uma rápida inspeção do código-fonte atual (mas em vias de mudar) das páginas do ~vbuaraujo revelará que eu tenho (ou tinha) o costume questionável de usar TABLEs para layout mais ou menos shamelessly. Meus motivos para isso eram:
- Se a tabela for linearizável, a página vai funcionar corretamente em basicamente qualquer browser em uso, visual ou não (corrijam-me se eu estiver errado).
- Alguns layouts que são simples de criar com tabelas costumavam exigir uma boa dose de contorcionismo com CSS. O exemplo clássico (para mim, pelo menos, já que esse é o caso com a minha página principal e com este blog) é criar um layout com:
- Um cabeçalho que ocupa todo o espaço horizontal da página;
- Duas ou mais colunas de texto, tais que todas as colunas tenham a mesma altura, determinada pela maior altura exigida por uma das colunas;
- Uma nota de rodapé que ocupa todo o espaço horizontal da página.
Até hoje eu não sei qual é o jeito "certo" de se fazer isso com CSS clássico. Os tutoriais que se encontram por aí que mostram como é simples criar um layout com colunas em CSS costumam ignorar o detalhe do "todas as colunas com a mesma altura".
De qualquer forma, essa tabela do blog andava me incomodando, em parte porque uma das coisas que eu mais gosto do CSS é a possibilidade de desabilitá-lo (View > Page Style > No Style no Firefox) e ler as páginas como as seqüências de texto que Deus quis que elas fossem, coisa que não é possível quando a página usa TABLEs.*
Recentemente eu descobri uma maravilha do CSS 2.1: é possível usar CSS para instruir o browser a renderizar elementos quaisquer (e.g., DIVs) como tabelas, linhas, células, etc. Assim, migrar de um layout baseado em TABLEs para um baseado em DIVs + CSS é trivial:
<!-- Exemplo com CSS inline; normalmente a coisa decente a se fazer
é dar IDs aos elementos e estilizá-los com um arquivo CSS externo. -->
<H1>Título</H1>
<DIV STYLE="display: table; width: 100%; table-layout: fixed">
<DIV STYLE="display: table-row">
<DIV STYLE="display: table-cell; width: 75%">
<P>coluna 1
</DIV>
<DIV STYLE="display: table-cell: width: 25%">
<P>coluna 2
</DIV>
</DIV>
</DIV>
<P>Rodapé.
No caso de uma tabela com uma única linha, a DIV com display: table-row (equivalente a um <TR>) não é estritamente necessária; o browser cria uma "linha anônima" para conter as células. A propriedade table-layout: fixed indica que a largura das colunas é fixa; o padrão é auto, que permite que a largura das colunas seja reajustada de acordo com o conteúdo das células. Há outros valores possíveis para display relacionados a tabelas; para mais informações, consulte o standard.
_____
* Normalmente eu faço isso quando estou usando uma tela pequena e quero dar zoom em uma página sem que ela transborde para fora da janela ou que uma barra lateral cresça junto com o texto e coma espaço útil da tela.
Fun with CSS (not)
2013-01-06 21:20 -0200. Tags: comp, web, em-portugues
HTML segue sendo minha maneira preferida de editar texto formatado desde 1927. (Houve um tempo, antes de entrar para a CIC, em que eu fazia trabalhos de aula em HTML e depois copiava e colava do browser no Word para imprimir.) Entretanto, esse tal de CSS e seu box model às vezes me decepcionam.
No penúltimo post, eu resolvi colocar uma imagem à esquerda do texto, de modo que o texto seguisse normalmente no espaço vazio à direita da imagem. Trabalho para um elemento floated. Coisa simples, não? Acontece que por três pequenos acasos essa tarefa foi menos trivial do que parecia ser.
Primeira tentativa
O primeiro passo foi adicionar a figurinha com a propriedade float: left e olhar no browser o resultado. Como eu ainda não tinha escrito o resto do texto do post, o que aconteceu é que o link de comentários e o post seguinte ficaram arranjados ao lado da imagem. Embora o problema fosse desaparecer assim que eu continuasse a adicionar texto, por uma questão de princípios eu resolvi garantir que o conteúdo de um post ficaria isolado do post seguinte independentemente de quanto texto houvesse no post. A primeira coisa que eu tentei foi colocar um <DIV> em volta do post inteiro. Isso não resolve o problema: o elemento floated não conta no tamanho da DIV por padrão, e a DIV termina antes da figura. A solução que eu encontrei nas Internets (e que não vou me dar ao trabalho de vasculhar no histórico para descobrir onde achei) foi dar a propriedade overflow: hidden para a DIV que engloba o post. Não, a definição oficial da propriedade overflow: hidden não é essa. Anyway. Primeiro problema resolvido.
Segunda tentativa
Por um acaso infernal, a primeira coisa ao lado da imagem, depois de um subtítulo, era um BLOCKQUOTE. O comportamento normal do BLOCKQUOTE é deixar uma margem à esquerda, indentando o texto citado. Porém, o CSS resolveu calcular a margem a partir da esquerda da DIV do post, ignorando a existência da imagem floated. Como a margem era menor que a largura da imagem, ela era simplesmente desprezada. O mesmo problema acontece com listas (com o bônus de que as bullets de uma lista são posicionadas no espaço da margem por padrão, e conseqüentemente aparecem por cima da imagem).
Não achei uma solução decente para isso. A solução indecente foi:
- Para o BLOCKQUOTE, usar position: relative; left: 24px para simular a margem que se foi (mas cuidado para não deixar o lado direito do texto transbordar);
- Para a bullet list, usar overflow: hidden (evidentemente a panecéia universal dos problemas com floats).
Agora está tudo certo, certo?
Terceira tentativa
Bem, não. Por outro acaso infernal, a imagem era um link. Lembra do nosso BLOCKQUOTE com margem maluca? Pois a margem maluca invisível agora fica sobreposta à imagem, e com isso o trecho de imagem que fica ao lado do BLOCKQUOTE não é clicável. Tentei tacar z-index na imagem e no BLOCKQUOTE para mudar a ordem de sobreposição. Nada.
Acontece que:
- z-index só afeta elementos que tenham sido explicitamente posicionados (com position: whatever);
- Elementos posicionados sempre ficam mais no topo do que elementos floated, e elementos floated mais no topo do que elementos com arranjo normal.
Ou seja, quando eu taquei um position: relative; left: 24px no BLOCKQUOTE, ele passou a ser empilhado sobre a imagem floated, com margem e tudo. A solução, portanto, é tacar um position: relative; z-index: 10 na imagem, para valores arbitrários de 10 (e um z-index: 0 no BLOCKQUOTE por via das dúvidas).
Agora tudo funciona. Certo?
Facebook stalks you
2012-01-05 23:49 -0200. Tags: comp, web, privacy, em-portugues
Que o Facebook não tem respeito nenhum pela privacidade dos seus usuários não é nenhuma novidade. Porém, os meios de que ele se utiliza para obter dados ainda me surpreendem.
Como bom nerd, eu tenho o costume de olhar os logs de acesso do blog para ver em que páginas as pessoas têm caído. Ontem eu notei uma seqüência de acessos interessante:
Data: 2013-01-04 01:50:01 -0200
IP: (removido)
URL: /~vbuaraujo/blog/?entry=20120820-xmodmap
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11
Referer: http://www.facebook.com/l.php?u=http%3A%2F%2Finf.ufrgs.br%2F~vbuaraujo%2Fblog%2F%3Fentry%3D20120820-xmodmap&h=VAQEHMeNj
Data: 2013-01-04 01:50:01 -0200
IP: 66.220.158.114
URL: /~vbuaraujo/blog/?entry=20120820-xmodmap
User-Agent: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)
Referer: (vazio)
Isto é:
- Usuário abre um link via Facebook;
- Logo depois o Facebook requisita a página para olhar.
O link contido na string de User-Agent do bot do Facebook tem o seguinte a dizer:
Why does Facebook appear in my server logs?
Facebook allows its users to send links to interesting web content to other Facebook users. Part of how this works on the Facebook system involves the temporary display of certain images or details related to the web content, such as the title of the webpage or the embed tag of a video. Our system retrieves this information only after a user provides us with a link. You may have found this page because a Facebook user sent a link from your website to other Facebook users. If you have any questions or concerns about any links or content sent by one of our users, please contact us at legal@facebook.com.
Parece útil, não? Parece quase uma razão legítima para stalkear o usuário (heh). Acontece, entretanto, que os acessos do facebookexternalhit normalmente ocorrem menos de um segundo depois que um usuário clica em um link, não quando o link é submetido. Não tenho conta no Facebook, e portanto não tenho como testar melhor isso; estou me guiando pelos acessos do facebookexternalhit nos logs. (Para minha surpresa, o bot já tinha visitado o blog algumas vezes antes. Nunca tinha descoberto porque os acessos foram ao famoso post sobre os horários dos TM{1,2,3}, que eu filtro dos logs para visualizar, já que ele é responsável pela grande maioria dos acessos.) Porém, nem sempre os dois acessos aparecem juntos, então não sei exatamente qual é o princípio por trás disso.
Proxy Auto-Config
2012-11-14 01:24 -0200. Tags: comp, web, mundane, em-portugues
Problema: fazer o browser usar um servidor proxy para apenas alguns sites.
Solução: Existe uma tecnologia de última geração inventada pela Netscape em 1996 chamada Proxy Auto-Config (PAC). A idéia é mui simples e bella: escreve-se um arquivo JavaScript definindo uma função FindProxyForURL(url, host). Essa função recebe a URL e o hostname da página que o browser está tentando acessar, e retorna uma string especificando como o acesso deverá ocorrer:
- "DIRECT": acesso direto (sem proxy);
- "PROXY servidor_proxy:porta": usa o servidor proxy e a porta especificados;
- "SOCKS servidor_socks:porta": usa o servidor SOCKS e a porta especificados.
A esse script estão disponíveis algumas funções para manipulação de URLs e hostnames, além das funções normais do JavaScript.
No meu caso, o objetivo é acessar o portal da ACM através do proxy do Instituto de Informática, para poder baixar papers, e usar uma conexão direta para todos os outros sites. O arquivo PAC fica algo como:
function FindProxyForURL(url, host) {
if (dnsDomainIs(host, "dl.acm.org"))
return "PROXY 127.0.0.1:3128";
else
return "DIRECT";
}
De posse do arquivo PAC, basta configurar o browser para usá-lo. No Firefox, selecione Preferences > Advanced > Network > (Connection) Settings... > Automatic proxy configuration URL, e insira a URL para o arquivo (no caso de um arquivo local, algo como file:///caminho/do/arquivo.pac).
Note que você poderia escrever um script para substituir esse arquivo automaticamente de acordo com a presença de servidor(es) proxy, ou apontar a URL para um script CGI/PHP/whatever em um servidor HTTP para gerar a configuração de proxy dinamicamente.
Quem me contou foi esse povo.
The woes of Firefox
2012-07-18 17:43 -0300. Tags: comp, web, mundane, em-portugues
Seguindo a aparente trend no mundo das interfaces gráficas para GNU/Linux, algumas das novas "features" do Firefox e seus addons só são configuráveis via propriedades no about:config. Eis uma relação das que me foram necessárias.
- Cinzificação de trechos de URL: browser.urlbar.formatting.enabled
- Remoção do http:// do começo das URLs: browser.urlbar.trimURLs
- Animação de criação de tab: browser.tabs.animate
- Atualização automáticas das subscriptions do AdBlock: extensions.adblockplus.subscriptions_autoupdate (a opção sumiu da interface na versão 2.alguma-coisa)
Itens úteis nessa vida de 3G:
- Número máximo de conexões simultâneas: network.http.max-connections
- Número máximo de conexões simultâneas por servidor: network.http.max-connections-per-server e network.http.max-persistent-connections-per-server
- Timeout de conexão: network.websocket.timeout.*
Outros:
- User-agent: general.useragent.override. Note que essa propriedade não existe por default; você precisa criá-la dando um clique da direita na lista de propriedades e selecionando New > string. Eu me pergunto quantas mais propriedades ocultas existem.
Provavelmente vou adicionar coisas a esse post no futuro.
Communications with the Twitter Team
2012-05-30 21:43 -0300. Tags: comp, web, privacy, em-portugues
Formatação HTML e links adicionados por conveniência.
From: Vítor De Araújo <µµµ@µµµ.com>
To: privacy@twitter.com
Subject: Questions about Do-Not-Track and protected tweets
Date: Fri, 25 May 2012 15:00:28 -0300Hi!
I have two points I'd like to question about Twitter's privacy policy.
- Recently Twitter announced that it now honors the Do-Not-Track header. I have also noticed that you have updated the privacy policy, but I don't see any mention of Do-Not-Track in the text. So, does the commitment to Do-Not-Track have any official value, i.e., is it something users can rely on as long as the current privacy policy is in effect, and if so, what guarantees that?
- The policy does not directly say anything about protected tweets. May Twitter share protected tweets with third parties according to the current policy? Also, I noticed that the current policy states that information about who I follow and who follows me can be shared, something the old policy didn't. May this information be shared even for protected accounts?
I left Twitter in late February when I came to know about the selling of the historical tweet database to DataSift. I liked Twitter a lot, and I would be more confortable using it if the policy gave explicit guarantees about protected posts and accounts not being shared.
Thanks for the attention!
Five days later...
From: phantasm <notifications-support@twitter.zendesk.com>
To: Vítor De Araújo <µµµ@µµµ.com>
Subject: #5352694 Twitter Support: update on "Questions about Do-Not-Track and protected tweets"
Date: Wed, 30 May 2012 16:55:36 +0000#5352694 Twitter Support: update on "Questions about Do-Not-Track and protected tweets"
----------------------------------------------
phantasm, May 30 09:55 am (PDT):Hi,
Thanks for your inquiry. Our Privacy Policy at http://twitter.com/privacy describes the information that Twitter receives, the purposes for which it may be used, and the limited circumstances in which private personal information may be shared.
Regards,
The Trust & Safety Team
I had hope.
Google dies, Twitter dies, the self must also die
2012-03-01 20:44 -0300. Tags: comp, web, privacy, em-portugues
"Die, Twitter! You don't belong in this world."
"It was not by my hands that I'm once again given cash. I was brought here by humans, who want to pay me tribute."
"Tribute? You steal men's tweets, and sell them to your knaves."
"Perhaps the same could be said of all social networks."
"Your words are as empty as your privacy policy. Mankind ill needs a network such as you."
"What is a profile? A miserable little pile of secrets? But that's enough talk. Have at you!"
— Twittlevania: Symphony of the Night
Há mais ou menos um mês o Google anunciou que mudaria sua política de privacidade. A nova política entrou em vigor hoje, e permite ao Google cruzar os dados de seus diversos serviços para melhor servi-lo. Acho mui nobre e respeitável eles terem avisado enfaticamente com um mês de antecedência das mudanças. Mas respeitável ou não, eu já estava há horas com vontade de abandonar o Google, e esse foi o último empurrãozinho que me faltava. Nunca usei o GMail, pela questão da privacidade, então não tinha muito a perder. Matei minha Google Account no final do dia 28 de fevereiro (afinal, eles não explicitaram a partir de 1º de março de qual fuso-horário a política nova entra em vigor).
Na iminência de perder o orkut, e na necessidade de suprir minha compulsão de compartilhar links que ninguém lê, resolvi criar uma conta no Twitter no final de janeiro. Depois de observar alguns bots dando "follow" no meu perfil, e depois de me dar conta de como é fácil fazer data mining no Twitter (ainda mais com as APIs que o Twitter fornece), protegi minha conta.
Estava muito feliz com o Twitter.
Ontem o Twitter vendeu o acesso a todos os tweets postados desde 2010 para duas empresas de pesquisa. A empresa britânica de data mining Datasift fornecerá acesso aos dados através de uma plataforma cloud-based, que dá acesso não apenas ao conteúdo dos tweets, mas também a dados computados a partir dos mesmos. "We enrich every Tweet, every social conversation with sentiment, social media influence, topic-analysis, and NLP. No-one offers more insights for Tweets."
A empresa alega que conversas privadas (para algum valor de "privado"; nada garante que a definição inclui tweets protegidos) e tweets excluídos não serão acessíveis pelo sistema (o que não quer dizer que a empresa não tenha acesso aos mesmos), mas não podemos ter certeza de nada. De fato, os termos de serviço e a política de privacidade do Twitter não dão qualquer garantia quanto à privacidade de tweets protegidos. Tudo o que elas dizem é que "What you say on Twitter may be viewed all around the world instantly. You are what you Tweet!".
Por essa razão, estou em vias de matar minha conta no Twitter. Se todos fizessem o mesmo com serviços que desrespeitam nossa privacidade, as empresas seriam obrigadas a respeitá-la, para não perder o lucro. Infelizmente, o mundo tende a preferir conveniência a privacidade. Um dia o mundo aprende. Ou não.
Addons para combater tracking
2012-02-26 21:01 -0300. Tags: comp, web, privacy, em-portugues
O artigo sobre o uso do User-Agent para tracking me levou por um passeio seguindo os links de artigos relacionados pelo site da EFF. Recomendo que você faça o mesmo. Resolvi experimentar alguns dos addons recomendados neste artigo, além de alguns outros addons relacionados que encontrei pelo caminho. São eles:
- NoScript, um addon que bloqueia JavaScript por padrão e permite ativá-lo seletivamente para alguns sites de maneira simples;
- RequestPolicy, um addon similar para bloquear requests de um domínio para outro;
- Cookie Monster, similar para ativação seletiva de cookies;
- Smart Referer, que envia o header Referer apenas quando a origem e o destino do link estão no mesmo domínio.
Com exceção do último, todos esses addons estão nos repositórios do Debian/Ubuntu, de modo que para instalá-los basta um comando: apt-get install xul-ext-cookie-monster xul-ext-noscript xul-ext-requestpolicy. Depois disso, basta reiniciar o Firefox. O outro addon pode ser baixado do site da Mozilla.
No início, usar esses plugins é um pouco inconveniente: deve-se liberar cada site confiável que se visita da primeira vez. Porém, isso é um termo constante e não afeta a complexidade assintótica da navegação (ou quase). (Por outro lado, o Smart Referer é totalmente invisível e não afeta em nada a navegação, portanto não há desculpas para não usá-lo.)
Outro inconveniente que encontrei é que o RequestPolicy pede confirmação para redirecionamentos de páginas, que em geral são inofensivos [citation needed], e não há uma opção para liberar redirecionamentos para todos os sites por padrão.
Como ponto positivo, se carrega menos porcarias ao acessar uma página, o que pode ter um efeito significativo quando se está usando um 3G da vida. (Além do benefício à privacidade, obviamente.)
No más.