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.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?