Mozilla: nieuwe browserengine Servo doorloopt Acid2-test succesvol

Mozilla Labs meldt dat de in aanbouw zijnde Servo-renderengine de Acid2-browsertest met succes heeft weten te doorlopen. Servo kan zijn layout-taken in een parallele omgeving laten draaien, waardoor het beter uit de voeten kan met multicore-cpu's en gpu's.

De Acid-tests worden al jarenlang gebruikt om te controleren of browsers zich houden aan webstandaarden. De Acid2-testpagina kwam in 2005 online en bevatte onder andere css- en html-tests. Volgens Mozilla Labs heeft zijn Servo-renderengine deze lakmoesproef nu succesvol doorlopen door de pagina correct te renderen. Daarmee is een belangrijke stap in de ontwikkeling van de renderengine gezet, zo stelt de browserbouwer. Overigens werd de Acid1-test in augustus vorig jaar door Servo met succes doorlopen.

Mozilla werkt bij de ontwikkeling van Servo samen met Samsung. De renderengine zou in de huidige staat volgens Mozilla ook in single threaded-modus al beter presteren dan die van huidige browsers, terwijl de prestaties in multi-threaded-modus logischerwijs nog flink toenemen.

Servo wordt geschreven in Rust, een nieuwe programmeertaal waar Mozilla Research aan werkt. Rust zou door een modernere architectuur geen last hebben van beveiligingsproblemen als buffer overflows en een veiliger geheugenbeheer hebben. Daarmee zouden bugs als Heartbleed onmogelijk zijn omdat deze door de Rust-compiler automatisch worden voorkomen.

Reacties (58)

tja, je kunt ook zeggen dat er steeds meer troep op het internet gebruikt wordt, veel pagina's laden al door alle onzin als dikke stront...
Het wordt ook eens hard tijd dat ze de HTML specificaties beter gaan definieeren zodat er geen verschillende interpretaties kunnen ontstaan (wat in het verleden ook een oorzaak was voor de grote verschillen tussen browsers).

Goede strategie om het forken van eigen ontwikkelde technologie door externen te bemoeilijken; Schrijf het gewoon in je eigen ontwikkelde programmeertaal met obscure syntax

Ik snap gezien je naam dat je niks met Rust hebt, maar er zitten wel degelijk voordelen aan Rust. De taal zou in principe niet zwaarder moeten zijn dan C++, maar is moderner. Zo is de taal wat functioneler omdat data immutable-by-default is en je first class functions hebt. Ook zitten er moderne dingen in om buffer overflows tegen te gaan. Op die manier zijn ze in staat Servo makkelijker (dan in de C++ waar Gecko in is geschreven) paralleliseerbaar te maken én veiliger.

Ik val Rust ook niet aan m.b.t. de functionaliteiten die het biedt.

Integendeel, het klinkt als een ware verademing. Die je enkel terug ziet in 'Runtime Enviroment'-talen zoals Java en C#.

Echter, de syntax is om te huilen. Het heeft niet de consistentie en niveau van gestructureerde layout zoals dat bij C en C++.

Return types achter de functie. Functie parameters en types ervan omgedraaid, lokale variabelen die niet getyped zijn. Semicolon die dan weer wel en dan weer niet nodig is. Alsof iemand een C++ clone wil maken en koste wat kost syntax van Objective-C, JavaScript en CoffeeScript in wil rammen.

Ik kan niet gedetailleerd op je reactie ingaan omdat ik Rust niet ken, maar om er even iets uit te lichten:

Echter, de syntax is om te huilen. (..) Return types achter de functie.

Dat doen wel meer talen en het is maar net wat je gewend bent; na tien jaar voornamelijk in Pascal gewerkt te hebben vond ik C's conventie juist wennen. Als je een reden hebt waarom het slechter zou zijn: laat maar horen. Maar als je enige bezwaar is dat het iets anders is dan wat je gewend bent, dan kan ik dat moeilijk als een probleem met Rust beschouwen...

De klachten 'return types achter de functie' en 'lokale variabelen die niet getyped zijn' klinkt mij alsof RoestVrijStaal nog nooit een functionele programmeertaal heeft gezien. Ik kan echter best een voorbeeld noemen waar de syntax van Rust te wensen overlaat.

Rust heeft ADTs en pattern matching. Ik ben zelf Haskell gewend en daar vind je die dingen overal terug. Hoewel een case-expressie in Haskell best lelijk kan worden, is de syntactische structuur ervan ontzettend regelmatig. Van Rust weet ik na tien minuten naar de tutorial gestaard te hebben nog steeds niet hoe een match-blokken syntactisch gezien werkt.

[Reactie gewijzigd door Anoniem: 164019 op 20 april 2014 18:41]

Heb je de OpenSSL-broncode wel eens gezien? Of C++ met allerlei template-hocuspocus door elkaar? Ik ga niet zeggen dat ik Rust mooi vind maar de bende van C/C++ aandragen als consistent en gestructureerd gaat veel en veel te ver. Als je eens een functionele taal als Scala of OCaml zou proberen zou je de Rust-syntax beter begrijpen.

Blijkbaar kwam de grap van Rust en RoestVrij ook niet over maar ja

Kijk alsjeblieft ook even naar functionele programmeertalen voor je opmerkingen maakt over taalontwerp. Functionele programmeertalen ontlenen veel syntax uit typentheorie, waarbij...

Return types achter de functie.

functietypes als `a -> b` geschreven worden, en

Functie parameters en types ervan omgedraaid

typering als `x : t` geschreven wordt. Nu is Rust geen (pure) functionele programmeertaal, maar daarom is deze syntax niet minder op z'n plek. Het alternatief is namelijk de achterlijke C-stijl van typenotatie, die vooral onleesbaar wordt als je je aan hogere-ordefuncties wilt wagen. Alsof de spiral rule zo handig is.

lokale variabelen die niet getyped zijn.

Type reconstruction is behoorlijk handig als je jezelf niet wil herhalen.

[Reactie gewijzigd door Anoniem: 164019 op 20 april 2014 18:56]

Helaas is het sentiment qua buffer overflows misplaatst. Heartbleed komt in eerste instantie omdat een count in een packet van buiten het systeem niet gechecked wordt.

En "buiten" het systeem wordt niet door de taal gemanaged, dus zulke bufferoverflow protectie mechanismes zijn daar ongevoelig voor. (nog afgezien dat het onwaarschijnlijk is dat de nieuwe browser SSL in Rust gaat herimplementeren)

Oftewel, language buffer protectie vermijdt slechts enkele vormen van buffer overflow problemen. En dan nog in het beste geval.

[Reactie gewijzigd door marcovtjetje op 18 april 2014 17:01]

Het gaat niet zozeer om buffer overflows, maar uberhaupt om het werken met buffers en pointers. In C is de enige manier om zo'n actie die Heartbleed mogelijk te maken een handmatige memcpy()-aanroep. In Rust heb je niet zomaar een memcpy() voor handen maar wel andere methoden die dit kopieren automatisch goed doen. Dat is het verschil.

Ah mooi. Andere browsers en ook firefox kwamen toch al volledig door de test?
Desalniettemin is dit fijn om te horen, je internetbrowser is het programma, dat een grote diversiteit aan code, vanuit een groot aantal onbekende bronnen voor de je draait. Juist dan is het zeer belangrijk dat je nieuwe* engine volgens dé webstandaard draait.

Het is wel goed dat de Firefox engine verbeterd wordt.
Chrome had op de desktop vaak de beste scores in de uitgebreidere HTML5 test.
En mobiel liep Firefox, ook achter op Chrome en vooral de Blackberry Browser.
Maar het is mooi, dat firefox weer stappen maakt, en ik hoop dat ze ook in snelheid in de buurt komen van Chromium op de desktop, of Blackberry (3x zo snel) op de mobiele platforms.

[Reactie gewijzigd door 3x3 op 18 april 2014 11:50]

Dit is een nieuwe render/layout engine. Voor zover ik weet gebruikt Firefox nog Gecko http://en.wikipedia.org/wiki/Gecko_%28software%29
Opera is ook al een tijdje over op webkit (waar safari en chrome al langer gebruik van maken)
Internet explorer gebruikt trident http://nl.wikipedia.org/wiki/Trident_%28layout-engine%29

Intussen zijn Chromium (Chrome) en Opera door op Blink, een fork van webkit

Snelheid op de desktop is minder belangrijk dan geheugengebruik en dat zit wel snor met Firefox. Ik heb ~100 tabs openstaan in Pale Moon voor ~3 GB aan geheugen.

Dit omdat Firefox tabs die niet recent gebruikt zijn uit het geheugen haalt en enkel in cache laat staan. Chrome probeert alles in het geheugen te houden totdat je begint te swappen telkens je tussen tabs schakelt.

Oftewel: tussen tabs switchen gaat nog steeds erg traag. Ook openen van meerdere tabbladen (tegelijk of snel achter elkaar) is nog steeds iets wat Firefox niet goed kan. Ook is de performance op pagina's met flash nog steeds erg matig.

Tussen tabs switchen gaat wel vlot, als deze in het geheugen zitten. Dat je bij tabs die je nog niet open hebt gehad even moet wachten, vind ik niet zo'n probleem. Het lijkt me overigens veel aangenamer om enkel even te moeten wachten voor de tabs die je werkelijk gebruikt, dan je sessie met honderd tabs openen en 10 minuten moeten wachten voor je browser eindelijk klaar is

Op je andere twee puntjes heb ik geen commentaar. Ik open niet zo vaak 10 tabs tegelijk, dus heb er niet zoveel last van als dat zo is. Van problemen met flash merk ik ook niet echt iets, maar misschien heeft mijn redelijk recente i7 daar wel mee te maken

Die HTML5Test zegt echter niks. Het is leuk als je browser het kent, maar begrijpt het ook wat het moet doen? Daar test die test niet op. Om maar te zwijgen over het feit dat lang niet alles in de HTML5Test überhaupt HTML5 is, en als het dat al niet is, is het zelfs niet eens een standaard. Chrome verdient in de HTML5Test ontzettend veel punten met ongestandariseerde onderdelen.

Je hebt gelijk, alleen de html5 test zegt niet alles.
Wel is het zo dat een functie kan ook best handig zijn als hij nog niet gestandaardiseerd is.

Omdat de html5 test niet alles zegt heb ik ook een toevoeging heb gedaan van het onderzoek naar 16 Miljard page load times. Zodat niet alleen (mogelijke) functies, gemeten zijn. Maar ook daadwerkelijke snelheid. Winnaars(incl het huidige FF) die zich in de top3 van de html5-test scharen, vind je ook terug in de top3 kortste laadtijden.

Wel opvallend dat Internet Explorer 11 bij die snelheidstest volledig is weggelaten. Chrome 30 is rond dezelfde tijd uitgebracht, en staat er wel gewoon in. Firefox 25 is zelfs na IE11 gelanceerd. Waarom wordt juist Internet Explorer 11, die vele performance verbeteringen heeft gekregen tegenover IE10, uit die test gelaten? Tests die browsers weg laten om welke reden dan ook terwijl die browsers zeker noemenswaardig zijn, neem ik niet voor serieus. Dan weet je gewoon dat er iets niet klopt.

Scratch that. Toen ik ging kijken wat Mozilla Gecko 11 was, bleek dit Internet Explorer 11 te zijn. M.a.w. IE11 staat voor IE10 op de per OS test bij Windows en 3de bij Desktop/Laptop.

[Reactie gewijzigd door Loller1 op 18 april 2014 18:30]

Mja ik heb ook het idee dat ze het niet op Windows 8 hebben getest. Daar start IE sowieso sneller op dan in Win7. En IE11 heeft inderdaad een hele snelle Javascript engine. Enige waar hij tegen lijkt te vallen is enkele browser-tests die specifiek op Webkit zijn toegepast.

Het is niet zo dat Firefox tot nu toe niet door de test kwam. Ze zijn bezig met het ontwikkelen van een nieuwe renderengine, die misschien later de huidige firefox render engine moet vervangen. Deze nieuwe engine is nu echter van zodanig niveau dat hij de acid test haalt, wat best een prestatie is.

Ik ben alleen een beetje bang dat hij alleen de Acid-test haalt en alles wat daarin niet getest wordt een op z'n best beroerd uit ziet, maar dat is slechts speculatie.

Als een test niet representatief is voor wat op websites verwacht kan worden heeft hij geen zin.

De meeste testen geven geen granatie voor succes, maar slechts uitsluiting van specifiek falen. Een fietsband moet bijvoorbeeld een druk van 3 bar kunnen weerstaan. Dat wil echter niet zeggen dat ieder object dat 3 bar kan weerstaan een goede fietsband is. Als je dus gaat ontwerpen om een test te kunnen doorstaan dan is dat waanzin. Als je bij het ontwerp een test in het oog houdt kan dat geen kwaad.

Ziet er goed uit. Sneller en veiliger is wel een must zo langzamerhand met al die shit op het web!

Daarmee zouden bugs als Heartbleed onmogelijk zijn omdat deze door de Rust-compiler automatisch worden voorkomen.

De compiler voorkomt dit niet, het is het memory allocatie systeem van de taal die het voorkomt. Heartbleed is trouwens geen buffer overflow bug, het was een bug in de ping. Het probleem zat in de data die ge-echo'ed wordt. Er werd gevraagd om b.v. 64000 bytes te echo'en er werden b.v. 10 opgestuurd. De ontvanger alloceerde dan 64000 bytes en overschreef de eerste 10 en echode vervolgens de hele buffer. De rest van de buffer bevatte dus eerder vrijgegeven heap geheugen waar nog vanalles in kon staan.

Zo snel ik het kon zien wordt dit voorkomen in rust door geheugen met 0 te vullen bij het vrijgeven. Overigens was het vroeger ook al "best practice" om wachtwoorden en gevoelige data niet in unallocated geheugen achter te laten maar met 0 te overschrijven. Nu hoef je daar bij Rust dus niet meer over na te denken want dat gebeurt automatisch.

Overigens managed omgevingen zoals Java en .Net bieden deze bescherming ook.

Maakt dat soort automatische met 0 overschrijven het process niet langzamer dan een taal waar in dat niet automatisch gebeurt. Dit omdat het meer geheugenactie vraagt? Ik weet dat geheugen heel snel is, maar alle beetjes helpen.

Vast wel, maar het is de vraag wat je liever hebt: een heartbleed bug of dat je ssl connectie 10 microseconde sneller is opgebouwd? Voor mezelf weet ik het antwoord wel

In C bestaat er ook zoiets: calloc() ipv malloc()

Een taal is maar zo goed als de programmeur die ze gebruikt...

das maar deels waar... als de taal inherent niet andere geheugen ruimte vrijgeeft dan kan je dat ook niet perrongelijk programmeren..

Het is nog veel erger: OpenSSL omzeilt standaard allocatie routines en heeft ze zelf geknutsteld. Hierin zit het probleem. Het is jammer dat OpenSSL nog zo populair is. Los van de kwaliteit van het product zie je dat zo'n monocultuur een klein probleem ineens heel groot maakt.

Tuurlijk is een taal zo goed als zijn programmeur, maar elke verbetering zorgt er wel voor dat een programmeur minder vouten kan maken :-)

(en ja ik weet dat vout fout geschreven is)

(en ja ik weet dat vout fout geschreven is)

Dat was wel duidelijk dat je dat met opzet deed. Over dat (nogal beschamende) "perrongelijk" van die andere reactie heb ik zo m'n twijfels.

De compiler voorkomt dit niet, het is het memory allocatie systeem van de taal die het voorkomt.

En waar wordt, bij een non-1G taal, het memory allocatie systeem geregeld?......

In sommige talen moet je geheugen inderdaad specifiek alloceren (zoals, bijvoorbeeld, C). In de meeste moderne talen wordt geheugen toewijzing geautomatiseerd in de compiler. Het is impliciet onderdeel van de manier waarop de taal in elkaar steekt maar wordt geïmplementeerd door de compiler.

[...]
En waar wordt, bij een non-1G taal, het memory allocatie systeem geregeld?......

In ieder geval niet door de compiler.
Het enige wat een compiler doet is programma- en/of bytecode omzetten in CPU-instructies. Niets meer en niets minder. De RunTime is verantwoordelijk voor geheugen allocaties, niet de compiler.

Misschien even inlezen, voordat je onwaarheden gaat verkondigen.

RunTime is wanneer het gebeurd. Er is inderdaad CompileTime en RunTime en geheugen allocatie gebeurd in RunTime maar als het gecompileerde code is dan kan een compiler voorkomen dat er geheugen allocatie fouten zijn.

In ieder geval niet door de compiler.
Het enige wat een compiler doet is programma- en/of bytecode omzetten in CPU-instructies. Niets meer en niets minder. De RunTime is verantwoordelijk voor geheugen allocaties, niet de compiler.

ennnehhh...... die.... RunTime.... wat runt die dan?
Niets anders dan datgene wat de compiler gebouwd heeft....

Een compiler doet heel wat meer dan alleen programma- en/of bytecode omzetten. De compiler genereerd de CPU-instructies die nodig zijn om datgene uit te voeren wat er in de code staat. Inclusief I/O, inclusief geheugenbeheer, inclusief mogelijke threading. De compiler genereerd alles wat er nodig is om te kúnnen draaien. Dat de daadwerkelijke allocatie in runtime gebeurd betekend nog niet dat dat buiten het gecompileerde stuk software gebeurt....

Ik zal je ad-hominem dit keer vergeven. Toen ik begon met programmeren was jij nog niet geboren dus je jeugd zal je wel in de weg zitten

Dat de daadwerkelijke allocatie in runtime gebeurd betekend nog niet dat dat buiten het gecompileerde stuk software gebeurt....

Dat zei ik ook niet. Jij beweerde dat de compiler zelf het geheugen alloceert voor de applicatie, wat niet waar is. De compiler zorgt dat het programma door de CPU kan worden uitgevoerd en dat de vereiste functies al dan niet in de executable worden bijgevoegd. De geheugenallocatie wordt dus niet door de compiler gedaan.

Jij beweerde dat de compiler zelf het geheugen alloceert voor de applicatie, wat niet waar is.

Dat beweer ik helemaal niet. Ik beweer alleen:

wordt geheugen toewijzing geautomatiseerd in de compiler.

Dat is heel wat anders dan beweren dat geheugen allocatie door de compiler gebeurt. Dat kan een compiler inderdaad niet aangezien dat zonder meer runtime móet gebeuren. Echter hóe dat in runtime gebeurt wordt door de compiler bepaald, zoals ik stel.

Ah. Op die manier.

Er werd gevraagd om b.v. 64000 bytes te echo'en er werden b.v. 10 opgestuurd. De ontvanger alloceerde dan 64000 bytes en overschreef de eerste 10 en echode vervolgens de hele buffer. De rest van de buffer bevatte dus eerder vrijgegeven heap geheugen waar nog vanalles in kon staan.

Volgens mij is die gealloceerde buffer niet het probleem, die wordt namelijk volledig overschreven door memcpy. Het probleem is dat memcpy een anonieme pointer ontvangt (geen type safety) en dan doodleuk 64000 bytes vanaf het adres waar die pointer naar wijst kopieert naar de buffer. memcpy moet eigenlijk ophouden als het de grens van de data structure waar de pointer naar wijst heeft bereikt (en dan eventueel een exception gooien). Maar dat kan in C niet.

Is dit iets wat straks gewoon in Firefox komt?

"Straks" is veel gezegd, maar ik schat dat hij tegen 2016 wel sort of bruikbaar moet beginnen te worden, en in 2017 een publieke beta zou mooi zijn. Het is inderdaad de bedoeling dat Servo in the long run Gecko moet gaan vervangen. Dit gaat jammer genoeg wel gevolgen hebben voor de huidige, krachtige, unieke XUL-addons, want er zijn geen plannen meer om XUL nog te ondersteunen. Ik hoop dat ze toch een oplossing vinden om Firefox zijn grootste voordeel niet te laten verliezen.

Ik denk dat Mozilla meer Jetpack gaat pushen voor het maken van addons. Fennec gebruikt al geen XUL..

Aangezien Mozilla zich steeds meer focust op het mobiele platform en een vete heeft tegen 'trage' add-ons, is het aannemelijk dat XUL in de loop der jaren zeker wordt gedropt.

Ja, en dat vind ik op zich heel jammer. Maar op mijn gsm kan ik dat voorlopig nog wel missen, omdat ik die enkel gebruik voor wat "casual" browsing onderweg, maar het meeste zit ik toch nog op mijn pc, want dat gaat nog steeds duizend keer efficiënter, en dat is onder andere door handige add-ons. Jetpack is beduidend minder sterk.

Het is vooralsnog expliciet niet de bedoeling dat Servo in de long run Gecko gaat vervangen; het is nog steeds bedoeld als research-project. Zie bijvoorbeeld hier:

https://news.ycombinator.com/item?id=7605431

"There are no plans yet to ever integrate Servo directly into Firefox. At the very least Servo will certainly exist as a standalone browser engine (and unlike Gecko, Servo is designed to be embeddable, so it will be an actual alternative to Webkit in that space)."

"Servo aims to be "dogfoodable" by the end of the year. It's still an experiment, really, so you won't be able to get anybody to commit to any plans further than that. The design is significantly different from Gecko that I suspect you'd never be able to wedge it into the existing Firefox, but it wouldn't be entirely implausible if a usable browser called Firefox used Servo within 5 years."

Ik weet dat het niet in de huidige Firefox zou passen, maar gezien de resultaten nu al vrij goed zijn, lijkt het me waarschijnlijk dat, mits er geen grote tegenslagen komen, we binnen x aantal jaar een Mozilla-browser met Servo hebben. Ze zouden er ook niet zoveel tijd en moeite in steken als ze helemaal geen praktisch nut ervan verwachtten, lijkt me

Dit is een ontwikkeling die ik toejuich - aangezien de browser (vrijwel) het enige onderdeel van je systeem is dat continu ongeverifieerde code uit het 'wilde' internet draait, zou het een grote stap vooruit zijn om juist de rendering engine in een managed code taal te schrijven. Maar in de praktijk zie je dat iedereen toch focused om de laatste performance druppels uit de code te trekken (mede veroorzaakt doordat tech reviewers vooral 'winnaars' aanwijzen op basis van JS en rendering performance benches), en dus terugvalt op het nogal riskante C/C++ werk.

Met de ene buffer overflow exploit na de andere...

[Reactie gewijzigd door Dreamvoid op 18 april 2014 11:46]

Misschief Offcotpic, maar ik moest door jouw verhaal denken aan HotJava, de Browser die Sun Microsystems had geschreven in Java, en die bovendien de eerste browser die Java ondersteunde. Die browser was meet een showcase dan een product, dus is nooit echt onderhouden, maar het is wel grappig dat het concept (een browser maken in een managed taal) toch weer opduikt om hele andere redenen.

Servo is zo indrukwekkend omdat het een van de enige engines is die CSS/HTML volledig parallel rendert.

Ben benieuwd hoe dan events gaan werken eigenlijk. Misschien heeft het er helemaal niets mee te maken, of het doet zich voor er niets mee te maken heeft.

Teveel deferren / async loaden kan soms ook problemen opgeven. Dus ben wel erg benieuwd naar die ontwikkeling naar paralel.

Ben benieuwd hoe ze op de acid3 test scoren. daar zitten ook een aantal performance tests in.

Woow super goede ontwikkeling!! Als web developer houdt ik veel van de ontwikkelingen met liefde bij, maar meestal hoor je toch meer over de javascript engine zoals V8. Het is mooi om te horen dat de daadwerkelijke 'render' engine ook nog steeds door ontwikkeld wordt..

Wellicht volledig offtopic, maar ik vind het toch altijd een leuk feitje (als javascript/front-end developer).

Backend developers kicken er gigantisch op als een api call 100ms versneld wordt (wat ook terecht erg mooi is uiteraard). Maar als je eens goed kijkt in bijvoorbeeld de timeline van Chrome, zie je dat het 'tekenen' in de DOM (bij middel tot grote hoeveelheden elementen + css) soms serieus ook nog gewoon 100ms in beslag kan nemen, laat staan de tijd die nog in beslag wordt genomen voor alles weer snel 'reageert' op klik/hover etc events.... Stel je voor dat de browser nog maar 20ms nodig heeft om te 'renderen' dan is er alsnog 80ms van de 'start to end' tijd afgetrokken!!!!

In mijn ogen dus ook net zo belangrijk!

Goed werk Mozzila!!

Mja het lijkt me inderdaad ook voor mobiele devices een grote verbetering als ze beter gebruik maken van meerdere cores. Dan kun je daarmee dichter in de buurt komen van native-apps qua performance. Op zich kan het nu al wel enigszins (als je de juiste html/css/js gebruikt), maar toch is het echt net niet gelijk. Hoe sneller mobiele devices worden, hoe makkelijker het wordt om complexe toepassingen te maken.

HTML heeft dit soort verbeteringen nodig om ervoor te zorgen dat we straks geen app-stores meer nodig hebben.

Dit is weer een klok-klepel-verhaal.

Servo wordt geschreven in Rust, een nieuwe programmeertaal waar Mozilla Research aan werkt. Rust zou door een modernere architectuur geen last hebben van beveiligingsproblemen als buffer overflows en een veiliger geheugenbeheer hebben. Daarmee zouden bugs als Heartbleed onmogelijk zijn omdat deze door de Rust-compiler automatisch worden voorkomen.

Servo wordt geschreven in Rust, een nieuwe programmeertaal waar Mozilla Research aan werkt. Rust is een modernere programmeertaal die geen last zou hebben van buffer overflows of andere problemen met het geheugenbeheer. Mozilla claimt dat de bug die Heartbleed veroorzaakte niet mogelijk geweest als OpenSSL in Rust was geschreven. Verder heeft Servo een modernere architectuur, die onveilige historische keuzes in de architectuur van andere browsers omzeilt.

Rust heeft geen architectuur, want het is geen programmeertaal. Servo heeft als programma wel een architectuur. Heartbleed heeft niks met Servo te maken en wordt hier gebruikt om Rust te promoten. Overigens is het zo dat bijna elke andere programmeertaal dan C het probleem dat Heartbleed veroorzaakte ook vermeden had.