A few days ago we brought you word that Google was looking to crack down on “sideloaded” Android applications. That is, software packages installed from outside of the mobile operating system’s official repository. Unsurprisingly, a number of readers were outraged at the proposed changes. Android’s open nature, at least in comparison to other mobile operating systems, is what attracted many users to it in the first place. Seeing the platform slowly move towards its own walled garden approach is concerning, especially as it leaves the fate of popular services such as the F-Droid free and open source software (FOSS) repository in question.

But for those who’ve been keeping and eye out for such things, this latest move by Google to throw their weight around isn’t exactly unexpected. They had the goodwill of the community when they decided to develop an open source browser engine to keep the likes of Microsoft from taking over the Internet and dictating the rules, but now Google has arguably become exactly what they once set out to destroy.

Today they essentially control the Internet, at least as the average person sees it, they control 72% of the mobile phone OS market, and now they want to firm up their already outsized control which apps get installed on your phone. The only question is whether or not we let them get away with it.

Must be This High to Ride

First, “sideloading”. The way you’re supposed to install apps on your Android device is through the Google Play store, and maybe your phone manufacturer’s equivalent. All other sources are, by default, untrusted. What used to be refreshing about the Android ecosystem, at least in comparison, was how easy it was to sideload an application that didn’t come directly from, and profit, Big G. That is what’s changing.

Of course, the apologists will be quick to point out that Google isn’t taking away the ability to sideload applications on Android. At least, not on paper. What they’re actually doing is making it so sideloaded applications need to be from a verified developer. According to their blog post on the subject, they have no interest in the actual content of the apps in question, they just want to confirm a malicious actor didn’t develop it.

The blog post attempts to make a somewhat ill-conceived comparison between verifying developer identities with having your ID checked at the airport. They go on to say that they’re only interested in verifying each “passenger” is who they say they are for security purposes, and won’t be checking their “bags” to make sure there’s nothing troubling within. But in making this analogy Google surely realizes — though perhaps they hope the audience doesn’t pick up on — the fact that the people checking ID at the airport happen to wear the same uniforms as the ones who x-ray your bags and run you through the metal detector. The implication being that they believe checking the contents of each sideloaded package is within their authority, they have simply decided not to exercise that right. For now.

Conceptually, this initiative is not unlike another program Google announced this summer: OSS Rebuild. Citing the growing risk of supply chain attacks, where malicious code sneaks into a system thanks to the relatively lax security of online library repositories, the search giant offers a solution. They propose setting up a system by which they not only verify the authors of these open source libraries, but scan them to make sure the versions being installed match the published source code. In this way, you can tell that not only are you installing the authentic library, but that no rogue code has been added to your specific copy.

Google the Gatekeeper

Much like verifying the developer of sideloaded applications, OSS Rebuild might seem like something that would benefit users at first glance. Indeed, there’s a case to be made that both programs will likely identify some low-hanging digital fruit before it has the chance to cause problems. An event that you can be sure Google will publicize for all it’s worth.

But in both cases, the real concern is that of authority. If Google gets to decide who a verified developer is for Android, then they ultimately have the power to block whatever packages they don’t like. To go back to their own airport security comparison, it would be like if the people doing the ID checks weren’t an independent security force, but instead representatives of a rival airline. Sure they would do their duty most of the time, but could they be trusted to do the right thing when it might be in their financial interests not to? Will Google be able to avoid the temptation to say that the developers of alternative software repositories are persona non grata?

Even more concerning, who do you appeal to if Google has decided they don’t want you in their ecosystem? We’ve seen how they treat YouTube users that have earned their ire for some reason or another. Can developers expect the same treatment should they make some operational faux pas?

Let us further imagine that verification through OSS Rebuild becomes a necessary “Seal of Approval” to be taken seriously in the open source world — at least in the eyes of the bean counters and decision makers. Given Google’s clout, it’s not hard to picture such an eventuality. All Google would have to do to keep a particular service or library down is elect not to include them in the verification process.

Life Finds a Way

If we’ve learned anything about Google over the years, it’s that they can be exceptionally mercurial. They’re quick to drop a project and change course if it seems like it isn’t taking them where they want to go. Even projects that at one time seemed like they were going to be a pivotal part of the company’s future — such as Google+ — can be kicked to the curb unceremoniously if the math doesn’t look right to them. Indeed, the graveyard of failed Google initiatives has far more headstones than the company’s current roster of offerings.

Which is so say, that there’s every possibility that user reaction to this news might be enough to get Google to take a different tack. Verified sideloading isn’t slated to go live until 2027 for most of the world, although some territories will get it earlier, and a lot can happen between now and then.

Even if Google goes through with it, they’ve already offered something of an olive branch. The blog post mentions that they intend to develop a carve out in the system that will allow students and hobbyists to install their own self-developed applications. Depending on what that looks like, this whole debate could be moot, at least for folks like us.

In either event, the path would seem clear. If we want to make sure there’s choice when it comes to Android software, the community needs to make noise about the issue and keep the pressure on. Google’s big, but we’re bigger.

hackaday.com/2025/08/28/the-br…

Un esperto di sicurezza ha scoperto che sei dei gestori di password più diffusi, utilizzati da decine di milioni di persone, sono vulnerabili al clickjacking, un fenomeno che consente agli aggressori di rubare credenziali di accesso, codici di autenticazione a due fattori e dati delle carte di credito.

ezstandalone.cmd.push(function () { ezstandalone.showAds(604); });
Il problema è stato segnalato per la prima volta dal ricercatore indipendente Marek Tóth, che ha presentato un rapporto sulle vulnerabilità alla recente conferenza di hacker DEF CON 33. Le sue scoperte sono state successivamente confermate dagli esperti di Socket, che hanno contribuito a informare i fornitori interessati e a coordinare la divulgazione pubblica delle vulnerabilità.

Ha testato il suo attacco su varianti specifiche di 1Password, Bitwarden, Enpass, iCloud Passwords, LastPass e LogMeOnce e ha scoperto che tutte le versioni del browser potevano far trapelare dati sensibili in determinati scenari.

ezstandalone.cmd.push(function () { ezstandalone.showAds(612); });
Gli aggressori possono sfruttare le vulnerabilità quando le vittime visitano pagine dannose o siti vulnerabili ad attacchi XSS o al cache poisoning. Di conseguenza, gli aggressori sono in grado di sovrapporre elementi HTML invisibili all’interfaccia del gestore delle password. L’utente penserà di interagire con innocui elementi cliccabili sulla pagina, ma in realtà attiverà il riempimento automatico, che “trapelerà” le sue informazioni riservate agli hacker.

L’attacco si basa sull’esecuzione di uno script su un sito web dannoso o compromesso. Questo script utilizza impostazioni di trasparenza, sovrapposizioni o eventi puntatore per nascondere il menu a discesa di compilazione automatica del gestore password del browser. Allo stesso tempo, l’aggressore sovrappone elementi falsi e fastidiosi alla pagina (come banner di cookie, pop-up o CAPTCHA). Tuttavia, i clic su questi elementi conducono a controlli nascosti del gestore delle password, che portano alla compilazione di moduli con informazioni riservate.

Ha dimostrato diversi sottotipi DOM e exploit dello stesso bug: manipolazione diretta dell’opacità dell’elemento DOM, manipolazione dell’opacità dell’elemento radice, manipolazione dell’opacità dell’elemento padre e sovrapposizione parziale o completa.

ezstandalone.cmd.push(function () { ezstandalone.showAds(613); });
Il ricercatore ha anche dimostrato l’utilizzo di un metodo in cui l’interfaccia utente segue il cursore del mouse e, di conseguenza, qualsiasi clic dell’utente, ovunque si trovi, attiva il riempimento automatico dei dati. Allo stesso tempo, Toth ha sottolineato che lo script dannoso può rilevare automaticamente il gestore di password attivo nel browser della vittima e quindi adattare l’attacco a un obiettivo specifico in tempo reale.

Di conseguenza, il ricercatore ha testato 11 gestori di password per individuare la vulnerabilità al clickjacking e ha scoperto che tutti erano vulnerabili ad almeno uno dei metodi di attacco. Sebbene Toth avesse informato tutti i produttori dei problemi già nell’aprile 2025 e li avesse anche avvisati che la divulgazione pubblica delle vulnerabilità era prevista per DEF CON 33, non ci fu alcuna risposta immediata. La scorsa settimana, Socket ha contattato nuovamente gli sviluppatori per ribadire la necessità di assegnare CVE ai problemi nei prodotti interessati.

I rappresentanti di 1Password hanno definito il rapporto del ricercatore “informativo”, sostenendo che il clickjacking è una minaccia comune da cui gli utenti dovrebbero essenzialmente proteggersi. Anche gli sviluppatori di LastPass hanno trovato il rapporto “informativo” e Bitwarden ha riconosciuto i problemi e, sebbene l’azienda non li abbia considerati gravi, le correzioni sono state implementate nella versione 2025.8.0, rilasciata la scorsa settimana. I seguenti gestori di password, che complessivamente contano circa 40 milioni di utenti, sono attualmente vulnerabili agli attacchi di clickjacking:

ezstandalone.cmd.push(function () { ezstandalone.showAds(614); });

• 1Password 8.11.4.27
• Bitwarden 2025.7.0
• Enpass 6.11.6 (correzione parziale implementata nella versione 6.11.4.2)ezstandalone.cmd.push(function () { ezstandalone.showAds(615); });
• Password iCloud 3.1.25
• LastPass 4.146.3
• LogMeOnce 7.12.4ezstandalone.cmd.push(function () { ezstandalone.showAds(616); });

Le patch sono già state implementate nei loro prodotti: Dashlane (v6.2531.1 rilasciata il 1° agosto), NordPass, ProtonPass, RoboForm e Keeper (17.2.0 rilasciata a luglio). Ora si consiglia agli utenti di assicurarsi di aver installato le versioni più recenti disponibili dei prodotti.

L'articolo I gestori di password più diffusi, tra cui LastPass, 1Password e Bitwarden sono vulnerabili al clickjacking proviene da il blog della sicurezza informatica.

Martyn Ditchburn, CTO in residence Zscaler

ezstandalone.cmd.push(function () { ezstandalone.showAds(604); });
L’intelligenza artificiale, come qualsiasi tecnologia, non è intrinsecamente buona o cattiva: tutto dipende da chi la utilizza e per quale scopo. Ciò che è certo però, è che l’IA si sta evolvendo più velocemente della sua controparte più prudente, cioé la regolamentazione, dal momento che i legislatori faticano a stare al passo. A complicare la situazione, l’IA sta innovando anche al proprio interno, generando un’accelerazione senza precedenti nello sviluppo tecnologico.

Questo scenario sta aprendo la strada a una nuova serie di sfide per la sicurezza, l’ultima delle quali è rappresentata dal vibe coding. Come per qualsiasi ciclo di innovazione in ambito IA, è fondamentale capire di cosa si tratta e quali sono le implicazioni per la sicurezza.

ezstandalone.cmd.push(function () { ezstandalone.showAds(612); });

Cos’è il vibe coding

Fondamentalmente, il vibe coding è un approccio moderno allo sviluppo del software. Questo cambiamento si comprende meglio osservando l’evoluzione del ruolo dello sviluppatore. In precedenza, uno sviluppatore avrebbe avuto il compito di scrivere manualmente ogni riga di codice, per poi procedere con le classiche fasi di ispezione, test, correzione e rilascio. Ora, con l’introduzione del vibe coding, uno sviluppatore di software – e anche una persona comune – è in grado di saltare il primo passaggio, affidando all’intelligenza artificiale la scrittura del codice, limitandosi a guidarla, per poi testarlo e perfezionarlo.

Sulla carta, i benefici sono evidenti. Gli sviluppatori possono lavorare in modo più efficiente, l’accesso alla programmazione viene democratizzato, aprendolo anche agli sviluppatori alle prime armi e la creatività e la sperimentazione sono stimolate, con la creazione di nuove applicazioni rivolte ai consumatori, intuitive e facili da usare. Anche il CEO di Google, Sundar Pichai, si è lasciato coinvolgere, affermando che “è una sensazione meravigliosa fare il programmatore”, dopo essersi lasciato sfuggire che stava provando a creare una applicazione web.

Come accade per ogni innovazione guidata dall’IA – e vista la crescente accessibilità degli strumenti – il fenomeno prende piede nel settore, cambia le abitudini e porta alla nascita di nuove aziende e strumenti. Solo poche settimane fa, la società di vibe coding Lovable era in trattative per una valutazione da 1,5 miliardi di dollari. È evidente che non si può fermare questa corrente: bisogna imparare a gestirla, creare barriere adeguate e gestire correttamente i rischi. Ma quali sono questi rischi?

ezstandalone.cmd.push(function () { ezstandalone.showAds(613); });

I rischi per la sicurezza

Così come il vibe coding può essere utilizzato per scopi innovativi, può anche diventare un veicolo per nuove minacce informatiche. Per affrontare in modo efficace lo scenario, le aziende hanno bisogno di un codice sicuro, conforme e gestibile. La verità è che un codice dannoso non deve essere sofisticato né particolarmente duraturo per creare danni.

Nell’odierno panorama delle minacce guidate dall’IA, i criminali possono persino utilizzare comandi vocali per generare codice dannoso volto a sfruttare le vulnerabilità. Se portiamo questa riflessione un passo oltre, il quadro si complica ulteriormente con l’introduzione degli agenti IA, che aggiungono un’altra dimensione pericolosa. Sebbene l’IA generativa possa già produrre codice come parte del vibe coding, è comunque necessario che l’esecuzione del codice avvenga in ambienti isolati, almeno finché un agente IA non se ne assumerà la responsabilità.

Il vibe coding può inoltre causare problemi all’interno dei team stessi della sicurezza. Spesso è un’attività individuale, che compromette la natura collaborativa e agile delle pratiche DevOps. Senza una programmazione strutturata e una consapevolezza della sicurezza, il vibe coding può introdurre rischi nascosti.

ezstandalone.cmd.push(function () { ezstandalone.showAds(614); });

Strategie difensive

Il vibe coding rappresenta un salto in termini di astrazione, consentendo ai programmatori di generare codice con il linguaggio naturale. Se da un lato abbassa la barriera d’ingresso e democratizza l’accesso alla programmazione, dall’altro aumenta il rischio di un uso improprio da parte di utenti non qualificati. Le aziende devono adottare una visione di lungo periodo. Il vibe coding è solo l’ultima evoluzione degli attacchi guidati dall’IA, e per quanto sia facile concentrarsi sulla tecnologia del momento, le aziende devono prepararsi a difendersi da questo fenomeno e da ciò che verrà dopo.

La prima e più importante strategia difensiva consiste nell’adozione di un’architettura Zero Trust. Questo processo di sicurezza presuppone che nessuna entità (utente, dispositivo o applicazione) debba essere considerata attendibile a priori, anche se si trova all’interno della rete aziendale. Il vecchio adagio “se riesci a raggiungerlo, puoi violarlo” non è mai stato così attuale. Per questo motivo, ridurre o eliminare la superficie d’attacco è uno dei modi più efficaci per rafforzare il proprio livello di sicurezza.

In secondo luogo, le tecnologie basate su piattaforma offrono un valore elevato. I fornitori di piattaforme, infatti, raccolgono e analizzano enormi quantità di dati grazie al supporto di milioni di clienti, e le informazioni che ne derivano sono estremamente preziose. È un po’ come il concetto di immunità di gregge; se una vulnerabilità viene individuata e risolta in un’organizzazione, la soluzione può essere rapidamente estesa a molte altre. In sostanza, adottando una piattaforma condivisa, le aziende beneficiano dell’esperienza collettiva e della protezione derivante dall’intero ecosistema. Infine, è fondamentale che le aziende adottino un approccio proattivo alla sicurezza, passando da una logica difensiva a una di tipo offensivo, quella che comunemente viene chiamata “threat hunting”, ovvero caccia alle minacce. Mitigando i rischi prima che si aggravino, le aziende possono rafforzare il loro livello di sicurezza complessivo.

ezstandalone.cmd.push(function () { ezstandalone.showAds(615); });

Uno sguardo al futuro

In definitiva, per ragioni come l’efficienza dei costi, l’intelligenza artificiale continuerà a cambiare il modo in cui lavoriamo e quindi a influenzare come ci proteggiamo dalle minacce in evoluzione. In futuro, il vibe coding potrebbe coinvolgere più agenti di intelligenza artificiale che gestiscono diversi aspetti del processo, con un agente per ambiti come la creatività, la sicurezza e la struttura.

Quando ben implementata, la sicurezza può stimolare crescita e guadagni, favorendo l’espansione sul mercato, l’agilità operativa e l’adozione di best practice aziendali. Al contrario, se trascurata, rende le aziende vulnerabili ai rischi legati alle più recenti innovazioni e tendenze dell’IA. Adottando una visione di lungo termine del panorama delle minacce, implementando un modello Zero Trust e adottando un approccio proattivo alla loro sicurezza, le aziende possono proteggersi meglio e crescere con successo.

L'articolo Vibe Coding: Rivoluzione o Rischio per la Sicurezza? proviene da il blog della sicurezza informatica.

NetScaler ha avvisato gli amministratori di tre nuove vulnerabilità in NetScaler ADC e NetScaler Gateway, una delle quali è già utilizzata in attacchi attivi. Sono disponibili aggiornamenti e il fornitore invita a installarli immediatamente: exploit per CVE-2025-7775 sono stati individuati su dispositivi non protetti.

ezstandalone.cmd.push(function () { ezstandalone.showAds(604); });
I bug includono un overflow di memoria con rischio di esecuzione di codice e di negazione del servizio, un secondo bug simile con crash del servizio e comportamento imprevedibile e un problema di controllo degli accessi nell’interfaccia di gestione. I bug interessano sia le release standard sia le build conformi a FIPS/NDcPP. Gli aggiornamenti sono già stati distribuiti per i servizi cloud gestiti dal fornitore, ma le installazioni client richiedono aggiornamenti manuali.

Le versioni interessate sono: NetScaler ADC e Gateway 14.1 (precedentemente alla versione 14.1-47.48), 13.1 (precedente alla versione 13.1-59.22), nonché NetScaler ADC 13.1-FIPS/NDcPP (precedente alla versione 13.1-37.241) e 12.1-FIPS/NDcPP (precedente alla versione 12.1-55.330).

ezstandalone.cmd.push(function () { ezstandalone.showAds(612); });
Si segnala inoltre che le versioni 12.1 e 13.0 non sono più supportati e devono essere trasferiti alle versioni correnti. Gli aggiornamenti sono disponibili sia per i gateway standard sia per le distribuzioni Secure Private Access on-prem e ibride che utilizzano istanze NetScaler.

Citrix consiglia di effettuare l’aggiornamento alle seguenti build:

• 14.1-47.48 e versioni successive per la riga 14.1;ezstandalone.cmd.push(function () { ezstandalone.showAds(613); });
• 13.1-59.22 e versioni successive per 13.1;
• 13.1-37.241 e versioni successive per 13.1-FIPS/NDcPP;
• 12.1-55.330 e versioni successive per 12.1-FIPS/NDcPP.ezstandalone.cmd.push(function () { ezstandalone.showAds(614); });

Non ci sono soluzioni alternative.

Sono già state implementate delle correzioni per i cloud gestiti da Citrix e per l’Autenticazione Adattiva.

Per valutare la propria installazione, gli amministratori possono verificare la presenza nella propria configurazione delle stringhe rivelatrici elencate nel bollettino. Citrix ha inviato una notifica a clienti e partner tramite il sito di supporto di NetScaler. I problemi sono confermati anche dai bollettini di settore e dai database delle vulnerabilità.

ezstandalone.cmd.push(function () { ezstandalone.showAds(615); });
L'articolo Vulnerabilità critiche in NetScaler ADC e Gateway. Aggiorna subito! Gli attacchi sono in corso! proviene da il blog della sicurezza informatica.

I criminali informatici stanno rapidamente padroneggiando l’intelligenza artificiale generativa, e non stiamo più parlando di lettere di riscatto “spaventose”, ma di sviluppo di malware a tutti gli effetti. Il team di ricerca di Anthropic ha riferito che gli aggressori si affidano sempre più a modelli linguistici di grandi dimensioni, fino all’intero ciclo di creazione e vendita di strumenti di crittografia dei dati.

ezstandalone.cmd.push(function () { ezstandalone.showAds(604); });
Parallelamente, ESET ha descritto un concetto di attacco in cui i modelli locali, dal lato dell’aggressore, assumono le fasi chiave dell’estorsione. La totalità delle osservazioni mostra come l‘intelligenza artificiale rimuova le barriere tecniche e acceleri l’evoluzione degli schemi ransomware.

Secondo Anthropic, i partecipanti alla scena dell’estorsione utilizzano Claude non solo per preparare testi e scenari di negoziazione, ma anche per generare codice, testare e pacchettizzare programmi e lanciare servizi secondo il modello “crime as a service”. L’attività è stata registrata da un operatore del Regno Unito, a cui è stato assegnato l’identificativo GTG-5004.

ezstandalone.cmd.push(function () { ezstandalone.showAds(612); });
Dall’inizio dell’anno, l’operatore offre kit di attacco su forum underground a prezzi compresi tra 400 e 1.200 dollari, a seconda del livello di configurazione. Le descrizioni includevano diverse opzioni di crittografia, strumenti per aumentare l’affidabilità operativa e tecniche per eludere il rilevamento. Allo stesso tempo, secondo Anthropic, il creatore non ha una conoscenza approfondita della crittografia, delle tecniche di controanalisi o dei meccanismi interni di Windows: ha colmato queste lacune con l’aiuto di suggerimenti e della generazione automatica di Claude.

L’azienda ha bloccato gli account coinvolti e implementato filtri aggiuntivi sulla sua piattaforma, tra cui regole per il riconoscimento di pattern di codice distintivi e controlli basati sulle firme dei campioni caricati, per impedire in anticipo i tentativi di trasformare l’IA in una fabbrica di malware . Ciò non significa che l’IA stia già producendo in serie tutti i moderni trojan crittografici, ma la tendenza è allarmante: anche gli operatori immaturi stanno ottenendo un acceleratore che in precedenza era disponibile solo per gruppi esperti di tecnologia.

Il contesto del settore non fa che gettare benzina sul fuoco. Negli ultimi anni, gli estorsori sono diventati più aggressivi e inventivi, e i parametri di valutazione all’inizio del 2025 indicavano volumi record di incidenti e profitti multimilionari per i criminali. Alle conferenze di settore, è stato riconosciuto che i progressi sistemici nella lotta contro l’estorsione non sono ancora visibili. In questo contesto, l’intelligenza artificiale promette non solo un adattamento estetico dell’estorsione, ma un ampliamento dell’arsenale, dalla fase di penetrazione all’analisi automatizzata dei dati rubati e alla formulazione delle richieste.

ezstandalone.cmd.push(function () { ezstandalone.showAds(613); });
Un capitolo a parte è la dimostrazione di ESET chiamata PromptLock(del quale abbiamo parlato ieri). Si tratta di un prototipo in cui un modello distribuito localmente può generare script Lua al volo per inventariare i file di destinazione, rubare contenuti e avviare la crittografia. Gli autori sottolineano che si tratta di un concetto, non di uno strumento visto in attacchi reali, ma illustra un cambiamento: i modelli di grandi dimensioni non sono più solo un “prompt” basato sul cloud e stanno diventando una componente autonoma dell’infrastruttura di un aggressore.

Certo, l’intelligenza artificiale locale richiede risorse e occupa spazio, ma i trucchi per ottimizzare e semplificare l’inferenza rimuovono alcune delle limitazioni, e i criminali informatici stanno già esplorando queste possibilità.

Il rapporto di Anthropic descrive anche un altro cluster, identificato come GTG-2002. In questo caso, Claude Code è stato utilizzato per selezionare automaticamente i bersagli, preparare strumenti di accesso, sviluppare e modificare malware e quindi esfiltrare e contrassegnare i dati rubati. Alla fine, la stessa IA ha contribuito a generare richieste di riscatto basate sul valore di quanto trovato negli archivi. Nell’ultimo mese, l’azienda stima che almeno diciassette organizzazioni del settore pubblico, sanitario, dei servizi di emergenza e delle istituzioni religiose siano state colpite, senza rivelarne i nomi. Questa architettura mostra come il modello diventi sia un “consulente” che un operatore, riducendo il tempo tra la ricognizione e la monetizzazione.

ezstandalone.cmd.push(function () { ezstandalone.showAds(614); });
Alcuni analisti osservano che la totale “dipendenza dall’intelligenza artificiale” tra i ransomware non è ancora diventata la norma e che i modelli sono più comunemente utilizzati come primo step di sviluppo, per l’ingegneria sociale e l’accesso iniziale. Tuttavia, il quadro emergente sta già cambiando gli equilibri di potere: abbonamenti economici, sviluppi open source e strumenti di lancio locali rendono lo sviluppo e la manutenzione delle operazioni ransomware più accessibili che mai.

Se questa dinamica continua, i difensori dovranno considerare non solo i nuovi file binari, ma anche le catene decisionali delle macchine che questi file binari producono, testano e distribuiscono.

L'articolo La Democratizzazione della Criminalità informatica è arrivata! “Non so programmare, ma scrivo ransomware” proviene da il blog della sicurezza informatica.

more here: instagram.com/p/DN0iMNCWNpU

#genocide #zionism #israhell #izrahell #Gaza #Palestine #privacy #datamining #datacontrol #facialrecognition #ai #control #apartheid #ethniccleansing #google #googlecomplicity