What could happen when you open-source a hardware project?

No, seriously. I hold a fair few radical opinions – one is that projects should be open-source to the highest extent possible. I’ve seen this make miracles happen, make hackerdom stronger, and nourish our communities. I think we should be publishing all the projects, even if incomplete, as much as your opsec allows. I would make ritual sacrifices if they resulted in more KiCad projects getting published, and some days I even believe bullying people into open-sourcing their projects can be justified. My ideal universe is one where companies are unable to restrict schematics from people getting their hardware, no human should ever hold an electronics black box, by force if necessary.

Why such a strong bias? I’ve seen this world change for the better with each open-source project, and worse with closed-source ones, it’s pretty simple for me. Trust me here – let me tell you a story of how a couple reverse-engineering efforts and a series of open-source PCBs have grown a tree of an ecosystem.

A Chain Of Blackberry Hackers

A big part of this story has been dutifully documented by [Michael] on his BBKB community website – it’s a meticulous summary of devices in the BBKB ecosystem. You should click on it and check it out, it’s a labor of love, aimed at introducing newcomers to the Blackberry keyboard-adorned device ecosystem, with a degree of care for fellow hackers that’s worth appreciating. In this article, I am relying on [Michael]’s research and interviews, but also on my own experience and research of Blackberry keyboard device community.

As [Michael] has found out, it all started in 2015, with a reverse-engineered replacement part keyboard for a Blackberry Q10. [JoeN] on Eevblog forums reverse-engineered the pinout, then posted the pinout and code to Arduino forums – for sufficiently devoted hackers to create with. Three years later, [WooDWorkeR] on our own Hackaday.io picked up the work, reverse-engineered the backlight, and made an Arduino Nano proof-of-concept. Things heated up when Hackaday superfriend [arturo182] picked up the mantle in 2018 – starting off with a Q10 keyboard PMOD, then eventually reverse-engineering the touchpad-equipped Q20 keyboard, and as a culmination, building a standalone Q20 keyboard with a USB-C connection and a RP2040 controller.

If you’ve seen a few QWERTY handhelds, you’ve likely seen one that’s downstream of [arturo182]’s work. Recently, he’s been big on creating castellated stamps – his RP2350 stamps make for great prototyping devices, can heavily recommend. He’s got a hardware company thing going on, called SolderParty, with a good few innovative products like the FlexyPins I’ve covered before – I adore castellated modules, and I feel like he’s mastered the craft of doing them.

Also, have you seen the Tanmatsu, and in particular, its custom QWERTY keyboard? That keyboard is one of his design – as of recent, he’s got a side project of hacker-friendly keyboards going on, partly to replace the Q20s as they become more and more scarce on the new-old-stock market.

But back to the Blackberry: the Q20 keyboard really hit the news, going beyond the hacker world, if I were to guess, relying upon a fair bit of nostalgy for QWERTY handhelds. My personal belief is “the more screen, the less soul”, and when reading articles like the ones written about the Q20 keyboard, I can feel that in the air. I wasn’t the only one, for sure – looks like Eric Migicovsky, founder of Pebble, felt it too.

My favourite theory of Blackberry keyboard device popularity. By [masklayer]Seen the Playdate? It’s a handheld games console with a cult following, equipped with a widely beloved Sharp Memory LCD. It’s reasonably easy to buy, with a decent 2.7″ diagonal, and it’s got whole 400×240 worth of resolution – nothing to write home about, but it very much is enough for a Linux terminal, and it can be comfortably driven a Pi Zero’s SPI interface, what’s with the whole “1 bit per pixel” thing keeping it reasonably low-bandwidth. You’re picking up what I’m putting down so far?

Beep Beep (Watch Out For Trademarks)

A few prototypes later, the SQFMI group released the Beepberry project, later known as Beepy. It had the essentials of a pocket computer – a Pi Zero, a Sharp LCD, a Q20 keyboard, an RP2040 tying its all together, a 2000 mAh cell and onboard battery management, plus, a few extra niceties like a side button and an RGB LED for notifications. What else? An integration with the Beeper project, a platform putting all your messaging service under a single roof. All files fully published on GitHub, including the KiCad files for the PCB. A Discord server with open invites. Minimum amount of software support. A rubberband and two pieces of double-sided tape keeping the battery, screen, and keyboard attached to the board. I think that was it?

First batch was merely 50 pieces. The pricing did raise my eyebrow – $80 for a PCBA ($10), Pi Zero 2 W ($10-15), Sharp screen ($20), a Blackberry keyboard ($10), and a 2000mAh cell, for a BOM total of around $50-60, all put together and presumably tested? That sure flies in the face of all “multiply BOM by three” advice. Nevertheless, more and more people started receiving their Beepberries, sharing pictures online, coming together on the Discord and other social media, and playing around with their new cool hardware. It got a good few reviews, too, including a must-read review from our own [Tom Nardi]!

The project’s journey wasn’t seamless, of course, but the problems were few and far between. For instance, the Beepberry project became Beepy – because of Blackberry, legally speaking, raising an eyebrow at the naming decision; it’s the kind of legal situation we’ve seen happen with projects like Notkia. If you ever get such a letter, please don’t hold any hard feelings towards the company – after all, trademarks can legally be lost if the company doesn’t take action to defend them. From what I gather, BlackBerry’s demands were low, as it goes with such claims – the project was renamed to Beepy going forward, and that’s about it.

Unity Through Discord

People deride Discord servers as means of community building, and by now, I’ve heard it all. I get it. Sadly, these days, you’re going to either get on Discord, or be detached from a large chunk of the hacker community – and such a detachment is bad if you want to stay up to date with things. Dislike Discord as much as you want, and I can assure you that all the bad things about it are true, but that’s how the game is played. So, if you’re not on the Beepy Discord server and you like what Beepy stands for, you’re missing out – thankfully, there is a Matrix integration, too.

Beepy owners and fans alike joined the crowd. Each had something to contribute, with varying degrees of hardware and software competence, modulated by varying degrees of executive function, as it goes. Some people received their own Beepies, a few people got the KiCad project and ordered the files, and an unexpected amount of people breadboarded a Beepy! The barebones software support might’ve had deterred people, but at the same time, it became a community obstacle to overcome.

Starting from [arturo182]’s Linux driver work and someone else’s Linux drivers for the Sharp screen, a Linux experience started to grow. Initially, just the keyboard and touchpad were supported, but the support grew – both the RP2040 firmware and the Linux driver grew in functionality, changed names, picked up by one developer after another. Different people picked fonts to fit the screen’s low resolution, mapped extra keycodes to layers built upon the 40-something buttons of the Q20 keyboard and designed on-screen hints, worked on “sleep” modes (mostly implemented within the RP2040 by powering down the Pi Zero in particular), wrote like a dozen different helper scripts for the GPIO-exposed side button, and the apps, oh were there apps!

People Found Purposes

Beepy is no X server-carrying device, and you won’t be running even LXDE on the Pi Zero and the 400×240 mono screen. Under the sheets of a virtual terminal, however, there’s heaps to work with. Of course, Linux has plenty of commandline apps – most of them aimed at a 80×24 text screen resolution and not a character less, but many worked outright. SSH and email clients? Weather alert UIs? Beeper-compatible messengers? Music players? Games? ChatGPT interfaces? Pico8 and other game emulators? Doom? Of course people ran Doom. There were multiple attempts at lightweight GUIs with apps, too, not to foreshadow too much too early.

Beepy became a hacker’s pocket friend. Maybe not everything was great all the time. The hardware had its sometimes-board-killing flaws, the GPIOs were quite tricky to hack on because of their layout, and the hardware features were pretty barebones. Software achievements and releases were somewhat uncoordinated, too – Discord just isn’t great for discoverability; I can only tell you about all this because I went through two years worth of Discord server logs, and found a lot of cool stuff that people published only to be forgotten in the chat logs. If you ask me, this period of the community would’ve been turbocharged by a monthly Beepy newsletter, also published on on a blog so that outsiders could be linked to it, too.

The Beepy community has truly made Beepy grow into a veritable pocket device, pushing the limits of the Pi Zero, the screen, and the keyboard alike. By now, there’s assortments of software you can run, documentation websites, Debian repositories running on GitHub infrastructure, a few lightweight Buildroot-based distros, dozens of 3D printed cases, and never a shortage of people coming into the Discord server asking when Beepy will be available for sale again.

Just The Beep-ginning

It genuinely fascinates me how a chain of, spanning years, has come from “keyboard pinout” to “a mass-manufactured open-source board with a big community” – Q10 keyboard reverse-engineering on Eevblog forums led to wider adoption, which eventually led to Arturo’s Q20 board and its splash, and that in led to Beepy and its Discord server. Did it end here? Of course it didn’t – I did say ecosystems, plural. Next week, you’re getting a continuation article about the Beepy derivatives, because the story is just starting here.

Enough about open-source – next article, you will hear about the phenomenon of closed-open-source, clones of high and low effort alike, and a pretty cool open-source Beepy successor. (Spoilers: I’m biased because I’m involved.) But for a start, we’ll talk about a mis-used Texas Instruments boost regulator, a mis-calculated resistor, and a few overlooked datasheet parameters.

Lettera aperta a Nicola Ghittoni, conduttore e autore del podcast "Morning", una rassegna stampa del Post che va in onda dal lunedì al venerdì (il sabato c'è ma è condotta da un'altra persona).

Caro Nicola,

mi permetto di chiamarti "caro" e di darti del "tu" perché da qualche tempo ogni giorno facciamo insieme la strada per andare al lavoro, io al volante della mia auto e tu dal microfono di "Morning".

E mi permetto di pubblicare questa lettera sul mio profilo nel Fediverso (@max@poliverso.org), perché in realtà quello che sto scrivendo a te lo vorrei scrivere a tante altre persone.

E' la seconda volta questa settimana che scrivo a un conduttore di podcast del Post, qualche giorno fa avevo scritto a Francesco Costa su un tema simile.

Vorrei attirare la vostra attenzione sul rischio che diventiate, involontariamente, veicolo di stereotipi anti-sindacali. Mi riferisco alla battuta con cui oggi hai aperto il tuo podcast, "In Italia siamo abituati agli scioperi di venerdì".

Provo a spiegarmi per punti perché l'argomento è articolato.

Punto 1: davvero si sciopera così spesso di venerdì?
Da 15 anni sono iscritto alla FIOM e da un anno circa sono un delegato sindacale. Ti metto qua sotto qualche informazione sulle date in cui sono stati fatti gli ultimi scioperi nella mia azienda (ho solo le date relative agli scioperi proclamati nell'ultimo anno, da quando sono diventato delegato):

• venerdì 29 novembre 2024 Sciopero generale, 8h (manifestazione a FI)
• mercoledì 11 dicembre 2024 Esplosione deposito ENI di Calenzano, 4h
• mercoledì 18 dicembre 2024 Rinnovo contrattuale, 8h (manifestazione a PO)
• mercoledì 19 febbraio 2025 Rinnovo contrattuale, 3h (presidio davanti azienda)
• venerdì 21 febbraio 2025 Rinnovo contrattuale, 5h
• mercoledì 26 marzo 2025 Rinnovo contrattuale, 8h (manifestazione a FI)
• martedì 22 aprile 2025 Rinnovo contrattuale, 2h (presidio davanti azienda)
• giovedì 24 aprile 2025 Rinnovo contrattuale, 2h (presidio davanti azienda)
• martedì 29 aprile 2025 Rinnovo contrattuale, 2h (presidio davanti azienda)

La classifica dei giorni scelti per gli scioperi è guidata da mercoledì (4 scioperi), seguono martedì e venerdì (2 scioperi a testa) e chiude giovedì (un solo sciopero).

Gli scioperi di un'azienda sola, per giunta in un periodo così breve, sono statisticamente significativi? No di certo, però un dubbio potrebbero farlo venire e potrebbe essere utile verificare se davvero ci sia questa schiacciante prevalenza di scioperi fatti di venerdì.

Da qui in avanti invece supporrò che davvero ci sia una netta prevalenza di scioperi fatti il venerdì, ma ripeto che sarebbe bello verificare quanto sia giustificata nei fatti questa convinzione.

Punto 2: di quali scioperi si parla?
Ci sono scioperi che si traducono in una semplice astensione dal lavoro, scioperi con astensione e presidio davanti all'azienda, scioperi con manifestazione provinciale, scioperi con manifestazione regionale e scioperi con manifestazione nazionale (in genere a Roma).

Ti dico come funziona uno sciopero con manifestazione nazionale perché a quanto mi risulta sono momenti a cui partecipa una sparuta minoranza di persone e può essere che pochi sappiano cosa succede realmente o, peggio ancora, che sopravviva l'idea che lo sciopero sia quella cosa che si faceva alle superiori e che si traduceva in una bella mattinata di vacanza, niente interrogazioni, passeggiata in centro con gli amici, ecc. ecc.

Abito a Firenze, il pullman della CGIL per Roma parte intorno alle 7:00 (da Firenze... pensa a che ora si parte da Torino o da Palermo...). Punto la sveglia alle 6:00 e alle 7:00 sono al punto di ritrovo (che non è lontano da casa mia, ma non per tutti è così). Partiamo e intorno alle 11:00 arriviamo a Roma (metro Anagnina). Intorno alle 12:00 arriviamo al concentramento, inizia il corteo e per un paio d'ore si cammina, fino a quando non si arriva al punto dove si terrano i discorsi e lì si sta un'oretta in piedi ad ascoltare i discorsi. Si riparte e, sempre a piedi, si raggiunge la prima stazione della metropolitana aperta (per motivi di sicurezza quelle più vicine sono chiuse, quindi si cammina parecchio), si prende la metro e si torna al pullman, si parte e si rientra a Firenze intorno alle 21:00 (a Firenze... pensa a che ora arriva a casa chi parte da Torino o da Palermo...).

Quindi, levataccia alle 6:00, viaggio andata e ritorno Firenze-Roma in giornata (o Torino-Roma, o Palermo-Roma, dipende...), ore passate a camminare o comunque in piedi, rientro a casa in serata (o in nottata)... e il giorno dopo dovremmo andare a lavorare? Vale la pena ironizzare o lanciarsi in ardite dietrologie sui motivi reconditi per cui questi scioperi vengano fatti "sempre" il giorno prima di un giorno in cui possiamo riposarci?

Punto 3: quanto costa scioperare?
Dall'inizio della campagna di scioperi per il rinnovo del nostro contratto ad oggi abbiamo accumulato quasi una settimana di scioperi. I giorni in cui si sciopera non vengono pagati, come si sa, e considerando una media di 20 giorni lavorativi al mese, conviene ricordare che una giornata di sciopero costa il 5% dello stipendio. Chi ha uno stipendio di 1500 euro netti al mese una giornata di sciopero se la paga 75 euro. Non sono proprio spiccioli.

Se anche si parlasse di scioperi locali, senza spostamenti a Roma, possiamo spenderci questi 75-100 euro nel giorno che preferiamo, magari approfittandone per unire l'utile al dilettevole e far cominciare qualche ora prima il nostro fine settimana? O dobbiamo spendere tutti quei soldi in un giorno che non ci torna neanche comodo? E per dimostrare cosa, che non siamo opportunisti? Che non siamo gente che sciopera per divertimento? Che siamo duri e puri, pronti al sacrificio (tanto duro quanto inutile) in nome dei nostri ideali? Vale di più la lotta fatta facendosi del male? E se scioperassimo flagellandoci sarebbe una dimostrazione ancora più alta di quanto siano nobili le nostre proteste?

Per cui, io non ho elementi per dire se davvero ci sia questa preminenza di scioperi fatti di venerdì, però se anche fosse così a me sembra che ci siano delle ragioni comprensibilissime dietro questa scelta.

Un saluto affezionato,
Massimiliano Polito

#ilPost #FIOM #scioperi

We’re suckers for a vintage electronic teardown here at Hackaday, and thus it’s pleasing to see [Thomas Scherrer OZ2CPU] with a 1962 AEG oscilloscope on his bench. It’s definitely seen better days, and is a single-trace 10 MHz unit of the type you might have seen in a typical general purpose electronics lab back in the day.

Pulling the cover off, and as expected there’s a row of tubes each side of the centrally mounted CRT. No printed circuits in sight, and no transistors either, though the rectifiers are selenium parts. After a clean-up it’s time to look at the tubes, and they show the metallic deposits characteristic of long operation. We’re more used to that from older televisions than test equipment,

Gently bringing the power up it looks promising, but there’s a purple glow from one of the PCL82 triode-pentodes. Replacing that and a double-triode results in a ‘scope that surprisingly, is working. It was evidently a high quality device in the first place, with components capable of lasting for over six decades.

We’ve seen more from his bench involving tubes, including this device using a magic-eye tube as the heavy lifter.

youtube.com/embed/-nZ8hAVJIWI?…

hackaday.com/2025/06/04/a-vint…

In questo articolo della nostra Rubrica WiFI parleremo dell’’implementazione di un sistema di autenticazione AAA come il captive portal:

• Authentication: Processo di registrazione che di solito avviene attraverso l’inserimento delle proprie generalità (ad es. il nome utente) e la validazione di queste tramite tecniche che ne consentono la verifica (come per esempio, SMS, validazione mail, carta di credito, etc…)
• Authorization: L’autorizzazione si riferisce alla concessione di privilegi specifici ad un’entità o ad un utente, in base al profilo autenticato, ai privilegi richiesti, allo stato corrente del sistema. Le autorizzazioni possono anche essere basate su restrizioni di tipo temporale, di tipo geografico o sul divieto di accessi multipli simultanei da parte dello stesso utente. Nella maggior parte dei casi il privilegio concesso consiste nell’utilizzo di un determinato tipo di servizio.
• Accounting:Il termine Accounting si riferisce alle statistiche e informazioni di utilizzo della rete da parte degli utenti. Tale attività è finalizzata a tenere traccia delle seguenti informazioni riguardante l’utente
  
  • Da dove si è collegato
  • Quando e per quanto tempo
  • Dispositivo utilizzato
  • Traffico effettuato
  • Etc..

  
  

Abbinata a un captive portal rappresenta il primo livello di controllo per una rete WiFi aperta. Questo approccio consente di gestire in modo sicuro l’accesso degli utenti, stabilire regole di navigazione e monitorare l’utilizzo della rete.

Come funziona nel dettaglio

Quando il client si collega ad una rete con Captive Portal il Network Access Controller (NAC), verifica se l’utente fa parte di quelli autenticati o con permessi alla navigazione. Se è così il client può navigare, altrimenti avviene il redirect dell’utente verso il captive portal come descritto in calce.

1) Presentazione Captive porta

• Quando il client effettua una richiesta Http, ovvero cerca di aprire un sito web
• Il NAC risponde con un 302 redirect, reindirizzando il Client verso la pagina del captive portal. In questa fase il NC aggiunge nella querystring le informazioni utili per identificare e gestire in modo dettagliato e specifico le richieste. Esempi di variabili:
  
  1. NAC ID: permette al Captive di capire da dove viene la richiesta
  2. IP+MAC Client: Server per identificare il dispositivo del Client
  3. Informazioni Aggiuntive: Oltre a quelle sopra citate possono essere passate diverse informazioni utili per gestire a 360 l’autenticazione. Tra queste per esempio può esserci anche la url richiesta all’inizio dal client per riportarla alla pagina richiesta in partenza una volta autenticato
  4. Una volta ricevuta la richiesta il captive verifica le variabili ed in base alle policy risponde al cliente con la pagina di login contenente anche il form di registrazione

  
  

2) Registrazione & Creazione Account (Authentication)

• Il Client compila il form di registrazione ed invia una richiesta di creazione account al Captive Portal
• Il Captive procede con la creazione dell’account, includendo informazioni come:
  
  1. Tipo Utente: il tipo di account , utile per esempio per definire diverse tipologie o gruppi di account. Di solito utilizzato per preimpostare le policy e per definire le location in cui può essere usato. Inoltre serve anche per definire dettagli come:
     
     • Hard Timeout: il tempo massimo di durata di una sessione al termine della quale il Client deve effettuare nuovamente il login
     • Idle Timeout: Tempo di inattività finito, che definisce che se il Client non effettua traffico per un determinato tempo viene effettuato un logout.

     
     

  2. Policy: Le regole con cui l’account può navigare su internet, per esempio può definire limiti giornalieri, mensili e/o totali di:
     
     • Ore massime di navigazione
     • Limiti di velocità
     • Traffico Internet
     • Numero dispositivi
     • etc…

     
     

  3. NAC ID: che permette per esempio di identificare la location da dove si è registrato il Client
  4. IP+MAC Client: Server per identificare il dispositivo del Client
  5. ETC…

  
  

• La procedura di registrazione restituisce al Captive le credenziali (username e password) dell’account appena creato
• Queste poi vengono restituite al Client. Importante che la comunicazione avvenga in modo sicuro e criptato.

3) Login del Client (Authorization)

• Una volta ottenuto le credenziali di accesso il client può quindi procedere con l’autenticazione del dispositivo inserendo le credenziali nella pagina del Captive
• Il Captive, verifica le credenziali e restituisce il modulo di accesso appropriato che il client deve inviare al NAC
• Il Client analizza la risposta e invia la richiesta di accesso al NAC.
• Il NAC analizza, gestisce la richiesta e crea una richiesta di accesso RADIUS utilizzando le credenziali ricevute dal Client.
• Il servizio Radius invia una richiesta di controllo dell’account al servizio di registrazione per verificare se le credenziali inviate sono valide per l’autenticazione.
• Se le credenziali sono valide, la registrazione restituisce le informazioni sulla sessione al servizio Radius.
• Il servizio Radius utilizza le informazioni della sessione per costruire una risposta di tipo RADIUS Access-Response, che viene inviata al NAC
• Il NAC riceve la risposta e quindi apre il firewall e invia una risposta di successo al client. Inoltre potremmo permettere al Client la navigazione già da questo momento.

4) Inizio Sessione (Accounting)

• Il NAC invia una richiesta di tipo RADIUS Account-Request con Acct-Status-Type=start al servizio Radius per avviare la sessione di accounting.
• Il servizio Registration aggiorna la sessione creata in precedenza.
• Il servizio Radius restituisce una risposta di Accounting RADIUS.
• Il servizio Radius invia una richiesta di avvio sessione al servizio Registration.

5) Stop Session (Accounting)

• Il NAC invia una richiesta di tipo RADIUS Account-Request con Acct-Status-Type=stop al servizio Radius per aggiornare la sessione.
• Il servizio Radius invia una richiesta di arresto della sessione al servizio Registration.
• Il servizio Registration aggiorna la sessione e la memorizza su uno storage per tenerne traccia si per fini statistici che di normativa/sicurezza
• Il servizio Radius restituisce una risposta al NAC che blocca le regole del firewall ed inibisce la navigazione al Client

Benefici dell’Autenticazione AAA con Captive Portal

Controllo degli Accessi

Consente di stabilire chi può accedere alla rete e con quali permessi. Gli utenti devono identificarsi tramite credenziali, social login, o registrazione, limitando così l’accesso a utenti autorizzati.

Questo di fatto permette di

• Evitare Connessioni Anonime e Non Autorizzate
  
  • L’accesso è riservato a utenti identificati, riducendo il rischio di utilizzo improprio della rete.
  • Previene l’abuso da parte di attaccanti o utenti non autorizzati.

  
  

• Creazione di Profili Personalizzati
  
  • Permette di configurare profili con permessi specifici, adattati alle esigenze degli utenti o dell’organizzazione. Come per esempio
    
    • Limitazioni in fasce orarie: L’accesso è consentito solo in determinati orari (es. durante l’orario di lavoro).
    • Tempo massimo di connessione: Disconnessione automatica dopo un tempo prestabilito.
    • Velocità massima per utente: Controllo della banda disponibile per evitare che un singolo utente monopolizzi le risorse.
    • Traffico massimo giornaliero: Limiti al volume di dati trasferiti per ogni utente.

    
    

  
  

• Gestione Centralizzata degli Utenti

• Consente di disconnettere o disabilitare specifici account in caso di utilizzo improprio.
• Funzionalità per disabilitare in modo massivo gli account in caso di emergenza o al termine di un evento.
• Tracciabilità completa per monitorare attività e prevenire comportamenti indesiderati.

Tracciabilità

Le sessioni degli utenti vengono registrate e tracciate, permettendo di mantenere un registro dettagliato delle attività di rete. Questo include dati come:

• Orari di connessione e disconnessione.
• Indirizzi IP assegnati e dispositivi utilizzati.
• Siti visitati e volumi di traffico generati.

La tracciabilità delle sessioni non è solo una pratica di sicurezza, ma anche un requisito essenziale per garantire conformità normativa e supportare le indagini in caso di necessità.

In calce un elenco dei vantaggi che la tracciabilità ci può portare:

• Risposta a Eventuali Abusi e Supporto alle Forze dell’Ordine
  
  • La tracciabilità permette di identificare comportamenti illeciti o attività sospette.
  • I log dettagliati possono essere forniti alla polizia postale o ad altre autorità competenti per supportare indagini su abusi o crimini informatici.

  
  

• Responsabilità e Conformità Normativa
  
  • Tutto il traffico generato dalla rete ricade sotto la responsabilità del proprietario della connessione. Ciò significa che, in caso di attività illecite (come accesso a contenuti illegali, invio di spam o crimini informatici), il proprietario potrebbe essere chiamato a rispondere in prima istanza. L’amministratore della rete deve essere in grado di dimostrare che ha messo in atto tutte le misure possibili per prevenire tali abusi, fornendo dati che identificano l’utente responsabile.

  
  

• Facilità di Analisi Post-Incidente
  
  • I registri delle attività consentono una rapida analisi di eventuali incidenti di sicurezza, come violazioni o accessi non autorizzati.
  • Permettono di individuare comportamenti sospetti e adottare misure correttive per prevenire futuri abusi.

  
  

Disclaimer e Responsabilità

In fase di login e/o registrazione, il captive portal può essere configurato per mostrare disclaimer e informative legali agli utenti che desiderano accedere alla rete. Questo passaggio è cruciale per definire chiaramente le regole di utilizzo della rete e per garantire conformità alle normative vigenti.

L’uso di disclaimer e informative legali non solo protegge il gestore della rete, ma garantisce una maggiore consapevolezza da parte degli utenti e conformità alle normative. Questo semplice passaggio aggiunge un livello essenziale di trasparenza e responsabilità per entrambe le parti.

Possiamo quindi affermare che l’utilizzo di disclaimer:

• Chiarisce le Regole e i Limiti di Utilizzo
  
  • Gli utenti vengono informati delle condizioni d’uso, inclusi divieti specifici, come l’accesso a contenuti illegali o il lancio di attività dannose.
  • Aiuta a educare gli utenti sulle responsabilità e sulle conseguenze di un uso improprio della rete.

  
  

• Protegge il Gestore della Rete da Responsabilità Legali
  
  • Dichiarare in modo esplicito che gli utenti sono responsabili delle attività svolte sulla rete aiuta a sollevare il gestore da potenziali implicazioni legali.
  • In caso di abusi, le autorità possono fare riferimento ai log delle connessioni e alle informative accettate dagli utenti.

  
  

• Assicura Conformità Normativa
  
  • Le normative come il GDPR richiedono di informare gli utenti sulla raccolta e sul trattamento dei loro dati personali. Il captive portal diventa quindi uno strumento per:
    
    • Comunicare in modo trasparente quali dati vengono raccolti e come saranno utilizzati.
    • Ottenere il consenso esplicito per il trattamento dei dati, ove necessario.

    
    

  
  

Contro dell’Autenticazione AAA con Captive Portal

Sebbene l’Autenticazione AAA con Captive Portal offra numerosi vantaggi, presenta anche alcune limitazioni e problematiche che devono essere prese in considerazione durante la sua implementazione. Di seguito un’analisi dei principali svantaggi:

Difficoltà nella Gestione delle Richieste Iniziali in HTTPS

Le pratiche di sicurezza dei browser e il diffuso utilizzo di HTTPS possono creare difficoltà nella prima fase di presentazione del captive portal. Questa situazione si verifica perché il captive portal, per sua natura, introduce un’interruzione nella connessione end-to-end prevista dal protocollo HTTPS, che può essere percepita come una sorta di attacco man-in-the-middle. HTTPS è progettato per garantire connessioni sicure e dirette tra client e server, ma l’intervento del captive portal con un reindirizzamento (HTTP 302 redirect) può causare una serie di problemi, tra cui:

• Errore Certificato SSL non validi: Durante il reindirizzamento, l’utente potrebbe ricevere un avviso sul browser a causa di certificati non corrispondenti, generando confusione o sfiducia.
• Mancata apertura automatica del Captive Portal: Alcuni dispositivi non mostrano automaticamente la pagina di login, costringendo l’utente a inserire manualmente un URL, con un’esperienza utente meno intuitiva.
• Incompatibilità con alcune applicazioni: Alcuni servizi o app (come per esempio le VPN) non funzionano finchè non si effettua il login.

Complessità di Configurazione e Gestione

Implementare e mantenere un sistema di autenticazione con Captive Portal richiede risorse significative, sia in termini di competenze tecniche che di infrastruttura. Le principali sfide comprendono:

• Configurazione iniziale complessa: La messa in opera di un captive portal richiede conoscenze avanzate per configurare server, certificati SSL/TLS, regole di rete e sistemi di autenticazione. In particolare:
  
  • Certificati SSL/TLS: È necessario configurare correttamente certificati validi per garantire connessioni sicure, evitando errori di certificato che possono compromettere la fiducia degli utenti.
  • Criptaggio dei dati: L’intero processo deve garantire che le credenziali degli utenti e altri dati sensibili siano crittografati sia in transito che a riposo, per prevenire intercettazioni o furti di informazioni da parte di attaccanti.

  
  

• Manutenzione continua: Gli aggiornamenti normativi e tecnologici richiedono costanti interventi per mantenere il sistema aggiornato e sicuro:
  
  • Conformità normativa: Regolamenti e normative vigenti obbligano il gestore a implementare misure di sicurezza adeguate per il trattamento e la protezione dei dati personali.
  • Aggiornamenti di sicurezza: La crescente sofisticazione delle minacce richiede l’applicazione regolare di patch e aggiornamenti software per evitare vulnerabilità sfruttabili da attaccanti.
  • Sicurezza delle comunicazioni: È fondamentale garantire che le comunicazioni tra il captive portal e i server di backend siano crittografate, utilizzando protocolli sicuri come HTTPS e TLS moderni.

  
  

• Gestione degli account utente: La gestione delle identità se ben fatta, può rappresentare una sfida significativa:
  
  • Creazione e aggiornamento degli account: Il processo di gestione delle credenziali deve essere sicuro e automatizzato, per evitare errori umani e ridurre i rischi di compromissione.
  • Revoca e controllo degli accessi: È necessario garantire la possibilità di disattivare rapidamente gli account in caso di comportamenti anomali o di violazioni, mantenendo al contempo un registro dettagliato delle attività per eventuali analisi post-incidente.
  • Gestione centralizzata: L’implementazione di sistemi di gestione centralizzata come RADIUS o altri strumenti AAA (Authentication, Authorization, Accounting) può complicare ulteriormente l’infrastruttura, ma è essenziale per garantire un controllo capillare e sicuro degli accessi.

  
  

In conclusione, la configurazione e la gestione di un captive portal non sono solo una questione di usabilità o funzionalità, ma richiedono un focus continuo sulla sicurezza, dalla protezione delle comunicazioni alla conformità normativa, per garantire un sistema robusto e affidabile.

Impatti sull’Esperienza Utente

L’esperienza dell’utente finale è un elemento cruciale da considerare durante la progettazione e l’implementazione di un sistema di autenticazione con Captive Portal. Scelte errate o implementazioni poco curate possono infatti compromettere l’usabilità e creare frustrazione. Ecco alcune problematiche comuni e le relative considerazioni:

• Accesso difficoltoso: Il processo di registrazione e autenticazione introduce un passaggio aggiuntivo rispetto alla connessione immediata, che può essere percepito come un ostacolo. È fondamentale trovare un equilibrio tra sicurezza e semplicità, implementando un’interfaccia intuitiva e procedure snelle per ridurre i tempi di accesso senza rinunciare alla sicurezza.
• Problemi di compatibilità con i dispositivi IoT: Molti dispositivi IoT non sono progettati per interagire con sistemi di Captive Portal, risultando incapaci di completare i processi di login. Questo richiede:
  
  • Soluzioni personalizzate: Configurazioni dedicate per gestire l’accesso dei dispositivi IoT, come whitelist di MAC address o autenticazione semplificata.
  • Automazione del processo di connessione: Sistemi che rilevino e autorizzino automaticamente dispositivi specifici, riducendo al minimo l’intervento manuale.

  
  

• Frustrazione dell’utente: La necessità di autenticarsi frequentemente, in particolare per sessioni brevi, può risultare irritante e compromettere l’esperienza complessiva. Per mitigare questo problema, è possibile adottare le seguenti soluzioni:
  
  • Riconoscimento automatico del dispositivo: Implementare una funzionalità che identifica e autentica automaticamente i dispositivi precedentemente registrati, eliminando la necessità per l’utente di ripetere il processo di login.
  • Persistenza della sessione: Estendere la durata delle sessioni attive (quelle definite come Hard Timeout precedentemente) per evitare disconnessioni frequenti, garantendo comunque un adeguato livello di sicurezza. Al contempo, è consigliabile mantenere brevi le sessioni di inattività (Idle timeout), così da assicurare una visibilità chiara e puntuale dei dispositivi effettivamente collegati in un dato momento.

  
  

Con un’attenzione mirata a questi aspetti, è possibile migliorare l’esperienza dell’utente finale, riducendo la frustrazione e favorendo l’adozione del sistema senza compromettere la sicurezza.

Conclusione

L’adozione di sistemi AAA (Authentication, Authorization, Accounting) unitamente a un captive portal rappresenta un approccio valido per garantire un accesso sicuro e regolamentato alle reti Wi-Fi, offrendo al contempo strumenti di monitoraggio e gestione della navigazione degli utenti. Questa combinazione permette di conciliare accessibilità e protezione, risultando particolarmente utile in contesti caratterizzati da hotspot aperti.

Tuttavia, è fondamentale riconoscere che l’implementazione di un captive portal comporta complessità tecniche e possibili ripercussioni sull’esperienza dell’utente. Un captive portal mal configurato o non integrato con altre misure di sicurezza rischia di trasformarsi in una vulnerabilità anziché in un beneficio. Proprio per questo, scegliere il fornitore IT e il servizio giusto diventa cruciale: come abbiamo visto nel nostro articolo “Hotel da sogno, Wi-Fi da incubo: l’importanza del giusto fornitore IT”, affidarsi a partner in grado di offrire competenze, aggiornamenti costanti e garanzie di sicurezza è l’unico modo per evitare spiacevoli sorprese e proteggere davvero la propria infrastruttura.

Nei prossimi articoli esploreremo altre contromisure fondamentali, a cominciare dall’isolamento del traffico, per rendere le reti wifi aperte ancora più resilienti. Se sei un utente o un amministratore di rete, non perderti questi consigli: l’intero RedWave Team condividerà con te tutta la sua esperienza per guidarti nella valutazione e nella prevenzione, in perfetto stile RedHotCyber.

L'articolo AAA + Captive Portal: La combo perfetta per una rete WiFi a prova di attacco proviene da il blog della sicurezza informatica.

Gli analisti di NordVPN stimano che miliardi di cookie rubati vengano venduti sul dark web e su Telegram. Circa il 7-9% di questi cookie è ancora attivo e può essere utilizzato dagli aggressori.

Secondo i ricercatori, attualmente i criminali possono acquistare più di 93,7 miliardi di cookie online. I cookie possono sembrare innocui, ma nelle mani sbagliate diventano chiavi digitali per accedere alle informazioni più personali. “Ciò che è stato progettato per comodità è ora una vulnerabilità crescente che viene sfruttata dai criminali informatici di tutto il mondo”, afferma Adrianus Warmenhoven.

NordVPN avverte che la stragrande maggioranza dei cookie rubati (90,25%) contiene dati identificativi volti a identificare gli utenti e a inviare pubblicità mirata. I cookie possono contenere anche dati come nomi, indirizzi di casa e indirizzi email, dati sulla posizione, password e numeri di telefono. Tuttavia, si segnala che tali informazioni sono presenti solo nello 0,5% di tutti i cookie rubati.

I cookie possono anche contenere informazioni sulle sessioni utente. Secondo gli esperti, più di 1,2 miliardi di questi file sono ancora attivi (circa il 6% del totale) e sono generalmente considerati il ​​problema più grave.

I criminali informatici possono utilizzare i cookie di sessione per impersonare altre persone sui siti web, autenticarsi a vari servizi senza utilizzare credenziali e, in molti casi, bypassare l’autenticazione a più fattori. Pertanto, i cookie di sessione sono molto interessanti per i criminali informatici, che possono utilizzarli per raccogliere informazioni da caselle di posta, applicazioni bancarie, sistemi aziendali e così via.

I cookie cadono più spesso nelle mani dei criminali grazie agli infostealer. Il leader in questo ambito, secondo i ricercatori, è Redline stealer (il 44% di tutti i cookie rilevati era associato a lui). Il secondo, terzo e quarto posto della lista sono occupati da Vidar, LummaC2 e Meta, sebbene le forze dell’ordine abbiano intrapreso azioni legali contro gli ultimi due (così come contro Redline).

Il costo di accesso a questi strumenti dannosi è relativamente basso, considerando l’enorme profitto che si può ricavare dal furto delle risorse digitali degli utenti. Lumma, ad esempio, può essere acquistato per soli 250 dollari, mentre Redline e Meta costano solo 150 dollari per il set di funzionalità base.

Gli esperti raccomandano inoltre di aggiornare regolarmente i dispositivi e di installare le patch più recenti se la priorità è prevenire infezioni da stealer e altri malware. Sarebbe inoltre consigliabile cancellare regolarmente la cronologia del browser ed eliminare i cookie non necessari. “Molti utenti non si rendono conto che le sessioni attive possono persistere anche dopo la chiusura del browser”, afferma Warmenhoven. “Cancellare questi dati aiuta a ridurre le possibilità di accessi non autorizzati”.

L'articolo Tanta Roba. 93 miliardi di cookie rubati! La nuova miniera d’oro degli hacker sul Dark Web proviene da il blog della sicurezza informatica.

Here are some events we hope you can make:

• Friday, June 13th, 6-8pm: Join us at the Boston Dyke March. We would love your help on the march;
• Sunday, June 15th, 10am-4pm: Attend our party conference in Somerville. Details at our conference page;
• Tuesday, June 17th, 6pm: Map surveillance cameras in Cambridge. Meet at Cambridge Kiosk (former Out of Town News), Harvard Square;
• Saturday, June 21st: Join us at the Boxborough Fifers Day. Tell us if you will help us at the table.

masspirates.org/blog/2025/06/0…

With few exceptions, amateur radio is a notably sedentary pursuit. Yes, some hams will set up in a national or state park for a “Parks on the Air” activation, and particularly energetic operators may climb a mountain for “Summits on the Air,” but most hams spend a lot of time firmly planted in a comfortable chair, spinning the dials in search of distant signals or familiar callsigns to add to their logbook.

There’s another exception to the band-surfing tendencies of hams: fox hunting. Generally undertaken at a field day event, fox hunts pit hams against each other in a search for a small hidden transmitter, using directional antennas and portable receivers to zero in on often faint signals. It’s all in good fun, but fox hunts serve a more serious purpose: they train hams in the finer points of radio direction finding, a skill that can be used to track down everything from manmade noise sources to unlicensed operators. Or, as was done in the 1940s, to ferret out foreign agents using shortwave radio to transmit intelligence overseas.

That was the primary mission of the Radio Intelligence Division, a rapidly assembled organization tasked with protecting the United States by monitoring the airwaves and searching for spies. The RID proved to be remarkably effective during the war years, in part because it drew heavily from the amateur radio community to populate its many field stations, but also because it brought an engineering mindset to the problem of finding needles in a radio haystack.

Winds of War

America’s involvement in World War II was similar to Hemingway’s description of the process of going bankrupt: Gradually, then suddenly. Reeling from the effects of the Great Depression, the United States had little interest in European affairs and no appetite for intervention in what increasingly appeared to be a brewing military conflict. This isolationist attitude persisted through the 1930s, surviving even the recognized start of hostilities with Hitler’s sweep into Poland in 1939, at least for the general public.

But behind the scenes, long before the Japanese attack on Pearl Harbor, precipitous changes were afoot. War in Europe was clearly destined from the outset to engulf the world, and in the 1940s there was only one technology with a truly global reach: radio. The ether would soon be abuzz with signals directing troop movements, coordinating maritime activities, or, most concerningly, agents using spy radios to transmit vital intelligence to foreign governments. To be deaf to such signals would be an unacceptable risk to any nation that fancied itself a world power, even if it hadn’t yet taken a side in the conflict.

It was in that context that US President Franklin Roosevelt approved an emergency request from the Federal Communications Commission in 1940 for $1.6 million to fund a National Defense Operations section. The group would be part of the engineering department within the FCC and was tasked with detecting and eliminating any illegal transmissions originating from within the country. This was aided by an order in June of that year which prohibited the 51,000 US amateur radio operators from making any international contacts, and an order four months later for hams to submit to fingerprinting and proof of citizenship.

A Ham’s Ham

George Sterling (W1AE/W3DF). FCC commissioner in 1940, he organized and guided RID during the war. Source: National Assoc. of Broadcasters, 1948
The man behind the formation of the NDO was George Sterling. To call Sterling an early adopter of amateur radio would be an understatement. He plunged into radio as a hobby in 1908 at the tender age of 14, just a few years after Marconi and others demonstrated the potential of radio. He was licensed immediately after the passage of the Radio Act of 1927, callsign 1AE (later W1AE), and continued to experiment with spark gap stations. When the United States entered World War I, Sterling served for 19 months in France as an instructor in the Signal Corps, later organizing and operating the Corps’ first radio intelligence unit to locate enemy positions based on their radio transmissions.

After a brief post-war stint as a wireless operator in the Merchant Marine, Sterling returned to the US to begin a career in the federal government with a series of radio engineering and regulatory jobs. He rose through the ranks over the 1920s and 1930s, eventually becoming Assistant Chief of the FCC Field Division in 1937, in charge of radio engineering for the entire nation. It was on the strength of his performance in that role that he was tapped to be the first — and as it would turn out, only — chief of the NDO, which was quickly raised to the level of a new division within the FCC and renamed the Radio Intelligence Division.

To adequately protect the homeland, the RID needed a truly national footprint. Detecting shortwave transmissions is simple enough; any single location with enough radio equipment and a suitable antenna could catch most transmissions originating from within the US or its territories. But Sterling’s experience in France taught him that a network of listening stations would be needed to accurately triangulate on a source and provide a physical location for follow-up investigation.

The network that Sterling built would eventually comprise twelve primary stations scattered around the US and its territories, including Alaska, Hawaii, and Puerto Rico. Each primary station reported directly to RID headquarters in Washington, DC, by telephone, telegraph, or teletype. Each primary station supported up to a few dozen secondary stations, with further coastal monitoring stations set up as the war ground on and German U-boats became an increasingly common threat. The network would eventually comprise over 100 stations stretched from coast to coast and beyond, staffed by almost 900 agents.

Searching the Ether

The job of staffing these stations with skilled radio operators wasn’t easy, but Sterling knew he had a ready and willing pool to pull from: his fellow hams. Recently silenced and eager to put their skills to the test, hams signed up in droves for the RID. About 80% of the RID staff were composed of current or former amateur radio operators, including the enforcement branch of sworn officers who carried badges and guns. They were the sharp end of the spear, tasked with the “last mile” search for illicit transmitters and possible confrontation with foreign agents.

But before the fedora-sporting, Tommy-gun toting G-men could swoop in to make their arrest came the tedious process of detecting and classifying potentially illicit signals. This task was made easier by an emergency order issued on December 8, 1941, the day after the Pearl Harbor attack, forbidding all amateur radio transmissions below 56 MHz. This reduced the number of targets the RID listening stations had to sort through, but the high-frequency bands cover a lot of turf, and listening to all that spectrum at the same time required a little in-house innovation.

Today, monitoring wide swaths of the spectrum is relatively easy, but in the 1940s, it was another story. Providing this capability fell to RID engineers James Veatch and William Hoffert, who invented an aperiodic receiver that covered everything from 50 kHz to 60 MHz. Called the SSR-201, this radio used a grid-leak detector to rectify and amplify all signals picked up by the antenna. A bridge circuit connected the output of the detector to an audio amplifier, with the option to switch an audio oscillator into the circuit so that continuous wave transmissions — the spy’s operating mode of choice — could be monitored. There was also an audio-triggered relay that could start and stop an external recorder, allowing for unattended operation.
SSR-201 aperiodic receiver, used by the RID to track down clandestine transmitters. Note the “Magic Eye” indicator. Source: Steve Ellington (N4LQ)
The SSR-201 and a later variant, the K-series, were built by Kann Manufacturing, a somewhat grand name for a modest enterprise operating out of the Baltimore, Maryland, basement of Manuel Kann (W3ZK), a ham enlisted by the RID to mass produce the receiver. Working with a small team of radio hobbyists and broadcast engineers mainly working after hours, Kann Manufacturing managed to make about 200 of the all-band receivers by the end of the war, mainly for the RID but also for the Office of Strategic Services (OSS), the forerunner of the CIA, as well as the intelligence services of other allied nations.

These aperiodic receivers were fairly limited in terms of sensitivity and lacked directional capability, and so were good only for a first pass scan of a specific area for the presence of a signal. Consequently, they were often used in places where enemy transmitters were likely to operate, such as major cities near foreign embassies. This application relied on the built-in relay in the receiver to trigger a remote alarm or turn on a recorder, giving the radio its nickname: “The Watchdog.” The receivers were also often mounted in mobile patrol vehicles that would prowl likely locations for espionage, such as Army bases and seaports. Much later in the war, RID mobile units would drive through remote locations such as the woods around Oak Ridge, Tennessee, and an arid plateau in the high desert near Los Alamos, New Mexico, for reasons that would soon become all too obvious.

Radio G-Men

Adcock-type goniometer radio direction finder. The dipole array could be rotated 360 degrees from inside the shack to pinpoint a bearing to the transmitter. Source: Radio Boulevard
Once a candidate signal was detected and headquarters alerted to its frequency, characteristics, and perhaps even its contents, orders went out to the primary stations to begin triangulation. Primary stations were equipped with radio direction finding (RDF) equipment, including the Adcock-type goniometer. These were generally wooden structures elevated above the ground with a distinctive Adcock antenna on the roof of the shack. The antenna was a variation on the Adcock array using two vertical dipoles on a steerable mount. The dipoles were connected to the receiving gear in the shack 180 degrees out of phase. This produced a radiation pattern with very strong nulls broadside to the antenna, making it possible for operators to determine the precise angle to the source by rotating the antenna array until the signal is minimized. Multiple stations would report the angle to the target to headquarters, where it would be mapped out and a rough location determined by where the lines intersected.

With a rough location determined, RID mobile teams would hit the streets. RID had a fleet of mobile units based on commercial Ford and Hudson models, custom-built for undercover work. Radio gear partially filled the back seat area, power supplies filled the trunk, and a small steerable loop antenna could be deployed through the roof for radio direction finding on the go. Mobile units were also equipped with special radio sets for communicating back to their primary station, using the VHF band to avoid creating unwanted targets for the other stations to monitor.

Mobile units were generally capable of narrowing the source of a transmission down to a city block or so, but locating the people behind the transmission required legwork. Armed RID enforcement agents would set out in search of the transmitter, often aided by a device dubbed “The Snifter.” This was a field-strength meter specially built for covert operations; small enough to be pocketed and monitored through headphones styled to look like a hearing aid, the agents could use the Snifter to ferret out the spy, hopefully catching them in the act and sealing their fate.

A Job (Too) Well Done

For a hastily assembled organization, the RID was remarkably effective. Originally tasked with monitoring the entire United States and its territories, that scope very quickly expanded to include almost every country in South America, where the Nazi regime found support and encouragement. Between 1940 and 1944, the RID investigated tens of thousands, resulting in 400 unlicensed stations being silenced. Not all of these were nefarious; one unlucky teenager in Portland, Oregon, ran afoul of the RID by hooking an antenna up to a record player so he could play DJ to his girlfriend down the street. But other operations led to the capture of 200 spies, including a shipping executive who used his ships to refuel Nazi U-boats operating in the Gulf of Mexico, and the famous Dusquense Spy Ring operating on Long Island.

Thanks in large part to the technical prowess of the hams populating its ranks, the RID’s success contained the seeds of its downfall. Normally, such an important self-defense task as preventing radio espionage would fall to the Army or Navy, but neither organization had the technical expertise in 1940, nor did they have the time to learn given how woefully unprepared they were for the coming war. Both branches eventually caught up, though, and neither appreciated a bunch of civilians mucking around on their turf. Turf battles ensued, politics came into it, and by 1944, budget cuts effectively ended the RID as a standalone agency.

hackaday.com/2025/06/04/high-s…

Ahoy Pirates,

Our next PPI board meeting will take place on 24.06.2025 at 20:00 UTC / 22:00 CEST.

Prior to that meeting on Tuesday, 10 June 2025, 14:00 UTC in the same Jitsi board room, we will hold a special IGF SCUBA working group meeting.

All official PPI proceedings, Board meetings included, are open to the public. Feel free to stop by. We’ll be happy to have you.

Where:jitsi.pirati.cz/PPI-Board

Minutes of last meeting: wiki.pp-international.net/wiki…

All of our meetings are posted to our calendar: pp-international.net/calendar/

We look forward to seeing visitors.

Thank you for your support,

The Board of PPI

pp-international.net/2025/06/b…

Si è conclusa recentemente presso la Scuola Superiore di Polizia in Roma una settimana di corso in materia di cybercrime, dedicato ad una delegazione di funzionari della Royal Malaysia Police (rmp.gov.my/).

L’iniziativa mira a rafforzare la cooperazione dell’Italia con i Paesi del sud-est asiatico ed in particolare con la Malesia.

Il corso, organizzato dall’Area di staff per le Relazioni internazionali del capo della Polizia, con la collaborazione della Direzione centrale per la polizia scientifica e la sicurezza cibernetica, ha avuto il sostegno finanziario della Direzione Generale Mondializzazione e Questioni Globali del Ministero degli Esteri e della Cooperazione Internazionale.

Il badge della RMP

L’attività è stata coordinata dall’area di staff per le Relazioni internazionali.

Il programma didattico, focalizzato sulle metodologie, tecniche investigative e buone pratiche in materia di cybercrime, tra cui pedopornografia online, protezione delle infrastrutture critiche, truffe online e l’uso dell’intelligenza artificiale, è stato predisposto con il Servizio polizia postale e sicurezza cibernetica, che ne ha curato le docenze.

Un significativo apprezzamento è stato espresso dai colleghi malesi, i quali hanno riconosciuto una valenza fondamentale per la conoscenza reciproca dei sistemi, degli strumenti e delle buone pratiche adottate nel contrasto alle organizzazioni criminali transnazionali ed ai fenomeni criminali nei settori del cybercrime e della cybersecurity.

Particolarmente apprezzate sono state anche le visite alle strutture di eccellenza della Polizia di Stato, quali il Centro nazionale anticrimine informatico per la protezione delle infrastrutture critiche (C.N.A.I.P.I.C.), il Centro nazionale per il contrasto alla pedopornografia online (C.N.C.P.O.) e il Commissariato di P.S. on-line.

La delegazione malese ha rinnovato l’auspicio per una prosecuzione di questi momenti formativi, da programmare sulla base di comuni esigenze, individuando settori prioritari condivisi, volti a rafforzare la capacità e la resilienza della Royal Malaysia Police, rispetto alle sfide ed alle minacce poste da una criminalità sempre più fluida e transnazionale. Queste iniziative consentono, come evidenziato dagli stessi esperti stranieri, di rafforzare le competenze della loro Polizia e la resilienza del loro Paese rispetto alle sfide ed alle minacce poste da una criminalità sempre più transnazionale, traendo spunti e know how dall’esperienza maturata negli anni dalla Polizia di Stato italiana.

#cybercrime #cooperazioneinternazionaledipolizia # Poliziapostale #poliziadistato #RoyalMalaysiaPolice

Nell’ambito del progetto di integrazione dell’Unione Europea “Facility supporting Serbia in Achieving the Objectives of Chapter 24: justice, freedom and security”, recentemente una delegazione di funzionari della Polizia della Repubblica di Serbia ha fatto visita al Comando Unità Forestali, Ambientali e Agroalimentari Carabinieri (#CUFAA).
Il gruppo ha preso parte alla presentazione dei settori di competenza del CUFAA, approfondendo così la specialità dell’Arma sul fronte della tutela ambientale, di salvaguardia del patrimonio della biodiversità e della sicurezza alimentare.

La visita ha riguardato anche le specifiche attività: del Nucleo Informativo Antincendio Boschivo (#NIAB), fiore all’occhiello del Comando in materia di prevenzione e repressione dei reati, e quelle del Raggruppamento #CITES in materia di tutela delle specie animali e vegetali minacciate di estinzione, oltre a quelle di sicurezza ambientale ed energetica.

La delegazione ha mostrato interesse per le informazioni raccolte durante l’incontro, avendo la polizia Serba da poco tempo attivato, nell'ambito della Polizia Criminale del Ministero dell’Interno, una specifica Unità per la repressione dei crimini ambientali e la protezione dell’ambiente. La visita, infatti, è parte di una trasferta nel nostro Paese con obiettivo di studio specifico sul contrasto ai crimini ambientali.

#criminiambientali #poliziaserba #Armadeicarabinieri

Non ho quasi mai alcuna reazione ai miei post, né commenti, né like, né condivisioni. Su Facebook avevo 100-150 amici e ogni post aveva qualche like, qualche commento, qualche condivisione. Mi sembra di non esistere.

Qualche giorno fa ho messo un post di test chiedendo a chi lo leggeva se era visibile e ho avuto una sola reazione (tra l'altro, di una persona iscritta a questa stessa istanza).

A me sono venute in mente due possibili spiegazioni, ma magari ce ne sono anche altre, non so.

1. La mia uscita da Facebook ha coinciso con un calo verticale della mia capacità di scrivere o condividere cose che interessino qualcun altro oltre a me;

2. Non ho capito bene come funziona il Fediverso e per qualche motivo i miei post invece di arrivare alle migliaia di persone che lo affollano (come mi aspetterei) non arrivano a nessun'altra istanza (o arrivano in un numero insignificante di istanze), benché io usi sempre la permission "public".

Ci sono altre spiegazioni che mi sfuggono?