Come ridare vita a vecchie stampanti via browser con WebUSB: l'idea che stupisce

Molte stampanti USB perfettamente funzionanti finiscono per restare inutilizzate o andare direttamente in discarica quando i produttori smettono di distribuire driver aggiornati. Il problema non riguarda solo modelli molto datati: basta un cambio di architettura, come il passaggio da x86 ad ARM, per rendere inutilizzabile hardware ancora efficiente. George MacKerron, sviluppatore e ricercatore, ha avuto un’intuizione geniale: come tornare a far funzionare su Windows una stampante Canon SELPHY acquistata per pochi “spiccioli” su eBay.

Il caso descritto ruota attorno a una stampante fotografica compatta, progettata per la stampa diretta di immagini su supporti dedicati tramite tecnologia a sublimazione termica. Si tratta di dispositivi apprezzati per la qualità di stampa ma spesso vincolati a driver proprietari.

Sui sistemi Linux, il supporto arriva grazie a progetti come Gutenprint, che include driver reverse-engineered per diversi modelli; su macOS e Windows, invece, la compatibilità dipende quasi esclusivamente dai pacchetti ufficiali rilasciati dal produttore. Con il passare del tempo e l’evoluzione delle architetture – come il passaggio ai chip Apple Silicon o l’introduzione di versioni Windows solo 64 bit – molti di questi driver non risultano più installabili o funzionanti, lasciando hardware perfettamente operativo senza un canale di supporto davvero sfruttabile.

Stampare senza problemi con un sistema x86 emulato nel browser

Da qui nasce l’idea di una soluzione radicale: spostare l’intero stack di stampa dentro il browser, eliminando dipendenze da driver locali e sistemi operativi specifici.

Così, MacKerron ha realizzato il progetto Printervention: se il sistema operativo non supporta più la periferica di stampa, si può ricreare un ambiente compatibile altrove. Ad esempio in una pagina Web!

Lo sviluppatore racconta di essersi servito di Anthropic Claude per velocizzare lo sviluppo della sua soluzione software e risolvere alcuni problemi incontrati lungo il tragitto.

I moderni LLM sono semplicemente incredibili: se i computer sono biciclette per la mente, come diceva Steve Jobs, allora Claude Code è un jet privato.

Ecco quindi che Printervention, seppur caricato come una normale pagina Web, è un sistema completo che esegue una macchina virtuale Linux in tempo reale, in locale, lato browser, sfruttando tecnologie Web moderne.

MacKerron ha utilizzato v86, un emulatore x86 scritto in JavaScript che traduce codice macchina in WebAssembly. L’obiettivo è replicare un intero PC all’interno del browser, con CPU, memoria e periferiche virtuali. Le prestazioni restano limitate rispetto a un sistema nativo, ma risultano sufficienti per operazioni come la gestione della stampa.

All’interno della macchina virtuale viene eseguita una distribuzione Linux minimale, nello specifico Alpine Linux, configurata con CUPS e i driver Gutenprint. Questa scelta non è casuale: CUPS rappresenta da anni il riferimento per la gestione delle stampe sui sistemi Unix-like, mentre Gutenprint fornisce supporto a numerose stampanti legacy spesso abbandonate dai produttori.

L’intero ambiente Printervention è inizializzato al caricamento della pagina: nessuna installazione locale, nessun binario esterno. Il browser diventa a tutti gli effetti un host per un sistema operativo virtuale.

Accesso diretto alla stampante con WebUSB

Per comunicare con l’hardware, l’applicazione sfrutta WebUSB, API disponibile in Chromium che consente a una pagina Web di interagire direttamente con dispositivi USB previa autorizzazione esplicita dell’utente. Il browser individua la stampante collegata, ne legge identificativi come vendor ID e product ID e avvia la procedura di configurazione.

Il sistema confronta il modello individuato con i driver disponibili in Gutenprint utilizzando un algoritmo basato su trigrammi, cioè sequenze di tre caratteri consecutivi, per individuare con maggiore precisione le corrispondenze più simili. La configurazione avviene inviando comandi come lpadmin alla shell della macchina virtuale, simulando l’interazione di un utente Linux.

Il risultato è sorprendente: una stampante non più supportata dal sistema operativo torna in funzione tramite il browser.

Dal file al dispositivo: come avviene la stampa

Quando l’utente carica un documento, l’applicazione lo trasferisce all’interno della macchina virtuale basata su x86. Qui entra in gioco il comando lp, che converte il file nel formato comprensibile dalla stampante attraverso i filtri CUPS. Il flusso generato consiste in dati binari pronti per l’invio diretto al dispositivo.

Il passaggio più delicato riguarda proprio il trasferimento di questi dati dal sistema virtuale al browser. Nella prima versione, un componente backend personalizzato di CUPS trasmetteva i dati della stampa byte per byte attraverso una TTY virtuale, cioè un terminale simulato usato per comunicazioni a basso livello. Il browser riceveva questi singoli byte, li ricomponeva nel flusso originale e li inviava alla stampante utilizzando chiamate USB di tipo bulk transferOut, una modalità di trasferimento che permette di inviare grandi quantità di dati in modo affidabile ma senza garanzie sui tempi di consegna.

L’approccio ha evidenziato un problema tipico dei canali testuali: la gestione dei caratteri di controllo. Senza una configurazione adeguata, i dati binari subivano alterazioni. L’introduzione del comando stty raw ha eliminato la trasformazione dei caratteri, permettendo una trasmissione corretta.

Una seconda iterazione ha utilizzato il filesystem 9p di v86 per trasferire blocchi più grandi, migliorando l’efficienza ma introducendo la necessità di sincronizzare esplicitamente i file con sync prima della lettura lato JavaScript.

Limiti strutturali e gestione degli errori

L’architettura presenta un limite evidente: il flusso di dati è unidirezionale. Il sistema invia dati alla stampante, ma non riceve informazioni di ritorno. In assenza di feedback, l’utente non può sapere se si è verificato un inceppamento carta o se il toner è esaurito.

In scenari più evoluti sarebbe possibile integrare un meccanismo bidirezionale, ma servirebbe una gestione più complessa del protocollo USB e una modellazione accurata dei comandi proprietari di ogni singolo dispositivo.

Compatibilità, sicurezza e scenari d’uso

La compatibilità dipende da diversi fattori: il browser deve supportare WebUSB, quindi soluzioni basate su Chromium risultano privilegiate. Su Windows, in alcuni casi è necessario installare driver generici tramite strumenti come Zadig (dallo stesso autore di Rufus) per consentire l’accesso diretto alla periferica.

Dal punto di vista della sicurezza, WebUSB richiede sempre un’autorizzazione esplicita dell’utente per ogni dispositivo. Nonostante questo, l’accesso diretto all’hardware introduce una superficie di attacco che va considerata con attenzione, soprattutto in ambienti aziendali.

Le applicazioni pratiche risultano numerose: recupero di stampanti fotografiche dismesse, utilizzo di periferiche industriali legacy, ambienti educativi dove si vuole dimostrare il funzionamento interno di uno stack di stampa completo.

La soluzione dimostra un principio tecnico interessante: un browser moderno può sostituire intere componenti del sistema operativo quando dispone di API sufficientemente avanzate. In questo caso, la combinazione tra emulazione, WebAssembly e accesso hardware diretto consente di superare ogni limite.