From tiago.carrondo ansol.org Mon Jul 6 21:47:18 2020 From: tiago.carrondo ansol.org (Tiago Carrondo) Date: Mon Jul 6 23:42:01 2020 Subject: [ANSOL-geral] As actividades da ANSOL em Junho 2020 Message-ID: <1aba1935-178a-c9d2-30bc-7477b9fa54ce@ansol.org> Caríssimos! A ANSOL, como parte da reestruturação da estratégia de comunicação delineada para os próximos tempos, tem o orgulho de publicar o seu primeiro resumo mensal de actividades. Mensalmente, pretendemos partilhar com o mundo aquilo que tem sido o nosso trabalho e em que projectos nos temos debruçado. Sentimos que é importante para dar a conhecer o nosso trabalho e o impacto que temos. Só comunicando podemos transmitir uma mensagem positiva e em prol do /software/ livre. A par da estratégia de comunicação, começámos a pensar em angariação de sócios. É através destes que conseguimos espalhar a mensagem e, naturalmente, há um efeito exponencial de crescimento à medida que os números subirem. Uma das nossas ponderações está relacionada com as quotizações de pessoas que se encontrem desempregadas. Outra reflexão, de modo a atingir novas massas, é sobre estratégias para a angariação de sócios que, a seu tempo, iremos divulgar. Até lá, se te revês no nosso trabalho e nos nossos valores, podes fazer-te sócio em https://ansol.org/inscricao/./ Este ano tem sido extraordinariamente complexo e imprevisível. Acreditamos que os novos desafios que nos têm sido impostos, como o teletrabalho e o ensino à distância, vieram dar maior motivação à adopção de /software/ livre. Tempos modernos requereram adaptação e superação, mas não às custas da nossa privacidade. Por esse motivo, a ANSOL tem procurado manter uma página com várias opções e alternativas livres aos programas recomendados e em voga. Essa lista pode ser consultada em https://adistancia.ansol.org/ e, continua em constante alteração: envia-nos as tuas sugestões! Por razões históricas também, deu-se início às discussões sobre a alocação do donativo anual da ANSOL para se atribuir a um projecto, entidade, ou pessoa, que se enquadre nos nossos objectivos. Mais informações serão divulgadas nos próximos meses. Caso tenham sugestões: contacto@ansol.org . No campo dos eventos, temos tido várias participações nacionais, a começar pelas sessões online organizadas pela Casa de Associações , em que estivemos, em parceria com a Comunidade Ubuntu Portugal , a jogar SuperTuxKart . Mais recentemente começámos a planear o envolvimento no Festival Colectivo para a Transformação Sustentável, de 9 a 17 de Outubro 2020, em Lisboa, organizado pela Umundulx . Em simultâneo, o ATV (Académico de Torres Vedras) convidou a ANSOL para uma apresentação sobre o /software /livre , os impactos sociais , a ideologia e manipulação de informação. Num espectro internacional, a direcção tem o orgulho de informar que tem vindo a fazer parte das sessões do OpenForum Europe , sessões essas que procuram alinhar os objectivos de uma estratégia europeia global. Sendo possível, mais informações serão divulgadas sobre este tema pois acreditamos bastante nesta iniciativa. Ainda no campo internacional, mas agora direccionado à linguística, a direcção tem promovido esforços para a tradução dos conteúdos da Free Software Foundation Europe , pois eles criam bastantes materiais interessantes e informativos, tornando-se desnecessário reinventar a roda. Para saberes mais como podes ajudar, entra em contacto connosco no Telegram ou via email, para contacto@ansol.org . Além desta publicação mensal, temos trabalhado em melhorias diversas da nossa infra-estrutura, visando simplificar alguns processos e permitir a intervenção de mais pessoas. Mais ainda, estas acções visam acabar com as dependências de todos os serviços de terceiros, uma grande ambição da direcção. Para facilitar a partilha de documentos e projectos, temos limpado e actualizado a nossa instância de NextCloud. Em simultâneo, e dedicado desta vez a mundos mais técnicos, implementámos uma instância do Phabricator para dela podermos usufruir. Todos os sócios que queiram acesso para terem suporte nos projectos livres, podem fazer-nos chegar essa solicitação por email para contacto@ansol.org . Não podemos deixar de publicamente agradecer aos novos sócios, que aderiram recentemente à associação, e com quem estamos ansiosos por colaborar: * G. Silva; * P. Silva; * R. Sousa. -- Melhores cumprimentos / Best Regards Tiago Miguel Feiteiro Carrondo Presidente da Direcção ANSOL - Associação Nacional para o Software Livre -------------- próxima parte ---------- Um anexo em HTML foi limpo... URL: http://listas.ansol.org/pipermail/ansol-geral/attachments/20200706/df06529d/attachment.htm From phakt nixnet.email Thu Jul 9 14:44:32 2020 From: phakt nixnet.email (phakt) Date: Thu Jul 9 14:44:39 2020 Subject: =?UTF-8?Q?Re=3A_=5BANSOL-geral=5D_App_de_=E2=80=9Ccontact_tracin?= =?UTF-8?Q?g=E2=80=9D_portuguesa_ter=C3=A1_c=C3=B3digo_aberto?= In-Reply-To: References: Message-ID: <6d56988649a326b7f15954c9d1861cd2@nixnet.email> On 2020-06-29 13:33, Rúben Leote Mendes wrote: > "O INESC TEC promete a "abertura pública de todo o código fonte" da > StayAway COVID, a aplicação de "contact tracing" portuguesa. A ideia é > que possa ser escrutinada livremente pela comunidade." > > > https://eco.sapo.pt/2020/06/29/app-de-contact-tracing-portuguesa-tera-codigo-aberto/ > > https://stayaway.inesctec.pt/ > > > > _______________________________________________ > Ansol-geral mailing list > Ansol-geral@listas.ansol.org > http://listas.ansol.org/mailman/listinfo/ansol-geral sounds like scam, mais uma aldrabice.. deleted From phakt nixnet.email Sun Jul 12 20:28:54 2020 From: phakt nixnet.email (phakt) Date: Sun Jul 12 20:29:03 2020 Subject: [ANSOL-geral] Kernel Research Message-ID: <4a5c3dbfa09f4bb584516321165e0d42@nixnet.email> Boas, conteudo interessante relacionado com Kernel: https://www.kernel.org/doc/html/latest/kernel-hacking/index.html ? Kernel Hacking Guides ? The Linux Kernel documentation https://kernelnewbies.org/ ? Linux_Kernel_Newbies - Linux Kernel Newbies https://wiki.osdev.org/Tutorials ? Tutorials - OSDev Wiki https://archives-recipes.org/ ? Archives pages of Kernel Recipes and Embedded Recipes conferences. https://bootlin.com/ ? Bootlin - Embedded Linux and kernel engineering ? https://0xax.gitbooks.io/linux-insides/content/ ? linux-insides. A book-in-progress about the linux kernel and its insides Thank you From phakt nixnet.email Sun Jul 12 20:34:10 2020 From: phakt nixnet.email (phakt) Date: Sun Jul 12 20:34:16 2020 Subject: [ANSOL-geral] Interesting Distros Message-ID: <348cb39a1b644ad60c892cea4eae22c8@nixnet.email> NuTyX GNU/Linux https://www.nutyx.org/en/ NuTyX is a complete GNU/Linux distribution with high flexibility, thanks to the collections and the groups concepts. We recommend that potential users first acquire some good knowledge about the GNU/Linux system. Original concepts like Base ISO installation, 'install GNU Guix - GNU's advanced distro and transactional package ... https://guix.gnu.org Guix is an advanced distribution of the GNU operating system. Guix is technology that respects the freedom of computer users. You are free to run the system for any purpose, study how it works, improve it, and share it with the whole world. alguem ja testou? interesting? Thanks From phakt nixnet.email Sun Jul 12 21:25:55 2020 From: phakt nixnet.email (phakt) Date: Sun Jul 12 21:25:59 2020 Subject: [ANSOL-geral] Unix Toolbox Message-ID: Unix Toolbox http://cb.vu/unixtoolbox.xhtml This document is a collection of Unix/Linux/BSD commands and tasks which are useful for IT work or for advanced users. This is a practical guide with concise explanations, however the reader is supposed to know what s/he is doing Regards From phakt nixnet.email Sun Jul 12 21:59:43 2020 From: phakt nixnet.email (phakt) Date: Sun Jul 12 21:59:49 2020 Subject: [ANSOL-geral] LibreHosters network Message-ID: <804204c0988ac261009b92dd55de2b25@nixnet.email> https://libreho.st/ -- liberatory hosting network. From jamatos fc.up.pt Tue Jul 14 17:33:20 2020 From: jamatos fc.up.pt (=?ISO-8859-1?Q?Jos=E9_Ab=EDlio?= Matos) Date: Tue Jul 14 17:33:30 2020 Subject: [ANSOL-geral] Interesting Distros In-Reply-To: <348cb39a1b644ad60c892cea4eae22c8@nixnet.email> References: <348cb39a1b644ad60c892cea4eae22c8@nixnet.email> Message-ID: <2468043.Lt9SDvczpP@myth> On Sunday, 12 July 2020 20.34.10 WEST phakt wrote: > NuTyX GNU/Linux > https://www.nutyx.org/en/ > NuTyX is a complete GNU/Linux distribution with high flexibility, thanks > to the collections and the groups concepts. We recommend that potential > users first acquire some good knowledge about the GNU/Linux system. > Original concepts like Base ISO installation, 'install > > GNU Guix - GNU's advanced distro and transactional package ... > https://guix.gnu.org > Guix is an advanced distribution of the GNU operating system. Guix is > technology that respects the freedom of computer users. You are free to > run the system for any purpose, study how it works, improve it, and > share it with the whole world. > > alguem ja testou? interesting? > > Thanks Aquilo que tenho visto está na distrowatch: https://distrowatch.com/table.php?distribution=nutyx https://distrowatch.com/table.php?distribution=guixsd Em cada uma delas é possível ver quais são as revisões que foram feitas. Estas revisões por vezes variam na qualidade mas em média dão uma boa ideia do que esperar. Por outro lado o número de horas do dia é limitado e prefiro explorar outros assuntos. :-) -- José Abílio From jamatos fc.up.pt Tue Jul 14 17:36:47 2020 From: jamatos fc.up.pt (=?ISO-8859-1?Q?Jos=E9_Ab=EDlio?= Matos) Date: Tue Jul 14 17:36:55 2020 Subject: [ANSOL-geral] App de =?UTF-8?B?4oCcY29udGFjdCB0cmFjaW5n4oCdIHBvcnR1Z3Vlc2EgdGVyw6EgY8OzZGlnbw==?= aberto In-Reply-To: References: Message-ID: <3412538.R56niFO833@myth> On Monday, 29 June 2020 14.33.50 WEST Rúben Leote Mendes wrote: > "O INESC TEC promete a "abertura pública de todo o código fonte" da > StayAway COVID, a aplicação de "contact tracing" portuguesa. A ideia é > que possa ser escrutinada livremente pela comunidade." > > > https://eco.sapo.pt/2020/06/29/app-de-contact-tracing-portuguesa-tera-codigo > -aberto/ > > https://stayaway.inesctec.pt/ Uma vez que esta mensagem foi escrita no dia 29, que em vários concelhos é feriado (São Pedro), eu tal como o São Tomé prefiro esperar para ver. :-) -- José Abílio From tiago.carrondo ansol.org Thu Jul 23 09:42:51 2020 From: tiago.carrondo ansol.org (Tiago Carrondo) Date: Thu Jul 23 09:43:03 2020 Subject: [ANSOL-geral] =?utf-8?q?ANSOL=3A_Disponibiliza=C3=A7=C3=A3o_do_c?= =?utf-8?q?=C3=B3digo_da_STAYAWAY_COVID_n=C3=A3o_=C3=A9_suficiente?= Message-ID: Versão web: https://ansol.org/STAYAWAY-COVID # PRESS RELEASE # ANSOL: Disponibilização do código da STAYAWAY COVID não é suficiente 23 de Julho de 2020 - A ANSOL - Associação Nacional para o Software Livre tem acompanhado com preocupação os desenvolvimentos sobre a aplicação de rastreamento de contactos (ARC) STAYAWAY COVID, desenvolvida pelo INESC TEC. Apesar do INESC TEC afirmar que vai disponibilizar o código fonte da aplicação, é certo que esta usa a API da Google e da Apple, cujo código não é escrutinável e, portanto, a disponibilização do código pelo INESC TEC corresponde apenas a uma parte da aplicação por onde passam os dados dos cidadãos. *"Qualquer modelo que passe por usar código que os cidadãos não podem escrutinar deve ser rejeitada. Estamos a falar de dados de saúde e, portanto, dados muito sensíveis. É imperioso que os cidadãos saibam que dados são recolhidos, quem os recolhe, e como é que esses dados vão ou podem ser usados."*, afirma Tiago Carrondo, presidente da ANSOL, acrescentando *"A mera informação sobre quem instala ou não a aplicação pode ser usada como fonte de discriminação".* A aplicação irá fazer uso da interface de Notificação de Exposição da Apple e da Google ([GAEN](https://www.google.com/covid19/exposurenotifications/)). Esta componente fornece acesso a funcionalidades do dispositivo e não são executadas directamente pela aplicação. Mas, embora a GAEN forneça amostras de como implementar os serviços de acesso, como podemos ver [neste exemplo de servidor](https://github.com/google/exposure-notifications-server), **o código usado na aplicação final não é público. Não é conhecido o tratamento de dados que leva, nem estas empresas se têm mostrado dispostas a disponibilizar estes detalhes.** Depois da [primeira deliberação da Comissão Nacional de Protecção de Dados (CNPD)](https://www.cnpd.pt/home/decisoes/Delib/DEL_2020_277.pdf) em relação à aplicação, que levanta questões em relação à falta de garantias que há com o uso da GAEN, temos observado com desagrado o facto de que nada se tem feito sobre esse assunto. Pelo contrário, o uso da GAEN, tal como o uso de uma ARC, continua a ser apresentado como uma inevitabilidade. Assim, foi publicada a [Resolução do Conselho de Ministros de 16-07-2020](https://www.portugal.gov.pt/pt/gc22/governo/comunicado-de-conselho-de-ministros?i=359), na altura ainda sem parecer emitido pela CNPD sobre o mesmo, algo que só veio a ocorrer - numa crítica ao Decreto-Lei - [no dia 21 de Julho](https://www.cnpd.pt/home/decisoes/Par/PAR_2020_82.pdf). Mais uma vez, a CNPD destaca, no modelo previsto, "uma parte substancial do tratamento de dados não ser controlada pelo responsável do tratamento, mas sim por uma parceria das duas maiores empresas de tecnologia", a interface GAEN, criada pela Google e pela Apple. Se fosse preciso algo mais do que desconfiança para perceber que as garantias que temos de conseguir, como sugere a CNPD, "a monitorização contínua do funcionamento" da GAEN, são nulas, temos a própria equipa que se encontra a desenvolver a aplicação a dar-nos um exemplo do quão não transparente é a relação entre eles e aquelas empresas. Em reacção a uma notícia do New York Times, que diz que vários dos países a implementar uma solução baseada em GAEN "estão desconfortáveis" com o comportamento da Google ao não aceitar alterar um dos detalhes do GAEN, o INESC TEC [disse ao Observador](https://observador.pt/2020/07/21/afinal-a-google-pode-recolher-dados-de-localizacao-nas-apps-de-rastreio-a-covid-19/) "Com outros responsáveis do desenvolvimento de aplicações similares europeias, temos vindo a questionar a Google e a solicitar a correcção do sistema operativo", além de ter dito ao [jornal ECO](https://eco.sapo.pt/2020/07/21/portugal-pressiona-google-a-desligar-acesso-ao-gps-na-app-de-contact-tracing/) que "a solicitação feita pelo Android é incorrecta e causa de preocupação em todas as aplicações que utilizam a GAEN". Contudo, não se obteve resposta sobre a possibilidade de alterar esta situação. Esta não é a primeira vez que nos deparamos com os problemas que advêm do uso desta componente de software proprietário. Em [resposta à comunidade científica](https://github.com/corona-warn-app/cwa-documentation/issues/228) quando esta encontrou um problema de segurança na ARC alemã, também assente na interface GAEN, a equipa que a desenvolve desresponsabilizou-se do problema, nem sequer alertando os seus utilizadores, com o argumento de que o problema está na GAEN, e que "não gerem essa componente", indicando que estas preocupações deviam ser "enviadas directamente à Apple e à Google". *"Depois da forma como a Google e a Apple optaram pela criação desta API, e pressionaram os países a adoptá-la, parece-nos difícil que estas empresas tenham abertura para torná-la numa componente livre"*, diz Tiago Carrondo, que acrescenta *"A opção destas gigantes da tecnologia por manter o controlo sobre a API é propositada, mas nós não somos forçados a utilizar esta API."* [A atitude que se observou recentemente, com o INESC TEC a dizer aos utilizadores do teste piloto que a CNPD tinha aprovado a app](https://twitter.com/direitosdig/status/1284892858810540033), levanta preocupações sobre a sensibilidade dos envolvidos para a privacidade dos dados e para o tratamento dos mesmos. Recorde-se que até agora o ponto mais positivo sobre a app e um requisito essencial por parte da Comissão Nacional de Protecção de Dados é o carácter voluntário da aplicação. *"De facto, não estão garantidas as condições sobre a privacidade dos cidadãos, para se poder recomendar o uso da aplicação"*, conclui Tiago Carrondo. -- Melhores cumprimentos / Best Regards Tiago Miguel Feiteiro Carrondo Presidente da Direcção ANSOL - Associação Nacional para o Software Livre -------------- próxima parte ---------- Um anexo que não estava em formato texto não está incluído... Nome : Comunicado_APPStayaway.pdf Tipo : application/pdf Tam : 19827 bytes Descr: não disponível Url : http://listas.ansol.org/pipermail/ansol-geral/attachments/20200723/8dddde51/Comunicado_APPStayaway-0001.pdf -------------- próxima parte ---------- Um anexo que não estava em formato texto não está incluído... Nome : Comunicado_APPStayaway.md Tipo : text/markdown Tam : 5754 bytes Descr: não disponível Url : http://listas.ansol.org/pipermail/ansol-geral/attachments/20200723/8dddde51/Comunicado_APPStayaway-0001.bin From bruno.rodrigues litux.org Thu Jul 23 11:07:26 2020 From: bruno.rodrigues litux.org (Bruno D. Rodrigues) Date: Thu Jul 23 11:07:37 2020 Subject: =?utf-8?Q?Re=3A_=5BANSOL-geral=5D_ANSOL=3A_Disponibiliza=C3=A7?= =?utf-8?Q?=C3=A3o_do_c=C3=B3digo_da_STAYAWAY_COVID_n=C3=A3o_=C3=A9_sufici?= =?utf-8?Q?ente?= In-Reply-To: References: Message-ID: Parabéns pelo contínuo esforço pela defesa do software livre. É fundamental não abrir mão da pressão para que o INESC liberte o código de toda a plataforma, desde as aplicações móveis aos código do servidor, tal como a SAP fez na Alemanha. No entanto tenho de discordar com parte desta mensagem, pois a funcionalidade da Exposure Notification está bem documentada e é claro para qualquer developer que não há informação pessoal envolvida de todo nesse componente - bem pelo contrário, até o ID do bluetooth deixa de ser visível. Criticar o projecto porque usa essa API é o equivalente a criticar porque corre em cima dos sistemas operativos fechados da Google e da Apple. É como criticar que não se pode usar a app a menos que todo o sistema operativo seja aberto por todas as marcas de telemóveis. Isto não faz sentido. A interface de EN foi criada propositadamente para garantir que não haja abusos de privacidade (por razões altruístas, sim) e para que seja eficiente energicamente (por razões económicas). Se só houvesse Android e as ARC usassem bluetooth normal, haveria facilmente a hipótese de abusos de privacidade, pois usando os IDs únicos do Bluetooth seria possível reconhecer outra pessoa em diversos dias, ou até ir à procura dela após a notificação de infeção. A API de EN tem zero de informação pessoal. No entanto a app que corre terá acesso a tudo o que quiser (ao que pedir autorização), desde dados pessoais a localização. A Apple e Google comprometeram-se a analisar as apps e tentar que sejam compliant com privacidade, mas isso não chega, e está nas nossas mãos exigir o código fonte de toda a plataforma para que vários olhos possam verificar que faz o que diz que fará, e temos todo o direito de o pedir pois é uma plataforma paga com o nosso dinheiro. A SAP lançou o código fonte duas semanas antes de lançar a app. Onde está o nosso código? Teremos disponível o código todo, incluindo servidor? O que é que a ANSOL recomenda que cada um de nós possa fazer pressão no INESC e no governo para que isto aconteça? Obrigado > No dia 23/07/2020, às 09:42, Tiago Carrondo escreveu: > > Versão web: https://ansol.org/STAYAWAY-COVID > > # PRESS RELEASE > > # ANSOL: Disponibilização do código da STAYAWAY COVID não é suficiente > > 23 de Julho de 2020 - A ANSOL - Associação Nacional para o Software > Livre tem acompanhado com preocupação os desenvolvimentos sobre a > aplicação de rastreamento de contactos (ARC) STAYAWAY COVID, > desenvolvida pelo INESC TEC. > > Apesar do INESC TEC afirmar que vai disponibilizar o código fonte da > aplicação, é certo que esta usa a API da Google e da Apple, cujo código > não é escrutinável e, portanto, a disponibilização do código pelo INESC > TEC corresponde apenas a uma parte da aplicação por onde passam os dados > dos cidadãos. > > *"Qualquer modelo que passe por usar código que os cidadãos não podem > escrutinar deve ser rejeitada. Estamos a falar de dados de saúde e, > portanto, dados muito sensíveis. É imperioso que os cidadãos saibam que > dados são recolhidos, quem os recolhe, e como é que esses dados vão ou > podem ser usados."*, afirma Tiago Carrondo, presidente da ANSOL, > acrescentando *"A mera informação sobre quem instala ou não a aplicação > pode ser usada como fonte de discriminação".* > > A aplicação irá fazer uso da interface de Notificação de Exposição da > Apple e da Google > ([GAEN](https://www.google.com/covid19/exposurenotifications/)). Esta > componente fornece acesso a funcionalidades do dispositivo e não são > executadas directamente pela aplicação. Mas, embora a GAEN forneça > amostras de como implementar os serviços de acesso, como podemos ver > [neste exemplo de > servidor](https://github.com/google/exposure-notifications-server), **o > código usado na aplicação final não é público. Não é conhecido o > tratamento de dados que leva, nem estas empresas se têm mostrado > dispostas a disponibilizar estes detalhes.** > > Depois da [primeira deliberação da Comissão Nacional de Protecção de > Dados (CNPD)](https://www.cnpd.pt/home/decisoes/Delib/DEL_2020_277.pdf) > em relação à aplicação, que levanta questões em relação à falta de > garantias que há com o uso da GAEN, temos observado com desagrado o > facto de que nada se tem feito sobre esse assunto. > > Pelo contrário, o uso da GAEN, tal como o uso de uma ARC, continua a ser > apresentado como uma inevitabilidade. Assim, foi publicada a [Resolução > do Conselho de Ministros de > 16-07-2020](https://www.portugal.gov.pt/pt/gc22/governo/comunicado-de-conselho-de-ministros?i=359), > na altura ainda sem parecer emitido pela CNPD sobre o mesmo, algo que só > veio a ocorrer - numa crítica ao Decreto-Lei - [no dia 21 de > Julho](https://www.cnpd.pt/home/decisoes/Par/PAR_2020_82.pdf). Mais uma > vez, a CNPD destaca, no modelo previsto, "uma parte substancial do > tratamento de dados não ser controlada pelo responsável do tratamento, > mas sim por uma parceria das duas maiores empresas de tecnologia", a > interface GAEN, criada pela Google e pela Apple. > > Se fosse preciso algo mais do que desconfiança para perceber que as > garantias que temos de conseguir, como sugere a CNPD, "a monitorização > contínua do funcionamento" da GAEN, são nulas, temos a própria equipa > que se encontra a desenvolver a aplicação a dar-nos um exemplo do quão > não transparente é a relação entre eles e aquelas empresas. Em reacção a > uma notícia do New York Times, que diz que vários dos países a > implementar uma solução baseada em GAEN "estão desconfortáveis" com o > comportamento da Google ao não aceitar alterar um dos detalhes do GAEN, > o INESC TEC [disse ao > Observador](https://observador.pt/2020/07/21/afinal-a-google-pode-recolher-dados-de-localizacao-nas-apps-de-rastreio-a-covid-19/) > "Com outros responsáveis do desenvolvimento de aplicações similares > europeias, temos vindo a questionar a Google e a solicitar a correcção > do sistema operativo", além de ter dito ao [jornal > ECO](https://eco.sapo.pt/2020/07/21/portugal-pressiona-google-a-desligar-acesso-ao-gps-na-app-de-contact-tracing/) > que "a solicitação feita pelo Android é incorrecta e causa de > preocupação em todas as aplicações que utilizam a GAEN". Contudo, não se > obteve resposta sobre a possibilidade de alterar esta situação. > > Esta não é a primeira vez que nos deparamos com os problemas que advêm > do uso desta componente de software proprietário. Em [resposta à > comunidade > científica](https://github.com/corona-warn-app/cwa-documentation/issues/228) > quando esta encontrou um problema de segurança na ARC alemã, também > assente na interface GAEN, a equipa que a desenvolve > desresponsabilizou-se do problema, nem sequer alertando os seus > utilizadores, com o argumento de que o problema está na GAEN, e que "não > gerem essa componente", indicando que estas preocupações deviam ser > "enviadas directamente à Apple e à Google". > > *"Depois da forma como a Google e a Apple optaram pela criação desta > API, e pressionaram os países a adoptá-la, parece-nos difícil que estas > empresas tenham abertura para torná-la numa componente livre"*, diz > Tiago Carrondo, que acrescenta *"A opção destas gigantes da tecnologia > por manter o controlo sobre a API é propositada, mas nós não somos > forçados a utilizar esta API."* > > [A atitude que se observou recentemente, com o INESC TEC a dizer aos > utilizadores do teste piloto que a CNPD tinha aprovado a > app](https://twitter.com/direitosdig/status/1284892858810540033), > levanta preocupações sobre a sensibilidade dos envolvidos para a > privacidade dos dados e para o tratamento dos mesmos. > > Recorde-se que até agora o ponto mais positivo sobre a app e um > requisito essencial por parte da Comissão Nacional de Protecção de Dados > é o carácter voluntário da aplicação. *"De facto, não estão garantidas > as condições sobre a privacidade dos cidadãos, para se poder recomendar > o uso da aplicação"*, conclui Tiago Carrondo. > > > -- > Melhores cumprimentos / Best Regards > > Tiago Miguel Feiteiro Carrondo > Presidente da Direcção > ANSOL - Associação Nacional para o Software Livre > _______________________________________________ > Ansol-geral mailing list > Ansol-geral@listas.ansol.org > http://listas.ansol.org/mailman/listinfo/ansol-geral From mindboosternoori gmail.com Thu Jul 23 22:34:28 2020 From: mindboosternoori gmail.com (Marcos Marado) Date: Thu Jul 23 22:34:53 2020 Subject: =?UTF-8?Q?Re=3A_=5BANSOL=2Dgeral=5D_ANSOL=3A_Disponibiliza=C3=A7=C3=A3o_do_c=C3=B3di?= =?UTF-8?Q?go_da_STAYAWAY_COVID_n=C3=A3o_=C3=A9_suficiente?= In-Reply-To: References: Message-ID: Olá Bruno, Este tema é abrangente e complexo: peço desde já desculpas por uma resposta que por um lado é longa e por outro lado menos profunda do que, se calhar, gostarias. Aqui vai ela. On Thu, Jul 23, 2020 at 11:07 AM Bruno D. Rodrigues wrote: [...] > É fundamental não abrir mão da pressão para que o INESC liberte o código de > toda a plataforma, desde as aplicações móveis aos código do servidor, tal > como a SAP fez na Alemanha. Concordo, mas também não tenho dúvidas que isso venha a acontecer. A promessa está feita no site oficial da aplicação[1], e tem sido reiterada[2], ainda que eles saibam que a promessa que fazem náo é suficiente para nos deixar descansados[3]. > No entanto tenho de discordar com parte desta mensagem, pois a funcionalidade > da Exposure Notification está bem documentada e é claro para qualquer > developer que não há informação pessoal envolvida de todo nesse componente - > bem pelo contrário, até o ID do bluetooth deixa de ser visível. Teremos de discordar. É verdade que a GAEN tem uma especificação pública, mas não consigo concordar que esteja "bem documentada". Para te dar um exemplo bem concreto, a Google decidiu finalmente lançar "algum" deste código (o que eles chamam de 'snippets', mas mesmo com esse código (que vais bem além da especificação), estão a haver dúvidas sobre o que é efectivamente feito na "parte escondida" - tens aqui um exemplo[4]. Também dá parte da questão de não haver informação pessoal envolvida é algo que tenho de discordar, não por achar que há, mas por achar que não tens informação suficiente para chegar a essa conclusão - afinal, a implementação é secreta... > Criticar o projecto porque usa essa API é o equivalente a criticar porque > corre em cima dos sistemas operativos fechados da Google e da Apple. É como > criticar que não se pode usar a app a menos que todo o sistema operativo seja > aberto por todas as marcas de telemóveis. Isto não faz sentido. Também não posso concordar. Uma aplicação que use APIs do sistema Android (repara, do Android, não do GMS, onde se encontra a GAEN) pode ser estudada, escritinada a 100%, validada, reproduzida, e até mesmo portada. A parte aplicacional está aberta, mas a parte do Sistema Operativo também, e essa aplicação já não teria, os problemas de, por exemplo, não funcionarem nalguns dispositivos da Huawei[5], ou em dispositivos com Lineage OS[6], ou de outra forma sem GMS[7]. A GAEN não é só uma implementação do protocolo BLE - se assim fosse, estaríamos provavelmente conversados. Mas a GAEN faz mais do que isso, e o que faz, e como faz são duas perguntas para os quais não temos resposta absoluta, o que já demonstrou ser um problema por exemplo para a comunidade científica[8]. A falta de controlo dos detalhes de implementação também tem sido vista como entrave[9]. > A interface de EN foi criada propositadamente para garantir que não haja > abusos de privacidade (por razões altruístas, sim) e para que seja eficiente > energicamente (por razões económicas). Parece-me que a razão dos "abusos de privacidade" (na realidade, a opção para uma solução descentralizada em vez de uma centralizada, além do não uso de GPS) foi usada muito eficazmente pela Google e Apple, mas, na realidade, julgo mais justa a afirmação "o DP^3T (no qual a GAEN se inspirou) apareceu com motivos altruístas, para garantir que não hajam problemas de privacidade". Ainda assim, nem sequer concordo que se possa afirmar (ainda que isto comece a ficar já um bocadinho off-topic) que o DP^3T garante a privacidade aos utilizadores do protocolo. Mas, acima de tudo, julgo que há pouco interesse nesta afirmação, porque, em termos pragmáticos, menos do que interessar porque é que determinada coisa apareceu, interessa é o que é que ela faz. E, lamento, mas como já disse acima, não acredito que possamos ter a certeza de que o GAEN não permite abusos de privacidade, quando não podemos escrutinar o que é ali feito, ao certo. Chamo a atenção, aliás, a um exemplo que a própria ANSOL apontou na sua nota à imprensa: > > No dia 23/07/2020, às 09:42, Tiago Carrondo > > escreveu: [...] > > Esta não é a primeira vez que nos deparamos com os problemas que advêm > > do uso desta componente de software proprietário. Em [resposta à > > comunidade > > científica](https://github.com/corona-warn-app/cwa-documentation/issues/228) > > quando esta encontrou um problema de segurança na ARC alemã, também > > assente na interface GAEN, a equipa que a desenvolve > > desresponsabilizou-se do problema, nem sequer alertando os seus > > utilizadores, com o argumento de que o problema está na GAEN, e que "não > > gerem essa componente", indicando que estas preocupações deviam ser > > "enviadas directamente à Apple e à Google". Já foi o problema de segurança encontrado e apontado nesse issue resolvido no GAEN? Sim? Não? Não sabes? Se sim, em que versão? Com updates automáticos e transparentes ao GAEN, como sabes o que mudou, o que foi resolvido e quando, a cada momento? Será que a própria equipa da aplicação sabe alguma destas respostas? > Se só houvesse Android e as ARC usassem bluetooth normal, haveria facilmente > a hipótese de abusos de privacidade, pois usando os IDs únicos do Bluetooth > seria possível reconhecer outra pessoa em diversos dias, ou até ir à procura > dela após a notificação de infeção. Repara que não só o DP^3T foi desenhado antes (e depois em paralelo) com a GAEN, como a GAEN se baseia nele. Ambos usam BLE, e há não só uma implementação e uma especificação abertas destas ARCs, recorrendo às APIs de sistema para o uso de BLE, sem recorrer ao GAEN[10]. Não há absolutamente alguma (que eu tenha conhecimento, mas aceito correcções!) indicação ou motivação no que diz respeito a segurança ou privacidade para que se use a "versão GAEN" do protocolo. Na realidade, as sugestões de implementação para melhorias em termos de privacidade até foram no sentido contrário (do DP^3T para a GAEN)[11]. > A API de EN tem zero de informação pessoal. A API não tem, é verdade. Mas ao contrário do sistema de permissões de uma aplicação, a GAEN é executada pelo GMS, que tem muitos outros componentes, faz muitas outras coisas, e /pode/ estar a fazer integração de dados. Não é que eu acredito esteja, pelo menos propositadamente, mas essa possibilidade existe, e a única forma que tens de garantir que isso não acontece, é com transparência, que até há data não existe. > No entanto a app que corre terá acesso a tudo o que quiser (ao que pedir > autorização), desde dados pessoais a localização. A Apple e Google > comprometeram-se a analisar as apps e tentar que sejam compliant com > privacidade, mas isso não chega, e está nas nossas mãos exigir o código fonte > de toda a plataforma para que vários olhos possam verificar que faz o que diz > que fará, e temos todo o direito de o pedir pois é uma plataforma paga com o > nosso dinheiro. É verdade que há uma "desresponsabilização confortável" na opção do uso da GAEN. Uma aplicação que implemente as coisas ela, tem de estar bem implementada, vai ser escrutinada, e quando forem encontrados erros, ou más opções de arquitectura, é a equipa que desenvolve a aplicação a ser responsabilizada. Já se usar a GAEN, as responsáveis pela API (Google e Apple) responsabilizam-se por esse controlo: elas garantem que a aplicação não está a tentar cruzar estes dados com dados de localização, por exemplo. Por outras palavras: com o GAEN, estamos a fazer outsourcing da responsabilização a duas empresas nas quais há bastante fé de que eles sabem o que estão a fazer; na opção "implementação própria" estamos a conviar numa centena de programadores dos mais variados institutos, tipicamente relacionados com a academia, e de quem quase de certeza ninguém ouviu falar. Mas - e é aqui que entra a minha opinião de que o Software Livre é, por desenho, vantajoso - eu acredito que vale mais a segunda opção (software aberto e escrutinável por todos), do que a primeira (software feito por gigantes tecnológicas que podem até ter conflitos legais com as suas promessas que não podem ser provadas do cumprimento da privacidade). > A SAP lançou o código fonte duas semanas antes de lançar a app. Onde está o > nosso código? Teremos disponível o código todo, incluindo servidor? O que já há está no github[12], e as promessas vagas que há sobre a matéria levam-me a acreditar que eles querem disponibilizar tudo, mais moldado do modelo suíço que no alemão. Infelizmente, principalmente devido há já falta de transparência até ao momento, além de atitudes como fazer trials antes de ter o código publicado, não acredito que a documentação, principalmente em termos de arquitectura, vá ser tão completa como o caso Suíço[13]. > O que é que a ANSOL recomenda que cada um de nós possa fazer pressão no INESC > e no governo para que isto aconteça? Mediatizar o assunto parece-me ser a coisa mais eficaz neste momento. Repare-se que estamos num cenário em que provavelmente a força que podemos fazer em termos oficiais não é muita: o Governo parece estar convencido que isto é uma ideia boa e popular, e se até está a fazer coisas como aprovar Decretos-Lei antes de pedir o parecer da CNPD ao mesmo, não os estou a ver a estar preocupados com a questão "então e o código". Mas a pressão mediática já fez, sem dúvida, o seu impacto, e algumas das afirmações e medidas tomadas pela equipa do Stayaway parecem ter sido já em relação a elas (por exemplo, ao excelente trabalho que a D3 tem desenvolvido sobre esta matéria). [1] https://stayaway.inesctec.pt/ [2] https://eco.sapo.pt/2020/06/29/app-de-contact-tracing-portuguesa-tera-codigo-aberto/ [3] https://twitter.com/mind_booster/status/1284217210769215488 [4] https://github.com/google/exposure-notifications-internals/issues/2 [5] https://visao.sapo.pt/exameinformatica/noticias-ei/software/2020-07-14-aplicacao-stayaway-covid-nao-vai-funcionar-em-smartphones-huawei-sem-servicos-google/ [6] https://gitlab.com/LineageOS/issues/android/-/issues/1949 [7] https://github.com/DP-3T/dp3t-sdk-android/issues/10 [8] https://www.scss.tcd.ie/Doug.Leith/pubs/luas.pdf [9] https://down.dsg.cs.tcd.ie/tact/posorient.pdf [10] https://github.com/DP-3T/dp3t-sdk-android/issues/143 [11] https://github.com/DP-3T/documents#apple--google-exposure-notification [12] https://github.com/stayawayinesctec [13] https://github.com/admin-ch/PT-System-Documents Cumprimentos, -- Marcos Marado From ruben nocturno.org Thu Jul 30 20:40:44 2020 From: ruben nocturno.org (=?UTF-8?Q?R=c3=baben_Leote_Mendes?=) Date: Thu Jul 30 20:40:55 2020 Subject: =?UTF-8?Q?Re=3a_=5bANSOL-geral=5d_App_de_=e2=80=9ccontact_tracing?= =?UTF-8?B?4oCdIHBvcnR1Z3Vlc2EgdGVyw6EgY8OzZGlnbyBhYmVydG8=?= In-Reply-To: References: Message-ID: <1cc09033-c8ea-4533-b106-5178036955e8@nocturno.org> Parece que já está disponível no github: https://github.com/stayawayinesctec/stayaway-app Às 14:33 de 29/06/20, Rúben Leote Mendes escreveu: > "O INESC TEC promete a "abertura pública de todo o código fonte" da > StayAway COVID, a aplicação de "contact tracing" portuguesa. A ideia é > que possa ser escrutinada livremente pela comunidade." > > > https://eco.sapo.pt/2020/06/29/app-de-contact-tracing-portuguesa-tera-codigo-aberto/ > > > https://stayaway.inesctec.pt/ > >