Gli exploit si dividono in due categorie distinte: quelli che infrangono le regole semantiche del linguaggio di implementazione (buffer overflow, use-after-free, cast di tipi non controllati ...) e quelli che giocano "secondo le regole". Dato che il nuovo lettore PDF è scritto in Javascript, gli exploit della prima categoria dovrebbero essere estremamente rari, a causa della protezione intrinseca integrata nella lingua (accessi di array controllati, garbage collection, tipizzazione strong ...). Per ottenere un'esecuzione arbitraria di codice da software Javascript, devi trovare un buco nel motore JavaScript stesso; i buchi nel software scritto in Javascript porteranno "solo" a un'eccezione, cioè a un arresto anomalo del software, il che è sconveniente, ma non tanto quanto vedere la tua macchina dirottata.
Presumibilmente, il motore Javascript di Firefox è stato accuratamente testato, poiché è molto usato.
Gli exploit che riproducono "secondo le regole" includono tutti i metodi per aggirare la Stessa politica di origine e l'abuso di gateway per i locali risorse. Questi non sono resi intrinsecamente più difficili o più facili in virtù del fatto che il lettore PDF sia implementato in Javascript. Tuttavia, fare cose del genere è simile al rendering di contenuti Web in modo sicuro, cosa che è stata per anni l'obiettivo principale di Firefox. Possiamo sperare che implementando il rendering PDF nel browser, saranno in grado di cavalcare il duro lavoro già fatto per proteggere il tuo browser da pagine Web ostili. Almeno, quando si tratta di contenere script PDF in una sandbox appropriata, mi fiderei delle persone che lo hanno fatto per anni (gli sviluppatori di Firefox) più delle persone per le quali questo è solo un elemento di lavoro secondario, distinto dal loro core craft ( gli sviluppatori di Adobe Reader).
Quindi, per sicurezza , questo nuovo lettore sembra davvero abbastanza promettente. Le cose diventano migliori, non peggiori.