• User

    @emanuele-ricci quindi ad oggi effettivamente non ci sono le garanzie richieste, perchè "si stanno attuando per raggiungere tale accordo".

    Mentre la soluzione usando direttamente google cloud sembrerebbe valida perchè:

    Quando utilizzi Google Workspace o Google Cloud:

    I dati appartengono a te, non a Google
    Google non vende i dati dei clienti a terze parti
    Google Cloud non utilizza i dati dei clienti per la pubblicità
    Tutti i dati dei clienti sono criptati per impostazione predefinita
    Proteggiamo i dati dei clienti dall'accesso di personale interno
    Non diamo mai ad alcun ente governativo un accesso "backdoor" ai dati
    Le nostre norme di tutela della privacy sono verificate in base agli standard internazionali

    https://cloud.google.com/security/transparency

    se lo dicono e non lo fanno, sarebbe un problema ben più grave di una sanzione da parte del garante che, parere personale, pensasse a capire come ottengono il consenso certi call center italianissimi a rompermi i maroni a ogni ora del giorno.

    edit: poi ripeto, se uno vuol essere ancora più sicuro come detto sopra, anzichè usare le istanze managed di App Engine, può benissimo creare il proprio server il cui hard disk è criptato con chiave gestite interamente dal cliente, ma a quel punto per aziende piccole, veramente, hai più ritorno di investimento andando totalmente alla cieca col tuo business online, oppure andare su soluzioni alternative, ma anche li, non è che sia tutto senza costi eh? anche un banale matomo va mantenuto


    kal 1 Risposta
  • User

    @claudiosaitta @kal avete assolutamente ragione, però vi faccio notare che il Garante ha analizzato e si è espresso su GA non su stape.io. Usare GA client side è palesemente errato, mentre... fino a che il garante non si esprime su stape.io io sono in buona fede.... Se seguiamo il vostro ragionamento che è corretto formalmente allora dovremmo smettere di usare FB, Google Ads, Insta e qualsiasi altra cosa abbia dati accessibili dagli USA....


    kal C 2 Risposte
  • Contributor

    @emanuele-ricci ha detto in Check list operativa per la migrazione a GA4:

    però vi faccio notare che il Garante ha analizzato e si è espresso su GA non su stape.io. Usare GA client side è palesemente errato, mentre... fino a che il garante non si esprime su stape.io io sono in buona fede

    Eh, insomma.

    La situazione legale quella è.

    Il bivio per me è:

    1. soluzione compliant 100% legale: in questo caso GA4 SOLO lato server su server PROPRIETARIO
    2. soluzione "alla bersagliera": lo installi lato client conscio del fatto che non sia compliant, e via

    È proprio una cesura netta.

    Soluzioni intermedie non possono essere vendute come "legali e compliant" perché non lo sono. Ti complichi la vita e basta... secondo me bisogna scegliere ciascuno nell'oscuro della propria cameretta se si vuol fare i banditi o i campioni.

    @emanuele-ricci ha detto in Check list operativa per la migrazione a GA4:

    Se seguiamo il vostro ragionamento che è corretto formalmente allora dovremmo smettere di usare FB, Google Ads, Insta e qualsiasi altra cosa abbia dati accessibili dagli USA....

    A tendere è esattamente così!

    Per quanto mi riguarda sto avendo una posizione molto pragmatica, ovvero:

    1. se devo migrare, migro a soluzioni legalmente blindate
    2. tutto ciò che è mission critical lo lascio
    3. comunque separo dove possibile i flussi (ovvero: per il remarketing e le conversioni uso i rispettivi tag e non collego Ads a GA)
    4. mi preparo con calma a soluzioni tecniche alternative (ad esempio, l'importazione delle conversioni tramite API lato server)

    Il problema è qui per restare, l'unica è navigare smontando con calma un pezzetto alla volta, quando serve e senza rompere nulla.


  • User

    @emanuele-ricci ha detto in Check list operativa per la migrazione a GA4:

    Se seguiamo il vostro ragionamento che è corretto formalmente allora dovremmo smettere di usare FB, Google Ads, Insta e qualsiasi altra cosa abbia dati accessibili dagli USA....

    ma infatti le cose starebbero così, questa è solo la prima risposta del garante ai famosi 101 reclami
    https://noyb.eu/en/eu-us-transfers-complaint-overview

    in futuro le cose andranno sempre peggio.

    la cosa bella è che il garante ha un canale youtube, quindi fa analitiche esportando i nostri dati in america. Se il problema non è l'ip ma l'enorme mole di dati incrociabile... si lasciano al lettore le considerazioni...


  • User

    @kal Sono sostanzialmente d'accordo. La maggior parte dei clienti fin'ora ha dato per scontato GA perchè veniva installato quasi per default gratis, giusto perchè da soli si sentivano soddisfatti di quei dati che potevano vedere.
    Nessun concetto di ROI, il dato per loro era solo numerico, quante visite e da dove e poco altro.
    Pochi i clienti che chiedevano aiuto e quindi pagavano la consulenza.

    Con GA4 ora solo i cliente diciamo un pò più "Evoluti" o direi meno "Utonti" hanno senso. Devono necessariamente pagare perchè gli prepariamo i report e perchè gli impostiamo un GA4 in maniera almeno decente.

    Quindi senza ombra di dubbio alla maggiorparte degli utenti meglio una soluzione più soft e gdpr compliance.
    Sto testando https://piwik.pro/ e credo che tra i tanti sia quello che possa andare bene per la maggior parte
    Ho sentito anche il loro supporto.

    1 cliente - 1 account - (gratis fino a 500k hit mese)

    matomo.org in cloud è solo a pagamento, onpremise ci sono i costri del server e i costi per mantenere in sicurezza il server. Un data breach su un server nostro onpremise sono cavoli ancora peggiori. Quindi a meno di non avere sistemisti con gli attributi lascerei perdere.

    Siti più strutturati, con dirigenza illuminata e pronti ad investire il giusto per i dati di analisi allora si può andare su GA4

    Opinione personale... ci mancherebbe


    C 1 Risposta
  • User

    @sabaxaba ha detto in Check list operativa per la migrazione a GA4:

    matomo.org in cloud è solo a pagamento, onpremise ci sono i costri del server e i costi per mantenere in sicurezza il server. Un data breach su un server nostro onpremise sono cavoli ancora peggiori. Quindi a meno di non avere sistemisti con gli attributi lascerei perdere.

    più che di onpremise parlerei di self-host (anche se sul sito scrivono on-premise ma è confusionario, in quanto con on-premise si intende un server fisico ma non è cosi)
    puoi installarti matomo anche su un tuo cloud in maniera completamente gratuita, managed o meno. Puoi anche comprarti un pacchetto di hosting dal tuo fornitore preferito (Aruba, Ovh, Serverplan, etc...) anche da 50 euro annui e installarlo, è un banalissimo installer php alla pari di quello di wordpress in quanto a facilità, assicurandoti in questo modo di gestire solo gli aggiornamenti di sicurezza di matomo.
    Certo, applicabile solo in caso di siti da poche visite, se gestisci magazine con migliaia di utenti contemporanei devi passare a soluzioni più performanti.


    S 1 Risposta
  • Contributor

    Giusto una nota su questo aspetto qua:

    @claudiosaitta ha detto in Check list operativa per la migrazione a GA4:

    Google Cloud non utilizza i dati dei clienti per la pubblicità
    Tutti i dati dei clienti sono criptati per impostazione predefinita

    Se usi Google Cloud per gestire un'istanza di GTM Server Side, entrambe queste cose sono tecnicamente ed irrimediabilmente false :rollo:


    C 1 Risposta
  • User

    @kal ha detto in Check list operativa per la migrazione a GA4:

    Giusto una nota su questo aspetto qua:

    @claudiosaitta ha detto in Check list operativa per la migrazione a GA4:

    Google Cloud non utilizza i dati dei clienti per la pubblicità
    Tutti i dati dei clienti sono criptati per impostazione predefinita

    Se usi Google Cloud per gestire un'istanza di GTM Server Side, entrambe queste cose sono tecnicamente ed irrimediabilmente false :rollo:

    no, non è google cloud a utilizzare dati dei clienti, bensì l'eventuale applicazione che ci installi sopra, e sono criptati finchè ovviamente non li trasmetti a Google Analytics, che ovviamente dovrai andare a "depurare" da qualsiasi dato personale che non devi trasferire.
    Lo stesso concetto altrimenti dovresti applicarlo all'onpremise presso un tuo server fisico in casa tua, dato che ad un certo punto ciò che trattieni su GTM SS lo trasferisci ad Analytics


  • Contributor

    @claudiosaitta ha detto in Check list operativa per la migrazione a GA4:

    e sono criptati finchè ovviamente non li trasmetti a Google Analytics

    Eh, no, mi spiace contraddirti... ma i dati delle hit vengono RICEVUTI criptati (via SSL), ma poi sono decodificati e successivamente elaborati in chiaro dalla macchina a te dedicata. Macchina che non è di tua proprietà... ma di proprietà di Google.

    Non può essere altrimenti, il dato deve essere decriptato per essere elaborato... a meno di costose (e lente) tecniche di criptazione omomorifica (che Google Cloud fra parentesi non offre).

    Da un punto di vista strettamente legale: usare GA4 lato client o usare Google Cloud (così come anche Stape) è esattamente la stessa cosa.

    Per questo ho dato sopra questa dicotomia forte:

    1. vuoi che sia "legale"? Usa server tuoi, da fornitore EU.
    2. non ti interessa che sia legale perché te ne sbatti delle conseguenze? Vai lato client.

    C 1 Risposta
  • User

    @kal non è una funzionalità intrinseca per far funzionare la virtualizzazione quello che dici tu, ma è qualcosa di fraudolento che devi inserire di proposito all'interno del sistema operativo guest per leggere un dato istantaneo nel momento dell'elaborazione.
    Difatti non è possibile leggere dai report delle VM la ram occupata perchè sarebbe un "andare a leggerla" quando non serve.
    Devi installare di proposito degli agent specifici per farlo all'interno della macchina guest.
    Nemmeno l'unione europea si è espressa in tal senso, per essere compliant è sufficiente criptare l'hard disk, che altrimenti potrebbe essere letto da chiunque anche a macchina spenta.
    Posso esasperare ancora di più la cosa, anche nel tuo sistema on premise dovremmo rendere illegale Microsoft Windows Server perchè non sappiamo cosa fa Microsoft con i dati, anzi dovresti usare solo sistemi operativi open source compilati a mano (sia mai che il pacchetto deb sia stato modificato da qualcuno), e ricompilare a mano ad ogni aggiornamento, e ovviamente prima di compilarlo devi leggerti i diff dal sorgente precedente perchè non si sa mai.

    edit: cosi al volo ho trovato la documentazione per ec2, ma il principio è identico per compute engine, senza agent installato di proposito sul guest, l'host non legge il contenuto della ram
    https://aws.amazon.com/it/premiumsupport/knowledge-center/cloudwatch-memory-metrics-ec2/


  • User

    @claudiosaitta a che pro andaru su matomo onpremise o self hosted come dici tu se piwik offre gratis fino a500k di hit mese? sostianzialmente mi sembra di aver capito che è un fork. quindi più o meno siamo li come funzionalità (lo dico con leggerezza perchè devo ancora approfondire la cosa)
    .


    C kal 2 Risposte
  • User

    @sabaxaba ad esempio nel caso tu gestisca una 50ina di siti a basso traffico, dato che il piano core di piwik prevede massimo 10 siti web.

    come ogni cosa non c'è mai la soluzione giusta per tutti, ma quella per le proprie esigenze.

    ps: io ad esempio sto valutando come degraderanno le prestazioni al crescere della dimensione del db mysql, attualmente per test sono a 300 mb, voglio ancora vedere come andrà una volta superati i 2-3 gb.


    S 1 Risposta
  • User

    @claudiosaitta Ni..
    Ho sentito il loro supporto appositamente.

    Al fine di rendere agevole enventuali spostamenti loro stessi consigliano di creare 1 account x ogni cliente

    Quindi credo che il 99% dei clienti non supererà i 10 siti web


  • User

    usa piwik pro allora 🙂
    io sto usando matomo solo a fini di test, spero fortemente che si raggiunga al più presto un nuovo accordo usa-eu e continuare a usare "tranquillamente" GA4


    S 1 Risposta
  • User

    @claudiosaitta Non sto tirando l'acqua a nessun mulino.. anch'io sto semplicemente testando e volevo sentire le opinioni di altri. Ma su questo thread stiamo davvero andando fuori tema. 🙂 meglio spostare discussione altrove


  • Contributor

    @claudiosaitta ha detto in Check list operativa per la migrazione a GA4:

    per far funzionare la virtualizzazione quello che dici tu, ma è qualcosa di fraudolento che devi inserire di proposito all'interno del sistema operativo guest per leggere un dato istantaneo nel momento dell'elaborazione.

    Capito... questa cosa può configurarsi come le già citate "additional safeguards"?

    Per un agente statale, ammettendo che il quadro legale glielo permetta, quanto è possibile (una volta ottenuto l'accesso all'infrastruttura cloud) andare ad installare gli agent sulle macchine virtuali?

    Perché non c'è bisogno di inserire questa eventualità nelle clausole contrattuali... se è prevista dalla legge.

    Ed il problema NASCE dalla legge.

    @sabaxaba ha detto in Check list operativa per la migrazione a GA4:

    sostianzialmente mi sembra di aver capito che è un fork

    Ni.

    Piwik Pro è un SaaS fatto e finito... la cui codebase è basata su un fork di Matomo. Ma ha un modello di business tutto suo (sostanzialmente "freemium") e diverso da Matomo stessa che ha invece un modello ibrido "free + plugin a pagamento" per la versione selfhosted, con "cloud a pagamento" in alternativa.


    C 1 Risposta
  • User

    @kal ha detto in Check list operativa per la migrazione a GA4:

    @claudiosaitta ha detto in Check list operativa per la migrazione a GA4:

    per far funzionare la virtualizzazione quello che dici tu, ma è qualcosa di fraudolento che devi inserire di proposito all'interno del sistema operativo guest per leggere un dato istantaneo nel momento dell'elaborazione.

    Capito... questa cosa può configurarsi come le già citate "additional safeguards"?

    Per un agente statale, ammettendo che il quadro legale glielo permetta, quanto è possibile (una volta ottenuto l'accesso all'infrastruttura cloud) andare ad installare gli agent sulle macchine virtuali?

    Loro dicono chiaramente che non esiste alcun tipo di backdoor, è una cosa contrattualizzata e regolata dalle più stringenti normative e certificazioni ISO.
    Gli agent vanno installati dal sistema operativo guest come fossero normali programmi; quindi se decido di criptare il disco integralmente per conto mio, direi che è impossibile;
    poi magari se ci affidiamo ai sistemi di crittografia gestiti da parte loro (di default su qualsiasi block storage direi, magari è fattibile, non saprei, anche se bisognerebbe installare un eseguibile dentro un hard disk semplicemente copiandoci dentro un file e configurandomi a sgamo un qualche file .ini del mio systemd, il tutto mentre ho il mio sistema acceso ovviamente ma se fosse cosi semplice e cosi "di prassi" qualunque sistemista degno di questo nome se ne sarebbe accorto.
    Ma a quel punto se ci sono motivi legali, non c'è nemmeno bisogno di farlo di nascosto installandoti l'agent, accedo ai tuoi dati e mi vanto anche alla luce del sole di averlo fatto. E io agente statale, a quel punto, o contatto google per farmi accedere ai tuoi dati o contatto te direttamente venendoti a trovare a casa cambia poco, devi darmi accesso alla macchina, punto.

    parere personale: finchè Google (o altro provider) dichiara, quantomeno nei propri servizi IaaS, (non voglio esprimermi per un SaaS), che non ci sono backdoor per l'accesso da parte dei governi, io penso di essere compliant a qualunque legislazione vigente in fatto di protezione dei dati personali, e di sicuro è una soluzione migliore di gestirmi le chiavi in casa, che se me le perdo (in quanto anche un azienda media non ha risorse per permettersi esperti e matematici in grado di gestire la sicurezza enterprise anche della semplice rotazione chiavi) è anche peggio, in quanto violo comunque la GDPR in quanto sono stato in grado di aver unico accesso, ma non sono stato in grado di preservarli i dati. E se scelgo di non criptarli anche peggio, in quanto di sicuro non ho le risorse per creare una struttura controllata giorno e notte da guardie armate a protezione del mio server farm.

    Chiudo dicendo: no, cloud is not just someone else computer.


    kal 1 Risposta
  • Contributor

    @claudiosaitta ha detto in Check list operativa per la migrazione a GA4:

    E io agente statale, a quel punto, o contatto google per farmi accedere ai tuoi dati

    Il punto della questione che ha causato tutto il casino normativo è proprio questo. In USA lo Stato può fare questa cosa qua, senza passare dal giudice.

    Se è tecnicamente possibile, allora sei in violazione della GDPR.

    Le "additional safeguards" sono proprio questo: misure tecniche che rendono molto difficile accedere al dato da parte di un attore statale autorizzato.

    Probabilmente una cosa del genere potrebbe andare:

    @claudiosaitta ha detto in Check list operativa per la migrazione a GA4:

    Gli agent vanno installati dal sistema operativo guest come fossero normali programmi; quindi se decido di criptare il disco integralmente per conto mio, direi che è impossibile;

    Anche se io avevo capito che non fosse realmente possibile... perché strumenti come GTM Server Side comunque devono elaborare il dato per gestire le hit. Ed il dato viene elaborato sempre in forma non criptata.

    Sbaglio?


    C 1 Risposta
  • User

    @kal ha detto in Check list operativa per la migrazione a GA4:

    @claudiosaitta ha detto in Check list operativa per la migrazione a GA4:

    E io agente statale, a quel punto, o contatto google per farmi accedere ai tuoi dati

    Il punto della questione che ha causato tutto il casino normativo è proprio questo. In USA lo Stato può fare questa cosa qua, senza passare dal giudice.

    Se è tecnicamente possibile, allora sei in violazione della GDPR.

    Le "additional safeguards" sono proprio questo: misure tecniche che rendono molto difficile accedere al dato da parte di un attore statale autorizzato.

    Probabilmente una cosa del genere potrebbe andare:

    Le SCC di Google e di AWS vanno ben oltre quanto dichiarato sufficiente dall'europa

    https://cloud.google.com/terms/sccs

    https://aws.amazon.com/it/blogs/security/new-standard-contractual-clauses-now-part-of-the-aws-gdpr-data-processing-addendum-for-customers/

    EDIT: ad esempio qui si specifica che non è proprio esatto che il governo arriva, entra e prende quel che vuole
    EDIT2, sorry avevo sbagliato link

    @claudiosaitta ha detto in Check list operativa per la migrazione a GA4:

    Gli agent vanno installati dal sistema operativo guest come fossero normali programmi; quindi se decido di criptare il disco integralmente per conto mio, direi che è impossibile;

    Anche se io avevo capito che non fosse realmente possibile... perché strumenti come GTM Server Side comunque devono elaborare il dato per gestire le hit. Ed il dato viene elaborato sempre in forma non criptata.

    Sbaglio?

    sinceramente non ho capito cosa intendi


    kal 1 Risposta
  • Contributor

    @claudiosaitta ha detto in Check list operativa per la migrazione a GA4:

    Le SCC di Google e di AWS vanno ben oltre quanto dichiarato sufficiente dall'europa

    Non è mai stato un problema di SCC (che infatti rimangono valide), ma di implementare o meno azioni tecniche effettive che prevengano o rendano eccessivamente costoso l'accesso statale alle informazioni.

    Non so Amazon, ma in nessun caso Google ha messo in campo le richieste "additional safeguards".

    Questa la situazione attuale.

    @claudiosaitta ha detto in Check list operativa per la migrazione a GA4:

    ad esempio qui si specifica che non è proprio esatto che il governo arriva, entra e prende quel che vuole

    Sì, lo so che in realtà è tutto più complicato... la cosa dell'accesso statale io la narro in quel modo perché sia chiaro a tutti quale è la situazione.

    @claudiosaitta ha detto in Check list operativa per la migrazione a GA4:

    sinceramente non ho capito cosa intendi

    Purtroppo temo che sia dovuto alla mia limitata comprensione degli aspetti tecnici della criptazione applicata ai sistemi cloud. Tu sopra hai fatto riferimento al fatto che si possa criptare il disco. Ma se il sistema gira, per eseguire tutti i processi il dato viene prima decriptato.

    Altrimenti nulla può girare, giusto?

    Cioè, è criptato solo se un agente esterno accede al disco "fisicamente"... ma dall'interno della macchina rimane tutto leggibile.

    Nella mia pur limitata comprensione della cosa, questo lascia il problema aperto... perché se gira in chiaro allora in qualche modo può essere letto (come hai detto tu, tramite l'inserimento di un agente nella VM).

    I fornitori cloud dichiarano che non ci sono backdoor... e fin qui ci sto da un punto di vista di contrattualistica a livello privatistico. Ma qui stiamo parlando di riconoscimento di diritti fondamentali e di legislazioni concorrenti.

    Le autorità Garanti hanno detto chiaramente che sulla questione non è ammissibile nessun "approccio basato sul rischio", come dire: diamo per scontato che se lo Stato USA può chiedere legalmente l'accesso, virtualmente è come se l'avesse già fatto.

    Per quanto assurda sia la situazione, siamo a sto punto.

    (questo a meno che io non abbia preso una grossa cantonata... ma non direi leggendo in giro gli esperti dell'ambiente legal/privacy sono tutti abbastanza concordi sulla questione)


    C 1 Risposta