Firefox 52 erhält Unterstützung für WebAssembly (wasm)
WebAssembly, oder kurz: wasm, ist ein neues Binärformat für das Web und soll deutliche Geschwindigkeitsvorteile gegenüber JavaScript liefern. Mozilla aktiviert die Unterstützung als erster Browserhersteller in Firefox 52. Google zieht wenige Tage später mit Chrome 57 nach.
Ausnahmslos alle Browserhersteller haben in den letzten Jahren enorme Fortschritte im Bereich der JavaScript-Performance gemacht. Doch schnell ist nicht schnell genug, vor allem wenn es um komplexere Anwendungen als einfache Webseiten geht.
Lesetipp: Firefox wieder führend bei der Implementierung neuer JavaScript-Features
WebAssembly ist ein neues Binärformat für das Web, entwickelt von Mozilla, Google, Microsoft und Apple in einer W3C Community Group. Ähnlich wie bei Mozillas asm.js oder Googles PNaCl handelt es sich dabei um das Resultat kompilierten Codes und soll die Performance von Webanwendungen auf eine neue Ebene heben.
Erstmals angekündigt wurde WebAssembly im Juni 2015, in Nightly-Versionen von Firefox getestet werden kann eine erste Implementierung seit März 2016. Vor wenigen Tagen hat Mozilla die Unterstützung für die finale Version von Firefox 52 aktiviert. Firefox 52 wird am 7. März 2017 erscheinen. In der ESR-Version von Firefox 52 wird wasm allerdings standardmäßig deaktiviert sein.
Google wird die Unterstützung für WebAssembly in Chrome 57 aktivieren. Chrome 57 erscheint eine Woche nach Firefox 52 am 14. März 2017. Seit dem Windows Insider Build 15025 kann eine erste Unterstützung für WebAssembly per Feature Flag in Microsoft Edge aktiviert werden. Informationen zur Verfügbarkeit in Apple Safari sind noch nicht bekannt.
Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, firefoxosdevices.org sowie sozone.de.
Na, das wird ja interessant! Haben wir damit noch vollgestopftere Webseiten und zusätzliche Angriffsmöglichkeiten zu erwarten oder wurde hier beim Entwurf gar mehr auf Sicherheit geachtet?
Ich verstehe deine Fragen nicht. Kein Browserhersteller arbeitet schließlich absichtlich Sicherheitsprobleme in neue Webstandards ein.
Gibt es schon Beispielanwendungen für wasm, die man sich anschauen könnte?
Dann sollte das hier ja eigentlich gehen in v52 b9?
http://webassembly.org/demo/
Tut es aber nicht bei mir. Es tut sich nichts.
@Tom:
Sollte man meinen, allerdings scheint die Demo nicht in Ordnung zu sein, denn in Chrome Canary funktioniert sie auch nicht.
@Simon:
Ich hätte dir jetzt die gleiche Demo genannt, die Tom in seinem Kommentar genannt hat, aber siehe Abschnitt drüber, die Demo scheint momentan nicht zu funktionieren.
Ich finde @tilman's Einwand schon sehr berechtigt – interessant zu wissen wäre, ob dieses Feature innerhalb einer VM ausgeführt wird oder ob es sonstige Sicherheitsvorkehrungen gibt?!
Wenn du den Einwand berechtigt findest, solltest du schon wenigstens das ergänzen, was dem Einwand gefehlt hat. Denn so in den Raum geworfen hat der Einwand keinen Sinn. Das muss man schon an irgendetwas festmachen. Ansonsten müsste man bei ausnahmslos jedem Webstandard, den Mozilla implementiert, die gleiche Frage stellen. Und ich sehe keinen anderen Artikel auf meinem Blog, wo jemals jemand diese Frage gestellt hätte. Wieso erfordert WebAssembly denn deiner Meinung nach besondere Maßnahmen, beispielsweise gegenüber JavaScript? Müssen nicht alle Sicherheitsmaßnahmen, die sinnvoll wären, grundsätzlich und nicht nur für WebAssembly vorhanden sein? Ansonsten erkläre mir bitte, was WebAssembly an Maßnahmen braucht, was vorher nicht notwendig war. Erkläre mir bitte außerdem, wieso du glaubst, dass Mozilla, Google, Microsoft und Apple mit all ihrer Erfahrung gemeinsam einen Standard entwickeln sollten, der ein ernsthaftes Sicherheitsproblem darstellt. Ich verstehe diesen Gedanken einfach nicht und würde ihn sehr gerne nachvollziehen können. Aber beide habt ihr jetzt leider nur komplett unbegründet eingeworfen, dass ihr Einwände – welcher Art auch immer – habt. 😉
Ah danke, muß ich also nicht mehr testen auf anderen Geräten.
Zum anderen Thema: Bei ausführbaren Binärdateien läuten halt bei vielen die Alarmglocken. Ob berechtigt oder nicht, kann ich nicht beurteilen. Dann gab es ja noch das verrufene ActiveX, aber das lief ja glaub ich eben auch nicht in einer Sandbox.
Zum Thema Sicherheit steht übrigens eh das Relevante auf der Webseite:
http://webassembly.org/
@Sören: Das klingt so nativ und wenn man sich damit nicht beschäftigt, denkt man wahrscheinlich einfach intuitiv, dass das unsicherer ist und Dinge besser umgehen kann. Assembly – Assembler das klingt so nach bösem Hackerzeug 😉
Dabei ist das nicht mal eine Assemblersprache sondern schlicht Bytecode – wie Java Bytecode oder .Net CIL – und keinerlei Hexerei.
Performancevorteile im Browser sind das eine, aber das passt sich ja auch ideal(vielleicht noch wichtigerer Treiber?) zum Trend zu plattformunabhängigen Programmen mit Frameworks with Electron und Cordova – CSS, HTML + Javascript – und es läuft überall.
Mit CSS und HTML überwindet man proprietäre Ansätze wie WPF/XAML und JavaFX und mit WebAssembly hat man dann auch noch eine Alternative zu JavaScript. Das ist zwar in aller Munde und wird fleißig genutzt – aber es bleibt ein großer Hemmschuh. Gerade professionelle Entwicklung in größeren Projekten ist ziemlich unstrittig ein würgen. Da kristallisiert sich mit Typescript als Entwicklungsüberbau zwar langsam auch ein angenehmerer Standard in der Breite heraus, aber WebAssembly schlägt dann doch noch viel mehr Fliegen mit einer Klappe.
Auf der einen Seite gab es bisher JVM auf der anderen CLI und nun mit WebAssembly eine Art Friedensschluss. Bessere Performance als JavaScript und vorallem Sprachfreiheit!
http://webassembly.org/demo/
Die Demo scheint wieder zu laufen, getestet mit 52 ESR RC.
Super, Danke für die Info!
@Soeren:
Keine Sorge, ich stelle diese Frage immer, egal ob bei Mozilla oder sonst irgendeiner Firma und jedwedem anderen Produkt.
Der Firefox, so sehr ich ihn liebe, ist code-technisch schon arg adipös geworden. Das trifft zwar auf viele Browser zu (6 Millionen Zeilen Code bei Chromium, über 10 Millionen bei Firefox, wth!)…
Klar, LOCs sind keine gute Metrik für Codequalität, ich frage mich dennoch warum alles so aufgebläht sein muss und es zehntausende Hacks benötigt, um Seiten korrekt darzustellen, deren Entwickler schlichtweg zu bequem waren sich an den Standard zu halten.
Aber sei’s drum.
Was das Feature und Sicherheit angeht: Kann ich das dann ebenso blockieren wie JavaScript? Ich verwende NoScript mit strikter Whitelist policy. Wenn eine Seite ohne JS nicht mal rendered, aber kein Webclient im eigentlichen Sinne ist, dann ist der Inhalt erfahrungsgemäß nicht wert angesehen zu werden, ergo verlasse ich die Seite dann wieder.
LOCs sind nicht "keine gute Metrik für Codequalität", das ist überhaupt keine Metrik dafür, es besteht nicht einmal der geringste Zusammenhang zwischen Qualität und Anzahl von Zeilen. Viele Zeilen können das Resultat umständlicher Programmierung sein. Aber umgekehrt erfordern viele gute Implementierungen genauso, deutlich mehr Zeilen Code zu schreiben als mit der einfachsten Implementierung notwendig wären. Eine vernünftige Abstraktion von Code kann diesen nämlich sehr viel umfangreicher machen. Also das sagt absolut gar nichts aus.
Entsprechend hat es auch überhaupt nichts mit "aufgebläht sein" zu tun.
Es gibt überhaupt nicht "den einen Standard", es gibt tausende Standards. Es gibt ja nicht einmal "den einen HTML-Standard", es gibt sowohl einen vom W3C als auch einen von der WHATWG und beide widersprechen sich in manchen Punkten. Spoiler: Mozilla hält sich eher an den der WHATWG als an den des W3C. Standards sind außerdem nichts Festes, sondern auch in Entwicklung. Und haben genauso wie die Implementierungen ihre ganz eigenen Bugs. Alleine, was es für CSS Flexbox in den letzten Monaten für Änderungen gab, auch abwärtsinkompatible, teilweise wurden Änderungen im Standard festgelegt und kurz darauf wieder geändert, und jedes Mal sind Anpassungen der Browserhersteller notwendig.
Über all das hinaus, weiß ich ehrlich gesagt nicht, worauf du hinaus willst. Denn weder Mozilla noch ein anderer Browserhersteller kann etwas dafür, wie Webseiten umgesetzt werden.
Ich verstehe den Sinn dahinter nicht, aber ja, du kannst wasm auf dem üblichen Weg deaktivieren. Der übliche Weg für Schalter, welche Webstandards betreffen, ist about:config. Einfach nach "wasm" suchen.
Lieber Sören,
ich schätze deine Informationspolitik bezüglich Mozilla sehr und möchte dir deswegen doch nochmal antworten und mich erklären.
Auf LOCs spielte ich aus dem einfachen Grund an, dass es viele Studien dazu gab, dass sich – übrigens Sprachunabhängig – etwa pro 1000 Zeilen Code ein Bug findet.
Der Rest ist einfache Mathematik, je mehr Zeilen Code, desto mehr Bug-Potenzial, ergo schlummern nach dieser Logik im Firefox weit mehr Bugs als beispielsweise im Chromium (nochmal: Unterschiedlicher Sicherheitsrelevanz, einfach nur Bugs)
Nun gibt es natürlich verschiedene Module, die unterschiedliche Auswirkungen auf die Sicherheit haben können etc.
Dennoch bin ich – übrigens auch als studierter Software Engineer mit mehrjähriger Berufserfahrung und sehr großen Legacy Projekten die auf hunderrtausende bis in die Millionen LOCs kommen – ein Anhänger der Unix bzw. auch KISS Philosophie und hoffe, dass der Firefox in Zukunft einmal einer radikalen Diät unterzogen wird.
Browser werden immer wichtiger, das stimmt. Das Web ist Dreh und Angelpunkt für viele Applikationen geworden und ich begrüße Initiativen wie WASM durchaus (wenngleich ich im Web derzeit entweder auf Rust oder Scala setze und letzteres ohne GC nicht funktionieren wird, ich also weiterhin über Scala.js nach JS transpilieren werde müssen), nur ist so eine Sandbox ganz und gar nicht einfach durchzusetzen.
Da ich aus der Informatik-Ecke komme und mein Handwerk durchaus verstehe, bin ich nicht so blauäugig anzunehmen, dass
a) Die Sandbox mit Sicherheit jedweden Outbreak unterbinden wird können
b) Die Intention jedes einzelnen Seitenbetreibers eine gute ist
Abgesehen davon, ziehe ich es vor, selbst zu entscheiden welcher Code auf meiner CPU läuft und den von mir bezahlten Strom verbraucht.
Deshalb ist JS auch standardmäßig aus und wird ge-whitelisted, selten sogar angepasst.
Zum Thema Standard:
Ich wollte keineswegs hierauf hinaus: https://xkcd.com/927/
Mir ging es viel eher um so Sachen wie nicht geschlossene Tags etc. die schlicht und ergreifend kein valides HTML sind (egal ob das strikte XHTML oder das sehr lockere HTML 5) und deren Sinn trotzdem – mittels Hacks im Browser und „Wahrsagerei“ à la „Was hat der Betrunkene Webdeveloper sich da wohl gedacht?“ – erraten werden.
Das ist in meinen Augen 1:1 dieselbe Problematik wie sie proprietäre GPU Treiber mit sich bringen, die eigene Renderpfade für spezielle Spiele implementieren, nur weil die Entwickler der Spiele ihr Handwerk nicht verstanden haben. (Was Mesa beispielsweise nicht macht und deshalb dann oft schlechter abschneidet als, sagen wir, der proprietäre NVIDIA Treiber – AMDGPU Pro mal aussen vor gelassen und NOUVEAU unter den Teppich gekehrt, also von AMD Open source zu Nvidia proprietär den Bogen geschlagen… böser Bloaty)
Diese Dinge sind in meinen Augen ein absolutes Nogo, ich verstehe aber, dass, wenn ein Vollidiot von Browserhersteller anfängt solche Quirksmodes zu implementieren, alle anderen nachziehen „müssen“, weil die User sonst meinen: „Sieh mal an, der Firefox kann die Seite nicht richtig darstellen!“ (obwohl ja eigentlich die Seite aus nicht validem Markup besteht, was ein „einfacher Nutzer“ nun mal nicht weiß)
Es ist aus der Software-Architektur trotzdem einfach falsch… vielleicht bin ich da zu wenig pragmatisch, vielleicht zu sehr Akademiker geblieben, ich find es trotzdem scheisse.
Sidenote: Wenn ich mir Projekte wie Redox OS oder Midori ansehe, da wird mein Herz warm.
Ich kenne keine solche Studie, aber diese Schlussfolgerung kann keinesfalls pauschal aufgestellt werden, und sprachunabhängig schon gar nicht, das ist ziemlich unrealistisch, weil nun einmal jede Sprache ihre eigenen Sprachcharakteristika hat und alleine die verwendete Sprache schon zu Teilen bestimmt, wie man Probleme angehen muss oder nicht angehen kann. Auch Best Practices können sich je nach Sprache unterscheiden.
Der entscheidende Punkt ist aber das, was ich bereits in meinem vorherigen Kommentar schrieb. Die Anzahl von Zeilen erhöhst du genauso mit umständlicher und unnötiger Programmierung wie auch mit sehr ordentlicher Programmierung, welche Code allein durch Abstraktionsebenen deutlich mehr werden lässt. Es ist vollkommen ausgeschlossen, aus der Anzahl der Zeilen ein Merkmal zur Qualität abzuleiten, denn diese Zusammenhang besteht nun einmal nicht.
Nein, das ist keine einfache Mathematik, das ist leider eine Milchmädchenrechnung. 😉 Ich erkläre gerne, wieso: Natürlich verstehe ich den einfachen Gedanken dahinter, dass jede Zeile Code eine Zeile mehr ist, in der ein Fehler stecken könnte. Aber lass uns mal weiter als das denken: Korrekter wäre, dass in gut geschriebenem Code weniger Potential für Fehler steckt als in schlecht geschriebenem Code. Gut geschriebener Code erfordert es häufig (nicht immer, Pauschalisierungen funktionieren auch hier nicht), dass man Dinge mit mehr Code umsetzt als es die naivste Implementierung erfordert. Dieser zwar umständlichere, aber qualitativ bessere Code hat mit sehr hoher Wahrscheinlichkeit ein geringeres Fehlerpotential.
tl;dr: Qualität bestimmt das Fehlerpotential maßgeblich, nicht Quantität.
Den Gedanken kann ich nicht nachvollziehen. Mozilla entwickelt einen Browser. Ein Browser muss eine sehr hohe Anzahl ganz unterschiedlicher Aufgaben erfüllen. Und bin lange genug in die Mozilla-Community involviert, um zu wissen, dass die Anforderungen der Nutzer kaum gegensätzlicher sein könnten. Frag 100 Leute und du wirst 99 verschiedene Antworten bekommen, was ein Browser leisten muss und was nicht. Ich muss sicher nicht dazu sagen, dass diese Zahl nicht wissenschaftlich ist, das ist eine gefühlte Menge. 😉 In jedem Fall ist es schlicht und ergreifend nicht möglich, auch nur im Ansatz alle Nutzer glücklich zu machen, wenn du die Hälfte der Features streichst. Ich wüsste auch gar nicht, welche Features du streichen willst. Was kann Firefox deiner Meinung nach, was für dich nichts in einem Browser verloren hat?
Ich gehe jetzt mal, dass der Punkt mit dem Strom scherzhaft gemeint war, ja? Ich frage das, weil ich durchaus auch schon Leute gelesen hatte, die sowas tatsächlich meinten. 😉
Das ist für mich ein sehr überraschendes Statement für jemanden, der aus der Entwicklung kommt. Das ist für mich, der ebenfalls Entwickler ist, überhaupt nicht nachvollziehbar. Denn JavaScript ist nun einmal ein ganz wesentlicher Bestandteil der Webplattform (und darüber hinaus, auch von Firefox selbst).
Ich bin auch nicht glücklich über die Fehlertoleranz, aber das ist ja auch überhaupt erst einer der Gründe, wieso sich HTML und das Web durchgesetzt haben. Natürlich hat das enorm dazu beigetragen, dass jeder Inhalte veröffentlichen konnte, ohne "ein studierter Techniker" zu sein (nein, das muss man für HTML nicht sein, aber aus der Sicht derer, die das nicht gelernt haben, ist das vermutlich eine treffende Beschreibung). Viele haben das nicht gelernt und schaffen es *irgendwie*, dass was angezeigt wird. Und es besteht keine Möglichkeit, nachträglich strikter zu werden, weil man damit das Web kaputt macht. Das Problem hätte, wenn überhaupt, ganz am Anfang vermieden werden müssen. Den Gedanken kann ich ja noch nachvollziehen. Aber nun ist das Web, was das Web ist, und damit ist das heute auch kein Thema mehr. Diese Toleranz gehört zu HTML und Browser müssen fehlertolerant sein, dazu gibt es keine Alternative.
Dass eine bessere Lösung automatisch mehr Code braucht, weil sie abstrakter sein muss, halte ich für Blödsinn.
Sorry, aber die generischste Lösung ist nicht immer die Beste.
Klar, wenn ich Code super wiederverwenden kann und der Code gut getestet ist, dann spare ich nicht nur Zeit bei einer Neuimplementierung für jeden weiteren Datentyp/Usecase, nein ich vermeide sogar Fehler, der Wartungsaufwand wird geringer etc.
Das heißt aber die Codebasis wäre hier im Idealfall KLEINER als bei mehreren naiven Lösungen für jedes Problem, deren Lösung eigentlich generisch umgesetzt werden könnte.
Umgekehrt gilt aber: Wenn ich nur ein Problem habe und den Code dann overengineere, weil „Es könnte ja sein, dass dieser Parser irgendwann auch die Hausaufgabe meiner Tochter parsen können muss“ und ich deshalb statt 5 files mit insgesamt N Zeilen, plötzlich 15 files mit mindestens 3N Zeilen benötige, dann ist das kein gutes Software-Design oder vorausschauend, sondern schlicht und ergreifend overengineered und das finde ich nicht unbedingt prickelnd. (Ausser bei privaten Projekten, da machts Spaß ;))
Und ich würde nicht sagen, dass der generische Code automatisch besser durchdacht ist, jedenfalls nicht im Blickpunkt auf Sicherheit. Wenn für einen Typ A und einen Typ B eine Implementierung reicht, funktional gesehen, heißt das nicht, dass die Sicherheitschecks für A auch für B ausreichend sind. Das kommt halt aufs Schneiden an und auch, wie viel Einfluss man drauf nehmen kann. Wenns nur interne Datentypen sind -> eher kein Problem.
Ist am Ende auch nicht so schlimm, wenns ordentlich getestet wurde, aber aus Erfahrung heraus sind die Software-Tests meistens eher „Mäh“.
Studien kann ich dir hierzu auch keine mehr Verlinken, ich finde derzeit keine. Mea culpa, I stand „corrected“.
Über Featuritis möchte ich mich gar nicht unterhalten, das wird zu subjektiv. Firefox kann eine Menge und ganz viel über Addons. Dafür liebe ich ihn und bin ihm über all die Jahre immer treu geblieben.
Allerdings finde ich es krank, wenn ein Browser – auch wenn das Web immer wichtiger wird – bald mehr Zeilen Code hat als ein ganzes Betriebssystem samt Treibern aus mehreren Dekaden. Das ist ein Gefühl und dabei kein gutes.
Vor allem weil Chromium ja – bis auf die Addons – prinzipiell dasselbe leistet, halt nur mit beinahe der Hälfte der LOCs.
Das mit dem Strom war scherzhaft gemeint, ja. Allerdings ist das beispielsweise auch bei der Werbung so. Ich sehe seit 10 Jahren keinerlei Werbung im Netz. Wenn mir eine Seite gefällt und drauf angewiesen ist, dann deaktivier ich den Werbeblocker schon mal für diese eine Seite. Wenn die allerdings nur Tracking-Werbung aus irgendwelchen fadenscheinigen Seiten lädt, dann kommt bei mir nichts durch und wenn sie aufdringliche Werbung schaltet, dann ist der Blocker sofort wieder an.
Das so als Randnotiz, weil es zum Thema passt. Wenn ich mobil unterwegs bin ist das Stromargument nämlich durchaus ein ernstgemeintes. Da hab ich keinen Bock auf irgendwelche Grütze, die mir den Akku leersaugt, nur damit ein bisschen Blinkieblinkie mehr am Schirm ist.
Tja, so ist das… ich bin -gsd- nur Hobbymäßig Webentwickler, auch wenn viele der Services an denen ich mitwirke übers Netz erreichbar sind.
Für mich ist JavaScript ein Enhancement. wird es beispielsweise benötigt um das Markup zu fixen (tatsächlich schon erlebt… ohne JS ist die Seite komplett zerschossen), dann ist das für mich ein starkes Indiz, dass da Idioten am Werk waren und ich meine Daten auf einer solchen Seite nicht möchte.
JS ist viel zu mächtig, als dass ich es einfach mal laufen lassen würde. Mit JS kann man soviel Schindluder treiben und deshalb muss man sich dieses Vertrauen erstmal verdienen.
Du siehst das anders, ist völlig legitim.
Ich bin Techie und Nerd durch und durch, ich interessiere mich quasi für alles technische. Das heißt nur nicht, dass ich – bei all den tollen Möglichkeiten – die Gefahren bzw. Probleme aus dem Blick verliere. Und da sehe ich in JS eben mehr ein Problem als du. Völlig okay.
Diese Fehlertoleranz bläht aber den Code unnötig auf, führt zu unsäglichem Branching im Code und erlaubt es eben auch, den Standard (der hier eindeutig ist!) zu verwässern.
Vom technischen Standpunkt ein absolutes Nogo. Für den Nutzer natürlich bequem, wie beim GPU Beispiel oben auch.
Die Leute beschweren sich, warum Spiel XY mit den freien Treibern nicht ordentlich läuft… na ja, weil das Spiel einfach kacke programmiert ist und nvidia in seine proprietären Treiber eben fucking Workarounds einbaut.
Treiber die für ein Spiel optimiert sind, Browser die für die Seiten optimiert sind… nicht umgekehrt, Spiele und Markupler halten sich an Standards… grauenhaftes inversion of control ist das… brrr
Ich mag es nicht, wenn man mir Worte in den Mund legt, die ich nicht gesagt habe, und noch weniger mag ich, wenn ich in meinem vorherigen Beitrag sogar sehr explizit in diesem Punkt war. Genau das habe ich ganz ausdrücklich nicht gesagt. Ich habe unmissverständlich geschrieben, dass mehr Code sowohl durch schlechten als auch durch guten Code erreicht werden kann. Und deswegen hat die Länge des Codes auch nicht die geringste Bedeutung. Eine solche Verallgemeinerung ist vollkommen ausgeschlossen.
Es ist halt grundsätzlich ein Problem, wenn man eine Behauptung oder eine Meinung in den Raum wirft, ohne das auszuführen und im Idealfall auch zu begründen. Zumal ich dir einen sehr guten Grund genannt hatte, wieso Browser, welche eine Marktrelevanz besitzen wollen, so viele Features haben müssen.
Was soll daran denn bitte krank sein? Nochmal: die Anzahl von Codezeilen sagt absolut gar nichts aus. Ich weiß ehrlich nicht, wie man sich daran so aufhängen kann. Und wenn du schon unbedingt einen Vergleich mit einem Betriebssystem aufstellen möchtest: Betriebssysteme führen komplexe Anwendungen aus bis hin zu 3D-Shootern, welche ich als sehr komplexe Anwendungen betrachte. Und genau sowas wird im Jahr 2017 auch in Browsern ausgeführt. Berühmte Spiele-Engines wie die Unreal-Engine stehen mittlerweile für Browser-Spiele zur Verfügung. NPAPI-Plugins als Bindeglied sind keine Option mehr. Also ja, ein Browser muss viele Aufgaben übernehmen können, die früher exklusiv das Betriebssystem konnte. Und das war nur eines von vielen Beispielen.
Und erneut: null Relevanz.
Bitte in weiteren Kommentaren keine Beleidigungen, auch wenn diese gegen eine nicht näher definierte Gruppe gehen. Ich lege auf meinem Blog großen Wert darauf, dass hier kein Niveau wie bei gewissen anderen Seiten herrscht…
Und was ist mit Bildern? Manipulierte Bilder sind kein ungewöhnliches Transportmittel für Angriffe. Dass Sicherheitslücken in den entsprechenden Bibliotheken zur Darstellung von Bildern behoben werden, ist ja nun auch keine Seltenheit. Ich glaube aber nicht, dass du Bilder in deinem Browser deaktiviert hast. Wenn man damit anfängt, was man alles kann, dann ist immer die Frage, wo man damit aufhört. Du kannst grundsätzlich ziemlich viel, was toll ist, auch für Schlechtes benutzen. Ist ja klar. Natürlich versuchen Angreifer, jede Möglichkeit für ihre Zwecke auszunutzen. Weit zielführender als die Deaktivierung wesentlicher Webstandards ist die Ausführung eines vernünftigen Sicherheitskonzeptes. Was das beinhalten kann, würde den Rahmen eines Kommentares hier sprengen. Aber wenn du dich mit deaktiviertem JavaScript sicherer fühst, bitte, dafür gibt es ja eine Einstellung im Browser (oder Add-ons mit detaillierteren Einstellungen).
Das ist aber eine vollkommen überflüssige Diskussion, weil die Realität nun einmal ist, wie sie ist. Ein weniger fehlertolerantes HTML ist nicht möglich. Es mussten auch schon neue Webstandards geändert werden, weil sie an der Realität scheiterten.
Wortwahl…
Abgesehen davon sind eben nicht immer die Anwendungen Schuld, in den Treibern liegen sehr häufig die tatsächlichen Probleme. Das bekomme ich alleine daher schon sehr gut mit, weil ich die Entwicklung von Firefox aktiv verfolge und das selbst für Firefox immer wieder ein Problem ist. Und das größte Problem ist, dass es irgendwann für die Nutzer einer bestimmten Hardware keine Treiber-Updates mehr gibt und Probleme daher nicht lösbar sind – außer man blockiert Treiber, was wieder seine ganz eigenen Probleme bringt, wie ein starker Einbruch der Performance.
Und das sollte dann auch genug Off-Topic gewesen sein. Mit WebAssembly hat das alles überhaupt nichts zu tun.