Supporto oltre a Apple/Google #1718
Comments
|
Bisogna inserire un ticket qui: https://gitlab.com/fdroid/rfp/-/issues |
|
@strk potrei pensarci io..mi servirebbe capire se i mainteiner mi danno "l'autorizzazione" a procedere. Inoltre dovremmo essere compatibili con le inclusion policy (No firebase, no google play-services..etc..) |
|
@giupardeb: leggendo la licenza si direbbe tu non abbia bisogno di autorizzazioni.
Vedi https://github.com/pagopa/io-app/blob/master/LICENSE#L59 |
|
bene, mi era sfuggita quella frase..la cosa importante da fare a questo punto è creare una fork ed iniziare ad eliminare firebase e i playservices |
|
È più stato fatto qualcosa? |
|
Beh ho provato a fare qualcosa...ma non avendo molta esperienza in firebase..ho avuto qualche problema all'inizio..poi purtroppo non ho avuto più il modo di lavorarci. |
|
Io volevo darci un'occhiata e provare a fare una versione senza Firebase, da pubblicare su F-Droid. La domanda, più che sul codice della app, è se la nuova "app" sarà o no autorizzata a chiamare le API del backend. Non so se @Undermaken o qualche altro developer può fare da tramite per questo |
|
Ciao @Enrico204, l'app non ha alcun meccanismo di HMAC o certificate pinning per cui il mittente della richiesta venga discriminato. Una volta ottenuto il token di sessione attraverso la login SPID o CIE ogni richiesta HTTP, con header Authentication impostato con il token di sessione, è valida. Piuttosto, lato nostro, dovremmo fare in modo di inoltrare la notifica verso altri providers che non siano solo Firebase e APNS (es Onesignal ?!). IO pone le sue fondamenta sugli avvisi (la PA verso il cittadino e non il vice versa), quindi è una caratteristica che dovrebbe essere assicurata quella delle push notifications [Update] la mia risposta è puramente tecnica. Fare un app clone di IO e distribuirla, è possibile? Questo è un tema di diritti di prodotto, immagino. Non so dire se sia lecito oppure no (@CaraDune thoughts?) Sicuramente si potrebbe incanalare lo sforzo tra comunity e PagoPa che ne garantisce l'autorità e la bontà dell'artefatto |
|
Si, come avrai intuito dopo l'update, la domanda era principalmente "burocratica". Tecnicamente parlando le cose si possono risolvere (c'è anche microG da valutare, per esempio), ma prima di fare qualsiasi sforzo dobbiamo capire se lato PagoPA è consentito che app di terze parti possano usare lo stesso backend. Senza backend chiaramente non ha senso neanche provare. Dal punto di vista di licenze per il codice della app, non ci sono problemi alla redistribuzione della app vista la licenza in uso (sebbene il trademark e forse qualche asset siano da cambiare). Se sarà consentito fare delle richieste al backend da app di terze parti, allora inizierò a metter su un repository e proporre qualche soluzione per i problemi tecnici (notifiche, etc) |
|
TL;DR: l’App potrebbe essere distribuita in futuro su altri store, ma non da terze parti, solo da PagoPA S.p.A. che ha l’incarico esclusivo per legge di sviluppare, pubblicare e gestire l’App, e condividere la roadmap con la Presidenza del Consiglio dei Ministri. stessa cosa vale per i contributi (preziosissimi) della community, che data la gioventù dell’App sono ancora disorganici, ma abbiamo in programma di implementare una serie di action per razionalizzare e incrementare l’engagement della community, che ci piacerebbe appunto condividere con la community per raccogliere feedback. infatti, al momento siamo già aperti ai contributi e li integriamo regolarmente, ma vorremmo fare di più - per questo servono delle policy e dei ruoli definiti |
|
@CaraDune purtroppo devo correggerti: la App può essere distribuita da terze parti. Lo avete stabilito nella licenza di questo repository (EUPL, e per alcuni asset Apache 2.0 e OFL). Dunque, dato per assunto che la app è redistribuibile e anche modificabile, la domanda rimane: le API possono essere utilizzate da qualsiasi persona liberamente, o soltanto dalla app distribuita e rilasciata da PagoPA? |
|
Grazie @Enrico204 per la domanda. Speriamo di aver chiarito la tua curiosità |
|
Quindi in sostanza l'uso delle API richiede un permesso dalla PA, ho capito bene ? Come si ottiene tale permesso ? |
|
grazie @CaraDune della precisazione. In effetti logo e nome della app (ed eventualmente altri asset) possono essere protetti da diversa licenza, cosa che tuttavia non pregiudica la redistribuzione di un binario compilato dai sorgenti (come nel caso di Firefox, che su F-Droid usa un logo diverso ed il nome "Fennec" per gli stessi motivi). Dunque, anche io, leggendo il messaggio, sono giunto alla stessa conclusione di @strk che sia necessaria un'autorizzazione per poter utilizzare le API che sta usando la app "Io". E anche io chiedo di conoscere le modalità per questo accreditamento. Siamo impazienti di capire come possiamo aiutare "Io" a diffondersi anche tra le persone, come me e credo @strk , che usano un sistema libero e non possono legarsi a Google per accedere ai servizi della PA :-) (ovviamente, la redistribuzione avverrà con un nome e logo diversi, in pieno rispetto delle licenze) |
|
Grazie a @Enrico204 e @strk per queste domande, anzi saremo contenti se le info che seguono vorrete diffonderle ad altri contributori interessati. In generale, potete consultare il sito ufficiale del progetto IO io.italia.it per avere un overview - è davvero molto ricco e dovreste trovare tutte le informazioni che vi interessano, in caso contrario fatecelo pure sapere, così che possiamo integrare i contenuti per altre persone che potrebbero avere le stesse vostre domande. L’intero funzionamento del progetto si trova invece su Docs Italia, dove sono pubblicate le linee guida che stanno per essere adottate da AgID ex 71 CAD, che regoleranno il punto di accesso telematico (di cui l’app IO rappresenta il canale mobile): lì c’è il dettaglio di tutto il processo, i ruoli dei diversi attori coinvolti, gli obiettivi, gli SLA, le misure tecniche, e soprattutto le disposizioni in materia di privacy (a cui teniamo particolarmente). Sull’uso delle API, come vedrete anche dalle linee guida, essendo pubbliche è consentito a chiunque di effettuare dei test (anche in produzione, utilizzando i vostri CF personali o CF fake che possiamo fornirvi), registrandosi al back office e consultando la documentazione API. Per esporre servizi su IO, utilizzando le API per conto di pubbliche amministrazioni, invece, uno sviluppatore (in proprio o con la sua società) deve stipulare un accordo con la PA interessata in qualità di partner tecnologico. Questo può essere fatto con gli strumenti legali che la singola PA ha previsto (es. una gara). La singola PA, a sua volta, dovrà (se non l’ha già fatto) aderire a IO firmando l’accordo di adesione (sempre pubblico e aggiornato, lo trovate qui). Per abilitare il partner tecnologico, dovrà nominare con proprio atto la persona fisica che opererà sul backoffice in qualità di Delegato e inserire il suo nominativo e i suoi riferimenti nell’accordo stesso, comunicando a PagoPA qualsiasi variazione via PEC secondo le istruzioni contenute nell’allegato 4 dell’accordo. Solo a seguito di comunicazione formale, infatti, il partner tecnologico può essere abilitato dai nostri admin ad operare in produzione per esporre i servizi che la PA intende offrire su IO. Si può dire che PagoPA sta considerando la rilevanza del caso d'uso di essere su F-Droid e potrebbe, in futuro, farlo (in virtù del mandato istituzionale conferito per legge). Speriamo di esservi stati d’aiuto, e grazie ancora per l’interessamento. Abbiamo in programma di coinvolgere la community sempre di più e ci piacerebbe farlo anche con il vostro contributo. |
|
grazie @CaraDune del vostro interessamento a questo ticket! Sto leggendo con molta attenzione le linee guida che ha indicato, sono molto interessanti. I "problemi" che io vedo con le linee guida indicate sono questi due:
Ho anche letto la documentazione delle API e le informazioni sul back-office, e tutto quello che riguarda la partnership tecnologica. Tuttavia sono cose che riguardano l'esporre servizi dentro "IO", mentre qui stiamo parlando di quello che, nella documentazione sopra citata, viene chiamato "Punto di accesso telematico" (ovvero la stessa app "IO"). Le linee guida sopra citate, riguardanti appunto il "Punto di accesso telematico", e la mancanza di un metodo di accesso completamente libero (APK libero disponibile, o sito web) obbligano le persone a legarsi alle due aziende private Google e Apple. Questo non è sempre possibile: ci sono casi documentati 1 2 3 4 in cui le due società, per motivi non comunicati alla persona interessata, hanno deciso di interrompere unilateralmente la fornitura di servizi a privati cittadini, per sempre. In altre parole, se la app "IO" rimane soltanto sul Google Play Store e sull'Apple App Store, ci sono (e/o ci saranno) cittadini che non potranno accedere alla app per volontà delle due aziende (in gergo, un "lifetime ban"). Visto che le linee guida sono ancora in bozza, e visto che ci sono diversi di noi che si stanno offrendo di collaborare a questa cosa, credo sia molto importante per PagoPA e AgID prendere al volo questa occasione di risolvere il problema tecnico-legale sopra citato che presenterà sicuramente in futuro. Comprendo che per strutturare un rilascio anche su piattaforme alternative serva del tempo (tecnico e non). Propongo quindi una soluzione: autorizzare l'uso delle API correnti della App "IO" a terze parti fino a quando PagoPA non sarà attrezzata per gestire il rilascio di APK liberamente (su F-Droid e altre parti), così da permettere alla community di creare una versione alternativa di "IO" (ovviamente con diverso logo/nome/etc) per colmare questo gap. La community si occuperà di questo fork (quindi partendo dal codice attuale, e tenendolo allineato) fino a quando PagoPA non sarà pronta a gestire la situazione. Grazie per il tempo dedicato :-) |
|
Ciao, ci sono novità? |
|
Ciao a tutti e grazie ancora per la vostra pazienza. Per quanto riguarda F-Droid (e altri stores) non siamo ancora in grado di fornire aggiornamenti in merito. Procedo a fare un pin di questa discussione. |
pietro909
changed the title
|
Salve a tutti, vorrei sapere se è previsto un aversione dell'app per KaIOS. Il sistema operativo va diffondendosi soprattutto tra le fasce di popolazione a rischio digital divide. Credo sarebbe una cosa utile averre il supporto per questo sistema operativo per permettere alle persone di accedere ai servizi della PA senza avere telefoni di costo troppo elevato. |
|
Ciao @scriptavolant, meglio evitare di andare off-topic visto che qui si parla espressamente di F-Droid. Ho visto che KaiOS non è altro che il continuo di Firefox OS e mi pare che le applicazioni presenti siano basate sulle tecnologie Web, quindi presumo quanto ci sarà un'interfaccia Web a IO sarà più facile fare una versione per KaiOS. Inoltre non sono sicuro di quanto sia diffuso questo OS in Italia (ripeto in Italia, ho visto che è molto più diffuso in altri paesi come l'India). |
|
Salve, a che punto è la versione web? Alcuni servizi (come la Carta Giovani Nazionale) sono erogati esclusivamente tramite IO e non credo sia giusto subordinarne la fruizione al possesso di un account Apple o Google. |
Sottoscrivo, una versione web potrebbe essere una soluzione alternativa al problema dell'accesso senza essere legati a servizi proprietari (e come già evidenziato è prevista come possibilità dalle linee guida, par. 4.2. - Punto di accesso telematico). Sarebbe anche un aiuto al problema del digital divide evidenziato da @scriptavolant : a quel punto il requisito minimo diventerebbe un browser, utilizzabile anche da un Internet Point. Tag: @pietro909 @CaraDune |
|
Un inizio (ma assolutamente non un punto di arrivo) potrebbe essere semplicemente rilasciare l'APK tramite le release di GitHub. La dipendenza dalle API di Google rimane, ma queste possono essere rimpiazzate da MicroG dall'utente finale stesso (l'utente che usi MicroG, al momento, non ha proprio modo di scaricare l'applicazione). Ovviamente questo sarebbe solo un punto di inizio per permettere l'utilizzo basilare dell'applicazione a chi non voglia o non possa interfacciarsi con Google nell'uso dell'applicazione. L'ideale, eticamente parlando, sarebbe la possibilità di evitare ogni tecnologia proprietaria se l'utente finale lo desidera, ma visti i potenziali tempi di sviluppo e l'importanza dell'applicazione, nel frattempo un compromesso del genere eviterebbe interminabili attese a chi volesse già da ora usare l'applicazione su dispositivi "degoogled". |
Per le push notification esiste unifiedpush ( completamente opensource e self-hostable ) : |
Sono perfettamente d'accordo, rilasciare i pacchetti ufficiali su github sarebbe un buon inizio. |
|
Vista la recente decisione di transitare, in un prossimo futuro, da SPID a CieID risulta necessario poter anche accedere al codice sorgente di quest'ultima app e valutare se può essere compilata per il rilascio su F-Droid o altri store alternativi. L'unica discussione che ho trovato in merito è questa Codice sorgente app CieID - CIE - Forum Italia. |
|
Vorrei aggiungere: l'utilizzo della Play Integrity API su quest'app è qualcosa di veramente negativo. Molte persone utilizzano GrapheneOS (che è oggettivamente più sicuro del sistema operativo usato dal 90% dei cellulari Android) o Ubuntu Touch (con virtualizzazione di Android tramite Waydroid), ma anche cellulari Huawei rilasciati dopo il ban. Play Integrity non risolve niente in quanto le famose chiavi Keybox di Google finiscono in leak pubblici ogni 15 min. Rendete solo più difficile a utenti legittimi di accedere all'app. |
CIE ID è un programma proprietario, fatto da una srl che ne detiene i diritti, è rilasciata sotto licenza libera una libreria (middleware) per interagire con la CIE. Rilasciare IO su fdroid sarebbe fantastico. |
Tralaltro mi si deve spiegare cosa si può fare con il root di male che giustifichi sto schifo di play integrity? Oh no, il dispositivo ha il root, il root è il male... Ma quand'è che ci si sveglierà? Il root è in ogni sistema informatico, non dico che sia essenziale per il suo funzionamento ma senza il sistema diventa ridicolo, e in effetti... Senza root non si potrebbero installare applicazioni, su Android Google (in realtà anche negli altri OS mobile) ha fatto una forzatura ma in ogni altro sistema operativo qualunque esso sia senza di esso non si potrebbe fare quindi si, si potrebbe dire che è essenziale . Parliamo però di Android, il suddetto è soltanto un os ridicolo che non può proteggere e/o criptare i dati delle app usando sistemi (vedi la TEE) che renderebbero i suddetti dati inaccessibili al root, allo stesso modo le varie app non criptano i loro stessi dati sensibili, per esempio io só di un'app bancaria che lo fa, la stessa cripta i suoi stessi file importanti. Allo stesso modo c'è un'altra app che all'avvio verifica tramite firma la sua stessa integrità, se non verificata mostra un messaggio e si chiude. Chiaramente la coesistenza è possibile.... Invece Google neanche si può impegnare a coesistere con il root e hanno fatto di tutto per distruggerlo (compreso il lavaggio del cervello a cui stiamo assistendo dove tutte le app lo bannano), e hanno implementato sistemi per tracciare e bloccare lo stesso e fanno advertising su come lo stesso sia pericoloso. Tutto questo per dire: il play integrity è ridicolo, questi controlli sono ridicoli, per carità non ho niente contro le varie app ma per amor del cielo, Android e le app potrebbero essere fatte in modo da poter coesistere con il root e non avere play int-bullsh*t Sembrerò pesante ma giuro, non ne posso più, Google ha esagerato e le persone ci sono cascate come polli a mio parere. |
|
Play Integrity, a partire da maggio 2025, sui cellulari con almeno Android 13 richiederà patch di sicurezza rilasciate nell'ultimo anno. https://developer.android.com/google/play/integrity/improvements
|
Non per difendere play integrity, trovo sia un sistema assurdo e afunzionale. Però attualmente "io" funziona anche senza (almeno a me), lo richiede solo per documenti digitali a quanto ho capito (la funzione dovrebbe essere disponibile per tutti da domani credo). |
È un dato di fatto che molti (troppi) dispositivi low-end non ricevono patch di sicurezza negli anni. Con questi requisiti si tagliano fuori troppi utenti. Pure Google Wallet si limita a Play Integrity "basic" |
I requisiti non sono di sicurezza ma meramente di conformità, altrimenti non consentirebbero l'aggiunta di documenti su telefoni con Android 8. https://github.com/eu-digital-identity-wallet/eudi-app-android-wallet-ui?tab=readme-ov-file#important-things-to-know (grassetto mio)
Essendo Play Integrity meramente una casella da spuntare potrebbero semplicemente passare a un livello di integrità inferiore così da preservare la compatibilità. |
Sarebbe molto utile permettere di scaricare l'applicazione da https://f-droid.org
The text was updated successfully, but these errors were encountered: