Codice sorgente app "YouPol"

L’applicazione è della Polizia di Stato.

Dove è hostato il codice sorgente?

1 Mi Piace

Tolto il rispetto formale di un obbligo di legge (ammesso che il software sia stato sviluppato o specificatamente commissionato da una p.a. italiana), per capire insieme, in un caso come questo quali sono i benefici attesi di pubblicazione e riuso della app (e del relativo backend)?

Più o meno è tutto spiegato qui Public Money, Public Code

C’è da considerare l’opposto: è normale avere closed source l’applicazione per fare segnalazioni alla polizia? Che usa firebase e quindi google legge i messaggi?

Ci vuole più trasparenza

4 Mi Piace

Chiaro.
Diciamo che ci sono due motivazioni:

  1. risparmio per altri soggetti (anche privati, eh) dato da riuso totale o parziale;
  2. trasparenza e controllo diffuso sul funzionamento e l’uso dei dati personali raccolti.

C’e’ anche qualche risvolto negativo:
3) mettere a disposizione il codice rende piu’ facile la vita a eventuali attaccanti.

Ora, sul punto 1) mi chiedo se tutte le applicazioni sviluppate dalla p.a. possano generare risparmio. alcune sono di uno specifico esasperato e hanno un senso solo per la p.a. che se le sono fatte (fare). Magari qualche modulo puo’ essere utile (es.: parte di autenticazione con SPID, integrazione con una banca dati nazionale, gestione dei documenti ecc.)

Sul punto 2) mi chiedo quanto sia efficace il controllo. L’esempio app IO non troppo distante nel tempo è significativo: che app IO geolocalizzasse a google i suoi utenti per operazioni insulse se ne e’ accorto il garante, non analizzando il codice ma lanciando la app in un ambiente apposito.

Sul punto 3), senza entrare nel merito di questo youpol (che magari e’ uguale uguale a un servizio di segnalazione di lampioni spenti), non mi sembra disdicevole una certa chiusura se il software e’ utilizzato in ambiti sensibili (quali attività di polizia). Vero che il controllo, proprio perche’ si tratta di dati trattati dall’autorità pubblica dovrebbe essere amplificato per evitare derive autoritarie… pero’ insomma, sono tutte esigenze da bilanciare. E, per esempio, per capire dove vanno i dati sembrano che esistano strumenti appositi, senza bisogno di aprire il codice.

2 Mi Piace

Sul terzo punto, che è l’approccio Security through obscurity - Wikipedia posso solo dire che è uno degli approcci più sbagliati della sicurezza informatica

4 Mi Piace

Secondo me il punto 3 va mediato.

Ok @Astheneir, formalmente e praticamente parlando la security by obscurity è una pessima idea.
Ma @frantheman ha correttamente osservato che pubblicare il codice rende oggettivamente la vita più facile agli attaccanti.

Il problema dal mio punto di vista è chi manutiene l’applicazione. Se essa è manutenuta regolarmente, una vulnerabilità di sicurezza scoperta da un ricercatore sarebbe sanata facilmente.

Se il progetto fosse chiuso e la manutenzione non fosse in corso? La falla rimarrebbe aperta.

Personalmente porrei questa come discriminante della sicurezza. Se un prodotto non è manutenuto, ha finito il suo ciclo di vita, meglio tenere il codice da parte, perché in caso di patatrac sarebbe necessario ritirare l’applicazione. Pubblicare il codice anticiperebbe la data del patatrac

Sono onestamente più spaventato dalla seconda domanda che dalla prima, ma in generale concordo.

Ha provato a contattare l’assistenza del prodotto per capire la licenza del software e la possibilità di avere il sorgente?

supporto.relest@poliziadistato.it

No, preferisco rimanere anonimo e le mail non sono il miglior metodo per rimanere tali.
Se qualcuno volesse provare a scrivere e riportare qui eventuali risposte, lo invito a farlo

apri TOR browser, fai un account protonmail e manda tutte le mail che vuoi.

Devi chiedere i sorgenti di una APP… non i codici per lanciare una testata nucleare eh… mha…