analytics open source e GDPR compliant?
esistono, immagino, soluzioni open source e GDPR compliant per avere un po' di analisi di traffico e utenti di un sito senza bisogno di usare Google Analytics. avete suggerimenti? Maurizio || ------------------------------------------------------------------------ Maurizio Lana Dipartimento di Studi Umanistici Università del Piemonte Orientale piazza Roma 36 - 13100 Vercelli tel. +39 347 7370925
Ci sono tante alternative per siti web, più o meno sofisticate. Un po' più complicato per avere metriche da app su mobile ma tutto fattibile con un po' di sforzo educativo per marketing e retooling. Buoni suggerimenti su questa discussione recente su HN: https://news.ycombinator.com/item?id=29888599 On Thu, Jan 13, 2022 at 10:33 AM maurizio lana <maurizio.lana@uniupo.it> wrote:
esistono, immagino, soluzioni open source e GDPR compliant per avere un po' di analisi di traffico e utenti di un sito senza bisogno di usare Google Analytics. avete suggerimenti? Maurizio
|| ------------------------------------------------------------------------ Maurizio Lana Dipartimento di Studi Umanistici Università del Piemonte Orientale piazza Roma 36 - 13100 Vercelli tel. +39 347 7370925 _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Il 13/01/22 19:46, Stefano Maffulli ha scritto:
[...] Un po' più complicato per avere metriche da app su mobile
In ambito "app-analytics", tra l'altro gestita in modo integrato con la componente "web" (in parole povere: "uno strumento che consente l'analisi delle metriche relative agli accessi che arrivano sia da browser che da app") suggerisco "Count.ly". https://count.ly/community-edition Ho avuto la possibilita' di conoscerne personalmente il team di sviluppo e garantisco che la versione "community" puo' essere "100% self-hosted" (ossia ospitata su infrastrutture locali, di cui si mantiene il controllo) ed e' rilasciata con licenza open-source [1]. Saluti, DV [1] https://github.com/Countly/countly-server -- Damiano Verzulli e-mail: damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
io uso matomo ciao,s. On 13/01/22 19:24, maurizio lana wrote:
esistono, immagino, soluzioni open source e GDPR compliant per avere un po' di analisi di traffico e utenti di un sito senza bisogno di usare Google Analytics. avete suggerimenti? Maurizio
|| ------------------------------------------------------------------------ Maurizio Lana Dipartimento di Studi Umanistici Università del Piemonte Orientale piazza Roma 36 - 13100 Vercelli tel. +39 347 7370925 _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Il 13/01/22 19:55, Stefano Quintarelli ha scritto:
io uso matomo
Aggiungo che, in ambito P.A., esiste una iniziativa "pubblica" ed "ufficiale", basata su Matomo, che consente l'attivazione di servizio di web-analytics (dei siti della P.A.) in modo banale. Ulteriori dettagli, qui: https://www.agid.gov.it/it/design-servizi/web-analytics-italia Aggiungo, inoltre, che in ambito P.A., esiste il "Portale del Riuso" [1][2] che contiene alcuni software riutilizzabili (open-source) e... "dovrebbe" contenere (rif. Art. 69 del CAD [3]) gran parte del software sviluppato dalla P.A. ("dovrebbe"....). Un saluto, DV [1] https://developers.italia.it/it/riuso.html [2] https://developers.italia.it/it/search?type=software_open&sort_by=release_da... [3] https://docs.italia.it/italia/piano-triennale-ict/codice-amministrazione-dig...
On 13/01/22 19:24, maurizio lana wrote:
esistono, immagino, soluzioni open source e GDPR compliant per avere un po' di analisi di traffico e utenti di un sito senza bisogno di usare Google Analytics. avete suggerimenti? Maurizio
-- Damiano Verzulli e-mail: damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
Ho dimenticato di espandere la mia risposta: Per la Open Source Initiative ho rimosso Google Analytics la settimana scorsa e siamo passati a Plausible dopo 3 mesi di test. Il vantaggio principale è che non usa cookies quindi non abbiamo bisogno di quegli orribili banner che appestano il web Lo puoi vedere in azione su https://plausible.io/opensource.org L'unico svantaggio che ho notato finora sono i goal per tracciare le conversioni: non sono banali da configurare. Confronto a GA, Plausible ha meno funzionalità, ma quello che serve veramente c'è e per la maggior parte degli use case credo sia più che sufficiente. Peraltro Plausible è una bella storia di azienda europea, bootstrapped, open source. On Thu, Jan 13, 2022 at 10:33 AM maurizio lana <maurizio.lana@uniupo.it> wrote:
esistono, immagino, soluzioni open source e GDPR compliant per avere un po' di analisi di traffico e utenti di un sito senza bisogno di usare Google Analytics. avete suggerimenti? Maurizio
|| ------------------------------------------------------------------------ Maurizio Lana Dipartimento di Studi Umanistici Università del Piemonte Orientale piazza Roma 36 - 13100 Vercelli tel. +39 347 7370925 _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Salve Maurizio, On Thu, 13 Jan 2022 19:24:42 +0100 maurizio lana wrote:
esistono, immagino, soluzioni open source e GDPR compliant per avere un po' di analisi di traffico e utenti di un sito senza bisogno di usare Google Analytics. avete suggerimenti?
tutto dipende, ovviamente da quali analisi del traffico ti servono, quanto spesso e per farci cosa [0]. In moltissimi contesti, AWStats [1] e GoAccess [2] sono ancora più che sufficienti dal punto di vista delle funzionalità _necessarie_ e nettamente più "privacy friendly" e GDPR compliat delle alternative: si basano infatti sull'analisi dei log delle richieste degli utenti registrati dal webserver: ovvero dati che puoi scartare, ma non puoi evitare di ricevere. Niente cookie, javascript o altri traccianti. Nonostante l'età (e nel caso di AWStat, la grafica che non concede nulla alla modernità :-D) sono ancora progetti attivi e manutenuti. Questa proposta farà forse sorridere qualcuno, ma personalmente ritengo questo tipo di strumenti analitici basati su log (un tempo ce ne erano di più) molto più etici di quelli contemporanei: analizzano solo ciò che l'utente necessita/vuole mandarti (assumendo un browser fedele). Se vuoi spostarti (o ti serve) su qualcosa di più complesso/moderno, nell'ordine di maturità/potenza crescente trovi Shynet [3], i già citati Plausible [4], Matomo [5] e Open Web Analytics [6] (che però non combacia molto con la qualificazione "un po'" :-D). Per le PA di medie dimensioni o più, consiglierei Matomo. Per le piccole, AWStat o Plausible (ma SOLO se self-hosted, vedi oltre). Per i privati... dipende. [0] :-) Vi sono poi montagne di altre alternative ma questi strumenti coprono un spettro di necessità e valori etici molto ampio. Una sola cosa è però veramente importante: qualunque software tu scelga, eseguilo SUL TUO HARDWARE o su hardware di persone di cui ti fidi. Installare un software di analytics libero su un cloud USA è prendere in giro i tuoi utenti, tradirne la fiducia. MAI usare questi servizi "as a Service"! Perché poi capita che ti affidi ad "una bella storia di azienda europea, bootstrapped, open source" [7]... ma finisci per cedere comunque i dati dei tuoi visitatori ad aziende USA come Amazon, Digital Ocean e Cloudflare, come nel caso di Plausible [8] https://mxtoolbox.com/SuperTool.aspx?action=a%3aplausible.io&run=toolpage Insomma, dal punto di vista del GDPR, il SaaS di Plausible.io non è diverso da Google Analytics. Se ti piacciono i loro prodotti, pagali! :-D Ma per installarteli suoi TUOI server, non su fumosi "cloud". Giacomo [0] un esempio eclatante, qui l'analitics web gira sul cellulare: https://lbrito1.github.io/blog/2020/07/replacing_google_analytics_android.ht... (naturalmente, in questo caso lo sviluppatore non si è preoccupato particolarmente della privacy dei propri visitatori quando, nel 2021, ha introdotto l'uso di ngrok... però l'hack originale non aveva questo difetto) [1] https://github.com/eldy/awstats demo: https://www.nltechno.com/awstats/awstats.pl?config=destailleur.fr [2] https://github.com/allinurl/goaccess demo: https://rt.goaccess.io/?20220111171310 [3] https://github.com/milesmcc/shynet [4] https://plausible.io/self-hosted-web-analytics demo https://plausible.io/plausible.io [5] https://matomo.org/matomo-on-premise/ demo https://demo.matomo.cloud/ [6] https://github.com/Open-Web-Analytics/Open-Web-Analytics [7] https://server-nexa.polito.it/pipermail/nexa/2022-January/023008.html Mi perdonerà Stefano per la citazione, ma mi ha molto colpito l'ingenuità di "azienda francese + opensource = GDPR compliant" E' sempre GDPR compliant solo se lo gestisci sui TUOI server. [8] dall'Italia, plausible.io risolve anche 18.192.76.182, sempre di Amazon: https://ipinfo.io/18.192.76.182
Buongiorno Maurizio e Giacomo, mi permetto di integrare quanto detto da Giacomo, non sono espertissimo di GDPR, quindi prendete tutto questo cum granu salis; se qualcuno con più esperienza specifica trovasse cose non corrette per favore mi corregga! Giacomo Tesio <giacomo@tesio.it> writes: [...]
tutto dipende, ovviamente da quali analisi del traffico ti servono, quanto spesso e per farci cosa [0].
cioè: certe pratiche di marketing aggressivo sono /molto/ impegnative e onerose da gestire nel rispetto del GDPR (ma non credo sia quello di cui necessiti tu, Maurizio)
In moltissimi contesti, AWStats [1] e GoAccess [2] sono ancora più che sufficienti dal punto di vista delle funzionalità _necessarie_ e nettamente più "privacy friendly" e GDPR compliat delle alternative:
non ho capito ancora bene cosa significa "GDPR compliant", ma se quei due software (egregi!) fossero installati su server USA, magari assieme ai log "di default" del web server, /credo/ che i metadati raccolti sarebbero sufficienti a "guastare" la compliance, a meno di non scartare in partenza dai log i dati traccianti (IP, altro?) o usare sistematicamente strumenti di anonimizzazione dell'IP (https://github.com/DigitaleGesellschaft/Anonip#motivation)
si basano infatti sull'analisi dei log delle richieste degli utenti registrati dal webserver: ovvero dati che puoi scartare, ma non puoi evitare di ricevere. Niente cookie, javascript o altri traccianti.
AFAIU il trattamento dei dati anche attraverso cookie, javascript o altre tecniche traccianti (utili al browser fingerprinting) è del tutto lecito per il GDPR, posto che si gestiscano in modo corretto gli adempimenti burocratici; il GDPR non ammette segretezza (et al.) ma non esclude nessun mezzo per raccogliere i dati personali (e il web è la /rete da pesca a strascico/ perfetta per raccoglierli). i soli e unici dati che permettono di evitare di predisporre tutta la /burokratia/ per la compliance GDPR sono quelli strettamente necessari all'esecuzione del contratto... quindi, sempre AFAIU, anche solo le analytics sui log /non anonimizzati/ implicano "attività da GDPR" sicuramente possiamo dire che un criterio necessario e sufficiente per invalidare la "GDPR compliance" è che i dati vengano trasferiti in paesi che non adottano misure di protezione equipollenti al quelle EU, a meno di FARSI CARICO IN PROPRIO di valutare le misure tecniche, ecc. ecc.... è ormai giuridicamente noto che gli USA non sono tra quei paesi e /non ci sono/ misure tecniche adeguate per dimostrare di essere "GDPR compliant" [...]
Questa proposta farà forse sorridere qualcuno, ma personalmente ritengo questo tipo di strumenti analitici basati su log (un tempo ce ne erano di più) molto più etici di quelli contemporanei: analizzano solo ciò che l'utente necessita/vuole mandarti (assumendo un browser fedele).
anche solo memorizzare l'IP è tracciamento di un dato personale, anche secondo gli autori di questo: https://github.com/DigitaleGesellschaft/Anonip#motivation [...]
Una sola cosa è però veramente importante: qualunque software tu scelga, eseguilo SUL TUO HARDWARE o su hardware di persone di cui ti fidi.
se fattibile, questa sarebbe la soluzione più semplice ed economica, ma /se/ e /solo se/ si utilizza software già pacchettizzato per la distrubuzione GNU/Linux utilizzata sul tuo web server, altrimenti dal punto di vista sistemistico potrebbe diventare un incubo... anche (soprattutto?) usando Docker. un vecchio amico ripeteva spesso: «per me, se non è pacchettizzato in Debian... non esiste» :-D
Installare un software di analytics libero su un cloud USA è prendere in giro i tuoi utenti, tradirne la fiducia.
...e NON è "GDPR compliant"... a meno di far arrivare a quel software solo log anonimizzati?
MAI usare questi servizi "as a Service"!
beh no dai, "su hardware di persone di cui ti fidi" significa "as a Service" il problema col GDPR è che nel caso ci si affidi a terzi l'onere di verificare che i mezzi tecnici implementati (dai terzi) siano "GDPR compliant" ricade sul titolare del trattamento dei dati personali: /io/ piuttosto che gestire un sistema di valutazione del genere valuterei MOLTO seriamente l'opportunità di avere quei servizi "on premises"
Perché poi capita che ti affidi ad "una bella storia di azienda europea, bootstrapped, open source" [7]... ma finisci per cedere comunque i dati dei tuoi visitatori ad aziende USA come Amazon, Digital Ocean e Cloudflare, come nel caso di Plausible [8]
https://mxtoolbox.com/SuperTool.aspx?action=a%3aplausible.io&run=toolpage
ecco appunto, questo è un rapidissimo test che dimostra che i mezzi tecnici adottati dal fornitore NON sono adeguati alla protezione dei dati personali secondo quanto stabilito dal GDPR [...]
[7] https://server-nexa.polito.it/pipermail/nexa/2022-January/023008.html Mi perdonerà Stefano per la citazione, ma mi ha molto colpito l'ingenuità di "azienda francese + opensource = GDPR compliant" E' sempre GDPR compliant solo se lo gestisci sui TUOI server.
no Giacomo, se raccogli dati personali (i log dei web server di default raccolgono l'IP) per essere GDPR compliant devi comunque gestire tutti gli aspetti burocratici, anche se ti gestisci da solo i tuoi server (un server dedicato in un datacentre USA è tecnicamente "tuo" no [0]?)... a meno di anonimizzare i log ...stai a vedere che l'unico modo per proteggere i dati personali sul web è poter "navigare" anonimamente! :-O [...] Saluti, 380° [0] come può esserlo un server moderno (con Intel Maganement Engine per esempio) il cui accesso fisico (e il sistema operativo /virtualizzato/ che gira sopra a Minix3) non è sotto il tuo controllo P.S.: più il tempo passa più si dimostra che il GDPR serve SOLO a rompere le scatole alle brave persone mentre quelli che /catturano/ immense quantità di dati personali per profilare il mondo intero, Pubblica Amministrazione italiana compresa, continuano imperterriti nella loro opera di tracciamento.
Ciao Giovanni, siamo sul confine cibernetico fra sistemi legali ed informatici, per cui può essere utile esplorare ulteriormente alcuni aspetti che tocchi nella speranza che i giuristi in lista ci/mi correggano integrando la nostra conoscenza in proposito. On Fri, 14 Jan 2022 14:46:23 +0100 380° wrote:
un server dedicato in un datacentre USA è tecnicamente "tuo" no [0]?
No. Un server dedicato in un datacenter USA è (o meglio _può_essere_, dipende dal contratto con il fornitore USA) _amministrativamente_ tuo. Cioé, un CONTRATTO con un fornitore PUO' prevedere che tu amministri personalmente il server e promettere solennemente che non ci metterà mano. Ma poiché può essere obbligato dalla legge USA a violare il contratto senza avvertirti, aprendo il case del tuo server e agganciandosi al BUS di sistema, in sostanza per il GDPR trasferire dati a quel server, di tua proprietà, presso un datacenter di terze parti negli USA è trasferire dati negli USA. In altri termini: un server dedicato in datacenter USA _implica_ trasferimenti dati negli USA e dunque:
a meno di FARSI CARICO IN PROPRIO di valutare le misure tecniche, ecc. ecc.... è ormai giuridicamente noto che gli USA non sono tra quei paesi e /non ci sono/ misure tecniche adeguate per dimostrare di essere "GDPR compliant"
Poi, come scrivevi, se l'utente autorizza consapevolmente, liberamente ed esplicitamente il trasferimento, qualsiasi trasferimento è lecito. Google può legittimamente usare Google Analytics sui propri siti web. Il punto sostanziale, che credo ABBIA rilevanza giuridica, sta in quei "liberamente" e "consapevolmente": nessun Giudice competente considerebbe valido un consenso carpito attraverso dark pattern, per esempio, perché non libero e non consapevole. Quanto all'IP: sì è un dato personale sensibile, in quanto può permettere la correlazione di diverse connessioni avvenute alla stessa ora, permettendo a sua volta l'identificazione dell'utente e l'estensione del suo profilo personale. TUTTAVIA, è anche un dato tecnicamente necessario all'erogazione del servizio (quanto meno sui protocolli HTTPS). Quindi non puoi tecnicamente rifiutarne l'invio o evitarne la ricezione, se intendi usufruire di un servizio che vi si basa. Essendo tecnicamente necessario per il funzionamento del servizio, non devi chiedere l'autorizzazione al trattamento per l'IP, a meno che tu non ceda tale informazioni a terzi (che potrebbero abusarne, anche se a tua insaputa). Devi, questo sì, proteggere i log per evitare che vengano diffusi a terze parti, ma fintanto che li detieni per fini di sicurezza, per tempi ragionevoli (da qualche parte ho letto 15gg?) etc... non hai AFAIK grandi attività burocratiche da gestire. Mi sbaglio? Naturalmente, stiamo parlando di log. Altre parti della tua applicazione (ad esempio il DB) potrebbero contenere altri dati personali sensibili ed, oltre alla protezione dei dati da data breach, questo potrebbe implicare altri diritti dei soggetti in questione e dunque doveri per chi amministra i servizi. Ad esempio il diritto di avere i propri dati cancellati o rettificati. E per quanto oneroso, mi sembra un diritto/dovere... doveroso! :-D
P.S.: più il tempo passa più si dimostra che il GDPR serve SOLO a rompere le scatole alle brave persone mentre quelli che /catturano/ immense quantità di dati personali per profilare il mondo intero, Pubblica Amministrazione italiana compresa, continuano imperterriti nella loro opera di tracciamento.
Ma questo è vero SOLO perché non viene applicato. E non viene applicato per ignoranza informatica e debolezza politica.
MAI usare questi servizi "as a Service"!
beh no dai, "su hardware di persone di cui ti fidi" significa "as a Service"
Permettimi di chiarire: quando un'azienda che sviluppa opensource offre il proprio software come SaaSS [1] (improprimanete detto SaaS), è sempre meglio installare tale software su server sotto il proprio controllo fisico ed amministrativo. Il fatto che il software sia opensource NON SIGNIFICA AFFATTO che ci si la versione eseguita da terze parti corrisponda al codice pubblicato. L'unico modo per garantire la protezione dei dati personali degli utenti è amministrare il sistema di Analytics come si amministra il software cui si riferiscono. Nel caso di un sito web, non si può caricarlo su AWS, Azure o Google Cloud e poi sostenere che Amazon, Microsoft o Google non hanno accesso ai dati! Nello stesso modo, non si può eseguire il software di analytics su queste piattaforme di sorveglianza di massa e poi sostenere di proteggere i dati degli utenti... "perché è opensource"! Giacomo [1] https://www.gnu.org/philosophy/who-does-that-server-really-serve.html PS: scusa(te) per la lunga mail... spero non troppo noiosa.
Ancora una piccolissima nota: On Fri, 14 Jan 2022 17:46:54 +0100 Giacomo Tesio wrote:
MAI usare questi servizi "as a Service"!
beh no dai, "su hardware di persone di cui ti fidi" significa "as a Service"
Permettimi di chiarire: quando un'azienda che sviluppa opensource offre il proprio software come SaaSS [1] (improprimanete detto SaaS), è sempre meglio installare tale software su server sotto il proprio controllo fisico ed amministrativo.
Questo NON significa necessariamente sfruttare il lavoro di sviluppo gratuitamente. E' sacrosanto pagare gli sviluppatori, ad esempio con contratti di supporto, formazione o consulenza. L'unica cosa da evitare, se si intende proteggere seriamente i dati degli utenti, sono le soluzioni SaaS, fossero anche erogate dal Papa. Perché come dimostra Plausible.io (e molto di più Mozilla), le dichiarazioni pro-privacy, pro-GDPR etc... sono solo marketing. E se anche non lo fossero oggi, potrebbero diventarlo domani. L'unico modo per proteggere i dati, è controllare il software e l'hardware che li elabora. Giacomo
Ciao Giacomo, Giacomo Tesio <giacomo@tesio.it> writes: [...]
On Fri, 14 Jan 2022 14:46:23 +0100 380° wrote:
un server dedicato in un datacentre USA è tecnicamente "tuo" no [0]?
No.
Un server dedicato in un datacenter USA è (o meglio _può_essere_, dipende dal contratto con il fornitore USA) _amministrativamente_ tuo.
sì hai ragione [...]
Ma poiché può essere obbligato dalla legge USA a violare il contratto senza avvertirti, aprendo il case del tuo server e agganciandosi al BUS di sistema,
sì certo [...]
a meno di FARSI CARICO IN PROPRIO di valutare le misure tecniche, ecc. ecc.... è ormai giuridicamente noto che gli USA non sono tra quei paesi e /non ci sono/ misure tecniche adeguate per dimostrare di essere "GDPR compliant"
Poi, come scrivevi, se l'utente autorizza consapevolmente, liberamente ed esplicitamente il trasferimento, qualsiasi trasferimento è lecito.
Se l'ho scritto credo di aver sbagliato: l'utente che risiede in EU autorizza il trattamento (non trasferimento) dei propri dati e il responsabile del trattamento (anche extra EU, ma che opera sul territorio EU) li deve trattare in ottemperanza al GDPR; non c'è bisogno di esplicita autorizzazione al trasferimento, "semplicemente" il trasferimento è /vietato/ verso altre nazioni extra EU che non hanno norme equipollenti a quelle previste dal GDPR (e se non mi sbaglio queste altre nazioni devono essere elencate in un apposito elenchino); gli USA non sono tra queste. [...]
TUTTAVIA, è anche un dato tecnicamente necessario all'erogazione del servizio (quanto meno sui protocolli HTTPS).
sì ma non è tecnicamente necessario memorizzarlo nei log
Quindi non puoi tecnicamente rifiutarne l'invio o evitarne la ricezione, se intendi usufruire di un servizio che vi si basa.
no, ma /in teoria/ potresti rifiutare che venga memorizzato nei log (di /tutti/ quelli che fanno il routing del tuo traffico :-O )
Essendo tecnicamente necessario per il funzionamento del servizio, non devi chiedere l'autorizzazione al trattamento per l'IP,
effettivamente non mi risulta che nessuno chieda autorizzazione al salvataggio dell'IP nei log... quindi molto probabilmente hai ragione tu... però: [...]
Devi, questo sì, proteggere i log per evitare che vengano diffusi a terze parti, ma fintanto che li detieni per fini di sicurezza, per tempi ragionevoli (da qualche parte ho letto 15gg?) etc... non hai AFAIK grandi attività burocratiche da gestire. Mi sbaglio?
no hai ragione, i fini di sicurezza sono sufficienti, ma a che scopo di sicurezza serve tenere l'IP completo dei visitatori alle pagine web di un sito? IMHO è difficile poter dimostrare le necessità di sicurezza e quindi fare a meno del consenso informato. Cosa diversa sono invece le necessità di sicurezza dei server email (per questioni antispam, adottando il graylisting, anche se cominicia a essere superato), dei servizi tipo fail2ban (protezione da tentativi di attacchi brute-force) o di verifica della sicurezza degli accessi via SSH. Alcuni riferimenti: 1. https://www.termsfeed.com/blog/gdpr-log-data/ «GDPR and Log Data» 2. https://www.ctrl.blog/entry/gdpr-web-server-logs.html «EU GDPR and personal data in web server logs» In merito alla "data minimization" il sito 1. sopra indicato riporta: --8<---------------cut here---------------start------------->8--- The Internet Engineering Task Force's Internet Area Working Group (IntArea) has produced some draft guidance which makes a suggestion about how to minimize the data collected for your log files: "keep only the first two octets (of an IPv4 address) or the first three octets (of an IPv6 address) with remaining octets set to zero, when logging" --8<---------------cut here---------------end--------------->8--- Per quanto riguarda quindi i log dei web server, direi che una "best pratice" sarebbe quella di anonimizzare in partenza gli IP. In metrito allo storage sicuro degli altri log necessari ai fini della sicurezza, l'articolo 2. suggerisce: --8<---------------cut here---------------start------------->8--- logrotate is a very useful tool that can be used to encrypt logs in storage even on edge servers, and can help automate the deletion of old log files. It can also be used to encrypt log files in storage which when combined with organizational measures can limit access to decrypting the log files. [...] The server can then use the public key to encrypt its log files without with public key cryptography; resulting in the server being able to encrypt the data without being able to decrypt it without the private. The log files could even be transferred to a centralized log-storage server for cold storage. [...] The logs are still kept unencrypted for up to 24-hours when they were first recorded. This is a small time window when the data isn’t stored encrypted, but it’s required to allow human technicians and automated log analyzing tools (like SSHGuard or Fail2Ban) to process the data and act upon it to help detect and prevent unauthorized or unlawful system access. --8<---------------cut here---------------end--------------->8--- [...]
P.S.: più il tempo passa più si dimostra che il GDPR serve SOLO a rompere le scatole alle brave persone mentre quelli che /catturano/ immense quantità di dati personali per profilare il mondo intero, Pubblica Amministrazione italiana compresa, continuano imperterriti nella loro opera di tracciamento.
Ma questo è vero SOLO perché non viene applicato.
No, questo succede perché il GDPR è la risposta sbagliata a una /gravissima/ carenza tecnica: la completa mancanza di anonimato in rete, ovvero l'IP non è anonimo. Sia chiaro: tutte le persone che hanno progettato, implementato e che cercano di far rispettare il GDPR hanno la mia più sincera stima, ma quello strumento non può funzionare.
E non viene applicato per ignoranza informatica e debolezza politica.
Anche se venisse pienamente applicato avrebbe così tante carenze /informatiche/ (i devices /hanno/ backdoors, la rete /è/ un colabrodo) che sarebbe comunque inadeguato; non vale la pena rischiare di perderci la salute per vederlo applicato a un ambiente tecnicamente inadeguato Il succo della mia critica del GDPR è contenuto in un mio messaggio del 13 Dic. scorso https://server-nexa.polito.it/pipermail/nexa/2021-December/022758.html --8<---------------cut here---------------start------------->8--- Il senso profondo di questo progetto (uno dei molti esempi, purtroppo spesso falliti nel tempo per varie ragioni) è che un altro modo di /progettare/ e /implementare/ la tecnologia (digitale in questo caso) è possibile. É ovvio ma purtroppo tocca ribadirlo ogni volta. Io credo che questo modo di procedere, ovvero agire /nella/ tecnologia (dall'interno), sia di almeno un ordine di grandezza più efficace che agire /sulla/ tecnologia (dall'esterno), con regole /estremamente/ difficili da applicare proprio perché /aliene/ allo spazio - il cyberspazio - nel quale le persone /agiscono/ tecnologicamente. --8<---------------cut here---------------end--------------->8---
MAI usare questi servizi "as a Service"!
beh no dai, "su hardware di persone di cui ti fidi" significa "as a Service"
Permettimi di chiarire: quando un'azienda che sviluppa opensource offre il proprio software come SaaSS [1] (improprimanete detto SaaS), è sempre meglio installare tale software su server sotto il proprio controllo fisico ed amministrativo.
Il fatto che il software sia opensource NON SIGNIFICA AFFATTO che ci si la versione eseguita da terze parti corrisponda al codice pubblicato.
sì certo, è per questo che è importante /compilarlo/ (le distribuzioni software svolgono un servizio di "compilation as a service", il 98% delle quali usando compilatori e librerie già compilate la cui integrità è impossibile da verificare) ed eseguirlo su hardware di persone di cui ti fidi, il vero problema è come si "guadagna" la fiducia.
L'unico modo per garantire la protezione dei dati personali degli utenti è amministrare il sistema di Analytics come si amministra il software cui si riferiscono.
concordo, con il /caveat/ che purtroppo trasmettere i dati in rete è tecnicamente insicuro... ma questo in genere viene escluso dalla responsabilità di chi tratta i dati personali, perché non ci può fare nulla (almeno se applica le protezioni allo "stato dell'arte") [...] Ciao, 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
participants (6)
-
380° -
Damiano Verzulli -
Giacomo Tesio -
maurizio lana -
Stefano Maffulli -
Stefano Quintarelli