No @ale purtroppo questa è una risposta frequente di fronte ad un problema architetturale di sicurezza, ma è semplicemente sbagliata.
Il fatto che un software implementi perfettamente delle specifiche, non garantisce la sicurezza degli utenti se tali specifiche sono fallate. Questo è tanto più vero per i browser WHATWG, che determinano i cosiddetti Living Standards attraverso l’implementazione: lo so che è paradossale, ma le specifiche del Web seguono l’implementazione più influente politicamente all’interno del WHATWG, e non solo di fatto, ma proprio by design,
Oggi le implementazioni più influenti sono Firefox e Chrome, ma Firefox perde terreno ogni giorno che passa, perché la sua influenza dipende dalla sua credibilità, e da qualche anno sta facendo un errore strategico dopo l’altro, tanto che iniziano a diventare evidenti persino ai suoi sostenitori.
Come ho fatto notare ai vertici di Mozilla, affrontare apertamente e tempestivamente questa classe di vulnerabilità avrebbe potuto cambiare rapidamente lo status quo, rivelando al mondo la profonda insicurezza (personale, aziendale e geopolitica) degli strumenti cui si affida al di là dell’ipocrisia e della retorica del Web.
Ma ti prego, non definire un bug architetturale di queste dimensioni “feature”.
Una backdoor installata e razionalizzata da miliardi di persone nel mondo è una feature solo se sei una potenza militare che distribuisce la stragrande maggioranza dei contenuti web.
Il problema non è JavaScript.
(e questo, detto da me che lo conosco più di quanto lo odio, dovrebbe seminare il panico nei cuori! 
)
Il problema è la combinazione di alcune caratteristiche fondamentali del web odierno:
- l’esecuzione automatica di programmi personalizzabili sotto il controllo di terze parti (sia JS o WASM è irrilevante)
- la distribuzione geografica di queste terze parti (hosting, cloud, cdn etc…): chi controlla il JS / WASM in esecuzione sulla tua macchina risponde a sistemi giuridici diversi dal tuo, che sia la Russia, l’Iran (in un recente attacco basato su lets encrypt), gli USA, la Cina (ricorderai certamente il DDoS a github di qualche anno fa) o chiunque altro.
- la profilazione capillare degli individui, dei gruppi e delle loro relazioni
- la pervasività della sorveglianza che permette di correlare una identità ottenuta legittimamente su un sito con le informazioni non autenticate (@calamarim giustamente osservava che i dati non aggregati non sono mai anonimi)
- l’adozione indiscriminata di HTTPS che impedisce il caching intermedio dei contenuti (a meno di MitM istituzionalizzati e razionalizzati come Cloudflare) che costringe il browser a ricontattare sempre e comunque il server autoritativo di ogni singolo contenuto
- il cache control HTTP che, sebbene abbia perso gran parte della sua utilità con la diffusione del HTTPS (l’unica cache che controlla è quella del browser in esecuzione, se visiti la stessa pagina HTTPS con due browser diversi sulla stessa macchina verrà scaricata comunque due volte dal server in autoritativo per essa e nessuno dei proxy intermedi potrà cacharla per ridurre il traffico o proteggere la tua privacy), permette di nascondere e rimuovere le prove di un avvenuto attacco
Oggi è ancora possibile detectare (con qualche difficoltà e con strumenti e competenze specialistiche) questi attacchi, ma la diffusione di DoH, HTTP/3 e soprattutto WebAssembly renderà anche questo proibitivo anche per gli esperti.
E comunque non puoi provare di aver subito un attacco del genere nemmeno se lo individui, perché trattandosi di dati, potresti averli fabbricati tu stesso. E per contro uno strozzino potrebbe salvare la contabilità illegale nella cache del browser e fingersi vittima di un attacco, con buona pace dell’informatica forense.
Tutto questo non è una feature checché ne divano gli standard (che i browser vendor hanno scritto dopo averli implementati).
Peraltro, anche formalmente, nessun passaggio degli standard WHATWG stabilisce che JavaScript debba essere abilitato di default. Dunque richiedere l’autorizzazione all’utente per l’esecuzione non violerebbe alcuno standard (tant’è che Chrome può essere facilmente configurato in questo modo). E visto che i Living Standard seguono le implementazioni, implementare queste mitigazioni in un browser maggiore è il primo passo per ridurre la vulnerabilità architetturale che il WHATWG ha creato.
Per questo ho aperto un bug report a Mozilla (per altro su suggerimento di Marco Ciurcina che in una mail aveva osservato che affinché la mia scoperta avesse rilevanza legale, i vendor dovevano essere informati pubblicamente della questione).
Perché fixare Firefiox fosse il primo passo per migliorare il Web. Un onere ed un onore che Mozilla ha buttato al vento. Lo farà anche il Partito Pirata? Non lo so…
Ma per me la questione è e rimane semplice. Se le persone che usano correttamente un mio programma possono essere attaccate attraverso di esso, non c’è specifica o strategia di marketing che tenga: si molla tutto e si chiude la falla nel modo più rapido possibile informando tutti del problema.
