Da ist ja die Geschichte wieder am Anfang. Die Java Architektur wurde verteufelt, weil von SUN, von andern gern auch mal boykottiert. Und vor kurzem wurde das böse und ja so unsichere Java aus dem Browsern verbannt . Der Youngstar ist WebAssembly. Ja so sicher ... wie echt jetzt JavaScript sicher?... egal ... läuft ja auch auf Windows. Da wird Sicherheit ja vom Mossad, NSA und BND garantiert
Und jetzt das, GC und Threads, Bytecode und eine VM innerhalb der Browser. Nein Hilfe! Gut das es Google gibt
Mir stellt sich die Frage warum haben wir es nicht geschafft eine wirkliche Befreiung von Hardware und Betriebssystem zu schaffen. Die technologische Ansatz war mit JAVA da. Mann stelle sich einmal vor wo JAVA jetzt hätte sein können. Ich meine ohne den, ich mache da nicht mit und Unterstütze nur meine eigene Technologie, Krieg, der Neider und falschen Unterstützern. Ja wer war das wohl Aber geben wir WebAssembly doch auch eine Chance.
Oder vielleicht entwickelt jemand noch eine Script Sprache, eine neue VM, einen neuen Programmiersprachen Dialekt oder Methodik, oder, oder... damit wir am Ende wieder am Anfang sind.
In der Anfangszeit der IT hat sich das durchgesetzt, was als erstes da war. Darum schlägt sich die Welt immer noch mit so einer unsäglichen Schei*e wie C und C++ rum.
Nachdem die IT inzwischen in der Hand weniger - in ihrem Segment jeweils marktbeherrschender - IT-Konzerne ist, setzt sich das durch, was mit dem größten Schub in den Markt gedrückt wird.
Und da geht es nicht um Qualität oder Sinnhaftigkeit, sondern um Dominanz auf dem Markt - egal wie schlecht das eigene Produkt ist.
C++ als Müll zu bezeichnen, kann ich nachvollziehen, aber C? Anhand Ihrer Aussagen möchte ich mich schon fast darauf festlegen, dass es sich bei Ihnen um einen Ruby-Programmierer handelt.
Komische Aussage, wenn man bedenkt, dass MRI, die Standardimplementierung von Ruby, in C geschrieben ist... Scheint wohl auf eine persönliche Einstellung zu einer imho interessanten (wenn auch derzeit noch nicht wirklich performanten) Sprache wie Ruby zurückzuführen zu sein. Und ja, ich schreibe seit einigen Jahren Software vA in Ruby.
Von kamome umiodori am Sa, 18. August 2018 um 12:52 #
Ein halbwegs sicher implementierbares JavaScript (oder ein Teil davon) wäre prima – aber nach über 20 Jahren glaube ich nicht mehr daran. Ich ärgere mich über die häufige Notwendigkeit, JS zu aktivieren – und über unsinnige/schlechte Entwicklungen in HTML und CSS (teilweise sicher aufgrund des Festhaltens an JS), die JS in vielen Fällen unnötig machen würden, z.B. range input ohne Zugriff auf den Wert von CSS aus.
Von InterneExplorer am So, 19. August 2018 um 18:32 #
Ob das jetzt so viel besser würde, wenn CSS noch komplexer würde (es ist bereits turingvollständig und für 3-4 Aufgaben zuständig) und weitere Sicherheitslücken aufreißt (es gibt schon die eine oder andere)?
Ein halbwegs sicher implementierbare Skriptsprache wäre prima...
...ist auf alle Aspekte ausgedehnt aber fast unmöglich. Sicher, die Web-APIs sind lächerlich und ungar, aber konzeptionell haben sowohl VMs als auch Prozess-Sandboxen ihre Grenzen.
Bytecode-Validierung kann man schwerlich bis unmöglich im Nachhinein dranbasteln, wie Java und auch viele andere auf die harte Tour gelernt haben. Und selbst bei den letzen beiden Versuche, ein sicheres Bytecode-Format im Internet zu nutzen, Flash und Silverlight, wurde ewig hinterhergebastelt. Adobe interessiert es halt nicht aber Verschwörungstheoretiker sagen, dass Silverlight auch deshalb eingestellt wurde. Ob das Design von WebAssembly in Ordnung ist, wird sich zeigen...
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine
Man kann eine VM dafür natürlich in JS schreiben und mutmaßlich kann das so auch in den Browsern realisiert sein, eine Notwendigkeit dazu besteht aber nicht!
Ich bin Laie, aber vermute der Grund hierfür ist, dass WebAssembly bisher innerhalb der JavaScript-Komponente der Browser-Engines, d.h. innerhalb der selben Verzeichnisstruktur, entwickelt wurde/wird. Wahrscheinlich arbeiten größtenteils die selben Personen/Teams an diesem Code und grundlegende Parallelen gibt es ja ohnehin: Im Quelltext der Internetseiten eingebetteter Code, der heruntergeladen, isoliert eingelesen und (üblicherweise) ausgeführt wird.
Historisch hat sich WebAssembly quasi aus Projekten oder Experimenten wie asm.js, PNaCl und emscripten entwickelt. Kompatibilität wird mittels polyfill gewährleistet. Dies könnten weitere Gründe sein.
Ich vermute, dass "stack-based virtual machine" hier ein Implementierungsdetails ist, worauf man sich geeinigt hat, um die gesetzten Ziele besser umsetzen zu können. Eine allgemeine Abwägung von Vor- & Nachteilen findet sich hier.
Wie steht es denn nun um Firefox und Edge bzw. deren Browser/JavaScript-Engines?
Frau Silvanovich schreibt dazu herzlich wenig, obwohl angeblich alle vier großen Browser(-Engines), die WebAssembly implementieren, untersucht worden seien. Nur zwei ältere Sicherheitslücken werden hier erwähnt, die teils per OSS-Fuzz identifiziert wurden.
Da stellt sich die Frage, in wie weit diese Schwachstellen WebAssemblys tatsächlich struktureller Natur sind. Es wirkt so, als wären die Sicherheitslücken weniger ein generelles Problem von WebAssembly, sondern viel eher stark implementierungsspezifisch.
Daher erscheint mir Frau Silvanovichs Blogeintrag eher wie Marketing/PR als alles Andere. Das einzige Interesse Googles, in anderen Implementierungen Schwachstellen bzw. Sicherheitslücken zu entdecken, das ich erkennen kann, erklärt sich mir nur damit, dass einem Sicherheitsimage/-debakel á la ActiveX, Java, Flash oder Silverlight für WebAssembly vorgebeugt würde.
Natürlich kann ich verstehen, wenn für die eigene Implementierung mehr Aufwand betrieben wird, als für die der Konkurrenz, aber dann muss Frau Silvanovich das auch so deutlich kenntlich machen.
Übrigens: Ich habe noch nicht herausfinden können, wie ich den Quelltext, also den Byte-Code, bzw. dessen binäres Format anschauen kann? Am diesem Beispiel habe ich das nicht herausfinden können, z.B. Entwicklertools oder Quelltextanzeige im Firefox habe ich nicht dazu bringen können.
Wird es Möglichkeiten zum Disassemblieren des Byte-Codes in ein verständlicheres Format der Programme zu erhalten, die man da so im Driveby lädt und ausführt?
Nicht speziell diesen Artikel betreffend: Ich sehe hier die Tendenz, dass immer mehr Webseiten unleserliche und unverständliche Quelltexte aufweisen - absichtlich oder unabsichtlich. Viele Webseiten werden heutzutage aussschließlich per JavaScript (teils "obfuskiert") auf die Bildschirme gezeichnet. Die Webseiten oder eher -anwendungen sind/würden damit quasi proprietär. WebAssembly ist ein weiterer Schritt in diese Richtung. Diese halte ich aber für äußerst schädlich für ein freies Internet und (FL)OSS. Trotzdem macht Mozilla mit, obwohl sie sich immer anders vermarkten. Lügt Mozilla seine Zielgruppe erfolgreich an? Ich finde die Entwicklungen seit Gründung der WHATWG größenteils bedenklich. Geht das nur mir so?
Da ist ja die Geschichte wieder am Anfang. Die Java Architektur wurde verteufelt, weil von SUN, von andern gern auch mal boykottiert. Und vor kurzem wurde das böse und ja so unsichere Java aus dem Browsern verbannt . Der Youngstar ist WebAssembly. Ja so sicher ... wie echt jetzt JavaScript sicher?... egal ... läuft ja auch auf Windows. Da wird Sicherheit ja vom Mossad, NSA und BND garantiert
Und jetzt das, GC und Threads, Bytecode und eine VM innerhalb der Browser. Nein Hilfe! Gut das es Google gibt
Mir stellt sich die Frage warum haben wir es nicht geschafft eine wirkliche Befreiung von Hardware und Betriebssystem zu schaffen. Die technologische Ansatz war mit JAVA da. Mann stelle sich einmal vor wo JAVA jetzt hätte sein können. Ich meine ohne den, ich mache da nicht mit und Unterstütze nur meine eigene Technologie, Krieg, der Neider und falschen Unterstützern. Ja wer war das wohl Aber geben wir WebAssembly doch auch eine Chance.
Oder vielleicht entwickelt jemand noch eine Script Sprache, eine neue VM, einen neuen Programmiersprachen Dialekt oder Methodik, oder, oder... damit wir am Ende wieder am Anfang sind.
viele Grüße vom Sarkasmus Team Sheldon
Ich habe nichts verstanden, was du da geschrieben hast...
Generation Doof?
Dein Vorschreiber hat übrigens vollkommen recht.
Klingt eher nach solchen Leuten, die Java verteufeln weil unsicher und voll auf Frameworks stehen, weil sicher.
Kannst du den erklären was er geschrieben hat und womit er recht hat. Ich habe es mehrmals durch gelesen und verstanden habe ich es immer noch nicht.
In der Anfangszeit der IT hat sich das durchgesetzt, was als erstes da war. Darum schlägt sich die Welt immer noch mit so einer unsäglichen Schei*e wie C und C++ rum.
Nachdem die IT inzwischen in der Hand weniger - in ihrem Segment jeweils marktbeherrschender - IT-Konzerne ist, setzt sich das durch, was mit dem größten Schub in den Markt gedrückt wird.
Und da geht es nicht um Qualität oder Sinnhaftigkeit, sondern um Dominanz auf dem Markt - egal wie schlecht das eigene Produkt ist.
Im letzten Satz hätte ich statt "Produkt" "Produkt bzw. Standard" schreiben müssen.
Und was wäre die Lösung um C/C++ loszuwerden? ASM?
C wird bleiben.
C++ kann man bei neuen Projekten, solange das drumherum passt, durch Rust ersetzen.
C++ als Müll zu bezeichnen, kann ich nachvollziehen, aber C? Anhand Ihrer Aussagen möchte ich mich schon fast darauf festlegen, dass es sich bei Ihnen um einen Ruby-Programmierer handelt.
Mahlzeit,
Kalle König
Komische Aussage, wenn man bedenkt, dass MRI, die Standardimplementierung von Ruby, in C geschrieben ist...
Scheint wohl auf eine persönliche Einstellung zu einer imho interessanten (wenn auch derzeit noch nicht wirklich performanten) Sprache wie Ruby zurückzuführen zu sein.
Und ja, ich schreibe seit einigen Jahren Software vA in Ruby.
Ein halbwegs sicher implementierbares JavaScript (oder ein Teil davon) wäre prima – aber nach über 20 Jahren glaube ich nicht mehr daran. Ich ärgere mich über die häufige Notwendigkeit, JS zu aktivieren – und über unsinnige/schlechte Entwicklungen in HTML und CSS (teilweise sicher aufgrund des Festhaltens an JS), die JS in vielen Fällen unnötig machen würden, z.B. range input ohne Zugriff auf den Wert von CSS aus.
Ob das jetzt so viel besser würde, wenn CSS noch komplexer würde (es ist bereits turingvollständig und für 3-4 Aufgaben zuständig) und weitere Sicherheitslücken aufreißt (es gibt schon die eine oder andere)?
...ist auf alle Aspekte ausgedehnt aber fast unmöglich.Sicher, die Web-APIs sind lächerlich und ungar, aber konzeptionell haben sowohl VMs als auch Prozess-Sandboxen ihre Grenzen.
Bytecode-Validierung kann man schwerlich bis unmöglich im Nachhinein dranbasteln, wie Java und auch viele andere auf die harte Tour gelernt haben. Und selbst bei den letzen beiden Versuche, ein sicheres Bytecode-Format im Internet zu nutzen, Flash und Silverlight, wurde ewig hinterhergebastelt. Adobe interessiert es halt nicht aber Verschwörungstheoretiker sagen, dass Silverlight auch deshalb eingestellt wurde.
Ob das Design von WebAssembly in Ordnung ist, wird sich zeigen...
Quelle:
Man kann eine VM dafür natürlich in JS schreiben und mutmaßlich kann das so auch in den Browsern realisiert sein, eine Notwendigkeit dazu besteht aber nicht!
Was du sagst, ist soweit korrekt.
Ich bin Laie, aber vermute der Grund hierfür ist, dass WebAssembly bisher innerhalb der JavaScript-Komponente der Browser-Engines, d.h. innerhalb der selben Verzeichnisstruktur, entwickelt wurde/wird. Wahrscheinlich arbeiten größtenteils die selben Personen/Teams an diesem Code und grundlegende Parallelen gibt es ja ohnehin: Im Quelltext der Internetseiten eingebetteter Code, der heruntergeladen, isoliert eingelesen und (üblicherweise) ausgeführt wird.
Historisch hat sich WebAssembly quasi aus Projekten oder Experimenten wie asm.js, PNaCl und emscripten entwickelt. Kompatibilität wird mittels polyfill gewährleistet. Dies könnten weitere Gründe sein.
Ich vermute, dass "stack-based virtual machine" hier ein Implementierungsdetails ist, worauf man sich geeinigt hat, um die gesetzten Ziele besser umsetzen zu können. Eine allgemeine Abwägung von Vor- & Nachteilen findet sich hier.
Wie steht es denn nun um Firefox und Edge bzw. deren Browser/JavaScript-Engines?
Frau Silvanovich schreibt dazu herzlich wenig, obwohl angeblich alle vier großen Browser(-Engines), die WebAssembly implementieren, untersucht worden seien. Nur zwei ältere Sicherheitslücken werden hier erwähnt, die teils per OSS-Fuzz identifiziert wurden.
Da stellt sich die Frage, in wie weit diese Schwachstellen WebAssemblys tatsächlich struktureller Natur sind. Es wirkt so, als wären die Sicherheitslücken weniger ein generelles Problem von WebAssembly, sondern viel eher stark implementierungsspezifisch.
Daher erscheint mir Frau Silvanovichs Blogeintrag eher wie Marketing/PR als alles Andere. Das einzige Interesse Googles, in anderen Implementierungen Schwachstellen bzw. Sicherheitslücken zu entdecken, das ich erkennen kann, erklärt sich mir nur damit, dass einem Sicherheitsimage/-debakel á la ActiveX, Java, Flash oder Silverlight für WebAssembly vorgebeugt würde.
Natürlich kann ich verstehen, wenn für die eigene Implementierung mehr Aufwand betrieben wird, als für die der Konkurrenz, aber dann muss Frau Silvanovich das auch so deutlich kenntlich machen.
Übrigens:
Ich habe noch nicht herausfinden können, wie ich den Quelltext, also den Byte-Code, bzw. dessen binäres Format anschauen kann? Am diesem Beispiel habe ich das nicht herausfinden können, z.B. Entwicklertools oder Quelltextanzeige im Firefox habe ich nicht dazu bringen können.
Wird es Möglichkeiten zum Disassemblieren des Byte-Codes in ein verständlicheres Format der Programme zu erhalten, die man da so im Driveby lädt und ausführt?
Nicht speziell diesen Artikel betreffend:
Ich sehe hier die Tendenz, dass immer mehr Webseiten unleserliche und unverständliche Quelltexte aufweisen - absichtlich oder unabsichtlich. Viele Webseiten werden heutzutage aussschließlich per JavaScript (teils "obfuskiert") auf die Bildschirme gezeichnet. Die Webseiten oder eher -anwendungen sind/würden damit quasi proprietär. WebAssembly ist ein weiterer Schritt in diese Richtung. Diese halte ich aber für äußerst schädlich für ein freies Internet und (FL)OSS. Trotzdem macht Mozilla mit, obwohl sie sich immer anders vermarkten. Lügt Mozilla seine Zielgruppe erfolgreich an? Ich finde die Entwicklungen seit Gründung der WHATWG größenteils bedenklich. Geht das nur mir so?