The phone ecosystem these days is horribly boring compared to the innovation of a couple decades back. Your options include flat rectangles, and flat rectangles that fold in half and then break. [Marcin Plaza] wanted to think outside the slab, without reinventing the wheel. In an inspired bout of hacking, he flipped a broken Samsung zFlip 5 into a “new” phone.

There’s really nothing new in it; the guts all come from the donor phone. That screen? It’s the front screen that was on the top half of the zFlip, as you might have guessed from the cameras. Normally that screen is only used for notifications, but with the Samsung’s fancy folding OLED dead as Disco that needed to change. Luckily for [Marcin] Samsung has an app called Good Lock that already takes care of that. A little digging about in the menus is all it takes to get a launcher and apps on the small screen.

Because this is a modern phone, the whole thing is glued together, but that’s not important since [Marcin] is only keeping the screen and internals from the Samsung. The new case with its chunky four-bar linkage is a custom design fabbed out in CNC’d aluminum. (After a number of 3D Printed prototypes, of course. Rapid prototyping FTW!)

The bottom half of the slider contains a Blackberry Q10 keyboard, along with a battery and Magsafe connector. The Q10 keyboard is connected to a custom flex PCB with an Arduino Micro Pro that is moonlighting as a Human Input Device. Sure, that means the phone’s USB port is used by the keyboard, but this unit has wireless charging,so that’s not a great sacrifice. We particularly like the use of magnets to create a satisfying “snap” when the slider opens and closes.

Unfortunately, as much as we might love this concept, [Marcin] doesn’t feel the design is solid enough to share the files. While that’s disappointing, we can certainly relate to his desire to change it up in an era of endless flat rectangles. This project is a lot more work than just turning a broken phone into a server, but it also seems like a lot more fun.

youtube.com/embed/qy_9w_c2ub0?…

hackaday.com/2025/09/02/phonen…

As the art of 3D printing has refined itself over the years, a few accessories have emerged to take prints to the next level. One of them is the threaded insert, a a piece of machined brass designed to be heat-set into a printed hole in the part. They can be placed by hand with a soldering iron, or for the really cool kids, with a purpose-built press. They look great and they can certainly make assembly of a 3D printed structure very easy, but I’m here to tell you they are not as necessary as they might seem. There’s an alternative I have been using for years which does essentially the same job without the drama.

Enter The Self-Tapper

This turret camera project features both inserts on the M12 lens holders, and self-tappers for the centre boss and the mounting screws.
When we think of screws or other fastenings, if we’re not a woodworker, the chances are that it’s a machine screw which comes to mind. A high-precision machined parallel thread, intended to screw into a similarly machined receptacle. Where this is being written they’re mostly metric, in fact I have a small pile of M3 bolts on my desk as I write this, for mounting a Raspberry Pi LCD screen. These are what you would use with those heat-set inserts, and they are generally a very good way to attach parts to each other.

However good an M3 bolt is though, I don’t use them for most of my 3D printing work. Instead, I use self-tapping screws. A self-tapper is a screw with a wide tapering pitch, designed to cut its own thread into a soft material. Most wood screws are self-tappers, as are many screws used for example with aluminium sheet. The material is soft enough for a reliable enough coupling to be made, even if repeated use or over-tightening can destroy it. It’s easy to make 3D prints that can take self-tapping screws in this way, I find it reliable enough for my purposes, and I think it can save you a bunch of time with heat inserts.

How To Make It All Happen

Designing for a self-tapping connection in a 3D print is simplicity itself: a suitable hole for the screw thread to pass through is placed in the upper side, while the lower side has a smaller hole for the thread to bite into. The size of the smaller hole can vary significantly without penalty, but I normally make it the diameter of the shaft of the screw without the thread. A simple example for a 3mm self-tapper in OpenSCAD is shown below, along with a render of the result.
//Screw head end
translate([0,0,20]){ //Move upwards to see both parts
difference(){
cube([20,20,4]);
//screw thread
translate([10,10,0]) cylinder(10,1.5,1.5);
//screw head
translate([10,10,2]) cylinder(10,3,3);
}
}

//Screw thread end
difference(){
cube([20,20,10]);
translate([10,10,0]) cylinder(10,1,1); // For the screw to bite into
}

Assembly follows construction in its simplicity; simply line up both holes and screw the self-tapping screw into them. It should be obvious when the screw is tight enough. Mashing upon it, just like with any other self tapper, risks stripping the thread.

Everyone makes things in their own manner, and it’s likely that among you will be people who might decry the use of self-tappers in a 3D print. But I have found this technique to be a simple and cheap time saver for as many years as I’ve been 3D printing. I hope by sharing it with you, I’ve given you a useful tool in your work.

hackaday.com/2025/09/02/no-nee…

The picture on a TV set used to be the combined product of multiple analog systems, and since TVs had no internal diagnostics, the only way to know things were adjusted properly was to see for yourself. While many people were more or less satisfied if their TV picture was reasonably recognizable and clear, meaningful diagnostic work or calibration required specialized tools. [Thomas Scherrer] provides a close look at one such tool, the Philips PM 5519 GX Color TV Pattern Generator from 1981.
This Casio handheld TV even picked up the test pattern once the cable was disconnected, the pattern generator acting like a miniature TV station.
The Philips PM 5519 was a serious piece of professional equipment for its time, and [Thomas] walks through how the unit works and even opens it up for a peek inside, before hooking it up to both an oscilloscope and a TV in order to demonstrate the different functions.

Tools like this were important because they could provide known-good test patterns that were useful not just for troubleshooting and repair, but also for tasks like fine-tuning TV settings, or verifying the quality of broadcast signals. Because TVs were complex analog systems, these different test patterns would help troubleshoot and isolate problems by revealing what a TV did (and didn’t) have trouble reproducing.

As mentioned, televisions at the time had no self-diagnostics nor any means of producing test patterns of their own, so a way to produce known-good reference patterns was deeply important.

TV stations used to broadcast test patterns after the day’s programming was at an end, and some dedicated folks have even reproduced the hardware that generated these patterns from scratch.

youtube.com/embed/jZtGrG6HhS4?…

hackaday.com/2025/09/02/checki…

[Arnov Sharma]’s latest PIP-WATCH version is an homage to Pip-Boys, the multi-function wrist-mounted personal computers of Fallout.
We like the magnetic clasp on the back end.
[Arnov] has created a really clean wearable design with great build instructions, so anyone who wants to make their own should have an easy time. Prefer to put your own spin on it, or feel inspired by the wrist-mounted enclosure? He’s thoughtfully provided the CAD files as well.

Inside the PIP-WATCH is a neat piece of hardware, the Lilygo T-Display-S3 Long. It’s an ESP32-based board with a wide, touch-enabled, color 180 x 640 display attached. That makes it a perfect fit for a project like this, at least in theory. In practice, [Arnov] found the documentation extremely lacking which made the hardware difficult to use, but he provides code and instructions so there’s no need to go through the same hassles he did.

In addition to the Hackaday.io project page, there’s an Instructables walkthrough.

If you put your own spin on a Pip-boy (whether just a project inspired by one, or a no-detail-spared build of dizzying detail) we want to hear about it, so be sure to drop us a tip!

youtube.com/embed/jQH54g_L25s?…

hackaday.com/2025/09/02/build-…

Over the past decades power grids have undergone a transformation towards smaller and more intermittent generators – primarily in the form of wind and solar generators – as well as smaller grid-connected batteries. This poses a significant problem when it comes to grid management, as this relies on careful management of supply and demand. Quite recently the term Virtual Power Plant (VPP) was coined to describe these aggregations of disparate resources into something that at least superficially can be treated more or less as a regular dispatchable power plant, capable of increasing and reducing output as required.

Although not actual singular power plants, by purportedly making a VPP act like one, the claim is that this provides the benefits of large plants such as gas-fired turbines at a fraction of a cost, and with significant more redundancy as the failure of a singular generator or battery is easily compensated for within the system.

The question is thus whether this premise truly holds up, or whether there are hidden costs that the marketing glosses over.

Reactive Power

The power triangle, showing the relationship between real, apparent and reactive power. (Source: Wikimedia)
The alternating current (AC) based electrical grid is a delicate system that requires constant and very careful balancing to ensure that its current current and voltage don’t go too far out of phase, lest grid frequency and voltage start following it well beyond tolerances. The consequence of getting this wrong has been readily demonstrated over the decades through large-scale blackouts, not the least of which being the 2025 Iberian Peninsula blackout event that plummeted all of Spain and Portugal into darkness. This occurred after attempts to reduce the amount of reactive power in the system failed and safeties began to kick in throughout these national grids.

This is also the point where the idea of a VPP runs into a bit of a reality check, as the recommendation by the grid operators (transmission system operators, or TSOs) is that all significant generators on the grid should be capable of grid-forming. What this means is that unlike the average invertor on a wind- or PV solar installation that just follows the local grid frequency and voltage, it should instead be able to both absorb and produce reactive power.

Effectively this involves adding local energy storage, which is where the idea seems to be that you can sort of fudge this with distributed dumb inverters and grid-connected batteries in the form of people’s whole house batteries and whatever Vehicle-to-Grid (V2G) capable BEV is currently plugged in within that subsection of the grid.

Theoretically with enough of these scattered generators and storage elements around, along with a few grid-forming converters and remotely controlled loads like EV chargers and airconditioning units, you could simulate the effect of a regular thermal- or hydropower plant. The question is whether you can make it work well enough, and as a logical follow-up question, there are those who would like to know who is really footing the bill in the end.

Battery Rental

Electricity generation by type, 2001-2024. (Credit: California Energy Commission)
An example of such a VPP in action can be found in California, where PG&E and others have recently been running tests. A big focus here is on these home batteries, which are also used for peak-shaving in these tests, with the battery owner compensated for withdrawn power. In a report sponsored by Sunrun and Tesla Energy, the Brattle Group describes this system in which the Demand Side Grid Support (DSGS) program aspect is hailed as a major revolution.
Fire at the Moss Landing Power Plant. (Credit: Guy Churchward)
The idea here is that regular grid-connected consumers install batteries which the grid operator can then tap into, which can compensate for California’s increasing amount of non-dispatchable, non-grid forming generation sources. Of note here is that grid-scale energy storage can never provide enough capacity to bridge significant spans of time, ergo the proposal here is primarily to provide an alternative to expensive peaker plants, of which California already has a significant number.

With a predicted 4 GW of home battery capacity by 2040, this could then save the grid operators a lot of cash if they can use these batteries instead of running special peaker plants, or installing more large batteries as at the (PG&E-operated) Moss Landing battery storage facility.

Incidentally, said Moss Landing battery storage facility has repeatedly caught fire, which highlights another potentially major savings for grid operators, as the fallout of such events are instead borne by the operator of the battery, which for the DSGS would be the home owner. So far, remote adjustment of air-conditioning doesn’t seem to be a big part of the discussion yet, but this would seem to be only a matter of time, considering the significant power savings that way, even if it relies just on paid volunteers like with the DSGS.

Signs Of Market Failure

Although it can seem tempting to imagine making money off that expensive home battery or electric car by letting the local grid operator tap into it, the same general issues apply as with the much older V2G discussion. Not only is there the question of battery wear, but as mentioned there are also insurance considerations, and the problem that home batteries and BEVs tend to be sited far from where they are likely needed. While a site like Moss Landing is directly plugged into the big transmission lines, home batteries are stuck on some local distribution grid, making dispatching their power a bit of a nightmare.

This is also the impression one gets when reading certain articles on VPPs over at the US Department of Energy, with a VPP plan in Illinois targeting larger commercial and community solar generators rather than residential, giving them a rebate if they want to foot the bill for installing a grid-following converter, which presumably would involve some level of on-site storage. A major problem with distributed resources is their distributed nature, which precludes any planning or siting considerations that directly address demand in the form of building a power plant or pumped hydro plant with a direct transmission line to where it’s needed.
Projected electricity generation pathways by 2040. (Credit: S&P Global Inc.)
Meanwhile a recent study commissioned by the American Clean Power Association (ACP) concludes that in the US alone, electricity demand by 2040 is likely to surge 35-40% compared to today, requiring an extremely fast buildout of additional generating resources involving mostly the same kind of power mix as today. At a projected 5.5 – 6 TWh by 2024 compared to about 4 TWh today with a significant boost in non-dispatchable generators, it seems fair to question how far home batteries and a handful of V2G-enabled EV cars can support this effort in some kind of national VPP system.

Asking The Basic Questions

Although it’s often said that ‘distributed electricity generation’ is the future, it’s rarely quantified why exactly this would be the case. Simply looking at how AC power grids work, along with the tracing of the kilometers of required transmission lines across a map in order to connect all disparate generators should give one plenty of pause. It seems obvious enough that an abundance of distributed, non-dispatchable, non-grid-forming generators on a grid would also prove to be problematic, especially in the wake of the Iberian blackout this year.

Patching around this by making end-users foot the bill for battery storage and grid-forming converters and calling it VPPs then feels disingenuous. Here a more reasonable model – that has also been repeatedly suggested and occasionally implemented – involves homes and businesses equipped with local storage that only serves to reduce demand on the grid. These batteries can be charged from the grid when the ¢/kWh rate is very low, providing a balancing influence on the grid without remote control by TSOs or similar levels of complexity.

Ultimately it would seem that the European TSOs (ENTSO-E) with their focus on eradicating dumb converters and requiring grid-forming ones are on the right track. After all, if every wind and solar generator installation acts for all intents and purposes as a dispatchable generator with the ability to absorb and generate reactive power, then the whole VPP debate and much of the grid-storage debate is instantly irrelevant. It just means that the investors for these variable generators will have to spend significantly more instead of palming these costs off on end-users as some kind of grand deal.

hackaday.com/2025/09/02/the-se…

Oggi, per tutte le grandi aziende, i dati rappresentano una risorsa strategica di primaria importanza. Grazie alle informazioni ricavate, è possibile fondare strategie decisionali che, in ogni settore, possono implementare le attività e i profitti di un’azienda. Analoghe considerazioni possono essere rivolte all’interno della Pubblica Amministrazione, dove i dati non solo rappresentano uno strumento per migliorare l’efficienza interna e i processi decisionali, ma, se resi disponibili alla collettività, possono generare valore sociale ed economico.

Seppur con modalità e finalità differenti, in questo contesto si inseriscono due fenomeni fondamentali, accomunati dalla necessità di gestire grandi quantità di informazioni; stiamo parlando di Open Data e Big Data. Come tutte le tecnologie che devono gestire una grosse molte e varietà di dati, dovranno garantire sicurezza, integrità e disponibilità delle informazioni. Di base, quando parliamo di Open Data, ci riferiamo a informazioni pubbliche, dove i dati presentano un formato aperto, standardizzato e liberamente disponibile, privi di copyright.

Data la natura open dei dati, saranno compatibili con tecnologie differenti e presenteranno formati di dati aperti e interoperabili, quali ad esempio il CSV o JSON, sfruttando l’utilizzo di API per accedere ai dataset o l’utilizzo di Linked Open Data. Facciamo una parentesi sui Linked Open Data, i quali sfruttano tecnologie semantiche per strutturare i dati, permettendo così una comprensione più profonda del significato e del contesto delle informazioni. Fondamentalmente, questo approccio si basa su principi fondamentali. L’utilizzo di URI (Uniform Resource Identifier) identifica ogni risorsa in modo univoco, e i dati devono interconnettersi tramite link, consentendo la navigazione tra di essi.

Affinché le informazioni possano essere interpretate correttamente, vengono utilizzati diversi standard, tra i quali ricordiamo, senza scendere nel dettaglio, il RDF (Resource Description Framework), che consente la rappresentazione di informazioni sul web in modo strutturato, e il OWL (Web Ontology Language), che definisce le relazioni tra i dati, facilitandone la comprensione.

Gli Open Data dovranno affrontare diverse problematiche, in primis la qualità dei dati, che molto spesso risulta incompleta o obsoleta. Inoltre, la mera pubblicazione dei dati (nel caso dei servizi offerti dalla Pubblica Amministrazione) non garantisce necessariamente il loro utilizzo da parte del cittadino. Inoltre data la natura del dato saranno, spesso dati riferibili a soggetti fisici, dovranno quindi rispettare e tutelare la privacy dei soggetti. Di base, tuttavia, la formazione e la sensibilizzazione dei cittadini sull’importanza e sull’uso dei dati aperti possono contribuire a un maggiore coinvolgimento e a un utilizzo più efficace delle informazioni disponibili.

Quando i dati non sono necessariamente pubblici e necessitano di una tecnologia in grado di gestire grandi quantità, molto spesso in formato grezzo, possiamo parlare di Big Data. Comunemente, si fa riferimento alle 5V: volume (grosso volume di dati), velocità (elevata velocità operativa), varietà (varietà del dato), veridicità (veridicità della fonte fornitrice del dato) e valore (valore del dato, legato all’interesse del soggetto).

Tra le tecnologie più importanti nel contesto dell’infrastruttura dei Big Data, troviamo:

• Database NoSQL
• Hadoop
• Apache Spark

Senza avere la pretesa di esaurire gli argomenti trattati, tentiamo di fornire alcuni cenni per far comprendere la differenza tra le varie tecnologie. Da un punto di vista dell’efficienza, i NoSQL, a differenza dei database relazionali, non presentano una natura strutturata. All’interno di questi sistemi, si barattano i pesanti vincoli della struttura relazionale con operazioni più rapide e dinamiche. Questi database sono basati sul concetto di tecnologia distribuita, dove i dati possono essere archiviati su più nodi di elaborazione. Non avremo più un modello basato sulle transazioni, ma sulla flessibilità dei dati.

La memorizzazione dei dati all’interno di queste tecnologie può essere sviluppata attraverso diversi modelli. Tra i modelli utilizzati, abbiamo quello Chiave/Valore, secondo il quale gli oggetti vengono memorizzati in strutture denominate bucket sotto forma di un elenco chiave-valore. Un altro modello utilizzato è quello dei documenti, attraverso il quale gli oggetti vengono salvati all’interno di documenti aventi una struttura che ricalca quella della programmazione orientata agli oggetti (O.O.).

Il principale vantaggio del modello documentale è l’elevata compatibilità con i sistemi odierni, tra i quali troviamo MongoDB. Un ultimo modello è quello a colonna, nel quale i dati, anziché essere orientati per righe, vengono organizzati in colonne. Praticamente, sebbene il concetto presenti un cambiamento che può sembrare solo formale, migliora la distribuzione all’interno dello spazio di archiviazione.

Abbiamo accennato a MongoDB, un database basato sul modello orientato ai documenti, progettato per gestire grandi volumi di dati non strutturati o semistrutturati. MongoDB sfrutta la rappresentazione binaria BSON (Binary JSON), la quale permette di avere all’interno dati provenienti da collezioni omogenee oppure che non possiedono la stessa natura. Tali documenti, a loro volta, vengono organizzati all’interno di collezioni, all’interno delle quali è possibile implementare indici per migliorarne le prestazioni.

Ricordiamo che, ad oggi, tra i framework maggiormente utilizzati per la gestione e l’archiviazione di grosse quantità di dati, abbiamo Apache Hadoop, la cui caratteristica principale è quella di scomporre grandi problemi in elementi più piccoli, dividendo la grossa quantità di dati in parti più piccole, gestibili parallelamente. Da un punto di vista architetturale, Hadoop sfrutta il principio che eventuali errori devono essere gestiti a livello applicativo e utilizza cluster di server o server virtuali per la sua implementazione.

Hadoop è principalmente costituito da due componenti fondamentali:

• Hadoop Distributed File System (HDFS): un file system distribuito progettato per archiviare grandi quantità di dati in modo affidabile e per fornire accesso ad alta velocità.
• MapReduce: un modello di programmazione per l’elaborazione di grandi set di dati in parallelo su un cluster di computer.

Il primo modulo è Hadoop Distributed File System (HDFS), un filesystem distribuito che memorizza i dati su commodity hardware, fornendo una banda aggregata molto alta. È necessario utilizzare un filesystem distribuito quando la quantità di dati da memorizzare può eccedere quella memorizzabile in una singola macchina. È quindi necessario partizionare i dati su più macchine, fornendo meccanismi di recupero nel caso in cui una macchina si rompa. Rispetto ai normali filesystem, quelli distribuiti richiedono comunicazione di rete e sono più complessi da sviluppare.

HDFS possiede un’architettura master/slave. All’interno di un cluster vi sarà un singolo nodo master (NomeNode), un server che regola il namespace del file system e gestisce l’accesso dal client. I file sono memorizzati separatamente nei DataNode, di cui solitamente ce n’è uno per nodo del cluster. Internamente, un file è spezzato in uno o più blocchi, e questi blocchi sono memorizzati in un insieme di DataNode.

Il secondo modulo è MapReduce, un modello di programmazione per l’elaborazione di grandi quantità di dati, realizzato per far sì che i calcoli siano sviluppati in parallelo. Esso si basa sul principio “divide et impera”, nel quale un problema corposo viene suddiviso in problemi indipendenti che possono essere risolti parallelamente. Fondamentalmente, vengono generate diverse coppie chiave-valore dal componente Map, mentre il componente Reduce le aggrega in varie coppie.

Oltre ai due moduli appena descritti, possiamo indicare la presenza del modulo YARN e COMMON. YARN è il gestore delle risorse del cluster e organizza i job sui dati, mentre COMMON contiene le librerie necessarie al funzionamento dei moduli.

Nato da Hadoop, Apache Spark presenta funzionalità specifiche progettate per offrire velocità computazionale, scalabilità e programmabilità necessarie per i big data, in particolare per lo streaming di dati, dati grafici, analisi e machine learning. A differenza di Hadoop, Spark permette di effettuare query rapide e ottimizzate sfruttando la sua elaborazione all’interno della cache. La scalabilità è ottenuta dividendo i workflow di elaborazione su grandi cluster di computer.

Spark presenta un’architettura gerarchica primaria/secondaria. Il nodo primario, definito driver, controlla i nodi secondari, gestisce il cluster e fornisce i dati al client applicativo. Nel programma principale di un’applicazione Spark (il programma driver) è presente un oggetto di tipo SparkContext, la cui istanza comunica con il gestore di risorse del cluster per richiedere un insieme di risorse (RAM, core, ecc.) per gli executor.

Un punto fondamentale tra i compiti svolti da Spark è la creazione di set di dati distribuiti, noti come RDD (Resilient Distributed Dataset). Gli RDD sono resilienti (quindi ricostruibili in caso di guasti), immutabili (ogni operazione crea un nuovo RDD) e partizionabili per permettere l’elaborazione in parallelo. Spark carica i dati facendo riferimento a un’origine dati o parallelizzando una raccolta esistente con il metodo di parallelizzazione di SparkContext per la memorizzazione dei dati in un RDD per l’elaborazione. Una volta caricati i dati in un RDD, Spark esegue trasformazioni e azioni su di essi in memoria, che è la chiave della velocità di Spark. Spark memorizza inoltre i dati in memoria, a meno che il sistema non esaurisca la memoria o l’utente non decida di scrivere i dati su disco per conservarli.

Ogni set di dati in un RDD è suddiviso in partizioni logiche, che possono essere calcolate su diversi nodi del cluster. Gli utenti possono eseguire due tipi di operazioni sugli RDD: le trasformazioni e le azioni. Le trasformazioni sono operazioni applicate per creare un nuovo RDD, mentre le azioni vengono utilizzate per istruire Apache Spark ad applicare il calcolo e restituire il risultato al driver.

Una caratteristica operativa di Spark è il Grafo Aciclico Diretto (DAG). A differenza del processo di esecuzione a due parti di MapReduce di Hadoop, viene creato un grafo per orchestrare e pianificare i nodi worker all’interno del cluster. Questa caratteristica è interessante poiché eventuali guasti o errori possono essere risolti considerando le operazioni sui dati registrate in uno stato precedente. Alla base del trattamento dei dati in parallelo, abbiamo il modulo Spark Core, che gestisce la pianificazione e l’ottimizzazione. Fornisce le principali funzionalità per le librerie di Spark e il trattamento dei dati grafici di GraphX.

“Spark vs. Hadoop” è un termine frequentemente cercato sul web, ma, come notato sopra, Spark è più un miglioramento di Hadoop e, più specificamente, del componente di trattamento dei dati nativo di Hadoop, MapReduce. Infatti, Spark è basato sul framework MapReduce e oggi la maggior parte delle distribuzioni di Hadoop supporta Spark. Come MapReduce, Spark consente ai programmatori di scrivere applicazioni che elaborano enormi set di dati più velocemente, elaborando porzioni del set di dati in parallelo su grandi cluster di computer. Tuttavia, mentre MapReduce elabora i dati su disco, aggiungendo tempi di lettura e scrittura che rallentano l’elaborazione, Spark esegue calcoli in memoria. Di conseguenza, Spark può elaborare i dati fino a 100 volte più velocemente di MapReduce.

Possiamo affermare che, sebbene Open Data e Big Data siano concettualmente distinti, la loro integrazione può generare sinergie significative. L’unione di dati provenienti da dataset pubblici, accessibili a tutti, con informazioni eterogenee raccolte da fonti diverse, offre opportunità uniche per l’analisi e l’innovazione. Questa combinazione non solo arricchisce il panorama informativo, ma consente anche di sviluppare soluzioni più efficaci e mirate, in grado di rispondere a esigenze specifiche della società e del mercato. In un’epoca in cui la quantità di dati cresce esponenzialmente, la capacità di integrare e analizzare queste risorse diventa fondamentale per prendere decisioni informate e promuovere un progresso sostenibile.

L'articolo Open Data e Big Data: gestione del dato e confronto tra Hadoop vs Spark proviene da il blog della sicurezza informatica.

Il massiccio scontro tra creatori di contenuti per adulti e pirati, trasferito oggi ai sistemi automatizzati di protezione del copyright, sta iniziando a modificare radicalmente il volto di Internet. Ogni giorno diventa sempre più difficile navigare online, e il motivo non è soltanto la censura, ma anche il funzionamento impreciso degli algoritmi. Questo fenomeno è particolarmente evidente su piattaforme come OnlyFans, dove gli autori indipendenti stanno cercando in massa di proteggere i propri materiali da fughe e distribuzioni non autorizzate.

La pirateria pornografica è presente sul web fin dagli albori, ma con l’esplosione dei guadagni legati agli abbonamenti, sempre più creatori hanno iniziato ad affidarsi a società specializzate per presentare reclami DMCA (Digital Millennium Copyright Act) contro i siti che sottraggono i loro contenuti. Oggi però, l’automazione di questo processo sta generando enormi errori: le reti neurali segnalano contenuti che nulla hanno a che fare con i creatori, e Google arriva a rimuovere dai risultati di ricerca pagine del tutto innocenti.

Un caso emblematico riguarda un articolo sui terapisti virtuali di Instagram, sparito da Google a causa di una denuncia DMCA presentata da Takedowns AI per conto della modella Marie Temara. Tra i 68 link contestati, figurava un collage di immagini generate da reti neurali senza alcun legame con Temara. E i falsi positivi non si fermano qui: nella stessa richiesta di rimozione comparivano persino screenshot di GTA V, immagini sportive, poster cinematografici e materiali provenienti da siti di informazione come Wccftech e Bloody-Disgusting.

Il problema deriva da un sistema che registra centinaia di reclami ogni giorno. Dal 2022, Takedowns AI ha inviato quasi 12 milioni di segnalazioni a Google. Sebbene molte siano legittime, il livello di falsi positivi mette in pericolo risorse accademiche, giornalistiche e artistiche. È accaduto persino a un articolo dell’Università del Missouri sulle api, rimosso solo perché il nome dell’autore coincideva con quello di una modella.

Altre aziende, come Cam Model Protection, sostengono di ridurre drasticamente gli errori grazie a whitelist e controlli manuali, ribadendo che la semplice menzione di un nome o una notizia non costituiscono violazione di copyright. Tuttavia, la pressione sui creatori li spinge sempre più spesso a chiedere la rimozione di qualsiasi riferimento al proprio nome, anche quando del tutto neutrale.

Molti autori, come la modella Elaina St. James, hanno confermato l’utilità dei servizi anti-pirateria per combattere copie illegali e account falsi, pur ammettendo che i risultati migliori si ottengono con segnalazioni manuali. Le piattaforme, inoltre, non sempre collaborano: TikTok e numerosi siti esteri ignorano i reclami.

Il ricorso massiccio a sistemi automatizzati non è nuovo: basti pensare ai limiti storici del Content ID di YouTube. Ma con la crescita dei creatori indipendenti e l’affidamento all’IA, gli errori aumentano e Internet si trasforma in un campo di battaglia tra reclami automatizzati, piattaforme che li processano meccanicamente e siti innocenti travolti nel fuoco incrociato.

Gli esperti legali sottolineano che il DMCA resta un’arma potente, capace di censurare contenuti legittimi senza reali verifiche. Con lo sviluppo dell’intelligenza artificiale, i falsi positivi diventeranno sempre più frequenti, alimentati da malizia, incompetenza o semplici errori algoritmici.

Nonostante ciò, aziende come Takedowns AI scaricano parte della responsabilità sui creatori stessi, che spesso pretendono la rimozione indiscriminata di link e citazioni. Google, da parte sua, afferma di mantenere controlli automatici e manuali, con la possibilità di presentare contro-reclami.

La realtà, però, è che le vulnerabilità sono sistemiche: il monopolio di Google, i limiti dell’automazione, le falle del DMCA e l’incapacità delle piattaforme di distinguere tra violazioni reali e coincidenze. Il risultato? Un web sempre più fragile, dove siti innocenti scompaiono e i pirati continuano a prosperare.

L'articolo La battaglia tra OnlyFans e Google: pirateria, IA e il caos del copyright automatizzato proviene da il blog della sicurezza informatica.

Il 31 agosto 2025 il volo AAB53G, operato con un Dassault Falcon 900LX immatricolato OO-GPE e con a bordo la presidente della Commissione Europea Ursula von der Leyen, è decollato da Varsavia ed è atterrato regolarmente all’aeroporto di Plovdiv (Bulgaria).

Il Financial Times, in un articolo di Henry Foy, ha parlato di un presunto jamming GPS mirato che avrebbe “accecato” il velivolo, costringendo i piloti a un atterraggio manuale con mappe cartacee dopo un’ora di attesa. Una ricostruzione suggestiva, ma tecnicamente insostenibile.
FT.com

Condizioni meteo e pista: tutto regolare

A Plovdiv, il 31 agosto, le condizioni erano favorevoli: temperature tra 12 °C e 28 °C, venti moderati da Ovest-Nordovest e visibilità superiore a 10 km. I METAR confermano:

LBPD 311400Z AUTO 28006KT 240V010 9999 FEW059/// 28/13 Q1009 NOSIG
LBPD 311430Z AUTO 30016KT 9999 FEW059/// BKN110/// 26/12 Q1009 NOSIG

Nessun fenomeno meteo rilevante, nessuna variazione significativa (NOSIG).
La pista 30 dispone inoltre di ILS CAT I, operativo e non segnalato come indisponibile.

Strumentazione di bordo e ausili a terra: il GPS è solo un supporto

Il Dassault Falcon 900LX, con avionica EASy II Flight Deck basata sul Honeywell Primus Epic System, dispone di numerosi sistemi avanzati per l’assistenza alla navigazione, approccio ed atterraggio, per garantire sicurezza e precisione… tra cui:

• IRS (Inertial Reference System): navigazione indipendente da segnali esterni.
• VOR/ILS Receiver: consente la navigazione basata su radioaiuti tradizionali e avvicinamenti strumentali.
• ILS (Instrument Landing System): per atterraggi di precisione in condizioni strumentali, operativo sulla pista 30.
• DME (Distance Measuring Equipment): misura la distanza dalla stazione radio, utile per avvicinamenti e gestione della rotta.
• FMS (Flight Management System): gestisce rotte, prestazioni e ottimizzazione dei voli.
• ADF (Automatic Direction Finder): ricezione segnali NDB per navigazione complementare.
• Autothrottle e Autopilot integrati: ottimizzano velocità e traiettoria, supportando fasi critiche come avvicinamento e atterraggio.
• RNP/AR (Required Navigation Performance/Authorization Required): consente procedure di precisione con margini ridotti, utile in aeroporti complessi o in condizioni di visibilità ridotta.
• GPS: supporto alla navigazione, non fondamentale per il funzionamento del sistema.

Questi sistemi lavorano in sinergia, assicurando che il velivolo possa operare con elevata affidabilità in scenari complessi, riducendo al minimo i rischi legati a condizioni meteorologiche avverse o interferenze esterne.
Dassault Falcon 900LX – Flight Deck

La pista dell’aeroporto di Plovdiv fornisce inoltre un set completo di ausili alla navigazione, tutti attivi:

• ILS CAT I sulla pista 30
  
  • Localizer (IPD) 109,9 MHz
  • Glideslope 333,8 MHz (3°)
  • Marker MM/OM 75 MHz

  
  

• DME PDV (ch. 96x) co-locato con DVOR 114,9 MHz
• Locator Middle PD 537 KHz

Questi sistemi, operativi e senza NOTAM di indisponibilità, garantivano un avvicinamento sicuro anche in caso di disturbo GPS. Quanto alle “mappe cartacee” citate dal FT: oggi i piloti utilizzano EFB (Electronic Flight Bag) e chart digitali su tablet o avionica integrata. Parlare di carte fisiche analogiche è pura drammatizzazione.

Quota e traiettoria: niente “ora di attesa”

Dati ADS-B e FlightAware mostrano che il Falcon 900LX si è presentato al primo avvicinamento a circa 2000 m sopra il livello della pista, circa 1700 m più alto del normale sentiero ILS seguito con l’avvicinamento definitivo.
Invece di tentare un atterraggio impossibile, l’aereo ha proseguito in sorvolo, effettuando un passaggio di circa 4 minuti (14:18-14:22 UTC) sorvolando l’area dell’aeroporto. Successivamente si è riallineato sulla stessa rotta 11 minuti dopo, ma alla quota corretta completando l’atterraggio alle 14:35 UTC.
Il presunto “giro di un’ora” citato dal FT è smentito dai dati oggettivi: il ritardo complessivo non ha superato i 15 minuti, del tutto compatibile con un sorvolo pianificato o una procedura operativa standard.
fonte: FlightAware

Jamming GPS: fenomeno diffuso, non mirato

Nella regione del Mar Nero si registrano da tempo disturbi ciclici del segnale GPS, con picchi a orari e giorni variabili, proprio a causa dello scenario geopolitico della zona, noto a tutti. Anche altri traffici aerei hanno riportato anomalie simili, indipendentemente dal tipo di velivolo o dalla natura del volo, civile, VIP o militare.

Distinguere un disturbo diffuso da un attacco mirato richiede apparecchiature elettroniche avanzate, tipiche di assetti militari di guerra elettronica, di cui un Falcon civile normalmente non dispone, né di cui vi sia evidenza o comunicazione.

Gli assetti EW presenti nella zona, soprattutto se in volo nelle vicinanze, avrebbero potuto identificare con precisione l’evento e la sua fonte o fonti. Tuttavia, comunicare l’evidenza di un attacco mirato, di matrice russa o di qualsiasi altro attore, senza prove tecniche concrete, localizzabili e correlabili, risulta estremamente problematico, e ancora meno fattibile per un giornalista.
STARKOM – Esempio di sistemi d’arma per guerra elettronica

I dati reali contro la narrativa della notizia virale

• Nessun ritardo di un’ora: l’atterraggio sulla pista 30 sarebbe stato possibile già appena 15 minuti prima e non 60.
• Nessun atterraggio “al buio”: ILS e IRS erano disponibili e operativi, il meteo era eccellente.
• Nessuna mappa cartacea: oggi si usano EFB e chart digitali.
• Nessun blackout totale del tracciamento della posizione: i tracciati ADS-B sono continui e completi.
• Jamming GPS? Possibile fenomeno diffuso, ma nessuna prova di attacco mirato.

Le evidenze e le riflessioni

L’atterraggio del volo che trasportava Ursula von der Leyen da Varsavia a Plovdiv, dai dati pubblici consultabili da chiunque, si è svolto con ragionevole certezza in totale sicurezza, in condizioni meteorologiche ottimali e con ausili alla navigazione pienamente operativi.

L’articolo del Financial Times sembra aver ignorato totalmente i dati tecnici pubblicamente disponibili, ma trasforma un normale sorvolo operativo, in un’area di confine notoriamente complicata, in un presunto e deliberato atto ostile.
È un esempio di sensazionalismo che, nel campo della sicurezza aeronautica e cibernetica, rischia di minare la fiducia dei cittadini, dei passeggeri delle compagnie aeree ed alimentare ulteriormente le tensioni geopolitiche.

In questo caso, le supposizioni e i rumors possono essere smentiti dai dati pubblici, che parlano chiaro: nessuna emergenza in volo, nessun atto mirato di guerra elettronica e, al massimo, un effetto diffuso di interferenze elettroniche su quell’area geografica. Purtroppo, ancora una volta, la cronaca distorta annebbia la situazione, impedendo di far emergere lo scenario per quello che è realmente.

Un dettaglio che potrebbe sembrare pignolo, insignificante, banale, ma che in realtà non lo è affatto: rischia anzi di diventare il punto centrale per costruire un “fantoccio di carta” utile a giustificare, in modo strumentale, un presunto attacco a copertura di un ritardo anomalo per l’atterraggio. Per questo motivo è stato lasciato per in fondo, per i lettori più attenti ed interessati.

Il decollo da Varsavia era infatti programmato alle 11:01 UTC, ma è avvenuto solo alle 12:37 UTC, con un ritardo di circa un’ora e mezza. Di conseguenza, anche l’atterraggio a Plovdiv, schedulato per le 12:58 UTC, non poteva che subire lo stesso slittamento, avvenendo infatti alle 14:35 UTC.
In altre parole, il ritardo registrato all’arrivo è perfettamente coerente e prevedibile rispetto al ritardo accumulato in partenza.

E davvero sarebbe troppo malizioso ipotizzare che un normale ritardo operativo possa essere trasformato, comunicativamente e ad arte, nell’evidenza di un presunto attacco mirato, proprio a quel volo, e soprattutto a quella persona?

L'articolo Terrore nel volo di Ursula von der Leyen? Facciamo chiarezza! proviene da il blog della sicurezza informatica.

Alla fine di agosto 2025 è stata resa pubblica una vulnerabilità ad alto impatto che riguarda HikCentral Professional, la piattaforma di Hikvision usata per gestire in modo centralizzato videosorveglianza e controllo accessi. La falla, catalogata come CVE-2025-39247, ha un punteggio CVSS di 8.6 (High) e permette a un attaccante remoto di ottenere accesso amministrativo senza autenticazione. In altre parole: chiunque, via rete, può entrare nel cuore del sistema di gestione della sicurezza.

Perché è importante

Gli ambienti che adottano HikCentral spesso lo considerano parte della “sicurezza fisica”, ma in realtà è un software esposto come qualsiasi altro servizio IT. Questo lo rende un bersaglio interessante: se compromesso, può fornire accesso non solo alle telecamere, ma anche a dati sensibili, configurazioni e potenzialmente all’intera rete aziendale.

In uno scenario reale, un attaccante potrebbe:

• visualizzare e manipolare i flussi video;
• modificare impostazioni e utenti;
• sfruttare il server come punto di ingresso per movimenti laterali.

Dove sta il problema

La vulnerabilità è di tipoImproper Access Control (CWE-284). In pratica, alcuni endpoint web/API di HikCentral non gestiscono correttamente i controlli di accesso. Il risultato è che richieste inviate senza credenziali vengono comunque trattate come privilegiate, permettendo l’escalation diretta a livello amministrativo.

Questo rende l’attacco estremamente semplice: non serve conoscenza approfondita del sistema, non servono credenziali rubate, non è necessaria interazione da parte dell’utente. È sufficiente essere in grado di raggiungere la porta del servizio.

Versioni coinvolte e fix

Le versioni vulnerabili vanno dallaV2.3.1 alla V2.6.2, oltre allaV3.0.0. Hikvision ha già rilasciato aggiornamenti correttivi:

• V2.6.3
• V3.0.1

Chiunque utilizzi release precedenti dovrebbe aggiornare immediatamente.

Mitigazioni pratiche

Oltre all’aggiornamento, che resta la misura più efficace, ci sono alcune azioni di hardening consigliate:

• Segmentare la rete: isolare i server HikCentral in VLAN dedicate, accessibili solo da subnet fidate.
• Limitare l’accesso: filtrare via firewall gli indirizzi che possono connettersi al servizio.
• Implementare un WAF: utile per intercettare richieste anomale agli endpoint.
• Monitorare i log: attivare alert per tentativi di accesso sospetti o non autorizzati.
• Applicare il principio del minimo privilegio: ridurre al minimo i diritti degli account interni.

Checklist operativa rapida

Per facilitare il lavoro dei team IT e sicurezza, ecco i5 step essenziali per mitigare CVE-2025-39247:

1. Aggiornare subito aV2.6.3 o V3.0.1.
2. Controllare la rete: isolare i server HikCentral in segmenti dedicati.
3. Limitare gli accessi esterni tramite firewall e VPN.
4. Abilitare logging avanzato e monitoraggio per individuare attività anomale.
5. Verificare i privilegi degli account ed eliminare eventuali utenze superflue.

Conclusione

Il caso diCVE-2025-39247 dimostra quanto sia rischioso sottovalutare i sistemi di sicurezza fisica. Non sono “black box” isolate, ma applicazioni IT esposte che meritano lo stesso livello di protezione dei sistemi core. Un exploit come questo può trasformare un sistema nato per proteggere in una porta d’ingresso per attacchi molto più gravi.

La priorità è quindi chiara:aggiornare subito, e contestualmente rafforzare i controlli di rete e monitoraggio. Solo così si riduce al minimo la finestra di esposizione e si garantisce che un sistema progettato per difendere non diventi la causa della compromissione.

L'articolo Videosorveglianza sotto attacco: Un bug in Hikvision consente accesso admin senza login proviene da il blog della sicurezza informatica.

Ieri il sito di Red Hot Cyber è stato inaccessibile per circa un’ora. Ma cosa sta succedendo ci siamo chiesti? Dopo una serie di analisi ecco il riscontro: internet sta cambiando rapidamente sotto la pressione dell’intelligenza artificiale.

Se in precedenza i siti soffrivano dei classici robot di ricerca, oggi una quota crescente di traffico è generata da nuovi scanner aggressivi che operano nell’interesse di grandi modelli linguistici. Secondo Cloudflare, quasi un terzo di tutto il traffico web globale proviene da bot, e tra questi i crawler AI sono quelli in più rapida crescita. Le analisi di Fastly specificano che l’80% di tale traffico è generato da programmi creati per la raccolta di massa dei dati necessari per l’addestramento dell’IA.

Formalmente, la storia degli scanner automatici è iniziata nel 1993, con la comparsa di Web Wanderer, che registrava le nuove pagine web. Ma gli esperti sottolineano: la differenza tra quei primi strumenti e i sistemi odierni è enorme. Gli algoritmi moderni non si limitano a indicizzare le pagine, ma sovraccaricano l’infrastruttura, creando costi elevati per i proprietari dei siti. Fastly registra numerosi casi in cui improvvisi picchi di richieste da parte di bot di intelligenza artificiale hanno aumentato il carico sui server di dieci, e talvolta venti volte, nel giro di pochi minuti, con conseguenti inevitabili cali di produttività e interruzioni del servizio.

I provider di hosting sottolineano che tali crawler non tengono quasi mai conto delle limitazioni relative alla frequenza di scansione e alle regole di risparmio del traffico. Scaricano il testo completo delle pagine, seguono link dinamici e script eseguibili, ignorando completamente le impostazioni dei proprietari delle risorse. Di conseguenza, anche i siti non direttamente presi di mira ne risentono indirettamente: se diversi progetti condividono un server e un canale di comunicazione comune, un attacco ai siti vicini ne compromette istantaneamente la velocità.

Per i siti di piccole dimensioni, ciò si traduce in una completa inaccessibilità. I proprietari di risorse notano che i consueti meccanismi di protezione DDoS offerti da Cloudflare e da altre società di rete affrontano efficacemente ondate di attacchi distribuiti, ma sono inutili contro l’assalto dei bot AI. Di fatto, stiamo parlando delle stesse conseguenze distruttive, sebbene formalmente il traffico non sia classificato come dannoso.

La situazione è difficile anche per i principali operatori. Per resistere a tali flussi, è necessario aumentare la quantità di RAM, le risorse del processore e la larghezza di banda della rete. In caso contrario, la velocità di caricamento delle pagine diminuisce, il che si traduce in un aumento del bounce rate. Le ricerche di hosting dimostrano che se un sito rimane aperto per più di tre secondi, più della metà dei visitatori chiude la scheda. Ogni secondo in più non fa che peggiorare il problema e l’azienda perde il suo pubblico.

Anche le più grandi aziende di intelligenza artificiale sono comparse nelle statistiche. Meta rappresenta il volume maggiore di traffico di ricerca , circa il 52%. Google ne rappresenta il 23% e OpenAI un altro 20%. I loro sistemi sono in grado di generare picchi fino a 30 terabit al secondo, il che causa guasti anche per le organizzazioni con un’infrastruttura potente. Allo stesso tempo, i proprietari di siti web non guadagnano nulla da tale interesse: se in precedenza una visita del robot di ricerca Googlebot offriva la possibilità di arrivare alla prima pagina dei risultati di ricerca e attrarre lettori o clienti, ora i crawler di intelligenza artificiale non riportano gli utenti alle fonti originali. I contenuti vengono utilizzati per addestrare i modelli e il traffico non genera profitto.

I tentativi di proteggersi con metodi classici – password, accesso a pagamento, CAPTCHA e filtri specializzati – raramente danno risultati. L’intelligenza artificiale riesce a superare queste barriere abbastanza bene. Anche il vecchio meccanismo robots.txt, che per decenni è stato utilizzato come metodo standard per indicare le regole di indicizzazione, perde il suo significato: molti bot semplicemente lo ignorano. Cloudflare ha quindi accusato Perplexity di aver aggirato queste impostazioni, e Perplexity, a sua volta, ha negato tutto. Ma i proprietari di siti web registrano regolarmente ondate di richieste automatiche da vari servizi, il che conferma l’impotenza degli strumenti esistenti.

Esistono iniziative per integrare robots.txt con un nuovo formato, llms.txt. Dovrebbe consentire ai modelli linguistici di trasmettere contenuti appositamente preparati senza compromettere il funzionamento del sito. Tuttavia, l’idea è percepita in modo ambiguo e non è chiaro se diventerà uno standard. Parallelamente, aziende di infrastrutture come Cloudflare stanno lanciando i propri servizi per bloccare i bot AI. Esistono anche soluzioni indipendenti come Anubis AI Crawler Blocker, un progetto aperto e gratuito che non impedisce la scansione, ma la rallenta a tal punto da non essere più distruttiva.

Si sta quindi delineando una nuova corsa agli armamenti su Internet. Da una parte ci sono i proprietari di siti web che vogliono mantenere le proprie risorse accessibili e redditizie. Dall’altra ci sono gli sviluppatori di intelligenza artificiale che sfruttano il flusso infinito di dati come carburante. Un equilibrio verrà probabilmente trovato nel tempo, ma il prezzo sarà alto: la rete diventerà più chiusa, le informazioni saranno frammentate e molti materiali finiranno dietro le quinte dei servizi a pagamento o scompariranno del tutto dall’accesso libero. I ricordi di un’Internet libera stanno gradualmente diventando storia e la prospettiva di una rete frammentata sta diventando sempre più concreta.

L'articolo Quasi un terzo del traffico web è generato da bot! L’era dell’AI invasiva è ora proviene da il blog della sicurezza informatica.

Di recente, un sottogruppo avanzato legato al noto autore della minaccia Lazarus è stato individuato, mentre distribuiva tre diversi trojan di accesso remoto (RAT) all’interno di organizzazioni operanti nel settore finanziario e delle criptovalute che erano state compromesse. L’accesso iniziale è stato realizzato prevalentemente attraverso campagne di ingegneria sociale condotte su Telegram, dove gli attaccanti fingevano di essere dipendenti legittimi di importanti società commerciali.

Siti web di incontri contraffatti, tra cui falsi portali come Calendly e Picktime, attirano le vittime, che vengono raggiunte tramite un exploit zero-day di Chrome che consente l’esecuzione silenziosa di codice sul loro computer. Gli aggressori, una volta dentro la rete, impiegano PondRAT come prima fase, mentre in seguito utilizzano ThemeForestRAT, più difficile da rilevare, che viene eseguito solo in memoria.
Catena di attacco di lazarus (Fonte Fox-it)
L’uso di nuove famiglie di malware e di sospetti exploit zero-day ha colto di sorpresa molti difensori. A rendere il tutto ancora più urgente, la raffinata sicurezza operativa del gruppo che dimostra la capacità di combinare loader personalizzati con il dirottamento di DLL di Windows e la crittografia DPAPI.

A seguito di mesi di esplorazione e movimenti strategici, Lazarus ottimizza l’accesso precedente eliminando gli artefatti superflui, e procede con l’installazione di un avanzato RemotePE RAT al fine di assicurare un controllo prolungato.

Di seguito i 3 RAT (Remote Access Trojan) utilizzati nella campagna:

• ThemeForestRAT
• PondRAT
• RemotePE

Gli analisti di Fox-IT e NCC Group hanno osservato che la velocità e la precisione di questa catena di infezioni evidenziano le capacità avanzate dell’autore e la sua profonda familiarità con gli strumenti personalizzati e disponibili al pubblico.

E’ stato notato dagli analisti che il servizio SessionEnv viene sfruttato da PerfhLoader attraverso il caricamento di DLL fasulle al fine di eseguire in modo continuativo PondRAT oppure il suo predecessore POOLRAT. Un file di payload non trasparente (come ad esempio perfh011.dat) viene decodificato dal loader utilizzando un algoritmo di cifratura XOR prima di essere eseguito nella memoria.

Dopo la decrittazione, PerfhLoader sfrutta un caricatore DLL manuale open source per iniettare PondRAT nella memoria senza scrivere file eseguibili sul disco, consentendo operazioni di ricognizione furtiva e di esfiltrazione dei dati..

L'articolo Lazarus APT: 3 RAT avanzati per organizzazioni finanziarie di criptovalute proviene da il blog della sicurezza informatica.

L’Agenzia per la Cybersicurezza Nazionale ti apre le porte

Martedì 16 settembre 2025
Casa delle Tecnologie Emergenti (CTE), Stazione Tiburtina – Roma

ore 9:30–18:30

L’Agenzia per la Cybersicurezza Nazionale (ACN) partecipa alla Rome Future Week con un’intera giornata dedicata alla cultura della sicurezza digitale.

Talk, incontri, workshop e momenti di confronto ti porteranno dentro il mondo della cybersecurity: dai sistemi di difesa cyber più avanzati, al monitoraggio in tempo reale delle minacce, fino alle nuove professioni e ai percorsi formativi del settore.

Sarà anche un’occasione unica per incontrare chi lavora ogni giorno per proteggere le nostre infrastrutture digitali e scoprire come entrare in questo mondo.

Mattina
Focus Istituzionale ACN

9:30–10:15
La cybersicurezza: una sfida per il presente, una professione per il futuro. Parteciperanno i vertici dell’Agenzia per la Cybersicurezza Nazionale.

Apertura istituzionale ACN con overview su:

• Analisi di contesto
• dati aggiornati sul panorama delle minacce
• overview sul futuro delle professioni (Risorse umane)

10:15–11:00
Servizio Operazioni e gestione delle crisi cyber
“Il cuore operativo dell’ACN: rilevamento e gestione della minaccia cyber“. Relatori del Servizio.

11:00–11:15
Coffee break

11:15–12:00
Servizio Certificazione e Vigilanza
Presentazione del Centro di Valutazione e Certificazione Nazionale (CVCN): analisi delle vulnerabilità nei sistemi ICT. Focus su casi e metodologie. Relatori del Servizio

12:00–13:15
Servizio Programmi Industriali tecnologici e di Ricerca
“Il futuro della cybersicurezza: progetti nazionali ed europei”
Relatori del Servizio

Pomeriggio
Open Day & incontri pubblici

Servizio Certificazione e Vigilanza

15:00–16:00
Dimostrazione pratica di PT ( Penetration test )

Divisioni Formazione e Consapevolezza

16:00-16:30
L’ACN e il mondo degli ITS Academy

16:30-17:30
Capture the flag in collaborazione con ITS Academy

17:30–18:00
Donne della Cybersecurity: esperienze a confronto (squadra cyber femminile delle scuole superiori – women4cyber)

18:15-19:15
Matching libero e networking
I partecipanti potranno avvicinare aziende e enti formativi, distribuire CV, fare domande, conoscere opportunità

Pubblico invitato:
Studenti delle scuole superiori, Studenti universitari, Giovani professionisti. Appassionati di tecnologia, Cittadini e cittadine curiosi/e, Aziende e startup, Enti di formazione

I lavori della giornata saranno moderati dal dott. Arturo Di Corinto

dicorinto.it/formazione/cybers…

Buongiorno a tutti,

Sono Erika, sto muovendo i primi passi nel fediverso -con non poche difficoltà-.

Sto cercando di capire dove io intenda collocarmi e ammetto di aver aperto un’infinità di profili su vari server, sicuramente sbagliando l’approccio.

Magari qualcuno può illustrarmi qualche possibilità per muovermi meglio nella rete.

Utilizzavo Instagram per educazione personale su temi come: trasfemminismo, politica nazionale ed internazionale, informazione indipendente, scienza ed altro. Avevo un podcast di lettura ad alta voce di fiabe della tradizione con musiche originali, sto cercando un luogo dove rilocarlo dopo aver lasciato spotify. Cucio robe e tento di farne un lavoro.
Erika

When you visit almost any website, you’ll see a pop-up asking you to accept, decline, or customize the cookies it collects. Sometimes, it just tells you that cookies are in use by default. We randomly checked 647 websites, and 563 of them displayed cookie notifications. Most of the time, users don’t even pause to think about what’s really behind the banner asking them to accept or decline cookies.

We owe cookie warnings to the adoption of new laws and regulations, such as GDPR, that govern the collection of user information and protection of personal data. By adjusting your cookie settings, you can minimize the amount of information collected about your online activity. For example, you can decline to collect and store third-party cookies. These often aren’t necessary for a website to function and are mainly used for marketing and analytics. This article explains what cookies are, the different types, how they work, and why websites need to warn you about them. We’ll also dive into sensitive cookies that hold the Session ID, the types of attacks that target them, and ways for both developers and users to protect themselves.

What are browser cookies?

Cookies are text files with bits of data that a web server sends to your browser when you visit a website. The browser saves this data on your device and sends it back to the server with every future request you make to that site. This is how the website identifies you and makes your experience smoother.

Let’s take a closer look at what kind of data can end up in a cookie.

First, there’s information about your actions on the site and session parameters: clicks, pages you’ve visited, how long you were on the site, your language, region, items you’ve added to your shopping cart, profile settings (like a theme), and more. This also includes data about your device: the model, operating system, and browser type.

Your sign-in credentials and security tokens are also collected to identify you and make it easier for you to sign in. Although it’s not recommended to store this kind of information in cookies, it can happen, for example, when you check the “Remember me” box. Security tokens can become vulnerable if they are placed in cookies that are accessible to JS scripts.

Another important type of information stored in cookies that can be dangerous if it falls into the wrong hands is the Session ID: a unique code assigned to you when you visit a website. This is the main target of session hijacking attacks because it allows an attacker to impersonate the user. We’ll talk more about this type of attack later. It’s worth noting that a Session ID can be stored in cookies, or it can even be written directly into the URL of the page if the user has disabled cookies.

Example of a Session ID as displayed in the Firefox browser’s developer panel

Example of a Session ID as seen in a URL address: example.org/?account.php?osCsid=dawnodpasb<...>abdisoa.

Besides the information mentioned above, cookies can also hold some of your primary personal data, such as your phone number, address, or even bank card details. They can also inadvertently store confidential company information that you’ve entered on a website, including client details, project information, and internal documents.

Many of these data types are considered sensitive. This means if they are exposed to the wrong people, they could harm you or your organization. While things like your device type and what pages you visited aren’t typically considered confidential, they still create a detailed profile of you. This information could be used by attackers for phishing scams or even blackmail.

Main types of cookies

Cookies by storage time

Cookies are generally classified based on how long they are stored. They come in two main varieties: temporary and persistent.

Temporary, or session cookies, are used during a visit to a website and deleted as soon as you leave. They save you from having to sign in every time you navigate to a new page on the same site or to re-select your language and region settings. During a single session, these values are stored in a cookie because they ensure uninterrupted access to your account and proper functioning of the site’s features for registered users. Additionally, temporary cookies include things like entries in order forms and pages you visited. This information can end up in persistent cookies if you select options like “Remember my choice” or “Save settings”. It’s important to note that session cookies won’t get deleted if you have your browser set to automatically restore your previous session (load previously opened tabs). In this case, the system considers all your activity on that site as one session.

Persistent cookies, unlike temporary ones, stick around even after you leave the site. The website owner sets an expiration date for them, typically up to a year. You can, however, delete them at any time by clearing your browser’s cookies. These cookies are often used to store sign-in credentials, phone numbers, addresses, or payment details. They’re also used for advertising to determine your preferences. Sensitive persistent cookies often have a special attribute HttpOnly. This prevents your browser from accessing their contents, so the data is sent directly to the server every time you visit the site.

Notably, depending on your actions on the website, credentials may be stored in either temporary or persistent cookies. For example, when you simply navigate a site, your username and password might be stored in session cookies. But if you check the “Remember me” box, those same details will be saved in persistent cookies instead.

Cookies by source

Based on the source, cookies are either first-party or third-party. The former are created and stored by the website, and the latter, by other websites. Let’s take a closer look at these cookie types.

First-party cookies are generally used to make the site function properly and to identify you as a user. However, they can also perform an analytics or marketing function. When this is the case, they are often considered optional – more on this later – unless their purpose is to track your behavior during a specific session.

Third-party cookies are created by websites that the one you’re visiting is talking to. The most common use for these is advertising banners. For example, a company that places a banner ad on the site can use a third-party cookie to track your behavior: how many times you click on the ad and so on. These cookies are also used by analytics services like Google Analytics or Yandex Metrica.

Social media cookies are another type of cookies that fits into this category. These are set by widgets and buttons, such as “Share” or “Like”. They handle any interactions with social media platforms, so they might store your sign-in credentials and user settings to make those interactions faster.

Cookies by importance

Another way to categorize cookies is by dividing them into required and optional.

Required or essential cookies are necessary for the website’s basic functions or to provide the service you’ve specifically asked for. This includes temporary cookies that track your activity during a single visit. It also includes security cookies, such as identification cookies, which the website uses to recognize you and spot any fraudulent activity. Notably, cookies that store your consent to save cookies may also be considered essential if determined by the website owner, since they are necessary to ensure the resource complies with your chosen privacy settings.

The need to use essential cookies is primarily relevant for websites that have a complex structure and a variety of widgets. Think of an e-commerce site that needs a shopping cart and a payment system, or a photo app that has to save images to your device.

A key piece of data stored in required cookies is the above-mentioned Session ID, which helps the site identify you. If you don’t allow this ID to be saved in a cookie, some websites will put it directly in the page’s URL instead. This is a much riskier practice because URLs aren’t encrypted. They’re also visible to analytics services, tracking tools, and even other users on the same network as you, which makes them vulnerable to cross-site scripting (XSS) attacks. This is a major reason why many sites won’t let you disable required cookies for your own security.

Example of required cookies on the Osano CMP website

Optional cookies are the ones that track your online behavior for marketing, analytics, and performance. This category includes third-party cookies created by social media platforms, as well as performance cookies that help the website run faster and balance the load across servers. For instance, these cookies can track broken links to improve a website’s overall speed and reliability.

Essentially, most optional cookies are third-party cookies that aren’t critical for the site to function. However, the category can also include some first-party cookies for things like site analytics or collecting information about your preferences to show you personalized content.

While these cookies generally don’t store your personal information in readable form, the data they collect can still be used by analytics tools to build a detailed profile of you with enough identifying information. For example, by analyzing which sites you visit, companies can make educated guesses about your age, health, location, and much more.

A major concern is that optional cookies can sometimes capture sensitive information from autofill forms, such as your name, home address, or even bank card details. This is exactly why many websites now give you the choice to accept or decline the collection of this data.

Special types of cookies

Let’s also highlight special subtypes of cookies managed with the help of two similar technologies that enable non-standard storage and retrieval methods.

A supercookie is a tracking technology that embeds cookies into website headers and stores them in non-standard locations, such as HTML5 local storage, browser plugin storage, or browser cache. Because they’re not in the usual spot, simply clearing your browser’s history and cookies won’t get rid of them.

Supercookies are used for personalizing ads and collecting analytical data about the user (for example, by internet service providers). From a privacy standpoint, supercookies are a major concern. They’re a persistent and hard-to-control tracking mechanism that can monitor your activity without your consent, which makes it tough to opt out.

Another unusual tracking method is Evercookie, a type of zombie cookie. Evercookies can be recovered with JavaScript even after being deleted. The recovery process relies on the unique user identifier (if available), as well as traces of cookies stored across all possible browser storage locations.

How cookie use is regulated

The collection and management of cookies are governed by different laws around the world. Let’s review the key standards from global practices.

1. General Data Protection Regulation (GDPR) and ePrivacy Directive (Cookie Law) in the European Union.
   Under EU law, essential cookies don’t require user consent. This has created a loophole for some websites. You might click “Reject All”, but that button might only refuse non-essential cookies, allowing others to still be collected.
2. Lei Geral de Proteção de Dados Pessoais (LGPD) in Brazil.
   This law regulates the collection, processing, and storage of user data within Brazil. It is largely inspired by the principles of GDPR and, similarly, requires free, unequivocal, and clear consent from users for the use of their personal data. However, LGPD classifies a broader range of information as personal data, including biometric and genetic data. It is important to note that compliance with GDPR does not automatically mean compliance with LGPD, and vice versa.
3. California Consumer Privacy Act (CCPA) in the United States.
   The CCPA considers cookies a form of personal information. This means their collection and storage must follow certain rules. For example, any California resident has the right to stop cross-site cookie tracking to prevent their personal data from being sold. Service providers are required to give users choices about what data is collected and how it’s used.
4. The UK’s Privacy and Electronic Communications Regulations (PECR, or EC Directive) are similar to the Cookie Law.
   PECR states that websites and apps can only save information on a user’s device in two situations: when it’s absolutely necessary for the site to work or provide a service, or when the user has given their explicit consent to this.
5. Federal Law No. 152-FZ “On Personal Data” in Russia.
   The law broadly defines personal data as any information that directly or indirectly relates to an individual. Since cookies can fall under this definition, they can be regulated by this law. This means websites must get explicit consent from users to process their data.

In Russia, website owners must inform users about the use of technical cookies, but they don’t need to get consent to collect this information. For all other types of cookies, user consent is required. Often, the user gives this consent automatically when they first visit the site, as it’s stated in the default cookie warning.

Some sites use a banner or a pop-up window to ask for consent, and some even let users choose exactly which cookies they’re willing to store on their device.

Beyond these laws, website owners create their own rules for using first-party cookies. Similarly, third-party cookies are managed by the owners of third-party services, such as Google Analytics. These parties decide what kind of information goes into the cookies and how it’s formatted. They also determine the cookies’ lifespan and security settings. To understand why these settings are so important, let’s look at a few ways malicious actors can attack one of the most critical types of cookies: those that contain a Session ID.

Session hijacking methods

As discussed above, cookies containing a Session ID are extremely sensitive. They are a prime target for cybercriminals. In real-world attacks, different methods for stealing a Session ID have been documented. This is a practice known as session hijacking. Below, we’ll look at a few types of session hijacking.

Session sniffing

One method for stealing cookies with a Session ID is session sniffing, which involves intercepting traffic between the user and the website. This threat is a concern for websites that use the open HTTP protocol instead of HTTPS, which encrypts traffic. With HTTP, cookies are transmitted in plain text within the headers of HTTP requests, which makes them vulnerable to interception.

Attacks targeting unencrypted HTTP traffic mostly happen on public Wi-Fi networks, especially those without a password and strong security protocols like WPA2 or WPA3. These protocols use AES encryption to protect traffic on Wi-Fi networks, with WPA3 currently being the most secure version. While WPA2/WPA3 protection limits the ability to intercept HTTP traffic, only implementing HTTPS can truly protect against session sniffing.

This method of stealing Session ID cookies is fairly rare today, as most websites now use HTTPS encryption. The popularity of this type of attack, however, was a major reason for the mass shift to using HTTPS for all connections during a user’s session, known as HTTPS everywhere.

Cross-site scripting (XSS)

Cross-site scripting (XSS) exploits vulnerabilities in a website’s code to inject a malicious script, often written in JavaScript, onto its webpages. This script then runs whenever a victim visits the site. Here’s how an XSS attack works: an attacker finds a vulnerability in the source code of the target website that allows them to inject a malicious script. For example, the script might be hidden in a URL parameter or a comment on the page. When the user opens the infected page, the script executes in their browser and gains access to the site’s data, including the cookies that contain the Session ID.

Session fixation

In a session fixation attack, the attacker tricks your browser into using a pre-determined Session ID. Thus, the attacker prepares the ground for intercepting session data after the victim visits the website and performs authentication.

Here’s how it goes down. The attacker visits a website and gets a valid, but unauthenticated, Session ID from the server. They then trick you into using that specific Session ID. A common way to do this is by sending you a link with the Session ID already embedded in the URL, like this: http://example.com/?SESSIONID=ATTACKER_ID. When you click the link and sign in, the website links the attacker’s Session ID to your authenticated session. The attacker can then use the hijacked Session ID to take over your account.

Modern, well-configured websites are much less vulnerable to session fixation than XSS-like attacks because most current web frameworks automatically change the user’s Session ID after they sign in. However, the very existence of this Session ID exploitation attack highlights how crucial it is for websites to securely manage the entire lifecycle of the user session, especially at the moment of sign-in.

Cross-site request forgery (CSRF)

Unlike session fixation or sniffing attacks, cross-site request forgery (CSRF or XSRF) leverages the website’s trust in your browser. The attacker forces your browser, without your knowledge, to perform an unwanted action on a website where you’re signed in – like changing your password or deleting data.

For this type of attack, the attacker creates a malicious webpage or an email message with a harmful link, piece of HTML code, or script. This code contains a request to a vulnerable website. You open the page or email message, and your browser automatically sends the hidden request to the target site. The request includes the malicious action and all the necessary (for example, temporary) cookies for that site. Because the website sees the valid cookies, it treats the request as a legitimate one and executes it.

Variants of the man-in-the-middle (MitM) attack

A man-in-the-middle (MitM) attack is when a cybercriminal not only snoops on but also redirects all the victim’s traffic through their own systems, thus gaining the ability to both read and alter the data being transmitted. Examples of these attacks include DNS spoofing or the creation of fake Wi-Fi hotspots that look legitimate. In an MitM attack, the attacker becomes the middleman between you and the website, which gives them the ability to intercept data, such as cookies containing the Session ID.

Websites using the older HTTP protocol are especially vulnerable to MitM attacks. However, sites using the more secure HTTPS protocol are not entirely safe either. Malicious actors can try to trick your browser with a fake SSL/TLS certificate. Your browser is designed to warn you about suspicious invalid certificates, but if you ignore that warning, the attacker can decrypt your traffic. Cybercriminals can also use a technique called SSL stripping to force your connection to switch from HTTPS to HTTP.

Predictable Session IDs

Cybercriminals don’t always have to steal your Session ID – sometimes they can just guess it. They can figure out your Session ID if it’s created according to a predictable pattern with weak, non-cryptographic characters. For example, a Session ID may contain your IP address or consecutive numbers, and a weak algorithm that uses easily predictable random sequences may be used to generate it.

To carry out this type of attack, the malicious actor will collect a sufficient number of Session ID examples. They analyze the pattern to figure out the algorithm used to create the IDs, then apply that knowledge to predicting your current or next Session ID.

Cookie tossing

This attack method exploits the browser’s handling of cookies set by subdomains of a single domain. If a malicious actor takes control of a subdomain, they can try to manipulate higher-level cookies, in particular the Session ID. For example, if a cookie is set for sub.domain.com with the Domain attribute set to .domain.com, that cookie will also be valid for the entire domain.

This lets the attacker “toss” their own malicious cookies with the same names as the main domain’s cookies, such as Session_id. When your browser sends a request to the main server, it includes all the relevant cookies it has. The server might mistakenly process the hacker’s Session ID, giving them access to your user session. This can work even if you never visited the compromised subdomain yourself. In some cases, sending invalid cookies can also cause errors on the server.

How to protect yourself and your users

The primary responsibility for cookie security rests with website developers. Modern ready-made web frameworks generally provide built-in defenses, but every developer should understand the specifics of cookie configuration and the risks of a careless approach. To counter the threats we’ve discussed, here are some key recommendations.

Recommendations for web developers

All traffic between the client and server must be encrypted at the network connection and data exchange level. We strongly recommend using HTTPS and enforcing automatic redirect from HTTP to HTTPS. For an extra layer of protection, developers should use the HTTP Strict Transport Security (HSTS) header, which forces the browser to always use HTTPS. This makes it much harder, and sometimes impossible, for attackers to slip into your traffic to perform session sniffing, MitM, or cookie tossing attacks.

It must be mentioned that the use of HTTPS is insufficient protection against XSS attacks. HTTPS encrypts data during transmission, while an XSS script executes directly in the user’s browser within the HTTPS session. So, it’s up to the website owner to implement protection against XSS attacks. To stop malicious scripts from getting in, developers need to follow secure coding practices:

• Validate and sanitize user input data.
• Implement mandatory data encoding (escaping) when rendering content on the page – this way, the browser will not interpret malicious code as part of the page and will not execute it.
• Use the HttpOnly flag to protect cookie files from being accessed by the browser.
• Use the Content Security Policy (CSP) standard to control code sources. It allows monitoring which scripts and other content sources are permitted to execute and load on the website.

For attacks like session fixation, a key defense is to force the server to generate a new Session ID right after the user successfully signs in. The website developer must invalidate the old, potentially compromised Session ID and create a new one that the attacker doesn’t know.

An extra layer of protection involves checking cookie attributes. To ensure protection, it is necessary to check for the presence of specific flags (and set them if they are missing): Secure and HttpOnly. The Secure flag ensures that cookies are transmitted over an HTTPS connection, while HttpOnly prevents access to them from the browser, for example through scripts, helping protect sensitive data from malicious code. Having these attributes can help protect against session sniffing, MitM, cookie tossing, and XSS.

Pay attention to another security attribute, SameSite, which can restrict cookie transmission. Set it to Lax or Strict for all cookies to ensure they are sent only to trusted web addresses during cross-site requests and to protect against CSRF attacks. Another common strategy against CSRF attacks is to use a unique, randomly generated CSRF token for each user session. This token is sent to the user’s browser and must be included in every HTTP request that performs an action on your site. The site then checks to make sure the token is present and correct. If it’s missing or doesn’t match the expected value, the request is rejected as a potential threat. This is important because if the Session ID is compromised, the attacker may attempt to replace the CSRF token.

To protect against an attack where a cybercriminal tries to guess the user’s Session ID, you need to make sure these IDs are truly random and impossible to predict. We recommend using a cryptographically secure random number generator that utilizes powerful algorithms to create hard-to-predict IDs. Additional protection for the Session ID can be ensured by forcing its regeneration after the user authenticates on the web resource.

The most effective way to prevent a cookie tossing attack is to use cookies with the __Host- prefix. These cookies can only be set on the same domain that the request originates from and cannot have a Domain attribute specified. This guarantees that a cookie set by the main domain can’t be overwritten by a subdomain.

Finally, it’s crucial to perform regular security checks on all your subdomains. This includes monitoring for inactive or outdated DNS records that could be hijacked by an attacker. We also recommend ensuring that any user-generated content is securely isolated on its own subdomain. User-generated data must be stored and managed in a way that prevents it from compromising the security of the main domain.

As mentioned above, if cookies are disabled, the Session ID can sometimes get exposed in the website URL. To prevent this, website developers must embed this ID into essential cookies that cannot be declined.

Many modern web development frameworks have built-in security features that can stop most of the attack types described above. These features make managing cookies much safer and easier for developers. Some of the best practices include regular rotation of the Session ID after the user signs in, use of the Secure and HttpOnly flags, limiting the session lifetime, binding it to the client’s IP address, User-Agent string, and other parameters, as well as generating unique CSRF tokens.

There are other ways to store user data that are both more secure and better for performance than cookies.

Depending on the website’s needs, developers can use different tools, like the Web Storage API (which includes localStorage and sessionStorage), IndexedDB, and other options. When using an API, data isn’t sent to the server with every single request, which saves resources and makes the website perform better.

Another exciting alternative is the server-side approach. With this method, only the Session ID is stored on the client side, while all the other data stays on the server. This is even more secure than storing data with the help of APIs because private information is never exposed on the client side.

Tips for users

Staying vigilant and attentive is a big part of protecting yourself from cookie hijacking and other malicious manipulations.

Always make sure the website you are visiting is using HTTPS. You can check this by looking at the beginning of the website address in the browser address bar. Some browsers let the user view additional website security details. For example, in Google Chrome, you can click the icon right before the address.

This will show you if the “Connection is secure” and the “Certificate is valid”. If these details are missing or data is being sent over HTTP, we recommend maximum caution when visiting the website and, whenever possible, avoiding entering any personal information, as the site does not meet basic security standards.

When browsing the web, always pay attention to any security warnings your browser gives you, especially about suspicious or invalid certificates. Seeing one of these warnings might be a sign of an MitM attack. If you see a security warning, it’s best to stop what you’re doing and leave that website right away. Many browsers implement certificate verification and other security features, so it is important to install browser updates promptly – this replaces outdated and compromised certificates.

We also recommend regularly clearing your browser data (cookies and cache). This can help get rid of outdated or potentially compromised Session IDs.

Always use two-factor authentication wherever it’s available. This makes it much harder for a malicious actor to access your account, even if your Session ID is exposed.

When a site asks for your consent to use cookies, the safest option is to refuse all non-essential ones, but we’ll reiterate that sometimes, clicking “Reject cookies” only means declining the optional ones. If this option is unavailable, we recommend reviewing the settings to only accept the strictly necessary cookies. Some websites offer this directly in the pop-up cookie consent notification, while others provide it in advanced settings.

The universal recommendation to avoid clicking suspicious links is especially relevant in the context of preventing Session ID theft. As mentioned above, suspicious links can be used in what’s known as session fixation attacks. Carefully check the URL: if it contains parameters you do not understand, we recommend copying the link into the address bar manually and removing the parameters before loading the page. Long strings of characters in the parameters of a legitimate URL may turn out to be an attacker’s Session ID. Deleting it renders the link safe. While you’re at it, always check the domain name to make sure you’re not falling for a phishing scam.

In addition, we advise extreme caution when connecting to public Wi-Fi networks. Man-in-the-middle attacks often happen through open networks or rogue Wi-Fi hotspots. If you need to use a public network, never do it without a virtual private network (VPN), which encrypts your data and makes it nearly impossible for anyone to snoop on your activity.

securelist.com/cookies-and-ses…

Over the years Intel has introduced a number of new computer form factors that either became a hit, fizzled out, or moved on to live a more quiet life. The New Unit of Computing (NUC) decidedly became a hit with so-called Mini PCs now everywhere, while the Intel Compute Stick has been largely forgotten. In a recent video by the [Action Retro] one such Compute Stick is poked at, specifically the last model released by Intel in the form of the 2016-era STK1AW32SC, featuring a quad-core Intel Atom x5-Z8330 SoC, 2 GB of RAM and 32 GB eMMC storage.

As the name suggests, this form factor is very stick-like, with a design that makes it easy to just plug it into the HDMI port of a display, making it a snap to add a computer to any TV or such without taking up a considerable amount of space. Although Intel didn’t make more of them after this model, it could be argued that devices like the Chromecast dongle follow the same general concept, and manufacturers like MeLe are still making new PCs in this form factor today.

In the video this 2016-era Compute Stick is put through its paces, wiping the Windows 10 installation that was still on it from the last time it was used, and an installation of Haiku was attempted which unfortunately failed to see the eMMC storage. Worse was the current Ubuntu, which saw its installer simply freeze up, but MX Linux saved the day, providing a very usable Linux desktop experience including the watching of YouTube content and network streaming of Steam games.

Although dissed as ‘e-waste’ by many today, if anything this video shows that these little sticks are still very capable computers in 2025.

youtube.com/embed/G3WvOzdlpwY?…

hackaday.com/2025/09/02/rememb…

While you can still find tape being used for backup storage, it’s pretty safe to say that the humble audio cassette is about as out of date as a media format can be. Still, it has a certain retro charm we’re suckers for, particularly in the shape of a Commodore Datasette. We’re also suckers for miniaturization, so how could we not fall for [bitluni] ‘s tiny datasette replica?

Aesthetically, he’s copying the Commodore original to get those sweet nostalgia juices flowing, but to make things more interesting he’s not using compact cassette tapes. Instead, [bitluni] started with a mini cassette dictaphone, which he tore down to its essentials and rebuilt into the Commodore-shaped case.

The prototyping of this project was full of hacks — like building a resistor ladder DAC in an unpopulated part of a spare PCB from an unrelated project. The DAC is of course key to getting data onto the mini-casettes. After some playing around [bitluni] decided that encoding data with FSK (frequency-shift keying), as was done back on the C-64, was the way to go. (Almost like those old engineers knew what they were doing!) The dictaphone tape transport is inferior to the old Datasette, though, so as a cheap error-correction hack, [bitluni] needed to duplicate each byte to make sure it gets read correctly.

The mini cassettes only fit a laughable amount of data by modern standards this way (about 1 MB) but, of course that’s not the point. If you jump to 11:33 in the video embedded below, you can see the point: the shout of triumph when loading PacMan (all 8 kB of it) from tape via USB. That transfer was via serial console; eventually [bitluni] intends to turn this into the world’s least-practical mass storage device, but that wasn’t necessary for proof-of-concept. The code for what’s shown is available on GitHub.

If you have an old Datasette you want to use with a modern PC, you’d better believe that we’ve got you covered. We’ve seen other cassette-mass-storage interfaces over the years, too. It might be a dead medium, but there’s just something about “sticky tape and rust” that lives on in our imaginations.

youtube.com/embed/GQwTPH67YqY?…

Thanks to [Stephen Walters] for the tip.

hackaday.com/2025/09/01/tiny-d…