Microsoft stelt veilig Gazelle-browserontwerp voor

Onderzoekers van Microsoft hebben een ontwerp voor een nieuwe veilige browser gepresenteerd. De Gazelle-browser is ontwikkeld op basis van IE7 en heeft zijn eigen besturingssysteem.

Gazelle maakt gebruik van een browserkernel die de bescherming en het delen van resources tussen websites regelt. Zo krijgt bijvoorbeeld elk iframe in een webpagina, afkomstig van een ander domein of subdomein, zijn eigen proces. Ook de netwerkcommunicatie en het renderen van de pagina's zijn volledig gescheiden processen. Het ontwerp heeft niet alleen als voordeel dat een crash van een tabblad geen consequenties heeft voor andere tabbladen of de browserkernel, maar het maakt de browser ook veilig voor hackpogingen, claimen de onderzoekers.

Plugins, een bron van potentiële beveiligingslekken, staan bij Gazelle niet langer in directe verbinding met het besturingssysteem van de pc, maar moeten gebruikmaken van Gazelle-systeemaanroepen. Ook wordt de plugin-code niet langer hergebruikt bij plugin-aanroepen van meerdere websites, maar worden hiervoor meerdere plugin-instances gecreëerd. Ontwikkelaars dienen hun plugins echter wel te herschrijven met het oog op deze api van Gazelle.

Gazelle gaat verder dan huidige browsers zoals Google's Chrome, Mozilla's Firefox of Microsofts eigen IE8 op het gebied van beveiliging. Zo worden bij Chrome geneste iframes, met een herkomst anders dan dat van de hoofdpagina, nog steeds in hetzelfde proces geplaatst als de parent-website. IE8 maakt voor elke tab een nieuw besturingssysteemproces aan, maar dit ontwerp biedt geen beveiliging voor bijvoorbeeld een iframe met content van een onbetrouwbare site.

Het Gazelle-prototype, gebaseerd op IE7 en draaiende op Vista met de 3.5-versie van het .Net-framework, biedt dan wel een rigide beveiliging, maar dit gaat momenteel nog wel ten koste van de prestaties. Zo kost het aanmaken van een nieuwe tab met google.com als url 16MB intern geheugen, terwijl dit bij IE7 slechts 1,4MB bedraagt. Ook duurt de creatie van dit tabblad bij Gazelle een seconde, terwijl IE7 hiervoor de helft nodig heeft. Surfen naar nytimes.com – met frames van verschillende herkomst – duurt zelfs meer dan zes seconden, terwijl IE7 de pagina al na 3,2 seconden heeft staan. Ook het geheugengebruik was bij Gazelle fors hoger: 88MB tegenover 53MB voor IE7.

Ondanks de magere prestaties van het huidige Gazelle-prototype zijn de onderzoekers niet uit het veld geslagen. "De implementatie en evaluatie van ons op IE-gebaseerd prototype toont de mogelijkheden van een praktische multi-principal OS-gebaseerde browser in de echte wereld. In de toekomst zullen we kijken naar het delen van resources tussen websites in onze browser kernel."

Reacties (99)

[VisionMaster]

Leuk idee om het concept van een ander nog een stuk verder door te trekken. Ik hoop dat ze er veel uitleren en hopelijk ook dat het handig is om het niet in .Net te doen om de hoeveelheid lagen van indirectie er gewoon bij de basis uit te halen. Dat zou een hoop resources en performance opleveren.

Wat ik me wel afvraag is of het niet alsnog mogelijk is het zaakie te verkloten. De processen hangen allemaal samen in het systeem, al is het maar om de inhoudt van ieder tabje, framepje of iframepje te laten zien. Er zal ook interactie worden verwacht tussen de javascript van elementen om met jQuery of andere Ajax technieken en toolkits te kunnen werken. Dat moet je nu dus in ieder afzonderlijk frame doen (prestatie verlies). Maar wat nou als die scripts van vanuit andere onderdelen wilt gebruiken? Heb je dan niet als nog een aanvals vector? Dus in dat opzicht verdwijnen een zooi minder interessante hackmogelijkheden, maar ik vraag me af hoeveel security winst je nou echt behaalt met zulke ingewikkelde truken in een dergelijk model.

[Dreamvoid]

Voordeel van .NET is dat je in een managed code omgeving zit waardoor je geen ellende met heap en stack overflows hebt (=de voornaamste reden achter al die exploits van Safari/Firefox/Opera/IE, op Windows/OS X/Linux). Eigenlijk zouden we ook nu al naar moeten streven, idealiter zou alles dat remote content opent in Java/.NET/etc moeten draaien. Helaas zijn alle volwassen renderengines nu nog in C++ gebouwd en kost het volledig ombouwen makkelijk twee jaar aan initiele coding en nog eens vier jaar bugfixen.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 01:54]

[VisionMaster]

Dat is een leuk voordeel, net als met Java, maar ja... als je een fout of een diep geworteld probleem vind en triggered in de JVM, dan crashed de hele JVM. Dat kan je ook bij .Net vinden.

Dus een indirectie heeft een voordeel, omdat je kan sandboxen in een goed in te graven omgeving, maar het mag natuurlijk geen reden zijn om troep te maken en te hopen dat je .Net of JVM je red. Je nadeel is natuurlijk de indirectie steeds. Dat vertraagt flink.

Uiteindelijk is het 'turtles all the way down'. De heap en stack overflows kan je ook op andere plekken vinden als het niet direct in je code zit. Het probleem is simpelweg dat het rotte code is gemaakt per ongeluk of ondertijdsdruk. En... ook nog populair is geworden of naar voren is geschoven als eind product.

[Dreamvoid]

Alleen is rotte code bouwen in unmanaged C++ een stuk simpeler dan in C#/Java, en vangt je CLR/JVM een hoop af, dingen die in je unmanaged code kunnen blijven zitten totdat jij of iemand anders ze ontdekt. Om het zo te zeggen: ze zijn niet onfeilbaar, maar ik sla de kwaliteit van CLR en JVM iets hoger aan dan de brouwsels die je krijgt als elke browserbouwer (onder diezelfde tijdsdruk) het wiel opnieuw gaat uitvinden en zijn eigen applicatie-specifieke VM-of-iets-wat-daarop-lijkt gaat bouwen.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 01:54]

[SunnieNL]

Vind dat je gewoon geen frames meer moet gebruiken.. om nog maar neit te spreken over iframes.. hadden ze nooit moeten bedenken.
Met CSS heb je totaal geen frames meer nodig. En ik dacht dat ajax juist bedoelt was om zonder frames dynamische inhoud te kunnen laten zien door de formulier onderdelen gewoon goed te plaatsen.

[sirono]

klopt, maar er zijn teveel websites die het nog gebruiken, dus als ze in een keer alle frames afblocken is het ook niet goed

[THAiSi]

IFrames worden veel gebruikt bij Web2.0 content, om op de achtergrond files te uploaden (kan nl niet via ajax) en om de wysiwyg editors mogelijk te maken.

[terabyte]

Waarom niet IE als een gewone applicatie, die niet zo verstrengeld is met de rest van het OS? A la Opera, Firefox, Chrome? Of zeg ik nu iets heel vreemds?

[Anoniem: 175233]

IE is als applicatie helemaal niet zo verstrengeld met de rest van het OS. Op dat punt zit er nauwelijks verschil met Opera, Firefox of Chrome.

De "verstrellingen" bestaat er meer uit, dat het OS voor veel taken een html engine gebruikt. Bijvoorbeeld voor de help functie. En dan is het logisch dat je daarvoor de al aanwezige renderer gebruikt.

Omdat er geen gestandaardiseerde structuur voor het aanspreken van een pure html engines is, is het niet zo simpel dat met een andere browser engines dan IE te doen.

[geert1]

Tja, is iets voor te zeggen, maar het heeft natuurlijk ook voordelen dat IE in het OS verweven is. Vooral de opstarttijd, die toch een stuk korter is dan die van Firefox.

[Dykam]

Want internet-explorer wordt geladen tijdens het starten van Windows, welke langer duurt.

Al vind ik wel dat de EC nu niet ineens met boetes moet dreigen nadat MS IE volledig legaal heeft geintregreerd in Windows, wat de efficiëntie ten goede kwam.

Ben zelf overig Firefox aanhanger vanwege 3 krachtige web-development addons.

[Anoniem: 80466]

IE8 maakt voor elke tab een nieuw besturingssysteemproces aan,

Dat is niet juist. IE8 verdeelt de geopende tabs over een stuk vier processen.
Wel worden eventueel gecrashte pagina's opnieuwe geopen in seprate processen.

[S2K]

Dit heeft vaag wat weg van Sandboxie: http://www.sandboxie.com/

Dit creëert een eigen beveiligde browser omgeving maar je kan ook andere programmatuur daarin draaien. Met name programmatuur die je niet vertrouwd.

[SunnieNL]

tis gewoon een doorontwikkeling van de sandbox die aanwezig is als je IE7 in Vista met UAC aan start.... ;-)

[Anoniem: 175233]

Dit gaat natuurlijk veel en veel verder... Met een sandbox heb je de browser afgeschermd van de rest van het systeem. Maar meer ook niet.

Met Gazelle heb je de inviduele pagina's in de browser afgeschermd van andere pagina's, en de renderer afschermd van code, etc etc...

Van de ene kant lijkt dat overkill, van de andere kant is de browser natuurlijk bij uitstek het onderdeel van het OS waar de meeste aanvallen op uitgevoerd worden.

[Anoniem: 24417]

ik dacht dat iframes niet of nauwelijks meer gebruikt werden. hoe zit het met via ajax ingeladen externe pagina's? worden die ook in een eigen process gedraaid?

verder lijkt me dat de balans prestaties/veiligheid een beetje naar rechts is doorgeslagen. leuk voor de security freak maar verder niet bijster nuttig. zelfs 'normale' browsers als firefox vreten al ziekelijk veel geheugen, dit wordt zo alleen maar erger natuurlijk..

[NNF]

Geheugengebruik, who cares? Geheugen is tegenwoordig spotgoedkoop en nieuwe systemen hebben minimaal 2GB RAM. En ongebruikt geheugen is nutteloos geheugen. Het zal mij echt worst wezen of Firefox nu 50MB, 100MB of 200MB gebruikt.

[kimborntobewild]

Zoals gebruikelijk, zijn er weer de nodige aantallen naïevelingen.
"640K ought to be enough..."

Zo kost het aanmaken van een nieuwe tab met google.com als url 16MB intern geheugen, terwijl dit bij IE7 slechts 1,4MB bedraagt.

Da's een 11-voudig gebruik van 't geheugen. Op dit moment neemt mijn browser 254MB geheugen in beslag (met zo'n 30 tabs open). Dat zou dan opeens bijna 3GB geheugen gaan worden...
Jongens, welke fabriek maakt de meeste geheugenmodules? Ff mijn aandelenpakket bijstellen...

Ik kan me ook niet aan de indruk onttrekken dat ook 1,4MB (zo'n 700 pagina's ongecomprimeerde tekst) voor 't bijhouden van een nagenoeg kale pagina (google.com) al erg veel is. Volgens mij wordt 't hoog tijd dat men meer in hogere programmeertalen gaat werken om de code stukken compacter te houden.

[Reactie gewijzigd door kimborntobewild op 23 juli 2024 01:54]

[Rekcor]

Gazelle maakt gebruik van een browserkernel die de bescherming en het delen van resources tussen websites regelt. Zo krijgt bijvoorbeeld elk iframe in een webpagina, afkomstig van een ander domein of subdomein, zijn eigen proces.

Heeft dit nu ook voordelen voor pc's met meerdere CPU-cores? Ik kan me zomaar voorstellen dat het ene proces op core 1 draait en het andere proces op core 2, en dat je dus in principe een hoop kunt winnen aan performance

[Exception]

Dus nog een browser erbij?

[truegrit]

Hij zal wel de IE rendering engine gebruiken, dus voor webdesigners geen extra zorgen

[urharm]

Of juist extra zorgen, omdat gazelle nog gebruik maakt van de, niet webstandaard respecterende, IE7 renderer. Daarnaast zal dit weer een reden kunnen zijn dat mensen weer terugstappen naar deze renderer, zodat er juist meer rekening gehouden moet worden voor deze browser, wil je een groot publiek bereiken.

[KilZone]

Ik denk niet dat Microsoft Gazelle uitbrengt met enkel de IE7 rendering engine. Het zou in ieder geval tactisch en marketing technisch een onhandige zet zijn, vanwege de hoge druk van de community op de standaarden (die overigens niet betekenen dat de website goed geschreven is, maar dat is een ander verhaal).

Ik denk dat Microsoft gekozen heeft voor IE7 omdat dit op het moment hun laatste 'stabiele' rendering engine is. Het is namelijk heel onhandig om in een 'principe product' een beta van een ander product te stoppen. Zo is het onmogelijk te zien of het probleem komt door de rendering engine of door de werking van Gazelle.

Op dit moment kunnen ze dus door de IE7 rendering engine te gebruiken met redelijke zekerheid zeggen dat een crash of probleem met de site (niet uiterlijk, maar werking ervan) komt door de (nieuwe) werking van Gazelle. Als het Gazelle-model goed genoeg werkt om als beta uit te brengen, dan is het vroeg genoeg om daar de IE8 rendering engine in te inplanteren (die hopelijk dan uit beta is).

[roy-t]

Gazelle's ontwikkeling is gestart toen IE7 de meest up-to-date render engine was. En het project heeft toen die versie gebruikt.

Het is nu niet meer dan een tech-demo en ik vermoed dat Gazelle pas ingezet wordt voor IE9 of IE10, dan met support van het hele IE team en met een actuele render engine die het pad volgt dat MS nu is ingeslagen (meer standard compliant).

[Sgreehder]

Dat valt wel mee, IE7 doet het heel aardig, en die paar problemen zijn uitstekend gedocumenteerd. Overigens lijkt het niet de belangrijkste poot van dit project; het is immers een prototype.

[Anoniem: 149075]

Ik hoop dat je deze browser ook dedicated kan starten op een systeem zonder iets anders erop te hebben.

Dat lijkt me ideaal als hij zijn eigen OS toch al "draait".

[Franckey]

Als je dat wilt draai je toch gewoon de meest lichte Linux variant waarmee je Firefox kan draaien?

[Anoniem: 43714]

Dat is niet waar ik hier op doel. Ik bedoel hier de Linux versie die vanuit een rom draait met een arm processor, voordat het hoofd OS opstart, als je dat dan tenminste wilt. Het komt al in laptops, netbooks en sommige moederborden hebben het ook al.


btw, ik 'draai' Linux

[Anoniem: 43714]

Dat zou best wel eens de bedoeling kunnen zijn. Met de komst van de mini Linux varianten, die gescheiden van het hoofd OS kunnen opstarten, zal MS iets vergelijkbaars moeten maken om niet teveel marktaandeel te verliezen in het netbook segment lijkt me.
Steeds meer zaken/programma's verplaatsen zich naar het internet en dan is zoiets best handig. Je kunt dan lekker lang met een accu doen.

[Anoniem: 251048]

Allemaal leuk en aardig zon veilige browser, maar zolang het surfen langer duurt dan andere browsers zal niemand hier op overstappen, daarvoor zijn er betere alternatieven.

[sirono]

toch zullen uiteindelijk een hoop mensen overstappen op zo'n browser.
als microsoft hem simpelweg mee gaat leveren met windows in 2011 ofzo gaan een hoop mensen hem automatisch gebruiken!

[Anoniem: 175233]

Welke betere alternatieven?

De architectuur die voor Gazelle omschreven wordt, zit in geen enkele browser. Die aparte processen voor tabbladen van Chrome zijn kleuterwerk, in vergelijking met wat MS hier voorstelt. Er zijn dus gewoon geen alternatieven...

Uiteraard is zo'n complexe structuur langzamer... Iedere veiligheids barriere levert onherroepelijk prestatie verlies en ongemak op. MS is nu aan het uitproberen hoe ze dat niettemin toch zo goed mogelijk kunnen inpakken.

[thegve]

Dat heet een concept cq "ontwerp". Heeft niets met een definitief product te maken en het hoeft zelfs nog niet eens een definitief ontwerp te worden.
Microsoft zal zelf ook wel begrijpen dat een dergelijke browser "niet goed zal zijn voor hun imago".

[renevanh]

Surfen naar nytimes.com – met frames van verschillende herkomst – duurt zelfs meer dan zes seconden, terwijl IE7 de pagina al na 3,2 seconden heeft staan.

En Chrome in krap 2 seconden...

Het 'idee' van MS doet wel heel erg denken aan het idee achter Chrome waarbij alle tabbladen een eigen proces hebben.

[Keypunchie]

Klopt, dit is inderdaad het idee achter chrome.

Het team van Chrome heeft een heel aardige 'comic' gemaakt, waarin ze ook proberen dit technische idee achter de browser in (voor een beetje tweaker) begrijpbare termen uit te leggen.

http://www.google.com/googlebooks/chrome/

(al in de eerste pagina's wordt het toegelicht).

Ik vind het jammer dat Chrome er alleen nog maar voor Windows is, want ik zou het graag eens op mijn Mac gebruiken.

[Cyw00d]

Als het goed is zijn ze daar nu mee bezig.

[NLChris]

Ik heb nog nooit een tabblad zien crashen bij Chrome. Als hij vastliep ging de hele browser. Dus ook bij Google moet er nog verder gewerkt worden aan deze functionaliteit

[psychodude]

Ik heb tabbladen bij chrome wel zien vastlopen. Maarja, dan heb je er nog weinig aan want hoe heten de processes? Juist, chrome.exe . Het tabblad sluit zichzelf vervolgens ook niet ofzo dus blijft daar maar een beetje in de weg staan.

IE8 doet daarbij precies hetzelfde, ieder tabblad in een eigen process maar loopt het vast kan je sluiten eigenlijk wel vergeten. Alhoewel op het kruisje drukken bij IE8 soms nog wel reageert maar duurt het vaak lang.

[Aaargh!]

Ik heb tabbladen bij chrome wel zien vastlopen. Maarja, dan heb je er nog weinig aan want hoe heten de processes? Juist, chrome.exe

Je weet dat Chrome een eigen taskmanager aan boord heeft precies voor dit soort doeleinden ?

[psychodude]

Nee, eigenlijk niet . Niet duidelijk aangegeven van Google , waar vind ik hem ergens?

Edit: Nounou, die sad smiley kijkt wel erg boos XD.

[Reactie gewijzigd door psychodude op 23 juli 2024 01:54]

[Lightmanone1984]

Heel makkelijk: rechtsklik in de bovenbalk (op een plaats waar geen tabblad is) en dan naar de 1-na onderste optie: task manager.. of via de tabblad in de windows taakbalk, zelfde optie..

De taskmanager is vrijwel altijd beschikbaar en opvraagbaar, zelfs als chrome vastloopt (hoe raar dit ook klinkt)

[Glashelder]

Ik heb al zo vaak bij IE8 het bericht gezien "This tab has been recovered".. Dan was er een tab gecrashed en was die automatisch weer hersteld.

Hier werkt het prima.

[Neko Koneko]

edit: ja hoor.. mod me maar omlaag.. omdat ikM$ zeg.. waar is de "vrijheid van meningsuiting" nu.. stelletje

Nee, je zit gewoon te flamen. En M$ zeggen is eigenlijk ook kinderachtig. Dan is het ook Googl€ of Appl€.

IE crashed bij mij trouwens nagenoeg nooit, en als het crashed komt dat door een plugin als die waardeloze Adobe Flash player.

[jqv]

En wat te denken van ie8.
Daar crashed dus wel een tabblad (nog niet gezien trouwens bij mezelf), maar niet de andere.

Chrome heeft ook nog een lange weg te gaan...