October 2020 - nexa - server-nexa.polito.it

Re: [nexa] The Citizen Browser Project—Auditing the Algorithms of Disinformation

by Giovanni Biscuolo

Buongiorno Antonio, Antonio Iacono <antiac(a)gmail.com> writes: [...] > Avete mai digitato chrome://credits/ su Chrome o un altro browser > basato su Chromium? Viene fuori una lista di oltre 300 componenti > open source, le cui licenze sono le più disparate. Il campo "license" di "guix show ungoogled-chromium" dice: license: Modified BSD, FreeBSD, Expat, ASL 2.0, MPL 1.1, MPL 2.0, Public Domain, ISC, non-copyleft, LGPL 2.1+ > Sicuramente quella più particolare è la licenza di Sqlite: > "The author disclaims copyright to this source code. In place of > a legal notice, here is a blessing: > May you do good and not evil. > May you find forgiveness for yourself and forgive others. > May you share freely, never taking more than you give." Quel testo inglobato in Chromium è molto obsoleto, da un po' (non so da quanto) è in Public Domain... e quelli di Chromium fanno _casino_ :-) > Chissà se ancora oggi Richard Hipp (qui [5] un articolo del Guardian > che ne parla), a distanza > di qualche lustro, è convinto di quella licenza. No, l'ha cambiata. Piuttosto, è particolarmente curioso questo: https://www.sqlite.org/copyright.html --8<---------------cut here---------------start------------->8--- Open-Source, not Open-Contribution SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from unknown persons. All of the code in SQLite is original, having been written specifically for use by SQLite. No code has been copied from unknown sources on the internet. [...] Contributed Code In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches. If you would like to make a suggested change, and include a patch as a proof-of-concept, that would be great. However please do not be offended if we rewrite your patch from scratch. --8<---------------cut here---------------end--------------->8--- Ovviamente Hipp sa benissimo che chi la usa può farci quello che vuole _prima_ di produrre il binario e inserirlo come libreria in quello che vuole, SENZA che chi riceve il binario possa chiedere di vedere cosa c'è scritto nel sorgente :-) [...] -- Giovanni Biscuolo

Oct. 21, 2020

Re: [nexa] Flamethrowers and Fire Extinguishers – a review of “The Social Dilemma”

by Roberto Resoli

Il 21/10/20 11:52, Antonio Iacono ha scritto: > Torno sull'argomento per segnalarvi un articolo (sotto le conclusioni) > e un incontro online di un gruppo di lavoro che stasera dialogherà sul > documentario. > > -https://librarianshipwreck.wordpress.com/2020/09/17/flamethrowers-and-fire-extinguishers-a-review-of-the-social-dilemma/ > > -https://twc-italia.org/events/12 > > Antonio Messo in agenda, grazie Antonio. rob

Oct. 21, 2020

Paul-Olivier Dehaye, sua attività e coinvolgimento da parte delle autorità svizzere

by Roberto Resoli

Paul-Olivier Dehaye è un matematico e attivista per i diritti digitali. Ieri è stato ingaggiato dall'unità per il tracciamento contatti del Cantone di Ginevra. Ho appena letto un suo articolo[1] in cui riassume la sua attività ed espone un suo possibile conflitto di interessi. Tra l'altro, spicca l'apprezzamento, che condivido in pieno, per un recente articolo[2] di Zeynep Tufekci su theAtlantic circa l'emergere di una spiccata stocasticità dei meccanismi di trasmissione della pandemia, e il miglioramento conseguente delle strategie per combatterla. Mi piace notare come ci siano luoghi in cui chi solleva problematiche, e indica possibili alternative e correzioni alle strategie in corso, sia ascoltato e coinvolto dalle autorità. rob [1] https://medium.com/@pdehaye/conflict-of-interest-disclosure-34197aca13d8 [2] https://www.theatlantic.com/health/archive/2020/09/k-overlooked-variable-dr…

Oct. 21, 2020

Flamethrowers and Fire Extinguishers – a review of “The Social Dilemma”

by Antonio Iacono

Torno sull'argomento per segnalarvi un articolo (sotto le conclusioni) e un incontro online di un gruppo di lavoro che stasera dialogherà sul documentario. - https://librarianshipwreck.wordpress.com/2020/09/17/flamethrowers-and-fire-… - https://twc-italia.org/events/12 Antonio ... The Social Dilemma responds to the question of “what kind of technology do we really need?” by saying “humane technology.” After all, the organization The Center for Humane Technology is at the core of the film, and Harris speaks repeatedly of “humane technology.” At the surface level it is hard to imagine anyone saying that they disapprove of the idea of “humane technology,” but what the film means by this (and what the organization means by this) is fairly vacuous. When the Center for Humane Technology launched in 2018, to a decent amount of praise and fanfare, it was clear from the outset that its goal had more to do with rehabilitating Silicon Valley’s image than truly pushing for a significant shift in technological forms. Insofar as “humane technology” means anything, it stands for platforms and devices that are designed to be a little less intrusive, that are designed to try to help you be your best self (whatever that means), that try to inform you instead of misinform you, and that make it so that you can think nice thoughts about the people who designed these products. The purpose of “humane technology” isn’t to stop you from being “the product,” it’s to make sure that you’re a happy product. “Humane technology” isn’t about deleting Facebook, it’s about renewing your faith in Facebook so that you keep clicking on the “like” button. And, of course, “humane technology” doesn’t seem to be particularly concerned with all of the inhumanity that goes into making these gadgets possible (from mining, to conditions in assembly plants, to e-waste). “Humane technology” isn’t about getting Ben or Isla off their phones, it’s about making them feel happy when they click on them instead of anxious. In a world of empowered arsonists, “humane technology” seeks to give everyone a pair of asbestos socks. Many past critics also argued that what was needed was to place a new word before technology – they argued for “democratic” technologies, or “holistic” technologies, or “convivial” technologies, or “appropriate” technologies, and this list could go on. Yet at the core of those critiques was not an attempt to salvage the status quo but a recognition that what was necessary in order to obtain a different sort of technology was to have a different sort of society. Or, to put it another way, the matter at hand is not to ask “what kind of computers do we want?” but to ask “what kind of society do we want?” and to then have the bravery to ask how (or if) computers really fit into that world—and if they do fit, how ubiquitous they will be, and who will be responsible for the mining/assembling/disposing that are part of those devices’ lifecycles. Certainly, these are not easy questions to ask, and they are not pleasant questions to mull over, which is why it is so tempting to just trust that the Center for Humane Technology will fix everything, or to just say that the problem is Silicon Valley. Thus as the film ends we are left squirming unhappily as Netflix (which has, of course, noted the fact that we watched The Social Dilemma) asks us to give the film a thumbs up or a thumbs down – before it begins auto-playing something else. The Social Dilemma is right in at least one regard, we are facing a social dilemma. But as far as the film is concerned, your role in resolving this dilemma is to sit patiently on the couch and stare at the screen until a remorseful tech insider tells you what to do.

Oct. 21, 2020

Re: [nexa] Replay Attack ad Immuni/GAEN

by Roberto Resoli

Il 21/10/20 10:00, Giovanni Biscuolo ha scritto: > Caro Roberto, > > solo un paio di commenti "a caldo", > > Roberto Resoli <roberto(a)resolutions.it> writes: > >> Il 20/10/20 17:00, Giovanni Biscuolo ha scritto: > [...] >>> Roberto Resoli <roberto(a)resolutions.it> writes: > [...] ... > [...] > >> Rispetto a questo scenario, inoltre, l'attacco prospettato da Iovino non >> necessita "harvests Bluetooth beacon data from millions of users", > > Sì, credo si riferisse all'attacco di re-identificazione Non credo; entrambi gli attacchi 2.1 e 2.2 nel paper di Dehaye (re-identificazione e replay) prevedono la raccolta massiva di RPI. La verifica di fattibilità fatta da Iovino è fatta rigenerando gli RPI e modificando l'ora del telefono principalmente per non commettere reati (come giustamente sottolinei, la raccolta massiva sul campo di RPI è illegale). Lo chiarisce direttamente in questo tweet: https://twitter.com/vincenzoiovino/status/1312742967799615488?s=20 "Last but not least, questi replay Attack con macchina del tempo si ricorda sono usati per simulare un attacco reale senza fare cose ilelgali. L'attaccante reale piazza uno sniffer all'aeroporto dove ogni giorno numero infetti>1" Ciò non toglie che l'attacco "targeted" con modifica dell'ora del telefono sia comunque possibile, anche senza accesso fisico al dispositivo: https://github.com/google/exposure-notifications-internals/issues/19#issuec… "I did the attack outside the house of a "victim" (who was informed of the fact but a real attacker would not inform him). I just needed to know the password of the wifi and guess by several attempts the IP of his phone. The attack was successful. Similarly, you can do the attack in any place (bar, restaurant, bus stations, etc.) where people stay for 15 minutes and they are connected to a wifi to which you can also connect. So it is very doable. Users can notice it but is only for 15 minutes. Via another trick that we did not disclose yet, you can shorten the time to much less than 15 minutes." rob

Oct. 21, 2020

Royal mail launches a 72p pick up service

by Luigi Scorca

Buongiorno, vi segnalo questo articolo https://www.bbc.com/news/business-54614871 Royal Mail says it has found a solution for its customers who have parcels to send but can't face the queues in their local post office. The firm's new "Parcel Collect" service will operate six days a week and you'll be able to send up to five parcels at a time. Your local postman or postwoman will either collect your parcels from your front door or a designated safe space and the service will be part of their daily round. To use the service you have to book online (www.royalmail.com/bookcollection or via their app) - this can be done from five days in advance up to midnight the day before collection. Customers will have to make sure their postage is paid for, print their own labels and then pay for the service online. The charge for using the service is 72p per parcel, in addition to postage costs. Parcel Collect is also available for pre-paid return items at a cost of 60p per item. Luigi

Oct. 21, 2020

Re: [nexa] Replay Attack ad Immuni/GAEN

by Giovanni Biscuolo

Caro Roberto, solo un paio di commenti "a caldo", Roberto Resoli <roberto(a)resolutions.it> writes: > Il 20/10/20 17:00, Giovanni Biscuolo ha scritto: [...] >> Roberto Resoli <roberto(a)resolutions.it> writes: [...] > Sì, la cosa è abbastanza semplice da essere veramente attuabile in > contesti reali. I contesti sono molteplici, dall'auto "attacco" per ottenere priorità sui tamponi fino all'inquinamento generalizzato delle segnalazioni di contatto, passando per l'attacco a un ristretto gruppo (o singolo). Queste prospettive sembrano sempre da paranoici complottisti fino a quando non si studia cosa è già stato fatto; per dire, quello che ha rivelato Snowden prima delle rivelazioni sembrava da paranoici. Per essere chiari: *non* sto prospettando scenari da DataGate in questo contesto, ma il rischio di qualcosa di serio c'è. [...] > Grazie del puntatore. Mi pare che in [2] corrisponda a "2.2 False > positive attacks". Sì, dove il 2.1 corrisponde ad un attacco di re-identificazione della persona che ha installato la app. [...] > Large-scale replay attacks would generate a high number of tests and > thus be easy to detect. In case the worst case, the app could then be > disabled. Sì certo, tutto sta in quanto tempo si riesce ad accorgersi (gli attaccanti mica sono scemi e potrebbero adottare tecniche di poisoning lento) e quanti danni sono stati provocati nel frattempo. Su queste cose mi piacerebbe che venisse svolta e _pubblicata_ una adeguata analisi dei rischi: le chiacchiere stanno a zero. > The damage would be limited to development costs of the app, > and a lost opportunity. Ecco fatto: analisi dei rischi in due righe, zac! [...] > In the end, this is a question that cannot be answered on a technical > level alone. Balle. Punto. > While such an attack is possible, it is associated with high costs for > the attackers. Falso, _tutti_ gli esperti nel settore lo sanno *e* sanno anche che per un attaccante con sufficienti motivazioni e risorse il costo non è un problema (DataGate docet). > As such, we believe that the benefit of the app is higher than the > potential risk of such an attack." Il rischio è sempre potenziale ma l'analisi dei rischi dovrebbe evidenziare quali sono i possibili danni (in questo caso sistemici) che un simile attacco potrebbe comportare. Per quello che leggo questa cosa non mi pare sia stata fatta, spero vivamente di sbagliarmi e che un simile documento sia semplicemente segreto e ben custodito in qualche cassetto che conta. > le risposte di Dehaye, a mio parere assai condivisibili: [...] > our quantitative discussion at the end will show that relatively small > actors could actually be impactful. Se l'analisi dei rischi fosse a disposizione per essere studiata non ci sarebbe bisogno di simili discussioni "campate per aria". > State-level adversaries would definitely have the possibility to > acquire the technical capacity to create havoc. Non sono solo "state-level", la tecnologia è ampiamente alla portata di molti criminali (non tutti mossi da motivazioni economiche). [...] > Rispetto a questo scenario, inoltre, l'attacco prospettato da Iovino non > necessita "harvests Bluetooth beacon data from millions of users", Sì, credo si riferisse all'attacco di re-identificazione [...] > L'attacco è ipotizzato anche in un Issue del "GAEN Internals": > > https://github.com/google/exposure-notifications-internals/issues/19 > > menzionato anche da Iovino, e a cui ha risposto confermando la fattibilità: > > https://github.com/google/exposure-notifications-internals/issues/19#issuec… Good catch: non ci sono segni che la issue sia stata considerata nè che si stia lavorando per risolverla. >> In *teoria*, ma è ovvio che nessuno lo vorrà mai fare, un attacco del >> genere è alla portata di chi può installare sufficienti beacon bluetooth >> e usare "fake base station" [3] per coprire aree pubbliche molto >> frequentate. Però è ovvio che nessuno lo vorrà mai fare, sarebbe >> assurdo no? > > Se ti riferisci allo scenario svizzero, come detto questo non sembra > necessario. Hai ragione, forse ho fatto un po' di confusione: devo ristudiami bene il vettore di attacco. [...] > Citando sempre Iovino: > https://github.com/immuni-app/immuni-app-android/issues/278#issuecomment-70… > > "5. Beyond proposing to look at alternative solutions, I actually do > have a likely solution to withstand replay attacks that works with GAEN > and would just require a change at the app level. Unfortunately, the > Immuni's ecosystem is not (contrarily to what you write in your FAQ) > open source and is not even testable, so I cannot perform tests to > confirm whether my solution may really work. If I had the possibility of > debugging, this would help. Bingo! Per i "normali utenti" è difficile percepire una app come "ecosistema" ma per gli sviluppatori non dovrebbe esserlo: fanno parte della app *tutte* le dipendenze dirette E indirette che servono a produrre il binario: se una di queste non è disponibile NESSUNO è in grado di fare test e debugging indipendenti e quindi di poter effettuare verifiche su eventuali problemi dell'ecosistema. > Being your process IMHO completely non-transparent until now, having you > based the app on a system that is not publicly debuggable, and for other > reasons, I prefer to not disclose my solution here. But I am open and > you may contact me privately." Questa non la capisco, ma pazienza. [...] > Non chiudere questa vulnerabilità mi sembra veramente irresponsabile. Il vero problema è che *pare* che Immuni e le altre app basate su GAEN sono letteralmente ostaggio di un vendor lock-in: 1. il vendor vuole risolvere la vulnerabilità? 2. gli sviluppatori che usano GAEN vogliono risolvere la vulterabilità? 3. se 2 è vero e 1 no, gli sviluppatori sono in grado di sostituire la libreria difettosa con una meno difettosa? Davvero per cose così delicate una nazione deve sottostare ai criteri di sviluppo e manutenzioone del software dettati da un paio di mutinazionali? [...] Saluti, Giovanni. -- Giovanni Biscuolo

Oct. 21, 2020

devozioni digitali

by don Luca Peyron

Segnalo una curiosità ma che ci aiuta a comprendere come il Covid e la trasformazione digitale stanno insieme, più o meno bene, anche nella componente religiosa delle persone. Buona lettura a chi lo desidera dl https://www.avvenire.it/rubriche/pagine/la-pandemia-cancella-la-festa-ecco-… ? _________________________ don Luca Peyron Direttore Ufficio per la Pastorale Universitaria Arcidiocesi di Torino www.universitari.to.it via XX settembre 83, Torino tel. 011 5156239

Oct. 21, 2020

We All Live in Don DeLillo's World. He's Confused by It Too. - The New York Times

by J.C. DE MARTIN

Molta tecnologia digitale in questa bella intervista al Maestro DeLillo. jc https://www.nytimes.com/interactive/2020/10/12/magazine/don-delillo-intervi… (Sent from my wireless device; please excuse brevity and typos (if any))

Oct. 21, 2020

Re: [nexa] Replay Attack ad Immuni/GAEN

by Roberto Resoli

Il 20/10/20 17:00, Giovanni Biscuolo ha scritto: > Buongiorno Roberto e nexiane, > > grazie mille Roberto della segnalazione! Prego, è stata veramente una scoperta casuale, mi sorprende che non se ne parli di più. > Ho dato una rapida occhiata nei miei archivi e non mi pare che questa > _specifica_ vulnerabilità sia stata segnalata prima in questa lista, > anche se è il replay attack è chiaramente segnalato come possibile > vulnerabilità in almeno un paio di paper girati qui sul tema. Si, pare anche a me (ho controllato prima di inviare). > Roberto Resoli <roberto(a)resolutions.it> writes: > >> Il 19/10/20 11:55, Roberto Resoli ha scritto: > > [...] > >>> https://github.com/immuni-app/immuni-app-android/issues/278 >> >> Vedo che l'autore è Vincenzo Iovino, ricercatore all'università di >> Salerno, che ha anche pubblicato al riguardo un articolo su >> agendadigitale.eu: >> >> https://www.agendadigitale.eu/sicurezza/privacy/replay-attack-contro-immuni… > > In buona sostanza si tratta *solo*, e sottolineo _solo_, di una > simulazione "casalinga" di un replay attack (auto inflitto o verso terzi > fa poca differenza): complimenti a Iovino che ha sviluppato il > proof-of-concept e lo ha attuato con strumenti alla portata di molti con > le necessarie competenze. Sì, la cosa è abbastanza semplice da essere veramente attuabile in contesti reali. > Il commento ufficiale di Immuni [1] dice che non ci possono far nulla > perché si tratta di un problema di GAEN: comodo eh! :-D > > Da quanto leggiamo, qundi, è altamente probabile che tutte le > applicazioni che usano GAEN sono vulnerabili a questo attacco: cosa si > starà dicendo in Germania o altri paesi "interoperabili" di 'sta cosa?!? > Tutto tace. L'attacco è stato riprodotto anche nel contesto dell'app svizzera SwissCovid, come annunciato nello stesso issue di immuni molto probabilmente da Martin Vuagnoux che menzioni poco oltre. https://github.com/immuni-app/immuni-app-android/issues/278#issuecomment-69… > In Svizzera a quanto pare la "Swiss cybersecurity agency" e la "Swiss > public health authority" hanno dichiarato [2] che due attacchi > evidenziati da una analisi dei soliti Serge Vaudenay e Martin Vuagnoux, > tra cui il replay attack, sono improbabili. Grazie del puntatore. Mi pare che in [2] corrisponda a "2.2 False positive attacks". L'autore di [2] è il matematico Paul-Olivier Dehaye, che cita anche le valutazioni ([7] nel testo) del National Cyber Security Centre: "It is difficult to estimate the likelihood that someone really tries to poison the whole system by large-scale replay attacks or to try to put individuals wrongly into quarantine by a targeted re-play attack against some persons. As notified individuals are now eligible by law to free testing, targeted attacks would only be effective for a short time (until the results of the tests are known). Large-scale replay attacks would generate a high number of tests and thus be easy to detect. In case the worst case, the app could then be disabled. The damage would be limited to development costs of the app, and a lost opportunity. The alternative would be not do offer a proximity tracing app at all – even an app using a centralized approach would be vulnerable to replay attacks to a certain, though lower, degree. In the end, this is a question that cannot be answered on a technical level alone. While such an attack is possible, it is associated with high costs for the attackers. As such, we believe that the benefit of the app is higher than the potential risk of such an attack." le risposte di Dehaye, a mio parere assai condivisibili: " We dispute several assertions in this quote. We agree that it is difficult to estimate the likelihood that someone really tries to poison the system. However a starting point would be to assess the technical difficulty of doing so. By showing an example here (under specific constraints), we hope to move this discussion forward a bit. While the example shown here might appear very random and small scale, our quantitative discussion at the end will show that relatively small actors could actually be impactful. State-level adversaries would definitely have the possibility to acquire the technical capacity to create havoc. We do not think the worst case would necessarily be so clear. An attacker with this type of leverage over the system will not necessarily use it right away and overtly. Instead, in certain disinformation attacks, the attacker would work at changing the perception of the system by different actors, thereby polarizing people around it. We have specific scenarios in mind of how to achieve this, but this is not the focus of the present report. We contend that the cost of technically performing the attack could be negligible to some actors, and we show this with an example of a mobile app SDK that already harvests Bluetooth beacon data from millions of users and sends it to central servers. " Rispetto a questo scenario, inoltre, l'attacco prospettato da Iovino non necessita "harvests Bluetooth beacon data from millions of users", perchè, se capisco bene, gli RPI vengono rigenerati in base alle TEK dei positivi normalmente pubblicati dai server dell'infrastruttura. Questo semplifica di molto l'infrastruttura necessaria a portare l'attacco. L'attacco è ipotizzato anche in un Issue del "GAEN Internals": https://github.com/google/exposure-notifications-internals/issues/19 menzionato anche da Iovino, e a cui ha risposto confermando la fattibilità: https://github.com/google/exposure-notifications-internals/issues/19#issuec… > In *teoria*, ma è ovvio che nessuno lo vorrà mai fare, un attacco del > genere è alla portata di chi può installare sufficienti beacon bluetooth > e usare "fake base station" [3] per coprire aree pubbliche molto > frequentate. Però è ovvio che nessuno lo vorrà mai fare, sarebbe > assurdo no? Se ti riferisci allo scenario svizzero, come detto questo non sembra necessario. > Teorire paranoiche (?!?) a parte, la cosa interessante (triste?) è che i > rompiscatole come Iovino et al. non si sono limitati a segnalare ma > hanno fornito interessanti contributi per trovare le migliori soluzioni > ai problemi riscontrati, ma *pare* siano stati inascoltati... o meglio: > "non possiamo farci niente, rivolgetevi all'ufficio reclami"... alla > faccia del software libero. Citando sempre Iovino: https://github.com/immuni-app/immuni-app-android/issues/278#issuecomment-70… "5. Beyond proposing to look at alternative solutions, I actually do have a likely solution to withstand replay attacks that works with GAEN and would just require a change at the app level. Unfortunately, the Immuni's ecosystem is not (contrarily to what you write in your FAQ) open source and is not even testable, so I cannot perform tests to confirm whether my solution may really work. If I had the possibility of debugging, this would help. Being your process IMHO completely non-transparent until now, having you based the app on a system that is not publicly debuggable, and for other reasons, I prefer to not disclose my solution here. But I am open and you may contact me privately." > Ora veniamo al nocciolo della questione: tutto questo era AMPIAMENTE > noto [3] prima del 20 Maggio, giorno in cui Vittorio Bertola ha aperto > la issue #58: > https://github.com/immuni-app/immuni-documentation/issues/58 > (issue tuttora in stato "open") Che necessita comunque dell'infrastruttura per raccogliere gli RPI. Nel caso di Iovino gli RPI vengono semplicemente rigenerati a posteriori (cosa tra l'altro alla base del meccanismo di GAEN che effettua il controllo rispetto agli RPI raccolti dal telefono). Quello che dici in [3] è sacrosanto: "chi non le sa fare le può acquistare già belle che fatte" e i costi sono assai più bassi. Non chiudere questa vulnerabilità mi sembra veramente irresponsabile. > Sostanzialmente la issue segnala questo paper: > https://down.dsg.cs.tcd.ie/tact/replay.pdf > «A Coronavirus Contact Tracing App Replay Attack with Estimated > Amplification Factors» pubblicata il 19 Maggio 2020 da due ricercatori > del Trinity College di Dublino. > > Se proprio avete lo stomaco, vi invito a dare un'occhiata al thread > scaturito in quella issue, giusto per rendervi conto coi vostri occhi > del tenore delle risposte ricevute. > > Se non avete lo stomaco e avete il coraggio di fidarvi di me, posso solo > dirvi che al netto di trolleggiamenti vari quella issue conferma che il > problema è "irricevibile" da Immuni perché SAREBBE risolvibile solo > mettendo mano a GAEN. > > Inoltre in quella issue non mancano le solite critiche al fatto che un > tipo di attacco del genere non gioverebbe a nessuno e quindi possiamo > tranquillamente ignorarlo. > > Saluti, Giovanni. > > [...] > > > [1] https://github.com/immuni-app/immuni-app-android/issues/278#issuecomment-69… > > [2] https://deepai.org/publication/swisscovid-a-critical-analysis-of-risk-asses… > > [3] sono illegali ma fattibili > https://www.blackhat.com/docs/eu-15/materials/eu-15-Borgaonkar-LTE-And-IMSI… > chi non le sa fare le può acquistare già belle che fatte al costo di una > decina di migliaia di EUR: https://yatebts.com/products/satsite/ >

Oct. 21, 2020