Planeta Tilde

March 05, 2021

N.S. do Computismo

The Writer Automaton, Switzerland

A 240 year old doll that can write, a clockwork creation by Pierre Jaquet-Droz, a Swiss watchmaker. The doll is able to write any custom text up to 40 letters long

writer doll


March 05, 2021 11:20 AM

March 04, 2021

N.S. do Computismo

March 03, 2021

N.S. do Computismo

March 02, 2021

N.S. do Computismo

March 01, 2021

N.S. do Computismo

February 28, 2021


repo: using a local manifest

One of the useful and rarely mentioned configurations of repo is the use of local manifests.

See, repo is a powerful tool when you need to deal with a project that uses several git repositories at the same time, and those are controled by a manifest file. However, on your local development environment, you will often want to extend or change something on the environment described on the manifest, either by removing, adding or more often replacing one of the entries with a slightly different configuration.

You can do that by using a local manifest, that will be applied on the top of the other manifest files. The CyanogenMod project used to have a pretty nice documentation about this, but that's one of the contents that were not migrated into Lineage OS's wiki, so I decided to make this blog post, reproducing the old wiki's content.

The local manifest

Creating a local manifest allows you to customize the list of repositories used in your copy of the source code by overriding or supplementing the default manifest. In this way, you can add, remove, or replace source code in the official manifest with your own. By including repositories (which need not even reside on GitHub) in a local manifest, you can continue to synchronize with the repo sync command just as you would have previously. Only now, both the official repositories from the default manifest and the additional repositories you specify will be checked for updates.

Adding and replacing repositories

To add to the contents of the default manifest, create a folder called local_manifests under the .repo directory, then create an XML file (text file with .xml extension) inside that directory. You can call the XML file anything you like, as long as it ends in .xml. The default however is roomservice.xml. Also, you can create separate XML files for different groups of repositories. e.g. mako.xml for Google Nexus 4 related repositories and cat-eater.xml for an unofficial device on which you're working.

Let's start with an example which we can use to describe the syntax:

<?xml version="1.0" encoding="UTF-8"?>


<remote name="omap" fetch="git://" />

<remove-project name="CyanogenMod/android_hardware_ti_omap3" />

<project path="hardware/ti/omap3" name="platform/hardware/ti/omap3" remote="omap" revision="jb-dev"/>


The first line containing <?xml version="1.0" encoding="UTF-8"?> is a standard XML declaration, telling interpreters this is an eXtensible Markup Language file. Once this is established, the <manifest> and </manifest> tags enclose some contents which the repo command will recognize.

First, a remote for git is declared and given the name "omap". In git, a remote essentially refers to a place and method for accessing a git repository. In this case, is a site that contains special up-to-date repositories for Texas Instrument's OMAP platform. This is equivalent to the following git command:

git remote add omap git://

The next line removes a project (specifically, cyanogenmod/android_hardware_ti_omap3) declared in the default manifest. After running repo sync, it will no longer be available in the source tree.

The next line defines a new project. In this case, it replaces the removed project android_hardware_ti_omap3 with one from Texas Instruments, using the "omap" remote that was defined above.

When adding a new project that replaces an existing project, you should always remove that project before defining the replacement. However, not every new project need replace an existing cyanogenmod project. You can simply add a new project to the source code, such as when you want to add your own app to the build.

Note that when adding new projects, there are at least three parts defined:

  • remote -- the name of the remote. this can be one that was defined in either the default manifest or local_manifest.xml.
  • name -- the name of the git project-- for github it has the format account_name/project_name.
  • path -- where the git repository should go in your local copy of the source code.
  • revision -- (optional) which branch or tag to use in the repository. If this attribute is omitted, repo sync will use the revision specified by the <default ... /> tag in the default manifest.

After creating .repo/local_manifests/your_file.xml, you should be able to repo sync and the source code will be updated accordingly.

Note: You can use local repositories in the manifest by creating a remote that points to file:///path/to/source. For example: <remote name="local-omap" fetch="file:///home/username/myomap" />


All textual content of the CyanogenMod Wiki was released under the Creative Commons Attribution-Share Alike 3.0 Unported license (CC-BY-SA), and so this blog post should be considered licensed under the same terms.

tags: repo, manifest, local-manifest, local_manifests, git, en

comentários? tweetar  

by ~marado at February 28, 2021 07:42 PM

February 23, 2021

N.S. do Computismo


Epic MegaGames first comercial title (1991)

February 23, 2021 11:20 AM

February 22, 2021

N.S. do Computismo

February 19, 2021

N.S. do Computismo

February 17, 2021

N.S. do Computismo

February 16, 2021

N.S. do Computismo

February 11, 2021

N.S. do Computismo

February 10, 2021

N.S. do Computismo

Halt and Catch Fire Syllabus

Tell me one thing that will be true about computers ten years from now?

The only interface that makes computer graphics easy as Apple pie

Halt and Catch Fire syllabus

February 10, 2021 12:20 PM

Halt and Catch Fire Syllabus

Tell me one thing that will be true about computers ten years from now?


Halt and Catch Fire syllabus

February 10, 2021 11:20 AM

February 08, 2021

N.S. do Computismo

Sword of Damocles

An early Virtual Reality head mounted display

more info @ wikipedia

February 08, 2021 11:20 AM

February 05, 2021

N.S. do Computismo

February 04, 2021

N.S. do Computismo

John McCarthy

John McCarthy is best known for having coined the term "Artificial Inteligence" and having created the Lisp programming language John McCarthy playing chess

February 04, 2021 11:20 AM

February 03, 2021

N.S. do Computismo

January 29, 2021

N.S. do Computismo

January 28, 2021

N.S. do Computismo

WTF is Going on with Gamestop stock

Social engineering at its finest


Indepth article @ vice

January 28, 2021 11:20 AM

January 27, 2021

N.S. do Computismo

January 26, 2021

N.S. do Computismo

Old Computers in Paper


Construct the computer from your childhood or build an entire computer museum at home with these paper models @ Rocky Bergen

January 26, 2021 12:20 PM

January 22, 2021

N.S. do Computismo

January 21, 2021

N.S. do Computismo

January 20, 2021

N.S. do Computismo

January 15, 2021

N.S. do Computismo

January 14, 2021

N.S. do Computismo

January 08, 2021

N.S. do Computismo

Microsoft Clipart Extra

2 kitties

Microsoft Clipart Extra: clipart from Microsoft Office 97 Professional (English). contains the Windows Metafiles from the collection, which is most of the images, converted to SVG with wmf2svg.


January 08, 2021 11:20 AM

January 06, 2021

N.S. do Computismo

DALL·E: Creating Images from Text

A trained a neural network called DALL·E that creates images from text captions for a wide range of concepts expressible in natural language.

a store front with openai written on it hardcore computing hardcore computing

source @

January 06, 2021 11:20 AM

January 05, 2021

N.S. do Computismo

January 04, 2021

N.S. do Computismo

December 31, 2020

N.S. do Computismo

Edward Sownden's initial interview (2013)

"The 29-year-old source behind the biggest intelligence leak in the NSA's history explains his motives, his uncertain future and why he never intended on hiding in the shadows"

@ the guardian

December 31, 2020 11:20 AM

December 30, 2020

N.S. do Computismo

December 29, 2020

N.S. do Computismo

How not to be Alone

"It is harder to intervene than not to, but it is vastly harder to choose to do either than to retreat into the scrolling names of one’s contact list, or whatever one’s favorite iDistraction happens to be. Technology celebrates connectedness, but encourages retreat. The phone didn’t make me avoid the human connection, but it did make ignoring her easier in that moment, and more likely, by comfortably encouraging me to forget my choice to do so. My daily use of technological communication has been shaping me into someone more likely to forget others. The flow of water carves rock, a little bit at a time. And our personhood is carved, too, by the flow of our habits."

more @ New York Times

December 29, 2020 11:20 AM

December 28, 2020

N.S. do Computismo

Classified docs reveal NSA's vast real-time warrantless Web surveillance (2013)

"For seven years, the US National Security Agency (NSA) has been using a congressionally approved warrantless Web surveillance system with a near-limitless ability to spy on Americans’ phone calls, emails, video chats, search history and more."

more @ rt

December 28, 2020 11:20 AM

December 27, 2020

N.S. do Computismo

December 24, 2020

N.S. do Computismo

December 23, 2020

N.S. do Computismo

Wi-Fi signals enable gesture recognition throughout entire home

"Forget to turn off the lights before leaving the apartment? No problem. Just raise your hand, finger-swipe the air, and your lights will power down. Want to change the song playing on your music system in the other room? Move your hand to the right and flip through the songs."

December 23, 2020 11:20 AM

December 22, 2020

N.S. do Computismo

December 21, 2020

N.S. do Computismo

December 20, 2020

N.S. do Computismo

December 19, 2020

N.S. do Computismo

The Wireless Newspaper

«Em 1938 O primeiro jornal wireless foi enviado da estação de rádio WOR em Nova Iorque. A foto mostra crianças a ler a página infantil de um jornal do Missouri. via Nationaal Archief (

wireless newpaper

December 19, 2020 12:20 PM

December 18, 2020

N.S. do Computismo

Cappella 2

The all seeing gods.

Capella 2

more info:

December 18, 2020 02:20 PM

December 17, 2020

N.S. do Computismo

The Information Machine

The Information Machine – Charles and Ray Eames (1973)

December 17, 2020 11:20 AM

May 18, 2020


O num verdadeiro computador retro

O HTML, quando bem feito e quando não precisa de muito mais do que apresentar informação textual, pode e deve ser feito de forma a que seja de fácil leitura no maior número de browsers e dispositivos: computadores tradicionais, tablets, telemóveis e até mesmo browsers sem suporte para CSS como terminais de texto ou browsers para invisuais.

A melhor forma de o fazer, tipicamente, é construir o HTML mais simples possível, que consiga ser de fácil leitura em software sem suporte para CSS. Só numa fase posterior é que se deverá dar maior atenção à componente visual, através de CSS e Javascript, para que seja apresentado de uma forma coisa jeitosa num browser mais moderno.

Quis saber se o seria facilmente navegável na minha plataforma retro preferida: o Amiga. Como browser usei o IBrowse que, apesar de ter sido lançado há 23 anos atrás, teve uma actualização ainda este ano.

Foi uma surpresa agradável. O passou com distinção no teste. Vejamos a homepage:


O espaço do ~rlafuente também passou o teste:


E o ~marado provou que usar tables para construir o layout uma página html (em vez de divs) tem as suas vantagens. Vejam:


Como não há milagres, o Hotel (que é uma bela obra de arte) depende muito de CSS e é apresentado apenas como uma simples lista. Lanço o desafio à ~aiscarvalho para a construção de uma versão em ASCII art.


Uma nota final: o computador usado para este teste foi uma versão "moderna" do Amiga baseada em FPGA, uma Vampire V4 Standalone. O sistema operativo é o Amiga OS 3.9 que infelizmente continua a ser proprietário devido a intermináveis guerras sobre a propriedade intelectual do mesmo. Felizmente temos o AROS 68k que está a caminhar a passos largos para se tornar uma séria alternativa open-source ao velhinho Amiga OS.

tags:, html, css, retro, amiga

by ~epifanio at May 18, 2020 11:15 PM

May 17, 2020


Dia Mundial da Internet

Feliz dia mundial da Internet! Sabias que...

  • Há 30 anos atrás (1990) foi organizada a 1ª Convenção Portuguesa de Unix.
  • Há 29 anos atrás (1991) foi montado o ".PT" ...
  • Há 28 anos atrás (1992) o tld "PT" foi reconhecido. O primeiro talker Português foi criado.
  • Há 27 anos atrás (1993) a EUNET era assim.
  • Há 26 anos atrás (1994) teve lugar no LNEC, o seminário "Portugal na Internet". Ligar à internet em Portugal era assim:

ligar à Internet em Portugal, em 1994

  • Há 25 anos atrás (1995) foi fundado o SAPO, na Universidade de Aveiro.
  • Há 24 anos atrás (1996) existem 10 entidades com licença para prestação de Serviços de Telecomunicações Complementares Fixos, no âmbito dos quais se pode enquadrar o acesso à Internet.
  • Há 23 anos atrás (1997) a PTNET, a maior rede de IRC Portuguesa, foi criada. Pulhas, Toxyn e KaotiK iniciam a sua campanha de hacktivismo por causa da ocupação a Timor.
  • Há 22 anos atrás (1998) a Saber & Lazer - Informática compra o SAPO.
  • Há 21 anos atrás (1999) a Sonaecom cria a Novis, resultante da compra da IP Global, e a marca Clix para o mercado residencial. A Esoterica é comprada pela VIA NET.WORKS.
  • Há 20 anos atrás (2000) a EUnet Portugal passa a KPNQwest.
  • Há 19 anos atrás (2001) a ANSOL - Associação Nacional para o Software Livre, é anunciada, durante a edição de 2001 do "Porto, Cidade Tecnológica".
  • Há 18 anos atŕas (2002) tanto o SAPO como o Clix lançam as suas ofertas de ADSL.
  • Há 17 anos atrás (2003) a moda dos blogs chega em força a Portugal, com a criação do serviço SAPO Blogs.
  • Há 16 anos atrás (2004) a Novis adquiriu a KPNQwest Portugal (antiga EUNet Portugal), ficando assim com o legado do primeiro ISP em Portugal (ainda enquanto PUUG).
  • Há 15 anos atrás (2005) o Clix lançou no mercado uma oferta de 16Mbps utilizando a tecnologia ADSL2+.
  • Há 14 anos atrás (2006) o Clix lançou para o público a SmarTV, um serviço de Televisão Digital e Home Video utilizando o sistema IPTV sobre a tecnologia ADSL2+, sendo a primeira oferta em Portugal a utilizar esta tecnologia.
  • Há 13 anos atrás (2007) a marca Novis foi incorporada pela marca Optimus. O evento SAPO Codebits teve a sua primeira edição.
  • Há 12 anos atrás (2008) apareceu a Clix Fibra, a primeira oferta comercial em Portugal de ligação à internet através de fibra óptica.

tags: pt, internet, history

comentários? tweetar  

by ~marado at May 17, 2020 10:51 PM

May 09, 2020


Contact Tracing

Pensei fazer um tweet, e quando dei conta tinha monologado uma thread bem grande. Para facilitar a sua leitura, decidi publicar essa thread aqui.

O Ricardo Lafuente escreve mais um interessantíssimo artigo no seu blog, desta vez sobre Contact Tracing.

Todo o artigo é bom (e leitura recomendada), mas gosto principalmente por estas duas frases que, em meu entender, são as que metem o dedo bem mesmo na ferida:

Seria ótimo termos em mãos a informação sobre o que se pretende implementar em Portugal, mas não existe ainda qualquer documento formal a descrever o que se está a preparar, apenas comentário de imprensa. Não pode ser assim, se estamos a falar de uma decisão sócio-política com implicações que ainda não conseguimos quantificar enquanto sociedade, mas cujo desfecho definirá as nossas existências nos tempos que aí vêm.

A meu ver, não podemos continuar a estar nesta situação em que aparentam estarem a testarem-se águas sobre várias soluções e a tentar formar opinião pública, sem que todas as cartas sejam postas em cima da mesa. É assim que temos coisas como este artigo da DECO, ao mesmo tempo que temos a admissão, mesmo dos proponentes deste tipo de apps, que, na realidade, a privacidade não está garantida, apesar dos riscos estarem minimizados (supostamente: nos promenores, encontram-se diversos compromissos a serem tomados mas várias soluções).

O artigo da DECO tb é apresentado como "país quer ARCs", quando na realidade os números que lá se vêm falam do inverso: afinal, "a maioria" pouco importa neste discurso, menos de 60% da população se voluntaria para o uso, e sem 60% estas apps são inúteis, dizem os estudos.

De notar que, pelo que se vai sabendo pela imprensa, a "app oficial", apoiada pelo Governo, será a StayAway, do INESC TEC. Mais uma vez, só se sabe dessa app o que vai aparecendo na imprensa, mas já com detalhes que levantam muitas questões.

Mas será mesmo assim? Urge que o Governo seja claro e transparente. Vai mesmo adoptar uma ferramenta? Haverá ainda espaço para o debate público sobre esta matéria? A adoptar, será mesmo a StayAway? Se sim, há ainda espaço para debate sobre as decisões de arquitectura da solução?

Urge termos respostas para estas perguntas. Até lá, será útil ler o artigo de ontem da ACM sobre o tema. Destaco três frases:

No known tracing applications can fully preserve individual privacy and anonymity, while multiple technical issues hinder the ability to prove or assume the apps' accuracy.

Moreover, high technical quality and functionality are insufficient for ensuring their efficacy.

Mechanisms should be employed for seeking the public’s and civil society representatives’ comment on proposed contact tracing technology and all aspects of its intended deployment.

tags: pt, tracing, COVID-19, privacy

comentários? tweetar  

by ~marado at May 09, 2020 03:38 PM


Pensar antes de instalar

E de repente, uma solução: as apps de rastreamento de contacto estão na ordem do dia. É boa ideia instalar?

Estão a chegar: as apps de rastreamento de contactos (ARCs) são apresentadas como uma possível esperança na luta contra o covid-19, como uma forma de nos prevenirmos coletivamente, e como um meio de reforçar o esforço epidemiológico para analisar o alastramento da doença. No entanto, elas levantam muitas questões que põem seriamente em causa a sua capacidade de corresponder a esses objetivos.

Uma das primeiras preocupações foi se uma ARC poria em causa a privacidade das pessoas, expondo o seu estado de saúde ou mesmo localização a sabe-se lá quem, e para isto surgiram um conjunto de abordagens com a privacidade como preocupação. Essas abordagens "privacy-first" têm procurado alguma consciência sobre as implicações de privacidade, embora não sejam apenas dessa ordem as consequências nefastas das ARCs. Neste tipo específico de ARCs que têm em conta a privacidade inclui-se a ARC desenvolvida pelo InescTec, que tudo indica que receberá o aval do governo português. Estas ARCs "amigas da privacidade" correspondem a um esforço genuíno de limitar o seu alcance, face a alternativas grotescas baseadas na geolocalização e cruzamento de dados, como no Reino Unido. Mas mesmo com essa preocupação, elas contêm riscos sérios que não são resolúveis tecnicamente.

Antes de entrar pelo lado técnico, importa ter o retrato total da problemática à volta das ARCs. É que neste momento as pessoas estão desesperadas por uma solução para o momento em que vivem. Estão desempregadas, com a integridade psicológica em risco, lidando com dramas familiares, sem capacidade de cuidar dos filhos a tempo inteiro ao mesmo tempo que trabalham à distância. O óbvio desespero que tais cenários motivam leva a uma adesão imediata a qualquer réstia de esperança numa solução mágica. As ARCs aparecem aqui como a esperança possível, que irá motivar muita gente a instalar uma app cuja eficácia não está de todo demonstrada e cujas consequências podem ser muito graves.

Os falsos positivos e negativos

Os modelos de ARC que estão a ser desenvolvidos recorrem ao Bluetooth para evitar o recurso à geolocalização (que exclui o anonimato). São medidos os "contactos" entre telemóveis, ou seja, os momentos em que dois aparelhos estão próximos durante um tempo suficiente para ser considerado um potencial contacto. Mais tarde, quando alguém é marcado como tendo covid-19, as pessoas com quem contactou receberão notificações do facto, sem haver transmissão direta da identidade das pessoas. Mesmo salvaguardando o anonimato, há um pormenor que não há como contornar: o falso positivo ou falso negativo.

É que o Bluetooth está longe de ser uma tecnologia milimétrica, e não foi desenhada para medir distâncias entre pessoas. Há "contactos" a 5 metros que podem ser registados, e contactos reais de meio metro que não o vão ser. Para complicar, o Bluetooth atravessa barreiras, registando um contacto mesmo quando há uma barreira de plástico, ou mesmo uma parede, entre as pessoas, registando um falso positivo. Será um cenário frequente em apartamentos: quantas vezes já vimos a coluna ou a TV do vizinho quando ligamos o Bluetooth no telemóvel para procurar aparelhos à nossa volta?

Podemos antever o resultado: uma rede de contactos falsa e incompleta, de utilidade epidemiológica muitíssimo questionável por conter tantos falsos positivos e negativos. Mas há uma consequência muito mais grave: muitas pessoas receberão notificações de contacto que não ocorreu na realidade. Não houve exposição, mas a notificação será enviada. As pessoas ficarão ansiosas, muitas a colocar-se em auto-quarentena até poderem realizar um teste, com implicações psicológicas e familiares que se somam ao tremendo stress que já todos sofremos. Se pensarmos que muitos destes casos serão falsos alarmes, está-se assim a criar uma nova fonte de ansiedade profundamente desnecessária, num momento em que ninguém no país precisa de mais.

O uso "voluntário"

Quando ligamos à nossa operadora de comunicações para resolver uma questão técnica, a voz automática informa-nos de que a chamada será gravada e, se não consentirmos, que temos de recorrer aos meios de comunicação alternativos. Em tempo de pandemia, o meio de contacto presencial está excluído. Se o nosso problema necessitar de resolução urgente, não confiaremos no e-mail para obter uma resposta célere, e a única forma que temos à disposição de obter uma resposta imediata é consentir na gravação da chamada.

É assim que algo que surge como uma aparente escolha, com consentimento informado, se torna na verdade uma discreta imposição para aceitar condições que não admitiríamos noutra circunstância. É este fenómeno que também vai ocorrer com as ARCs e o seu carácter de adesão voluntária. É perverso argumentar que quem não quer, não precisa de aderir.

Olhemos para o que se passou na Índia, onde existe uma ARC promovida pelo governo, de uso voluntário. Muita gente está a ver barrada a sua entrada em farmácias, onde só se entra quando se mostra que a app está instalada no telemóvel. Os estafetas de entrega de refeições do Zomato são obrigados a ter a app instalada, senão não podem trabalhar. Alguns condomínios vedam o acesso a serviços aos condóminos que não provam ter a app instalada, e provocam o maldizer de vizinhos em relação a quem prefere não instalar.

Resumindo: é voluntário, mas obrigação existe de facto, na forma que a app se torna mediadora do acesso que temos a serviços essenciais, trabalho e ao nosso próprio domicílio. Nota-se muito a falta de qualquer contributo sociológico, etnográfico ou filosófico na concepção das ARCs, uma omissão que tem de ser destacada: é mais uma lacuna motivada por uma vontade solucionista de focar o debate nos pormenores técnicos e minimizar o valor de qualquer outro ângulo. Esta leveza na apresentação das ARCs como de uso "voluntário" tem de ser questionada.

Big brother? Não é bem isso

Vários dos proponentes das ARCs têm avançado o mesmo slogan de que "não se trata de um Big Brother". Têm razão, e devemos evitar a fácil condenação de que correspondem a uma conspiração por parte do Estado (ou privados) que apenas procuram um pretexto para acumular poder. Tem a ver com o desespero que tanto cidadãos como políticos estão a sentir na falta de qualquer solução mágica. A Comissão Europeia faz parte deste grupo desesperado: estava até há bem pouco tempo sob fortes críticas de não conseguir coordenar uma resposta conjunta à crise, até aparecer o pretexto das ARCs, que estão agora a ser propostas (e quase impostas) sem testes, análises profundas ou sequer uma especificação do valor real dessas apps. Tem de ser e pronto.

Esta é a doutrina solucionista: reduzir os problemas complexos a cenários preto e branco que só podem ser resolvidos com soluções tecnológicas. Essa doutrina reduz o discurso aos pormenores de implementação e descarta qualquer consideração fora dessa esfera. Neste caos em concreto, ela propõe falsamente uma dicotomia entre a app e o confinamento, ou em sentido mais lato, entre a salvação e o marasmo. Podemos recordar que antes de se falar de ARCs, a linha comummente aceite era que até à cura ou vacina não encontraremos soluções mágicas. Agora a solução existe -- uma ARC -- muitas vezes sem qualquer menção concreta das suas vantagens. Ela é apresentada como algo que tem de ser. A sua introdução contempla pouco ou nenhum debate. Não podemos, mesmo com a ansiedade coletiva em busca de soluções, apressar adoções em massa com implicações sociais fortes.

Temos ainda demasiado poucas pistas para o que aí vem, considerando que estamos a definir o precedente para o nosso futuro próximo: aceitaremos apps e engenhos tecnológicos como forma de mediação social? O Primeiro-Ministro, na sua entrevista recente na RTP, não sugere uma solução vinda do Estado, mas um ecossistema de apps de uso voluntário. Seria ótimo termos em mãos a informação sobre o que se pretende implementar em Portugal, mas não existe ainda qualquer documento formal a descrever o que se está a preparar, apenas comentário de imprensa. Não pode ser assim, se estamos a falar de uma decisão sócio-política com implicações que ainda não conseguimos quantificar enquanto sociedade, mas cujo desfecho definirá as nossas existências nos tempos que aí vêm.

Há ainda outros focos de preocupação que o espaço deste artigo não chega para albergar. Estamos na D3 a preparar um recurso para ajudar cada pessoa a decidir se é boa ideia instalar ou não a app: o ainda está a ser montado, mas dá para deixar lá o e-mail para receber um aviso quando estiver pronto, e assim poder ter os factos no sítio na altura de decidir se é boa ideia instalar uma app destas ou não.

tags: ARCs

by Ricardo Lafuente at May 09, 2020 02:04 PM

April 28, 2020


Decentralized Privacy-Preserving Proximity Tracing -- is it really?

DP-3T, as it is known, stands for Decentralized Privacy-Preserving Proximity Tracing. It tries to be a decentralized, privacy-preserving solution to a problem: to make phone applications help mitigate the current COVID-19 pandemic.

OK, let me take a step back. There have been talks (and in some contries already actions) about having an app to use phones in order to help track down the spread of COVID-19. I am not focused, in this article, to argue that the idea, in general is bad (tip: I think it is, due to privacy concerns), or to point out that relying on big companies like Google or Apple to "take care of it" using closed and opaque methods is a really bad idea (tip: it should be obvious: it is). I also don't plan to discuss what is each country proposing, adopting, or doing: not even the Portuguese case, where the Prime Minister and President announce they are against geolocalization, one week later the same Prime Minister consider it a possible solution, and one other week later the adoption of a platform for that is announced. I am not even focused on the discussion between the adoption of DP-3T or one of the proposals of PEPP-PT: much was already written about it, and if you still don't know that DP-3T is a better design than any of the PEPP-PT endorsed solutions.

Instead, this article is about something I didn't see yet anything making the case for: DP-3T, the best protocol/architecture for a solution out there, claims to be Privacy-Preserving. But is it?

Not yet

My first take on this issue is to consider DP-3T as it is right now. It is, we understand, an ever-evolving specification, that, due to the time constraints inherent to the demand for applications of this sort, need to adopt a 'release early, release often' approach. Still, in the moment I am writting this, there are 14 open issues to the spec tagged as 'privacy risks'. Privacy, like security, or life, in certain cases is quite binary: there only needs to be one privacy issue with a certain protocol, format or tool, to make it not be privacy-preserving, so the answer to the question of DP-3T is privacy perserving is... "not yet."

Not really

But is that it? If you take a closer look, things get even grimmer. From the "privacy risk" issues previously opened and now closed on the project, we can see that several of them (nine, at this moment) were closed because they stopped having input. While a manual reading of each of them will show a status of them, and most of them were dealt (partially or entirely) one way or another, the struggle of the maintainers of the project to keep the number of issues low is clear, the reference to future versions of the documents leave things unclear of wether the issues have been addressed or not, and the way some things are not solved, but only mitigated shows that there is a "best effort" sort of approach to privacy, the idea that "let's see how privacy-preserving can we be in a rushing development cycle", instead of what it should be: a firm stance that no privacy-risk can exist in a privacy-preserving solution.

I do understand that the critic here so far is vague enough that one could argue that we're still on the 'not yet' field: after all, after all the privacy-related issues are closed, after all the documents still being prepared are published, one can go through all of those issues, check the latest version of the document, and verify if all of the privacy issues were indeed solved. Arguably, they could. But we do not need to stay on the theoretical field here, not when the "best effort" approach, even in partial sacrifice of privacy, is actually documented. My favorite example of this, is the FAQ's 5th point, about the use of anonymous communication systems.

Why not use mixnets or other anonymous communication systems to query the server?

In the answer to this question, DP-3T stipulates, first, that this is a valid question and concern. Then, they explain that they decided not to for three reasons: a solution would increase complexity, anonymity would cost latency and bandwidth, and it would widen the field of research necessary to take protocol decisions.

In the end, the answer is a claim that there currently is no system ready to use DP-3T could piggy back on and simply use to this purpose, mature enough to the scale DP-3T aims to be deployed -- if there was, they'd use it.

While I do not disagree - such anonymous communication system is a need we, as a society, have for a long time, but an itch we did never focus on scratching, and the solutions so far are far from a stable and consolidated state - I also believe that this is clear proof that DP-3T is, by design, not 'Privacy-Preserving', but only 'as Privacy-Preserving as we can be, with these time constraints'.

Why does it matter?

The difference between "private" and "as private as possible" is not small, no matter how tiny it is: it is the difference between a solution that respects your privacy, and a solution that doesn't. While I can understand DP-3T and its interesting properties as an academic project, it is, IMO, a dangerous assumption to think that, because this is the best someone has came up to, that it is good enough for us, and that we should adopt it. In fact, my belief is that, since DP-3T is the best we aim to be able to achieve during this outbreak, it should not be used. On the other hand, this can and should be used as a learning experience, proof that there is a need to serious public investment on the development of real Privacy-Preserving technologies, of which anonymous communication systems are just an example.

What could have been

This article is long enough already, and I could go on and on about what can be done, if the serious effort is made to make it happen. The first paper I wrote about GNUnet was more than 15 years ago: since then many things have happened, extraordinary developments in many technological fields, a decade and half has passed... but GNUnet seems to me as being still the most promising privacy-centric project out there, and, quite unfortunately, it is still in an early alpha stage. The latest incarnation of its website has a tagline that is quite fitting for this article: "The Internet of tomorrow needs GNUnet today". In 2020, technology failed us in many ways: when a worldwide event like COVID-19 hit, we searched for technological solutions that still did not exist. 2020 was tomorrow, and we did not have GNUnet (or any other solution of choice -- take your pick, there is plenty around to do). My biggest fear on this subject is not to see solutions like DP-3T (or worse) being adopted, affecting the privacy of real lives, real people. My biggest fear that we will step out of the current sittuation, and decide not to learn from the evidences of past mistakes. Let's build the Internet of tomorrow, now.

tags: en, DP-3T, COVID-19, privacy, tracking, tracing, localization, PEPP-PT, gnunet

comentários? tweetar  

by ~marado at April 28, 2020 11:51 PM

April 25, 2020


Dicionários visuais com emoji no Inkscape

Uma vez, ao usar o telemóvel com o Eduardo (o nosso filho de 2 anos) ao lado, deu para reparar no interesse dele nos emoji. Experimentámos deixá-lo brincar com o teclado do ecrã um par de vezes e ele entusiasmou-se bastante a selecionar e a procurar mais emoji, dizendo os objetos que reconhecia. Noutra altura mais tarde, ocorreu-nos que as várias categorias e diversidade nos emoji podiam ser uma boa base para treinarmos o vocabulário com ele, em vez de dependermos de livros infantis de vocabulário cujas escolhas editoriais nos costumam deixar perplexos.

Durante a sesta de hoje, começámos à procura. Não encontrámos modelos prontos a imprimir numa rápida pesquisa, e percebemos que era melhor construirmos os nossos próprios. A seguir decidimo-nos a encontrar forma de usar o Inkscape (a nossa ferramenta preferida para design vetorial) para dispôr graficamente os conjuntos de emoji, mas não se mostrou trivial empregar fontes de emoji.

Encontrámos uma boa surpresa numa package pronta a instalar em Debian: inkscape-open-symbols. É um conjunto extenso de coleções de ícones de vários tipos, colocados à disposição na paleta de símbolos do Inkscape – um recanto desta ferramenta que não conhecíamos ainda. A coleção do inkscape-open-symbols é impressionante, incluindo pictogramas da AIGA, símbolos de diagramas elétricos ou ícones vindos do Material Design, Wordpress, GitHub e outros – todos eles recursos que nos vão dar jeito um dia. E, claro, lá encontramos os emoji da coleção Emoji One[^1].

Uma pequena amostra do que a coleção do inkscape-open-symbols nos tem para dar.

Antes de ele acordar da sesta, conseguimos fazer o layout de duas páginas e imprimi-las, uma com emoji relativos à alimentação e outra com meios de transporte. Foi útil podermos compôr a nossa versão e lidar com algumas das decisões editoriais que não esperávamos encontrar: Incluímos fast food e doces que ele não conhece, como hamburgeres ou donuts? Na falta dos autocarros dos STCP que ele conhece, é melhor usar uma camioneta ou um "school bus" amarelo à americana? Os livros não nos costumam dar a escolher, e valeu a pena o trabalho adicional para conseguirmos acabar com algo mais familiar e mais nosso.

Os emoji são uma condensação injusta e demasiado concisa da diversidade do mundo – falta lá encontrar um prato de bacalhau ou rissóis, limusines (ele adora) ou trotinetes. Apesar disso, para este modesto fim que procurávamos hoje, deram muito jeito depois de os imprimir e prender na parede.

[^1]: Uma outra descoberta deste empreendimento foi que a coleção EmojiOne passou a chamar-se JoyPixels e deixou de ser livre, com os acrescentos feitos desde esta mudança a ser sujeitos a licença paga. Como o conjunto original continua de acesso livre, serve para os nossos propósitos atuais, mas é uma pena. Outros virão.

by Ricardo Lafuente at April 25, 2020 09:44 PM

April 15, 2020


Relatos de pedagogias remotas

Tal como todos os professores, fui recentemente confrontado com a urgência de passar a um modelo de ensino à distância. E tal como a maioria, encontrei-me muito pouco preparado para essa transição de emergência. Volvido mais ou menos um mês desde o momento em que se tornou claro que teríamos de dar aulas à distância, aproveito agora para documentar alguns dos princípios, reflexões e conclusões que estão a motivar a minha metodologia para esta estranha forma de fazer escola.

Algum contexto antes de continuar. A Ana Isabel Carvalho e eu começámos em setembro a dar aulas no departamento de Design de Comunicação da ESAP, com disciplinas dedicadas ao design na web. Neste semestre, estou eu a dar uma cadeira sobre design de interfaces, após uma introdução ao código na web no primeiro semestre, enquanto que a Ana leccionou uma cadeira de projeto e design para a web. Estar apenas eu a dar aulas neste semestre revelou-se um acaso afortunado para as coisas correrem menos mal -- a quarentena imposta mais tarde fez com que um de nós tivesse de estar mais presente nos cuidados ao nosso filho. Nesses entretantos, a Ana e eu fomos trabalhando bem mais do que seria saudável para conseguir chegar a um sistema de aulas à distância que pudesse ser sustentado durante um par de meses (um cenário pessimista na altura, mas agora revelou-se acertado). Apesar de ser eu quem está a dar as aulas e a acompanhar os trabalhos, toda a construção dos sistemas e métodos que vou descrever neste e em futuros posts são um sério trabalho de equipa.

Após algum nervosismo inicial, o diretor do curso deixou-nos à vontade para ensaiar e avançar com as metodologias que sentíssemos adequadas. Daí, tentámos endereçar esta situação como um problema de design. Sabíamos já que vários alunos estavam com as suas rotinas despedaçadas e alguns ainda a ter de trabalhar em empregos muito exigentes, particularmente em época de crise. Também vimos como primeira prioridade assegurar a privacidade e integridade de quaisquer plataformas que empregássemos, obrigando a olhar para além das soluções "cloud" do costume. E finalmente, sentimos necessidade de questionar e ir mais além do que os modelos convencionais de e-learning, com plataformas holísticas que tentam mediar todo o processo de aprendizagem e avaliação (Moodles e afins).

A nossa experiência de vários anos a trabalhar à distância enquanto designers com clientes no estrangeiro tem sido particularmente útil. O nosso contacto com a área do jornalismo de dados também nos familiarizou com os MOOCs, de eficácia variável mas que introduzem muitos novos métodos e tácticas de transmitir conhecimento por via digital. Com isto, sentimos que poderíamos analisar as partes do processo pedagógico, retirar as que não nos servem, e idealizar metodologias e workflows que pudessem responder à necessidade de uma framework estável que pudesse sustentar as nossas aulas online.

Assim, identificámos um conjunto de premissas a que precisaríamos de dar resposta:

  • Assincronia. Mesmo mantendo as rotinas pré-crise e propondo a continuação de aulas à mesma hora que o habitual, é preciso dar resposta a quem não pode estar presente -- não é preciso enumerar os casos e possibilidades em que pessoas confinadas podem ter os seus planos e prioridades alterados. Por isso, procurámos formas que não prejudicassem quem não tem um horário regular, e permitir nesses casos o acesso a tudo o que se passou antes, ao ritmo possível de cada pessoa.
  • Software livre e open source. Já há mais de uma década que usamos exclusivamente ferramentas livres nos nossos contextos profissionais, artísticos, pessoais e experimentais. Sabíamos existir uma boa variedade de ferramentas promissoras vindas da comunidade livre; sabemos também das estratégias questionáveis de entidades proprietárias que disponibilizam ferramentas atractivas (Zoom, Google Classroom, MS Teams, entre muitos outros) que apresentam também riscos para a privacidade e autonomia. Por isso, a nossa escolha recairia sempre em ferramentas cujo código é aberto e cuja reutilização é livre.
  • Autonomia e self-hosting. A única forma de termos controlo sobre as ferramentas que usamos é, para além de evitar soluções proprietárias e preferir o open source, tê-las instaladas nos nossos próprios servidores. Por sorte, tínhamos acabado de adquirir um computador desktop decente para o nosso escritório cuja utilidade ficou limitada com a quarentena, pelo que podíamos utilizá-lo como servidor para alojar as plataformas que precisássemos -- e foi neste ponto que a nossa experiência com o self-hosting (instalar e manter plataformas no nosso próprio servidor) se mostrou preciosa. Poderíamos ter enveredado por um alojamento convencional na cloud que nos pouparia algumas dores de cabeça, mas não pouparia a carteira. Como tínhamos o computador à mão, foi uma possibilidade que aproveitámos.

O self-hosting é uma estratégia trabalhosa: foram precisas várias dezenas de horas para montar, configurar, afinar, colocar no ar e desenhar tácticas de manutenção para cada uma das ferramentas que usamos. No final, a recompensa é um sistema que controlamos integralmente, sem dependência de fornecedores, e com total autonomia: sabemos onde estão os nossos dados (e os dos nossos alunos), sabemos que estão seguros -- não totalmente porque há sempre possíveis riscos, mas bem mais do que se confiássemos num serviço cloud com servidores do outro lado do mundo e termos de serviços profundamente armadilhados.

Vou tentar detalhar nos próximos posts os pormenores da nossa implementação técnica, mas importa já expôr as ferramentas que adotámos:

  • para conversa em texto, do mesmo tipo de plataforma que o Slack. Esta tem-se revelado fundamental como alternativa a aulas por videoconferẽncia, que sentimos ser um meio limitado que não responde à premissa da assincronia (um assunto a desenvolver num post em breve). A esta plataforma chamámos "Recreio": porque na escola é o local onde nos reunimos em caso de emergência, mas também devido a uma expressão popular de que às vezes se aprende mais no recreio do que na sala de aula (um pouco taxativa, mas a mensagem é que no recreio também se aprende!).
  • Um mini-site com vídeos que vamos gravando com os conteúdos programáticos. Dos MOOCs retirámos a conclusão que vídeos curtos (máx. 15 min) a expôr assuntos individuais são o melhor formato para este tipo de meio. Recorremos ao OBS (Open Broadcasting Studio) para os gravar, VidCutter para os editar e cortar, ffmpeg para converter para mp4, e um gerador de sites estáticos que escrevemos para os publicar.
  • Um Raspberry Pi com um webserver para os alunos poderem publicar os seus trabalhos. Como a área das nossas disciplinas é a web, é algo que precisávamos e que, felizmente, já havíamos implementado e testado no primeiro semestre com os alunos, pelo que já estava tudo no sítio para continuar.
  • Open Streaming Platform para transmitir diretos, um formato mais próximo do Twitch ou Youtube Live do que da videoconferência tradicional. Inicialmente, pareceu uma possibilidade útil para aulas à distância, mas foi rapidamente suplantada nos nossos planos pelo Recreio/ Mesmo assim, vamos fazer experiências mais à frente para determinar se é um formato com potencial de complemento para as outras duas plataformas.

Até agora já decorreram 3 semanas de aulas (excluindo as férias da Páscoa), pelo que já pudemos tirar várias conclusões. Vou tentar documentá-las em mais posts, bem como ir mais a fundo sobre como cada plataforma tem funcionado e as pormenores interessantes que tem potenciado. Felizmente, sentimos que estamos a obter bons resultados dado o carácter de emergência que todo este esforço tem tido. E faz sentido partilhá-los, porque este novo paradigma de ensino vai ter muita presença nos próximos tempos, e temos de falar sobre isso.

tags: ensino-à-distância

by Ricardo Lafuente at April 15, 2020 10:14 PM