We’ll admit it. We have access to great debugging tools and, yes, sometimes they are invaluable. But most of the time, we’ll just throw a few print statements in whatever program we’re running to better understand what’s going on inside of it. [Loop Invariant] wants to point out to us that there are things a proper debugger can do that you can’t do with print statements.

So what are these magical things? Well, some of them depend on the debugger, of course. But, in general, debuggers will catch exceptions when they occur. That can be a big help, especially if you have a lot of them and don’t want to write print statements on every one. Semi-related is the fact that when a debugger stops for an exception or even a breakpoint, you can walk the call stack to see the flow of code before you got there.

In fact, some debuggers can back step, although not all of them do that. Another advantage is that you can evaluate expressions on the fly. Even better, you should be able to alter program flow, jumping over some code, for example.

So we get it. There is more to debugging than just crude print statements. Then again, there are plenty of Python libraries to make debug printing nicer (including IceCream). Or write your own debugger. If gdb’s user interface puts you off, there are alternatives.

hackaday.com/2025/09/11/debugg…

Milioni di persone e aziende si affidano a Google Drive per archiviare contratti, report, foto e documenti di lavoro, utilizzando il client desktop di Windows per sincronizzare i file tra cartelle locali e cloud. Ma è stata proprio questa applicazione a rivelarsi vulnerabile: è stato scoperto un grave bug che consente a chiunque, su un computer condiviso, di ottenere l’accesso completo ai contenuti dell’account Google Drive di qualcun altro senza dover richiedere una nuova autorizzazione.

I ricercatori hanno scoperto che il programma salva copie dei dati sincronizzati in una cartella DriveFS nascosta all’interno del profilo di Windows. Questa directory dovrebbe essere accessibile solo al proprietario, ma l’applicazione non verifica i diritti di accesso quando si connette alla cache. È sufficiente copiare il contenuto della cartella DriveFS di un altro utente sul proprio profilo, dopodiché il client caricherà i dati di qualcun altro come se fossero propri. All’avvio, Google Drive Desktop percepisce la cache trasferita come legittima, aggirando i controlli di autenticazione e consentendo l’accesso ai file personali e aziendali.

Un test pratico ha dimostrato che su Windows 10 e 11 con versione client 112.0.3.0 la procedura è elementare: l’aggressore accede a Google Drive con il proprio account, chiude l’applicazione, copia la directory DriveFS della vittima (C:/Users/[vittima]/AppData/Local/Google/DriveFS/[ID]) nella propria directory (C:/Users/[attaccante]/AppData/Local/Google/DriveFS/[ID]) e riavvia il programma. Di conseguenza, ottiene pieno accesso all’unità principale della vittima, nonché a tutte le unità condivise, senza password o notifiche.

Codici sorgente, bilanci finanziari, foto personali e qualsiasi altro documento sono in formato aperto.

Questo meccanismo viola i principi fondamentali di Zero Trust, che richiedono la verifica obbligatoria dell’identità a ogni accesso, e compromette anche la protezione associata alla crittografia dei dati. I file nella cache vengono archiviati in chiaro e possono essere utilizzati da chiunque abbia accesso al sistema. Ciò è in contrasto con gli standard e le normative NIST, ISO 27001, GDPR e HIPAA, che prevedono un rigoroso isolamento e una verifica periodica delle credenziali.

Fino al rilascio di una correzione, si consiglia alle organizzazioni di interrompere l’utilizzo di Google Drive Desktop su computer con più utenti. Le misure temporanee includono la cancellazione della cache quando si cambia account, l’utilizzo di profili Windows separati con diritti di accesso rigorosi e la limitazione dell’esecuzione del client solo su dispositivi attendibili. Per risolvere definitivamente il problema, Google dovrebbe implementare la crittografia individuale dei dati memorizzati nella cache, un nuovo accesso obbligatorio quando si monta una cartella e autorizzazioni rigorose a livello di file system.

Dato che una percentuale significativa di perdite è causata da personale interno, affidarsi a una cache non protetta diventa una minaccia diretta. Finché l’azienda non colma questa lacuna, utenti e reparti IT corrono il rischio di accesso non autorizzato ai dati più critici .

L'articolo Un bug in Google Drive consente l’accesso ai file di altre persone su desktop condivisi proviene da il blog della sicurezza informatica.

Nella giornata di ieri, su un noto forum underground frequentato da cyber criminali, è apparso un post che riguarda direttamente il Comune di Canegrate (Milano, Italia).

L’annuncio è stato pubblicato da un utente con nickname “krek1i”, attivo dal mese di aprile 2025 e con una reputazione di 81 punti, indice di una certa affidabilità all’interno della community underground. Lo stesso utente vanta decine di post e thread aperti, fattori che lo rendono un profilo consolidato nell’ambiente.

Disclaimer: Questo rapporto include screenshot e/o testo tratti da fonti pubblicamente accessibili. Le informazioni fornite hanno esclusivamente finalità di intelligence sulle minacce e di sensibilizzazione sui rischi di cybersecurity. Red Hot Cyber condanna qualsiasi accesso non autorizzato, diffusione impropria o utilizzo illecito di tali dati. Al momento, non è possibile verificare in modo indipendente l’autenticità delle informazioni riportate, poiché l’organizzazione coinvolta non ha ancora rilasciato un comunicato ufficiale sul proprio sito web. Di conseguenza, questo articolo deve essere considerato esclusivamente a scopo informativo e di intelligence.

Nel messaggio, il criminale informatico sostiene di essere in possesso di un database e degli accessi ai sistemi del Comune di Canegrate, offrendo il tutto in vendita per la cifra di 500 dollari.

A corredo dell’annuncio sono stati pubblicati alcuni sample per dimostrare l’autenticità del materiale. Dall’analisi di tali sample emergono i seguenti elementi potenzialmente sensibili:

• dati personali di cittadini e utenti;
• account e password associati ai sistemi compromessi;
• schemi di database con numerose tabelle, a conferma di un’ampia quantità di informazioni potenzialmente esfiltrate.

Al momento, sul sito ufficiale del Comune di Canegrate non sono presenti comunicazioni in merito alla presunta violazione. Non si hanno quindi conferme ufficiali su quanto dichiarato dal criminale informatico.

Se confermata, la compromissione rappresenterebbe un grave incidente di sicurezza informatica ai danni di un ente pubblico locale, con possibili ripercussioni sulla protezione dei dati personali dei cittadini.

Come nostra consuetudine, lasciamo sempre spazio ad una dichiarazione dell’organizzazione qualora voglia darci degli aggiornamenti su questa vicenda e saremo lieti di pubblicarla con uno specifico articolo dando risalto alla questione.

RHC monitorerà l’evoluzione della vicenda in modo da pubblicare ulteriori news sul blog, qualora ci fossero novità sostanziali. Qualora ci siano persone informate sui fatti che volessero fornire informazioni in modo anonimo possono accedere utilizzare la mail crittografata del whistleblower.

L'articolo Comune di Canegrate: presunta violazione e vendita di database e accessi proviene da il blog della sicurezza informatica.

Attaullah Baig, che avrebbe guidato il team di sicurezza di WhatsApp dal 2021 al 2025, ha intentato una causa contro la società madre Meta. Baig sostiene di essere stato licenziato per aver ripetutamente tentato di risolvere i gravi problemi di sicurezza informatica dell’app di messaggistica.

Baig ha intentato una causa ai sensi del Sarbanes-Oxley Act per aver presumibilmente occultato problemi di sicurezza che avrebbero potuto portare a potenziali frodi da parte degli azionisti, nonché potenziali violazioni delle norme della Securities and Exchange Commission (SEC) degli Stati Uniti in materia di controlli interni delle informazioni.

Nella causa, l’ex dipendente di WhatsApp (che in precedenza aveva ricoperto posizioni legate alla sicurezza informatica presso PayPal e Capital One) sostiene che la dirigenza di WhatsApp lo ha ingiustamente licenziato, travisando la sua valutazione delle prestazioni e usandola come pretesto per rescindere il suo contratto.

I documenti affermano che poco dopo essersi unito a WhatsApp nel 2021, Baig “ha scoperto problemi sistemici di sicurezza informatica che creavano gravi rischi per i dati degli utenti e violavano gli obblighi legali di Meta ai sensi della Risoluzione sulla privacy del 2020 e delle leggi federali sui titoli”.

Baig sostiene che circa 1.500 ingegneri di WhatsApp avevano accesso illimitato ai dati personali sensibili degli utenti e sono stati in grado di copiarli e rubarli senza essere scoperti o sottoposti a controlli.

L’8 settembre 2022, Baig avrebbe sollevato le seguenti violazioni durante una riunione di lavoro:

• impossibilità di inventariare i dati degli utenti;
• incapacità di localizzare ed elencare i repository di dati;
• accesso illimitato ai dati degli utenti, a disposizione di 1.500 ingegneri informatici;
• mancanza di controllo sull’accesso ai dati degli utenti;
• incapacità di rilevare perdite di dati;
• incapacità di proteggere gli account utente da eventuali furti (si stima che si verifichino circa 100.000 casi di questo tipo al giorno).

Nell’ottobre 2022, Baig avrebbe informato dieci dirigenti senior di WhatsApp, tra cui l’amministratore delegato Will Cathcart e l’ingegnere capo Nitin Gupta, dei problemi, avvertendo che l’azienda avrebbe potuto affrontare conseguenze legali.

Baig afferma di aver tentato di sollevare le sue preoccupazioni nel 2023, ma di aver incontrato la resistenza dei dirigenti. Poi, all’inizio del 2024, avrebbe inviato una lettera al CEO di Meta Mark Zuckerberg e al consulente legale Jennifer Newstead, informandoli delle potenziali violazioni, delle resistenze che stavano affrontando e delle “prove che il team di sicurezza stava falsificando i report per nascondere le proprie decisioni e non affrontare i rischi di furto di dati”.

Nel febbraio 2025, Baig venne licenziato dall’azienda, presumibilmente diversi mesi dopo aver personalmente segnalato alla Securities and Exchange Commission degli Stati Uniti presunte violazioni della sicurezza informatica presso Meta.

Ora Baig chiede un processo con giuria e vuole che Meta lo reintegrasse, oltre a rimborsargli gli stipendi arretrati, le spese legali, i danni emotivi e le sofferenze. Tuttavia, Meta ha dichiarato ai media che Baig non ricopriva affatto il ruolo di “responsabile della sicurezza” di WhatsApp, ma piuttosto quello di responsabile dello sviluppo software, con diversi dirigenti senior al di sopra di lui. Secondo l’azienda, diversi ingegneri senior hanno stabilito in modo indipendente che le sue prestazioni non soddisfacevano le aspettative dell’azienda, il che ha portato al suo licenziamento.

“Purtroppo, è uno scenario familiare quello in cui un dipendente viene licenziato per scarse prestazioni e poi rilascia dichiarazioni distorte che sminuiscono l’essenza del duro lavoro del nostro team”, ha affermato Andy Stone, direttore delle comunicazioni di Meta.

Inoltre, secondo i documenti forniti dall’azienda a SecurityWeek, il Dipartimento del Lavoro degli Stati Uniti aveva precedentemente respinto il reclamo di Baig. L’OSHA ha concluso che Meta non aveva attuato ritorsioni nei confronti di un dipendente che aveva cercato di sollevare problemi di sicurezza. I documenti mostrano inoltre che il Dipartimento del Lavoro ha stabilito che le azioni di Baig non erano giustificate ai sensi del Sarbanes-Oxley Act.

L'articolo Ex dipendente di WhatsApp: “1500 ingegneri hanno accesso ai dati riservati degli utenti” proviene da il blog della sicurezza informatica.

Every Thursday of the week, Bastian’s Night is broadcast from 21:30 CEST (new time).

Bastian’s Night is a live talk show in German with lots of music, a weekly round-up of news from around the world, and a glimpse into the host’s crazy week in the pirate movement.

If you want to read more about @BastianBB: –> This way

piratesonair.net/bastians-nigh…

Does the in 65F02 “F” stand for “fast” or “FPGA”? [Jurgen] doesn’t know, but his drop-in replacement board for the 6502 and 65c02 is out there and open source, whatever you want it to stand for.

The “f” could easily be both, since at 100 MHz, the 65f02 is blazing fast by 6502 standards–literally 100 times the speed of the first chips from MOS. That speed comes from the use of a Spartan 6 FPGA core to implement the 6502 logic; making the “f” stand for “FPGA” makes sense, given that the CMOS version of the chip was dubbed the 65c02. The 65f02 is a tiny PCB containing the FPGA and all associated hardware that shares the footprint of a DIP-40 package, making it a drop-in replacement. A really fast drop-in replacement.

You might be thinking that that’s insane, and that (for example) the memory on an Apple ][ could never run at 100 MHz and so you won’t get the gains. This is both true, and accounted for: the 65F02 has an internal RAM “cache” that it mirrors to external memory at a rate the bus can handle. When memory addresses known to interact with peripherals change, the 65f02 slows down to match for “real time” operations.
The USB adapter board for programming is a great touch.
Because of this the memory map of the external machine matters; [Jurgen] has tested the Commodore PET and Apple ][, along with a plethora of German chess computers, but, alas, this chip is not currently compatible with the Commodore 64, Atari 400/800 or BBC Micro (or at least not tested). The project is open source, however, so you might be able to help [Jurgen] change that.

We admit this project isn’t totally new– indeed, it looks like [Jurgen]’s last update was in 2024– but a fast 6502 is just as obsolete today as it was when [Jurgen] started work in 2020. That’s why when [Stephen Walters] sent us the tip (via electronics-lab), we just had to cover it, especially considering the 6502’s golden jubilee.

We also recently featured a 32-bit version of the venerable chip that may be of interest, also on FPGA.

hackaday.com/2025/09/10/65f02-…

E’ stato analizzato che gli inviti del Calendario iCloud sono stati utilizzati per inviare email di phishing camuffate da notifiche di acquisto direttamente dai server di posta di Apple. Questa tattica aumenta le probabilità di bypassare i filtri antispam.

Bleeping Computer ha segnalato che all’inizio di questo mese un lettore ha condiviso un’e-mail dannosa che si spacciava per una ricevuta di 599 dollari, presumibilmente addebitata sul suo conto PayPal. L’e-mail includeva un numero di telefono nel caso in cui il destinatario volesse contrassegnare il pagamento o apportare modifiche.

Lo scopo di queste email è indurre gli utenti a credere che il loro account PayPal sia stato hackerato e che il denaro venga utilizzato da truffatori per effettuare acquisti. I truffatori cercano di spaventare il destinatario dell’email in modo che venga chiamato il falso numero di “assistenza”.

Durante la chiamata, i truffatori continuano a intimidire le vittime, convincendole che l’account è stato effettivamente violato. Gli aggressori si offrono quindi di connettersi da remoto al computer della vittima (presumibilmente per restituire i fondi) o chiedono di scaricare ed eseguire un software. Naturalmente, gli aggressori alla fine utilizzano l’accesso remoto ottenuto per rubare denaro dai conti bancari dell’utente, distribuire malware o rubare dati dal computer compromesso.

Tuttavia, la cosa strana in questo caso era che l’email fraudolenta proveniva da noreply@email.apple.com, superando tutti i controlli di sicurezza SPF, DMARC e DKIM. In altre parole, il messaggio proveniva effettivamente dal server di posta di Apple.

I giornalisti spiegano che l’email era in realtà un invito al Calendario iCloud. Gli aggressori hanno semplicemente aggiunto del testo di phishing al campo Note e poi hanno inviato l’invito a un indirizzo Microsoft 365 da loro controllato. Quando si crea un evento nel Calendario iCloud e si invitano persone esterne, un’email di invito viene inviata dai server Apple a (email.apple.com) per conto del proprietario del Calendario iCloud. Questa email proviene da noreply@email.apple.com.

I ricercatori ritengono che questa campagna sia simile a un’altra truffa scoperta nella primavera del 2025. Questo perché in entrambi i casi l’indirizzo Microsoft 365 a cui viene inviato l’invito è in realtà una mail che inoltra automaticamente tutte le email ricevute a tutti gli altri membri del gruppo.

Poiché l’e-mail dannosa proveniva originariamente dai server di posta di Apple, non avrebbe superato i controlli SPF se inoltrata a Microsoft 365. Per evitare che ciò accada, Microsoft 365 utilizza lo schema di riscrittura del mittente (SRS) per riscrivere il percorso di ritorno a un indirizzo correlato a Microsoft, consentendo al messaggio di superare i controlli.

Sebbene l’e-mail di phishing in sé non fosse nulla di speciale, l’abuso della legittima funzionalità di invito del Calendario iCloud e dei server di posta elettronica di Apple aiuta gli aggressori a eludere i filtri antispam perché le e-mail sembrano provenire da una fonte attendibile.

L'articolo Truffa phishing via Calendario iCloud: come funziona e come difendersi proviene da il blog della sicurezza informatica.

Due vulnerabilità significative nell’elevazione dei privilegi, che riguardano la crittografia BitLocker di Windows, sono state risolte da Microsoft. Il livello di gravità di queste falle, identificate come CVE-2025-54911 e CVE-2025-54912 è stato definito elevato. La divulgazione di tali vulnerabilità è avvenuta il 9 settembre 2025.

Entrambi i bug CVE-2025-54911 che CVE-2025-54912 sono classificate come vulnerabilità “ Use-After-Free “, un tipo comune e pericoloso di bug di danneggiamento della memoria. Questa debolezza, catalogata in CWE-416, si verifica quando un programma continua a utilizzare un puntatore a una posizione di memoria dopo che tale memoria è stata liberata o deallocata.

La scoperta del CVE-2025-54912 è stata attribuita a Hussein Alrubaye, in collaborazione con Microsoft, a dimostrazione di uno sforzo collaborativo tra l’azienda e ricercatori di sicurezza esterni per identificare e risolvere problemi di sicurezza critici.

Le vulnerabilità potrebbero permettere a un attaccante con autorizzazione di acquisire i privilegi SYSTEM completi su un computer, superando i protocolli di sicurezza che BitLocker è concepito per far rispettare.

In questo scenario, un malintenzionato potrebbe sfruttare questi bug per eseguire codice arbitrario, portando alla completa compromissione del sistema. La presenza di due distinti bug in BitLocker evidenzia le sfide in corso nel mantenimento della sicurezza della memoria nei software complessi.

Microsoft ha sottolineato che lo sfruttamento è considerato “meno probabile” e, al momento della divulgazione, le vulnerabilità non sono state descritte pubblicamente né sono state viste sfruttate in attacchi specifici.

Secondo le metriche CVSS fornite da Microsoft, un attacco richiede che l’avversario disponga di privilegi sul sistema di destinazione. Inoltre, affinché l’exploit abbia successo, è necessaria una qualche forma di interazione da parte dell’utente, il che significa che un aggressore dovrebbe indurre un utente autorizzato a eseguire un’azione specifica.

In risposta alla scoperta, Microsoft ha corretto le vulnerabilità nell’aggiornamento Patch Tuesday di settembre 2025. L’azienda ha esortato utenti e amministratori ad applicare tempestivamente gli ultimi aggiornamenti per proteggere i propri sistemi da potenziali attacchi.

L'articolo Vulnerabilità critiche in BitLocker: Microsoft risolve 2 falle di sicurezza proviene da il blog della sicurezza informatica.

All’interno della relazione presentata da parte dell’Autorità Garante per la protezione dei dati personali con riferimento all’attività svolta nel 2024, un capitolo è dedicato ai data breach. Saltano all’occhio il numero di notifiche e la particolare frequenza delle violazioni di riservatezza e disponibilità. Non solo: nel 66,6 % dei casi (quindi: 2 su 3), è avvenuta una notifica per fasi con una notifica preliminare e successive notifiche integrative.
Fonte: relazione 2024 Garante Privacy.
Doverosa considerazione di metodo: il rapporto riguarda i settori che hanno notificato o per cui sono stati rilevati data breach da parte dell’autorità di controllo. Questo impone pertanto di fare attenzione a non incappare nel pregiudizio di sopravvivenza facendo l’errore di ritenere che riguardi tutti i soggetti che hanno subito un data breach. Ad ogni modo è un campione comunque rappresentativo, quanto meno dei soggetti che hanno inteso notificare l’evento di violazione dei dati personali. Che comprende anche quanti, spinti da moventi decisamente meno virtuosi, si sono trovati costretti a non poterli più nascondere.

Ad ogni modo, i settori più colpiti in ambito pubblico sono stati comuni, strutture sanitarie e istituti scolastici. Mentre nel settore privato sono state principalmente le grandi telco, energetiche, bancarie e dei servizi, nonché PMI e professionisti. Questo dato può confermare dunque che nessuno può dirsi esente dall’essere oggetto di attenzioni da parte dei cybercriminali.

Gli attacchi ransomware rimangono i grandi protagonisti della scena, con compromissione di disponibilità e riservatezza dei dati per effetto della doppia estorsione. Sono state riportate come maggiormente significative le violazioni dolose causate da accessi non autorizzati o illeciti a sistemi informativi e compromissione di credenziali. Le divulgazioni accidentali sono invece riconducibili per lo più da errori di configurazione o errori nell’impiego di piattaforme informatiche o sistemi di gestione della posta elettronica.

Comuni denominatori delle istruttorie in caso di data breach.

L’apertura di un’istruttoria in seguito alla ricezione di una notifica di violazione non può essere ridotta ad un “atto dovuto” da parte del Garante di natura meramente burocratica. Piuttosto, è condotta allo scopo di verificare se c’è un’adeguata protezione degli interessati, sia nelle misure adottate o che il titolare altrimenti intende adottare per porre rimedio alla violazione ed attenuare gli effetti negativi nei confronti degli interessati, sia nell’analisi dei rischi svolta.

Bisogna infatti ricordare che queste misure sono prescritte come contenuto essenziale della notifica dall’art. 33 par. 3 GDPR:

La notifica di cui al paragrafo 1 deve almeno:
a) descrivere la natura della violazione dei dati personali compresi, ove possibile, le categorie e il numero approssimativo di interessati in questione nonché le categorie e il numero approssimativo di registrazioni dei dati personali in questione;
b) comunicare il nome e i dati di contatto del responsabile della protezione dei dati o di altro punto di contatto presso cui ottenere più informazioni;
c) descrivere le probabili conseguenze della violazione dei dati personali;
d) descrivere le misure adottate o di cui si propone l’adozione da parte del titolare del trattamento per porre rimedio alla violazione dei dati personali e anche, se del caso, per attenuarne i possibili effetti negativi.

L’esito dell’attività istruttoria è dunque innanzitutto quello di constatare se queste misure sono adeguate, fornendo i correttivi del caso, nonché quello di verificare se il titolare del trattamento sia stato in grado di analizzare compiutamente i rischi. Assumendo, anche con attività ispettive e acquisizioni documentali, tutti gli elementi necessari per valutare tanto i rischi quanto l’adeguatezza delle misure adottate ed esercitare i provvedimenti correttivi del caso. Fra cui, nelle ipotesi di rischi elevati, quello di ingiungere la comunicazione agli interessati coinvolti e fornire le indicazioni specifiche per proteggersi da eventuali conseguenze pregiudizievoli.

In particolare, all’interno del settore sanitario i provvedimenti sanzionatori derivanti da data breach per inadeguatezza delle misure di sicurezza predisposte sono stati talmente significativi da essersi meritati un capo dedicato all’interno della relazione (par. 5.4.1.), con la ricognizione di alcuni casi particolarmente significativi ed esemplari.

Alcuni dubbi sugli obblighi collegati al data breach (che però il Garante non può risolvere).

La relazione conferma alcuni dubbi sugli obblighi di gestione del data breach. Dubbi che richiederebbero un intervento da parte del legislatore in nome di una semplificazione ben più efficace di quella annunciata da Bruxelles e dalle tinte blu ridicolo cui siamo purtroppo abituati. Mettiamo i primi tre sul podio.

Il termine di gestione del data breach di 72 ore serve davvero a qualcosa?

Piuttosto, sembra che i migliori intenti della norma non superino il reality check. Nella realtà è un onere burocratico, svolto per lo più (in 2 casi su 3 da relazione del Garante) con un: compiliamo subito ora, integriamo poi. Con buona pace degli interessati che invece spesse volte dovranno attendere l’intervento del Garante successivo (e ben oltre le 72 ore) per leggere una comunicazione di data breach non sempre chiara, talvolta ridotta a un formalismo, e spesso inefficace per una serie di ragioni legate al fattore tempo. Ne è infatti trascorso abbastanza perchè i più attenti abbiano già appreso l’evento dai media e i più disattenti ne abbiano subito gli effetti negativi. Top timing!

Ben diversa natura ha invece la notifica degli incidenti informatici ad ACN (e che riguarda soggetti PSNC e NIS 2), che va oltre la tutela degli interessati ma segue scopi di sicurezza nazionale, per cui invece la tempestività è d’obbligo.

Non sarebbe meglio prescrivere 72 ore per comunicare agli interessati?

Forse il termine di 72 ore è maggiormente adeguato per la comunicazione agli interessati, senza lasciare quella formula “senza ingiustificato ritardo” che invece comporta continui ritardi o comunicazioni sgangherate. Questo sì che gioverebbe agli interessati consentendo loro di essere consapevoli dell’accaduto adottare tempestivamente misure a loro protezione.

Inoltre, enfatizzerebbe quell’approccio di responsabilizzazione previsto dal GDPR: rendicontare la gestione dell’incidente, dunque dare priorità alle garanzie a tutela degli interessati.

Magari gioverebbe anche una maggiore attenzione da parte del Garante e conseguenti sanzioni per comunicazioni inadeguate. Just to say. Speriamo di trovare un capo dedicato nelle prossime relazioni di attività.

Perchè parlare di rischio improbabile?

Questa è una perla. Semantica e concettuale. Quel concetto di improbabilità riferito al rischio porta con sé il retrogusto dell’ineffabile.

L’art. 33 par. 1 GDPR prevede infatti che:

In caso di violazione dei dati personali, il titolare del trattamento notifica la violazione all’autorità di controllo competente a norma dell’articolo 55 senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne è venuto a conoscenza, a meno che sia improbabile che la violazione dei dati personali presenti un rischio per i diritti e le libertà delle persone fisiche. Qualora la notifica all’autorità di controllo non sia effettuata entro 72 ore, è corredata dei motivi del ritardo.

Certo, il considerando n. 85 propone che stia al titolare comprovare il fatto che” è improbabile che la violazione dei dati personali presenti un rischio per i diritti e le libertà delle persone fisiche”. In nome dell’accountability, che viene spesso citata quando non si sa come spiegare le cose.

Ma dal momento che anche l’EDPB fatica a fornire indicazioni e criteri di carattere generale, profondendosi piuttosto in una miriade di esempi, forse sarebbe meglio riformulare il trigger che fa scattare un esonero dall’obbligo di notifica.

Che so, ad esempio citando un rischio basso. E lasciando (vedi sopra circa le 72 ore) tempo al titolare per valutare correttamente il rischio prima di spammar notifiche di data breach “perchè non si sa mai”. Con buona pace dell’accountability.

L'articolo Data breach: cosa leggiamo nella relazione del Garante Privacy proviene da il blog della sicurezza informatica.

11–13 сентября 2025 года состоится очередной трёхдневный так называемый единый день голосования. Избирателям предстоит участвовать в выборах глав субъектов и иных органов власти, включая встроенные в вертикаль после öбнуления Конституции органы местного «самоуправления». Официальным символом голосования власти цинично выбрали символ свободы, жизни и победы.

Пиратская партия России последовательно выступает за внедрение и развитие системы прямого, непрерывного, свободного доступа граждан к участию в решении всех общегосударственных и местных вопросов через систему электронного референдума. Однако, для перехода к прямой демократии представительные органы власти всех уровней должны стать честными, открытыми и подконтрольными гражданам, их выбирающим, а процедуры, предусматривающие реализацию конституционного права каждого гражданина избирать и быть избранным, максимально упрощены.

Мы намерены осуществлять наблюдение за ходом голосования, в том числе на федеральном уровне за тем, что по каким-то причинам всё ещё зовётся системой дистанционного электронного голосования, которая в текущем виде противоречит базовым принципам избирательного права, о чём мы в том числе рассказывали в Госдуме РФ в апреле этого года.

Каждый гражданин вправе самостоятельно принимать решение о своём участии или неучастии в выборах. Мы уважаем выбор каждого, если он сделан свободно, без давления и после внимательного анализа информации о кандидатах и партиях.

Мы призываем фиксировать все нарушения избирательного процесса, сообщать о них наблюдателям и независимым организациям, а также добиваться их публичного обнародования.

Также напоминаем, что жизнь важнее единичного проявления политической позиции хотя бы потому, что живой человек будет способен выражать политическую позицию в дальнейшем. В случае каких-либо осложнений, связанных с вашим местонахождением, здоровьем либо другими потенциально препятствующими факторами, оставайтесь дома или в любом другом безопасном для вас месте.

Сообщение О выборах 12-14 сентября 2025 года появились сначала на Пиратская партия России | PPRU.