“Immuni” non è e non può essere un thriller. La gente ha bisogno di sentire anche voci che stonano con gli entusiasti filogovernativi che si complimentano vicendevolmente con “Good Job!” e altre espressioni anglofone che simulano un successo che è ancora tutto da vedere.
“Il Reverendo” ha risposto alla sollecitazione a tenere…. un’omelia, invito rivoltogli da Umberto Rapetto appena ha saputo di suoi esperimenti e verifiche sul codice sorgente.
Massimiliano Uggeri viene visto da molti come il “prete spretato”, come il “Bastiano” del Marchese del Grillo. Ha avuto qualche disavventura imprenditoriale, ma la sua competenza prescinde dalle tribolazioni giudiziarie che qualcuno vorrebbe utilizzare come scudo alle frecce che “Max” è pronto a scoccare.
Sviluppatore e hacker, studi di Ingegneria elettronica al Politecnico di Milano e una significativa esperienza al Media Lab del MIT, Massimiliano Uggeri conosce sulla propria pelle il fantasticare che si può fare sulle “app” e la lezione della vita lo spinge oggi a redigere questo “messaggio in bottiglia” e a “dire la verità, tutta la verità e nient’altro che la verità” su “Immuni”…
Alcune premesse iniziali, giusto per settare le aspettative e capire bene di cosa stiamo parlando:
Apple iOS è un sistema chiuso, blindato “by design”, e non è possibile bypassare questi controlli: tutto viene controllato dal Sistema Operativo, che per evitare situazioni potenzialmente rischiose, per questo Apple – insieme a Google – ha rilasciato la possibilità di accedere al Bluetooth e lasciarlo sempre acceso – che è una delle cose a rischio – a chi come entità governative o sviluppatori ufficialmente investiti da queste volesse sviluppare un’App per il tracciamento.
Quando il Commissario straordinario per l’emergenza Covid-19 (che per brevità qui chiameremo Arcuri) ha chiesto chi fosse in grado di fare gratis quest’App si sono presentati in molti. Peccato che Apple e Google ancora non avevano annunciato questa nuova possibilità, nemmeno nei canali non ufficiali si sapeva nulla, per cui chiedersi cosa c’era scritto nelle funzionalità dell’App approvata da Arcuri è assolutamente legittimo, ma lo è ancora di più chiedersi come società blasonatissime ed esperte abbiano potuto solo pensare di realizzare un’App – parlo per iOS – ben sapendo che non avrebbe non solo potuto funzionare ma che sarebbe stata rifiutata da Apple.
Dopo qualche tempo Apple e Google rilasciano le specifiche, per cui iniziano i lavori, anche se ormai è chiaramente troppo tardi perché l’App abbia qualche efficacia, ma comunque a gran voce viene chiesto di rilasciare il codice sorgente, in modo che – visto l’argomento molto delicato – chiunque in grado di farlo possa sia controllare che non ci siano cose “strane” ed anche contribuire. E qui cominciano a non quadrare le cose: prima viene rilasciata la documentazione (OK, avendo fatto l’analisi è chiaro che sia più facile che venga prodotta prima) e poi – dopo richieste sempre più pressanti – ecco che arriva il codice! Si, ma solo delle App – Android e iOS – e niente per il backend, ovvero la parte server che riceve i dati – non si sa quali – che li registra e gestisce. Questo rende molto difficile – diciamo quasi impossibile – capire quali vengano inviati, ma soprattutto non è proprio dato di sapere chi e cosa verrà fatto di questi dati.
Sappiamo che il sistema (chiamarlo App non ha nessun senso) è fatta da Bending Spoons, ma di fatto è un “consorzio” di società nel quale è chiaro cosa faccia solo BS. Degli altri attori si sa poco o nulla, se non che sono Jakala, SOGEI, e PAGOPA (che fa pagamenti sicuri? Ma che c’entra?)
Qualche giorno fa avevo scritto qualche cosa sulla prima versione dell’App iOS rilasciata: vabbè, sintetizzo dicendo che era una versione inutile, con riferimenti a server inesistenti ed altre amenità varie, tipo che senza poter recuperare la chiave per la crittografia (non rilasciata, ma nel codice c’era l’indirizzo del server inesistente) era di fatto un mockup, una demo, la definizione che avevo dato era “ci hanno messo nel recinto dei bambini così i grandi potevano lavorare in pace”, ed ho continuato a controllarne l’evoluzione. In tutto questo l’utilizzo smodato di tool esterni e di Pod (pezzi di codice open source) che sono sicuramente comodi ma di fatto fanno perdere il controllo del codice.
Poi arriva la grande sorpresa: il codice del Backend! Ok, in meno di mezz’ora installo una macchina virtuale con Debian minimalista, scarico tutto il codice e inizio ad installare. La documentazione per l’installazione del backend è scarna, come per l’App piena di tool esterni e librerie di terzi, grazie ad un po’ di esperienza e una buona dose di testardaggine, sono riuscito a farlo partire. Scarico la versione definita come “RELEASE” con tanto di pacchetto firmato per la submission ad Apple e… niente, è cambiato davvero poco o nulla. Niente di trascendentale, per carità, ora i server sono magicamente apparsi funzionano ma sono malconfigurati (chiave e i documenti necessari per la GDPR e i Termini di Servizio non sono accessibili, permesso negato, e non tutto viene recuperato e/o trasmesso in HTTPS, forse PagoPA che di mestiere fa anche i certificati SSL aveva da fare in questi giorni, boh?) Nella RELEASE c’è ancora il menu di debug, e – tra l’altro – crasha parecchio.
Insomma: fin dal primo rilascio su GitHub la versione è sempre stata “1.0” che già uno dice vabbè, così fino alla RELEASE che hanno – secondo loro – già inviato a Apple. Però dentro c’è scritto 0.9.0: come lo spiegate se non con una “presa per il culo”?
Qualche riga di debug (sul telefono, ovviamente): per chi conosce la materia è chiaro che sono errori un po’ grossolani, e
2020-05-29T14:04:12+0200 error: [immuni.main-application]: Unable to schedule background task: Error Domain=BGTaskSchedulerErrorDomain Code=1 “(null)”2020-05-29 14:04:42.808506+0200 Immuni[45219:6791010] Task <5CD722CA-E0D5-447F-AFA5-D088A5042C4D>.<2> finished with error [-1001] Error Domain=NSURLErrorDomain Code=-1001 “The request timed out.” UserInfo={_kCFStreamErrorCodeKey=-2102, NSUnderlyingError=0x6000036fb270 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 “(null)” UserInfo={_kCFStreamErrorCodeKey=-2102, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <5CD722CA-E0D5-447F-AFA5-D088A5042C4D>.<2>, _NSURLErrorRelatedURLSessionTaskErrorKey=( “LocalDataTask <5CD722CA-E0D5-447F-AFA5-D088A5042C4D>.<2>”), NSLocalizedDescription=The request timed out., NSErrorFailingURLStringKey=https://upload.immuni.gov.it/v1/ingestion/check-otp, NSErrorFailingURLKey=https://upload.immuni.gov.it/v1/ingestion/check-otp, _kCFStreamErrorDomainKey=4}2020-05-29 14:04:42.810928+0200 Immuni[45219:6791027] Task <5CD722CA-E0D5-447F-AFA5-D088A5042C4D>.<2> HTTP load failed, 0/0 bytes (error code: -999 [1:89])
2020-05-29 14:06:45.315550+0200 Immuni[45219:6789935] Could not signal service com.apple.WebKit.Networking: 113: Could not find specified service
LLVM Profile Error: Failed to write file “default.profraw”: Read-only file system
E qualche screenshot (dall’emulatore di Xcode
