Mozilla bouwt PDF-lezer in Firefox
Mozilla werkt aan een project om Firefox via HTML5 en JavaScript PDF-bestanden te laten openen, waardoor gebruikers geen externe plugin meer nodig hebben. Firefox zou na Google Chrome de tweede browser met een ingebouwde PDF-lezer zijn, alleen hanteert Mozilla een andere aanpak. Chrome gebruikt namelijk een API voor de plugin, terwijl Mozilla voor een combinatie van HTML5 en JavaScript kiest om PDF-bestanden weer te geven. Het project heet dan ook toepasselijk "pdf.js".
Volgens Mozilla-onderzoeker Andreas Gal komt dit de veiligheid van gebruikers ten goede. "De traditionele aanpak voor het renderen van PDFs in een browser is het gebruik van een native-code plugin, ofwel Adobe's eigen PDF-lezer of andere commerciële renderers, of een open source alternatief, bijvoorbeeld poppler", aldus Gal op zijn eigen blog.
"Vanuit een beveiligingsperspectief gezien, vergroot dit te vertrouwen codebasis, en daarom doet Google's Chrome browser veel moeite om de PDF-renderers te sandboxen, om zo code-injectie aanvallen te voorkomen. Een HTML5-gebaseerde implementatie is volledig immuun voor dit soort problemen."
Plugin
In eerste instantie zal Mozilla de ingebouwde PDF-lezer als plugin beschikbaar maken, maar het uiteindelijke doel is het implementeren van de PDF-lezer binnen Firefox zelf.
"Dit zorgt voor wezenlijke bruikbaarheid, maar ook beveiligingsverbeteringen voor onze gebruikers. Pdf.js gebruikt alleen veilige webtalen en bevat geen native code gedeelten die aanvallers kunnen misbruiken", zo laat Gal weten. Kwetsbare PDF-plugins zijn al jaren een oorzaak dat aanvallers systemen van internetgebruikers kunnen overnemen.
En ze gaan nu ook het geheugengebruik eens aanpakken. Maar vergeleken met Chrome vind ik het wel meevallen.
Safari heeft dit ook al.
Functioneel begrijp ik al totaal niet waarom objecten, die niet binnen een HTML pagina gerenderd hoeven te worden, zonodig in een webbrowser getoond moeten worden. Vaak wordt allerlei functionaliteit geschrapt t.o.v. de full blow viewer of editor (bijv. zoekfunctionaliteit), is onduidelijk of keyboard shortcuts naar de browser of naar de plugin gaan, en heb je minder effectieve schermoppervlakte voor de informatie die je bekijkt.
Daarnaast betekent meer functionaliteit in een webbrowser een loggere en zwaardere (geheugenvretende en langzamer opstartende) applicatie.
Vanuit security oogpunt vormt elke plugin een risico (PDF zou wel eens het grootste risico gemeten over de afgelopen 10 jaar kunnen zijn). Naast het "dikker" en trager worden van de webbrowser wordt hiermee ook het aanvalsoppervlak vergroot en neemt de noodzaak tot vaker patchen toe. KISS, anyone?
Mijn grote voorkeur heeft het als de gebruiker voor bedoelde objecten altijd een vraag krijgt of hij/zij deze wil opslaan of openen, naar keuze in de default voor de bestandsextensie geconfigureerde applicatie of in een alternatieve toepassing (bij een twijfelachtige .pdf bijv. een veiliger geachte app met minder functionaliteit en/of minder features, bij een .doc bijv. de Word viewer i.p.v. Word). Met zo'n vraag aan de gebruiker voorkom je in elk geval dat een PDF exploit door het slechts bezoeken van een webpagina zonder enige gebruikerinteractie er in slaagt malware te starten.
Om een uitvoerder programma te kunnen starten is met een Mac overigens ook iets meer nodig dan op 'n Startknop drukken of op een bestand eindigend met .com of .exe te dubbelklikken. Ik zwijg maar over zichzelf startende informatiedragers als CD's, DVD's, USB-stokjes, laat staan die vermaledijde, ik kan het haast niet uit m'n mond krijgen Active Directories. Die zijn pas link...
Heb je 't wel goed gelezen? Ze renderen de pdf compleet met alleen JavaScript + HTML, dus geen nieuwe aanvalsfactor. Zoals gezegd, de PDF-viewer is niet meer dan een geavanceerde webpagina, dus keyboard shortcuts e.d. zijn ook geen probleem. (I.t.t. de Ctrl+Tab etc. die worden afgevangen door bijvoorbeeld de Adobe-plugin.)
En meer functionaliteit? HTML en Javascript worden native ondersteund, dus dat argument gaat ook al niet op. Moet ik nog even de rest van de punten opnoemen, of ga je het artikel lezen?
Uit http://blog.mozilla.com/cjones/2011/06/15/overview-of-pdf-js-guts/
[...]
Canvas has problems though. First, it’s missing many features needed to render PDFs. We’ve starting adding some of these to the web (->https://bugzilla.mozilla.org/show_bug.cgi?id=655926) platform (->https://bugzilla.mozilla.org/show_bug.cgi?id=662038), when it makes sense to do so, and there’s more to come.
Als PDF viewen een vast onderdeel wordt van Firefox voorspel ik een lompe webbrowser met veel meer patches dan nu het geval is.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime
Ben jij er klaar voor om de leiding te nemen in het bevorderen van de regionale samen-werking in de strijd tegen gedigitaliseerde criminaliteit en cybercrime? Samen met collega's, politie en regionale en landelijke partners? Dan is de dynamische rol van Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime bij het Regionaal Samenwerkingsverband Integrale Veiligheid (RSIV) jouw op het lijf geschreven!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.