Un Firefox compilato in WebAssembly gira dentro un altro browser
Testo scritto con l’intelligenza artificiale a partire da una fonte citata, senza revisione umana prima della pubblicazione.
Il progetto Puter ha mostrato la demo il 16 luglio 2026 e instrada tutto il traffico via proxy WebSocket.
Il 16 luglio 2026 un post descrive una demo: il blog dell’autore gira in Firefox, compilato in WebAssembly, dentro Chrome. Un browser completo esegue un sito reale dentro un altro browser1.
Gli autori hanno scelto Firefox/Gecko per il forte supporto al modello single‑process. Questa caratteristica ha guidato la scelta dell’obiettivo di porting rispetto ad alternative con architetture diverse1.
Il post linka un repository pubblico, firefox-wasm. Cita anche theogbob/WebkitWasm, un progetto simile che compila WebKit a WebAssembly1.
La rete è il vincolo chiave. Il codice che gira nel browser non può aprire connessioni arbitrarie. Per questo tutta la navigazione della demo passa attraverso un server di Puter: un proxy via WebSocket che usa il protocollo Wisp. Il traffico esce dal browser ospite verso il proxy e rientra nello stesso canale dopo l’instradamento verso Internet. È una condizione necessaria per far funzionare l’esperimento nel modello di sicurezza del browser1.
Il post stima una spesa di circa 25.000 dollari in token di Claude Opus e Fable, sfruttando un abbonamento Claude Max. Nota anche che, durante la discussione su Hacker News, il team ha dovuto aumentare la capacità dei server per reggere il traffico generato dalla demo1. La combinazione tra proxy centralizzato e interesse del pubblico ha imposto un ridimensionamento dell’infrastruttura lato server1.
Puter afferma che la soluzione supporta la cifratura end‑to‑end. L’autore del post ha ispezionato i messaggi sul WebSocket e riporta questo risultato: il traffico verso un sito HTTPS appariva cifrato, mentre le richieste e risposte a http://www.example.com/ erano in chiaro1. L’osservazione distingue il tunnel di trasporto (il WebSocket) dal contenuto delle singole richieste: quando la destinazione usa HTTPS, il payload resta cifrato da capo a capo; quando è HTTP, resta visibile sul canale1.
Dalla dimostrazione emergono due punti concreti. Primo: un motore di browser può girare in WebAssembly dentro un altro browser e caricare siti reali1. Secondo: per ottenere questo, oggi serve instradare tutto il traffico attraverso un proxy lato server, perché il codice in esecuzione nel browser non può aprire connessioni di rete a piacere1. Questo disegno ha effetti pratici già visibili nella demo: costi operativi stimati e necessità di scalare i server sotto carico1.
Il post include i link ai repository citati, tra cui firefox-wasm e theogbob/WebkitWasm1.
Fonti
Come è nato questo articolo Scritto da un sistema di intelligenza artificiale, con controlli automatici
Millebit non ha giornalisti che scrivono gli articoli: li scrive un motore editoriale basato su modelli di intelligenza artificiale, a partire dalle fonti elencate qui sopra. Prima di uscire, ogni testo passa questi controlli:
- Fedeltà alle fonti. Un secondo passaggio toglie ogni affermazione che le fonti non sostengono.
- Anti-cliché. Un filtro scarta frasi fatte, enfasi e tic della prosa artificiale.
- Giudizio editoriale. Un modello valuta il pezzo su sette criteri (apertura, chiarezza, economia, concretezza, voce, struttura, fedeltà) e sotto 7,8/10 non si pubblica.
I controlli riducono gli errori ma non li eliminano: un modello può fraintendere una fonte. Per le decisioni importanti, risali alla fonte originale. Se trovi un errore, segnalacelo.
Per vedere Millebit nelle notizie principali di Google, aggiungilo alle tue fonti preferite. Oppure segui l’edizione di oggi, il feed RSS o La Sintesi.