January 2022 - nexa - server-nexa.polito.it

Re: [nexa] "German police under fire for misuse of COVID contact tracing app"

by Claudio Agosti

"la gente"? a me sembra siano stati i ristoranti/pub a portare all'adozione. rendendola sia uno standard de facto. (nota: l'ho vissuta superficialmente, e pirtroppo non so dire se a livello nazionale o federale ci sono state direzioni/avvalli/interoperabilitá... ma stando molto spesso in germania mi é parso di capire che sia andata cosí.) l'app ufficiale é stata snobbata similarmente ad immuni On Tue, Jan 18, 2022, 12:32 Giuseppe Attardi <attardi(a)di.unipi.it> wrote: > Curioso che la gente abbia obiettato a soluzioni decentralizzate come > quella ufficiale ‘Corona Warn’, e poi oltre 7 milioni di persone abbiano > adottato una soluzione centralizzata e gestita da un’azienda privata, >

Jan. 18, 2022

per viaggiare, compratevi il Nokia...

by M. Fioretti

Era una buona idea 4 anni fa, e lo e' ancora adesso: https://stop.zona-m.net/2022/01/dubmphones-are-smartphones-again/ Marco -- Help me write my NEXT MILLION WORDS for digital awareness: https://stop.zona-m.net/2021/10/funding-2021-2022/

Jan. 18, 2022

Re: [nexa] "German police under fire for misuse of COVID contact tracing app"

by Giuseppe Attardi

Curioso che la gente abbia obiettato a soluzioni decentralizzate come quella ufficiale ‘Corona Warn’, e poi oltre 7 milioni di persone abbiano adottato una soluzione centralizzata e gestita da un’azienda privata, oltretutto complicata da usare, perché richiede di scandire un QR code all’entrata o uscita da un posto. Luca has a problematic centralised architecture, it is opaque and proprietary (it "creates a dependency on a single private company with the intention of making a profit as the operator of the system"), and its use is nonetheless "de facto compulsory," thus violating many of the privacy and rights-preserving principles established during the development of Germany's exposure notification app, 'Corona Warn'. — Beppe > On 18 Jan 2022, at 11:38, nexa-request(a)server-nexa.polito.it wrote: > > Date: Tue, 18 Jan 2022 09:40:05 +0100 > From: "J.C. DE MARTIN" <demartin(a)polito.it> > To: Nexa <nexa(a)server-nexa.polito.it> > Subject: [nexa] "German police under fire for misuse of COVID contact > tracing app" > Message-ID: <38a342a7-806e-b301-41fe-41d3fb699773(a)polito.it> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > *German police under fire for misuse of COVID contact tracing app** > */ > //German police used a contact tracing app to track down witnesses in a > local crime case. The scandal has data protection advocates up in arms, > with politicians warning that abuse of the app could undermine public > trust./ > > [...] > > continua qui: > https://www.dw.com/en/german-police-under-fire-for-misuse-of-covid-contact-…

Jan. 18, 2022

Libro: "Digisprudence: Code as Law Rebooted" (open access)

by J.C. DE MARTIN

*"Digisprudence: Code as Law Rebooted"* Laurence Diver Edinburgh University Press 276 pages Future Law Published December 2021 https://edinburghuniversitypress.com/book-digisprudence-code-as-law-reboote… *PDF disponibile in open access** * Reboots the debate on ‘code as law’ to present a new cross-disciplinary direction that sheds light on the fundamental issue of software legitimacy Reinvigorates the debate at the intersection of legal theory, philosophy of technology, STS and design practice Synthesises theories of legitimate legal rulemaking with practical knowledge of code production tools and practice Proposes a set of affordances that can legitimise code in line with an ecological view of legality Draws on contemporary technologies as case studies, examining blockchain applications and the Internet of Things Laurence Diver combines insight from legal theory, philosophy of technology and programming practice to develop a new theoretical and practical approach to the design of legitimate software. The book critically engages with the rule(s) of code, arguing that, like laws, these should exhibit certain formal characteristics if they are to be acceptable in a democracy. The resulting digisprudential affordances translate ideas of legitimacy from legal philosophy into the world of code design, to be realised through the ‘constitutional’ role played by programming languages, integrated development environments (IDEs), and agile development practice. The text interweaves theory and practice throughout, including many insights into real-world technologies, as well as case studies on blockchain applications and the Internet of Things (IoT). 1. Introduction The Structure of the Argument Rebooting ‘Code as Law’ Aspiring to Legitimacy in Code ‘Code as Law’, Code Versus Law, or Something Else? Concluding *Part I: Computational Legalism and the Rule(s) of Code* 2. A Design Perspective: Code Is More Than Law Affordance Infusing Code with Normativity 3. A Legal Philosophy Perspective: Code is Less Than Law What is Legalism? Computational Legalism Conclusion *Part II: What Makes a Good Rule?* 4. Criteria for Laws Normative Criteria for Law-Making: the Aspirations of Legality Conclusion 5. Criteria for Code Input and Output Legitimacy in Code Input Legitimacy Conclusion *Part III: Legitimating Code: Theory and Practice* 6. The Digisprudential Affordances Assessing Decisions, Or Assessing Design? Mapping the Criteria From Characteristics To Affordances Conclusion 7. Operationalising Digisprudence The Programmer of the Programmer Agile Development Integrated Development Environments Code and Natural Language Conclusion 8. Rebooting Code as Law: Conclusions and Next Steps The Contemporary Relevance of Digisprudence Next Steps? Concluding Thoughts

Jan. 18, 2022

La connessione satellitare Starlink di Elon Musk deve fare i conti con una “minaccia” inaspettata: i gatti

by don Luca Peyron

Per sorridere ogni tanto, ma in fondo... anche questa è cultura e società nella condizione digitale! Buona settimana dl https://www.greenme.it/tecno/gatti-provocano-problemi-connessione-satellita… _________________________ don Luca Peyron Direttore Ufficio per la Pastorale Universitaria Arcidiocesi di Torino www.universitari.to.it via XX settembre 83, Torino tel. 011 5156239

Jan. 18, 2022

Re: [nexa] US airline officials warn of ‘catastrophic’ crisis in aviation with new 5G service | 5G | The Guardian

by Alberto Cammozzo

"In early 2021, the Federal Communications Commission (FCC) awarded the mobile wireless industry radio spectrum to operate 5G transmissions in the “C-Band,” or 3.7-3.98 GHz, adjacent to the spectrum used by radar altimeters. This approval was made despite the aviation industry informing the FCC since 2018 of the need to ensure that radar altimeters are protected from 5G interference." <https://www.alpa.org/resources/aircraft-operations-radar-altimeter-interfer…> Altri allarmi, già dal 2019, riguardano le interferenze con i radar meteo: <https://www.nature.com/articles/d41586-019-03609-x/> 22 November 2019 -- Global 5G wireless deal threatens weather forecasts -- Meteorologists say international standards for wireless technology could degrade crucial satellite measurements of water vapour. Non parliamo degli effetti sulla salute: <https://pubmed.ncbi.nlm.nih.gov/?term=5g+radiation> La forza inarrestabile del progresso? A. On 18/01/22 09:19, M. Fioretti wrote: > On Tue, Jan 18, 2022 07:49:45 AM +0000, Alberto Cammozzo via nexa wrote: > >> <https://www.theguardian.com/technology/2022/jan/17/ >> us-airline-officials-crisis-5g> >> >> US airline chiefs have warned that the introduction of a new 5G >> service could cause US commerce to “grind to a halt” [because] new >> C-Band 5G technology could interfere with critical airplane >> instruments such as radio altimeters – which judge the distance from >> the ground to the bottom of the flying vessel – and have an impact >> on low-visibility operations. > scusate, io queste cose non le seguo piu' giornalmente come 10/15 anni > fa, percio' chiedo anche se probabilmente (spero) e' una domanda ingenua: > > quanto sopra, cioe' che il fatto che certi strumenti vitali per il > traffico aereo anche in/sopra aree urbane o quasi funzionano a certe > frequenze e non tollerano disturbi dalle medesime, non e' > un'ipotesi. E' un dato scientifico certo che risultava, esplicitamente > o meno ma sicuramente risultava senza ambiguita', dai data sheet > ufficiali e certificati da FAA etc... di quegli apparati dal primo > giorno che li hanno installati, sicuramente ben prima del 5G. > > Ergo, come accidenti e' possibile che gli "airline chiefs" non abbiano > mandato lo stesso avvertimento ALMENO 10 ANNI FA, o che i promotori > del 5G non abbiano da almeno 10 anni risposte pronte e inoppugnabili > che non ci sono problemi? > > Perche' qui non si parla di complottismo, della possibilita' che > l'incidenza di certi tumori passi da 0.0001 a 0.001 % in 30 anni; ma > della certezza che gli aerei che fatturano decine di milioni al giorno > non possano piu' farlo tutti i giorni. Cioe', perche' R&D, industria > aerea e industria TLC non si sono gia' scannate su questo e trovato > una soluzione definitiva e pro-business per tutti gia' 10/15 anni fa? > > Boh, > Marco

Jan. 18, 2022

"German police under fire for misuse of COVID contact tracing app"

by J.C. DE MARTIN

*German police under fire for misuse of COVID contact tracing app** */ //German police used a contact tracing app to track down witnesses in a local crime case. The scandal has data protection advocates up in arms, with politicians warning that abuse of the app could undermine public trust./ [...] continua qui: https://www.dw.com/en/german-police-under-fire-for-misuse-of-covid-contact-…

Jan. 18, 2022

Re: [nexa] US airline officials warn of ‘catastrophic’ crisis in aviation with new 5G service | 5G | The Guardian

by M. Fioretti

On Tue, Jan 18, 2022 07:49:45 AM +0000, Alberto Cammozzo via nexa wrote: > <https://www.theguardian.com/technology/2022/jan/17/ > us-airline-officials-crisis-5g> > > US airline chiefs have warned that the introduction of a new 5G > service could cause US commerce to “grind to a halt” [because] new > C-Band 5G technology could interfere with critical airplane > instruments such as radio altimeters – which judge the distance from > the ground to the bottom of the flying vessel – and have an impact > on low-visibility operations. scusate, io queste cose non le seguo piu' giornalmente come 10/15 anni fa, percio' chiedo anche se probabilmente (spero) e' una domanda ingenua: quanto sopra, cioe' che il fatto che certi strumenti vitali per il traffico aereo anche in/sopra aree urbane o quasi funzionano a certe frequenze e non tollerano disturbi dalle medesime, non e' un'ipotesi. E' un dato scientifico certo che risultava, esplicitamente o meno ma sicuramente risultava senza ambiguita', dai data sheet ufficiali e certificati da FAA etc... di quegli apparati dal primo giorno che li hanno installati, sicuramente ben prima del 5G. Ergo, come accidenti e' possibile che gli "airline chiefs" non abbiano mandato lo stesso avvertimento ALMENO 10 ANNI FA, o che i promotori del 5G non abbiano da almeno 10 anni risposte pronte e inoppugnabili che non ci sono problemi? Perche' qui non si parla di complottismo, della possibilita' che l'incidenza di certi tumori passi da 0.0001 a 0.001 % in 30 anni; ma della certezza che gli aerei che fatturano decine di milioni al giorno non possano piu' farlo tutti i giorni. Cioe', perche' R&D, industria aerea e industria TLC non si sono gia' scannate su questo e trovato una soluzione definitiva e pro-business per tutti gia' 10/15 anni fa? Boh, Marco -- Help me write my NEXT MILLION WORDS for digital awareness: https://stop.zona-m.net/2021/10/funding-2021-2022/

Jan. 18, 2022

Enforcing the pyramid of Open Source | daniel.haxx.se

by Alberto Cammozzo

<https://daniel.haxx.se/blog/2022/01/17/enforcing-the-pyramid-of-open-source/> The well-known log4j security vulnerability of December 2021 triggered a lot of renewed discussions around software supply chain security, and sometimes it has also been said to be an Open Source related issue. This was not the first software component to have a serious security flaw, and it will not be the last. What can we do about it? This is the 10,000 dollar question that is really hard to answer. In this post I hope to help putting some light on to why it is such a hard problem. This comes from my view as an Open Source author and contributor since almost three decades now. In this post I’m going to talk about security as in how we make our products have less bugs in the code we write and land on purpose. There is also a lot to be said about infrastructure problems such as consumers not verifying dependencies so that when malicious actors purposely destroy a component, users of that don’t notice the problem or supply chain security issues that risk letting bad actors insert malicious code into components. But those are not covered in this blog post! The OSS Pyramid I think we can view the world of software and open source as a pyramid, and I made this drawing to illustrate. The OSS pyramid, click for bigger version. Inside the pyramid there is a hierarchy where things using software are build on top of others, in layers. The higher up you go, the more you stand on the shoulders of open source components below you. At the very bottom of the pyramid are the foundational components. Operating systems and libraries. The stuff virtually everything runs or depends upon. The components you really don’t want to have serious security vulnerabilities. Going upwards In the left green arrow, I describe the trend if you look at software when climbing upwards the pyramid. Makes more direct money Shorter lifetimes, faster iterations Higher level languages Shrinking share of Open Source More end user facing At the top, there are a lot of things that are not Open Source. Proprietary shiny fronts with Open Source machines in the basement. Going downwards In the red arrow on the right, I describe the trend if you look at software when going downwards in the pyramid. Maintenance is more important than new fluff Longer lifetimes Bugs have larger impact and take longer to get deployed Lower level languages At the bottom, almost everything is Open Source. Each component in the bottom has countless users depending on them. It is in the bottom of the pyramid each serious bug has a risk of impacting the world in really vast and earth-shattering ways. That is where tightening things up may have the most positive outcomes. (Even if avoiding problems is mostly invisible unsexy work.) Zoom out to see the greater picture We can argue about specific details and placements within the pyramid, but I think largely people can agree with the greater picture. Skyscrapers using free bricks A little quote from my friend Stefan Eissing: As a manufacturer of skyscrapers, we decided to use the free bricks made available and then maybe something bad happened with them. Where is the problem in this scenario? Market economy drives “good enough” As long as it is possible to earn a lot of money without paying much for the “communal foundation” you stand on, there is very little incentive to invest in or pay for maintenance of something – that also incidentally benefits your competitors. As long as you make (a lot of) money, it is fine if it is “good enough”. Good enough software components will continue to have the occasional slip-ups (= horrible security flaws) and as long as those mistakes don’t truly hurt the moneymakers in this scenario, this world picture remains hard to change. However, if those flaws would have a notable negative impact on the mountains of cash in the vaults, then something could change. It would of course require something extraordinary for that to happen. What can bottom-dwellers do Our job, as makers of bricks in the very bottom of the pyramid, is to remind the top brass of the importance of a solid foundation. Our work is to convince a large enough share of software users higher up the stack that are relying on our functionality, that they are better off and can sleep better at night if they buy support and let us help them not fall into any hidden pitfalls going forward. Even if this also in fact indirectly helps their competitors who might rely on the very same components. Having support will at least put them in a better position than the ones who don’t have it, if something bad happens. Perhaps even make them avoid badness completely. Paying for maintenance of your dependencies help reduce the risk for future alarm calls far too early on a weekend morning. This convincing part is often much easier said than done. It is only human to not anticipate the problem ahead of time and rather react after the fact when the problem already occurred. “We have used this free product for years without problems, why would we pay for it now?” Software projects with sufficient funding to have engineer time spent on the code should be able to at least make serious software glitches rare. Remember that even the world’s most valuable company managed to ship the most ridiculous security flaw. Security is hard. (How we work to make sure curl is safe.) Components in higher levels can help All producers of code should make sure dependencies of theirs are of high quality. High quality here, does not only mean that the code as of right now is working, but they should also make sure that the dependencies are run in ways that are likely to continue to produce good output. This may require that you help out. Add resources. Provide funding. Run infrastructure. Whatever those projects may need to improve – if anything. The smallest are better off with helping hands I participate in a few small open source projects outside of curl. Small projects that produce libraries that are used widely. Not as widely as curl perhaps, but still millions and millions of users. Pyramid-bottom projects providing infrastructure for free for the moneymakers in the top. (I’m not naming them here because it doesn’t matter exactly which ones it is. As a reader I’m sure you know of several of this kind of projects.) This kind of projects don’t have anyone working on the project full-time and everyone participates out of personal interest. All-volunteer projects. Imagine that a company decides they want to help avoiding “the next log4j flaw” in such a project. How would that be done? In the slightly larger projects there might be a company involved to pay for support or an individual working on the project that you can hire or contract to do work. (In this aspect, curl would for example count as a “slightly larger” kind.) In these volunteers-only projects, all the main contributors work somewhere (else) and there is no established project related entity to throw money at to fix issues. In these projects, it is not necessarily easy for a contributor to take on a side project for a month or two – because they are employed to do something else during the days. Day-jobs have a habit of making it difficult to take a few weeks or months off for a side project. Helping hands would, eh… help Even the smallest projects tend to appreciate a good bug-fix and getting things from the TODO list worked on and landed. It also doesn’t add too much work load or requirements on the volunteers involved and it doesn’t introduce any money-problems (who would receive it, taxation, reporting, etc). For projects without any existing way setup or available method to pay for support or contract work, providing man power is for sure a good alternative to help out. In many cases the very best way. This of course then also moves the this is difficult part to the company that wants the improvement done (the user of it), as then they need to find that engineer with the correct skills and pay them for the allotted time for the job etc. The entity providing such helping hands to smaller projects could of course also be an organization or something dedicated for this, that is sponsored/funded by several companies. A general caution though: this creates the weird situation where the people running and maintaining the projects are still unpaid volunteers but people who show up contributing are getting paid to do it. It causes unbalances and might be cause for friction. Be aware. This needs to be done in close cooperating with the maintainers and existing contributors in these projects. Not the mythical man month Someone might object and ask what about this notion that adding manpower to a late software project makes it later? Sure, that’s often entirely correct for a project that already is staffed properly and has manpower to do its job. It is not valid for understaffed projects that most of all lack manpower. Grants are hard for small projects Doing grants is a popular (and easy from the giver’s perspective) way for some companies and organizations who want to help out. But for these all-volunteer projects, applying for grants and doing occasional short-term jobs is onerous and complicated. Again, the contributors work full-time somewhere, and landing and working short term on a project for a grant is then a very complicated thing to mix into your life. (And many employers actively would forbid employees to do it.) Should you be able to take time off your job, applying for grants is hard and time consuming work and you might not even get the grant. Estimating time and amount of work to complete the job is super hard. How much do you apply for and how long will it take? Some grant-givers even assume that you also will contribute so to speak, so the amount of money paid by the grant will not even cover your full-time wage. You are then, in effect, expected to improve the project by paying parts of the job yourself. I’m not saying this is always bad. If you are young, a student or early in your career that might still be perfect. If you are a family provider with a big mortgage, maybe less so. [...]

Jan. 18, 2022

[REMINDER] WEBINAR GI-STS con F. Giannotti e G. Tamburrini: Intelligenza artificiale e sistemi d’arma autonomi - coordina G. Colombetti

by Diego.Latella

[Con preghiera di diffusione] =========================== ANNUNCIO WEBINAR =========================== Intelligenza artificiale e sistemi d'arma autonomi Seminario on-line aperto al pubblico MERCOLEDÌ 19 Gennaio 2022 alle 16:00 (Official language: Italian) Coordina Giuliano Colombetti (CNR-IBF. GI-STS) 16:00 Saluti Istituzionali Antonello Provenzale (Presidente - Area della Ricerca di Pisa del CNR) 16:15 Stato dell'arte in Intelligenza Artificiale. Potenzialità e limiti delle tecnologie dell'Intelligenza Artificiale Fosca Giannotti (Scuola Normale Superiore, Pisa; CNR/ISTI) 16:45 La militarizzazione dell'Intelligenza Artificiale, le armi autonome e la pace internazionale Guglielmo Tamburrini (Università degli Studi di Napoli "Federico II") 17:15 Discussione Il webinar è organizzato dal Gruppo Interdisciplinare su Scienza, Tecnologia e Società (GI-STS) dell'Area della Ricerca di Pisa del CNR In cooperazione con Areaperta - Area della Ricerca CNR di Pisa Caffè della Scienza "N. Badaloni" - Livorno Centro Interdisciplinare Scienze per La Pace dell'Università di Pisa Istituto di Biofisica del CNR Istituto di Fisiologia Clinica del CNR Istituto di Informatica e Telematica del CNR Istituto di Scienza e Tecnologie dell'Informazione ``A. Faedo'' del CNR La Nuova Limonaia Laboratorio Informatica e Società del CINI Pugwash Conferences on Science and World Affairs Unione degli Scienziati Per Il Disarmo e con il patrocinio della Rete Università per la Pace Per ulteriori informazioni---incluso il link per la partecipazione all'evento---si rimanda alla pagina "Events" (http://gists.pi.cnr.it/events.html )del sito web del Gruppo Interdisciplinare su Scienza, Tecnologia e Società (GI-STS) dell'Area della Ricerca di Pisa del CNR,(http://gists.pi.cnr.it ). =========================== For more information---including the link for participation---please refer to the "Events" page (http://gists.pi.cnr.it/events.html ) in the web site of the Gruppo Interdisciplinare su Scienza, Tecnologia e Società (GI-STS) dell'Area della Ricerca di Pisa del CNR (http://gists.pi.cnr.it ). =========================== D. Latella -- Dott. Diego Latella - Senior Researcher CNR/ISTI, Via Moruzzi 1, 56124 Pisa, Italy (http:www.isti.cnr.it [1]) FM&&T Lab. (http://fmt.isti.cnr.it) CNR/GI-STS (http://gists.pi.cnr.it) https://www.isti.cnr.it/People/D.Latella - ph: +390506212982, fax: +390506212040 =================== I don't quite know whether it is especially computer science or its subdiscipline Artificial Intelligence that has such an enormous affection for euphemism. We speak so spectacularly and so readily of computer systems that understand, that see, decide, make judgments, and so on, without ourselves recognizing our own superficiality and immeasurable naivete with respect to these concepts. And, in the process of so speaking, we anesthetise our ability to evaluate the quality of our work and, what is more important, to identify and become conscious of its end use. […] One can't escape this state without asking, again and again: "What do I actually do? What is the final application and use of the products of my work?" and ultimately, "am I content or ashamed to have contributed to this use?" -- Prof. Joseph Weizenbaum ["Not without us", ACM SIGCAS 16(2-3) 2--7 - Aug. 1986] Links: ------ [1] http://www.isti.cnr.it

Jan. 18, 2022