In der Rechnersicherheit gibt es ein zentrales Prinzip, dass Daten harmlos sind, weil sie nur von bereits vorhandener Software dargestellt werden, aber Programme geführlich sind, weil sie sich selber ausführen und damit beliebigen Schaden anrichten können. Daher ist eines der wichtigsten Massnahmen eine klare Trennung von Daten, welche beliebig vom Netz heruntergeladen werden können sollen, und Programmen, welche nur explizit von vertrauenswürdigen Quellen installiert werden sollten! JavaScript unterläuft diese Massnahme, mit Programcodeschnipsel in ansonsten harmlos aussehenden Daten eingebaut, ohne dass der Benutzer vor holen und ausführen dies erkennen kann.
Ansgesichts von etwas derart fraglichem sollte JavaScript nicht benutzt werden, oder zumindest nur unter sehr gut kontrollierten Bedingungen. Aber das wichtige "default ausgeschaltet" Prinzip wurde hier von den dahinter steckenden Featurefetischisten "selbstverständlich" wieder einmal komplett ignoriert, weil sie einer bedingunglosen "mehr ist besser" Ideologie folgen. Folglich haben Webbrowser Schreiber und Website Designer dies bis heute noch nicht kapiert, erstere implementierten daraus ein "default eingeschaltet" und zweitere setzen es einfach ungefragt voraus. Daher wurden hier statt stets sicher bleibende HTML Webpages diese mit unsicherem JavaScript sabotiert.
In der Rechnersicherheit gibt es ein weiteres zentrales Prinzip, dass jeder Missbrauch auf ausnutzen von ungewollten Seiteneffekten basiert, und daher die Chancen von solchen minimiert werden sollte. Die Mathematik besagt, dass bei n Elementen mit n*(n-1)/2 Interaktionen zu rechnen ist. Jeder Angreiffer wird versuchen, in diesen einen ausnutzbaren Seiteneffekt zu finden. Daher ist die Menge n reduzieren wichtig. Jedes ausgeschaltete Feature macht dies. Daher ist "default ausgeschaltet" ein wichtiges Prinzip. Jedes nicht implementierte erst recht, weil selbst der Ausschalter abwesend ist. (All dies ist wiederum nur ein Sonderfall von der uralten generellen Ingenieursregel von "Behalte es simpel, Dummkopf", weil nur einfache zu fehlerfreier und somit robuster und davon zuverlässiger Technologie führen kann.)
Eine frühe Form davon war durch massives Fluten mit Fenstern oder Popups, oft voller Werbung, welche teils auch nach Browserfenster zumachen noch herumliegen und nerven. Wie kann man das noch optimieren? Durch Popups mit zu kleinem "Schliessen" Knopf, damit der Benutzer jedes X-te mal einen ungewollten Klick auf die Werbung macht, gefolgt von wegen dieser Umleitung zuerst auch noch beenden müssen mehr genervt sein. Noch schlimmer? Selbst nach Knopf erwischen nur halbe Werbung weg, damit zweiter Wegklick notwendig wird, für zweite Chance auf danabenklicken erzeugen. Noch schlimmer? Selbst nach Knopf zweimal erwischen noch den Knopf anzeigen um die Werbung zurück zu holen, so wie wenn jemand nach zweimal loswerden das Teil wieder haben wollte! Aber dazu ein Overlay benutzen, welches Scrollen verlangsamt. Die Vorstellung von Werbung als Bild in Page, welche duch normales ohnehin gemachten scrollen automatisch weg geht ist wohl zu einfach.
Das geht bis zum ganzen Browserverhalten unvorhersehbar machen oder zumindest Browsertiming. Gerade "hilfreiches" automatisches Textfeld vervollständen "glänzt" mit solchen Sabotageeffekten, bis zu Site unbenutzbar machen, wenn es gar editieren blockiert während suchen (gerade auch wenn es im Mobilnetz zu langsam seine Daten holen kann, oder schlicht wegen Server von vielen automatischen Zugriffen überlastet). Das zudem nur zu oft gefolgt von danach das falsch vervollständigte wieder löschen müssen, wonach sofort ein weiterer Versuch an vervollständen losgeht...
Es ist erstaunlich, wie viele Websites durch JavaScript abschalten wieviel besser werden (und einige davon erst wieder brauchbar!). Dem entgegen stehen nur sehr wenige Sites, welche mit JavaScript erst ermöglicht wurden (sowie wenige weitere welche damit ernsthaft besser wurden). (Weshalb ich JavaScript auf meinem Handy stets ausgeschaltet habe, anfangs damit die hiesige Fahrplan Website wieder brauchbar wird, inzwischen damit das Web überhaupt benutzbar ist. Aber auch auf meinem Desktop, wegen vieler Nervigkeiten loswerden, plus dort mit bewusst altem Browser ohnehin unvermeidlich.)
JavaScript Code besteht aber aus Kommandos. Neue unbekannte führen zu Scriptabbruch, eine ganze Funktion entfällt, auch wenn das Script funktionskritisch gewesen wäre! Womit eine zu neue Site unbenutzbar wird, ausser der Designer weiss genug um auf Neues zu testen und einen Fallback zu organisieren. Was aber viele davon nicht können, oder einfach wegen Aufwand nicht wollen. (Das Prinzip vom allen Personen mit allen Rechnern und allen Browsern, im offenen World Wide (=weltweit!) Web wird so wieder einmal mit Füssen getreten.)
Weiter geht es mit Sicherheitslöcher ausnutzen, dem aufwendigen JavaScript Interpreter und den Dokument Objekt Modellen (DOM) dahinter als eine grosse Menge an zusätzlichen von Angreifern ausnutzbaren Codepfaden. (Das muss nicht mal ein absichtlicher Angriff sein, obiges vervollständigen welches die Fahrplan Site unbenutzbar machte, zeigt dass es auch ohne Absicht in Sabotage ausarten kann!)
Es geht bis hin zu den Cross Site Scripting (XSS) Attacken, wo JavaScript in per HTML dargestellten Daten "versteckt" wird, und beim "anzeigen" im Browser des Opfers ausgeführt einen Schaden anrichten kann. Dies bis hin zu als Virus weitere Kopien von sich in Daten einfügen, mit dem jeweiligen aktuellen Leser seinen Privilegien. Womit ein einzelner Daten schreibender Benutzer eine beliebige "harmlose" (und daher vertraute!) Website unterlaufen kann, damit sie andere Leser sabotiert, und beliebig indirekt weitere. Dazu braucht die betroffene Website nicht mehr als eine Kommentarfunktion, mit deren Eingaben nicht von potentiellen JavaScripten bereinigt werdend, wozu jeder einzelne Website Schreiber alle potentiellen Scriptauslöser aller Browser kennen und abfangen muss! Daher versagen immer wieder Sites dabei, aus Prinzip.
Nebenbei: Strikte ist solches Cross Site Scripting ein Spezialfall des generischen "Interpollation" Problemes, welches in allen Scriptsprachen unvermeidbar auftritt, in denen Daten per Variablennamen durch Daten ersetzen bereits dereferenziert und eingefügt (=interpolliert) werden, bevor das Script syntaktisch interpretiert wird. Womit deren Dateninhalt zu einer loadtime/runtime Sourcecode Modifikation wird, und damit auch benutzt werden kann um Schadcode via Daten in den Nutzcode einzuschleusen, was eine als Code Injection bekannte sehr universelle Angriffsart ist. Bei der JavaScript in HTML Situation, mit allen Daten bereits auf dem Webapp Server eingefügt, und danach erst alles beim Zielrechner syntaktisch interpretiert, wird dies zu einem fundamentalen und unvermeidlichen Problem. Es kann daher nur via jede einzelne Website sicher schreiben absichert werden, mit dort verhindern dass Scripte in Daten enthalten sind. Was danach verlangt, dass jeder Website Designer absichern muss, dass die ganzen Daten in ausreichend sichere "Escapes" eingepackt sind, aber selber keine solche als Zeichen beinhalten, mit denen sie einen Datensatz in zwei kleinere mit Programmcode dazwischen "aufspalten" können. Womit bei Zugriff auf beliebige Servern durch den Benutzer keine stabil sichere von ihm vertraubare Lösung existieren kann.
Nebenbei: Für sicher sein müsste der JavaScript Nutzcode in einer separaten statischen Datei (ohne irgendwelche eingefügte Daten) ausgeliefert und interpretiert werden, mit danach zu runtime die Daten aus der Script aufrufenden HTML Page nachfordern und ohne durch den Interpreter gehen direkt als Daten verwerten. (Wie dies übrigens in Java Applets stets der Fall ist.) Dazu müsste JavaScript aber erweitert/umgebaut werden, und damit zu bestehenden Browsern inkompatibel werden. Zudem erlaubt dies auch nur neu geschriebene Sites sicher zu sein, lässt den Browser für alle alten oder gar absichtlich defekten Sites verwundbar. Also auch keine stabil sichere vertraubare Lösung.
Dies nervt erst recht bei Sites welche einst ohne JavaScript einwandfrei liefen! Ein Fall davon ist Google Maps, welches vor Herbst 2009 ohne problemlos benutzbar war, mit seither brachialem Einsatz davon (trotz davor erwiesen unnötig!). Dies gerade auch unterwegs wenn man Karten brauchen würde, mit dann einfache Phonebrowser und schwache Phoneprozessoren massiv (über-)fordernd. Bonuspunkte, wenn dies selbst in Google ihrem expliziten "Mobile Modus" geschieht, welcher nach einer Weile gar auf Desktops in älteren Browsern nicht mehr richtig funktionierte! (Zum Gl&uuuml;ck gibt es inzwischen komplett vom Web, inklusive auch Google, unabh%auml;ngige Open Steet Map basierte Smartphone/Tablett Apps. Aber dafür mussten wir 10 Jahre warten.)
Dies nervt noch viel mehr bei Sites, welche nicht nur einst ohne liefen, sondern auch mit JavaScript immer schlimmer wurden (aber ohne es brauchbar blieben!), und dann plotzlich ohne nicht mehr gehen (und man dann ihren Horror mit haben muss). Besonders "optimal" wird dies bei Webformularen, welche nur neu hinter dem Absenden Knopf etwas JavaScript haben, und man dieses erst nach alles ausfüllen merkt, man dann einschalten und Seite neu laden und alle Daten erneut eingeben muss. Nochmals schlimmer wenn dieses erst noch gar nichts macht was es braucht, nur weil der ignorante Designer nicht mehr weiss wie man ohne JavaScript ein Webformular abschickt!
Als Beispiel die MMS Bilder anzeigen Website meines Handy Providers, welches einst ohne JavaScript einwandfrei lief, dann plötzlich nur um die Loginbox abzuschicken es braucht, ohne ansonsten irgendwie mehr zu können, einfach nur kaputterweitert. Besonders nervig zusammen mit auf Handy JavsScript ausgeschaltet haben wegen dem weitaus wichtigerem Fahrplan der Eisenbahn nur so benutzbar sein. Weshalb ich MMS nicht mehr benutze, Kollegen abgewöhnt habe mir solche zu schicken. (Was alles wieder mal einen Fall ergibt von statt Illusion von mehr Features real weniger Funktion bekommen!)
Das Extrem hier ist aber eindeutig Doodle, vom einfachen Tabellen Webformular App zum JavaScript Interface-Monster, mit allem obigen überhaupt begehbaren Fehlern darin. Dies erst noch mit default nur Teilansicht der Tabelle zeigend (wem bringt dies etwas?) und volle erst mit zweites mal nachhaken, beides langsam von JavaScript (und nochmals langsamer von doppelt Seiten holen). All das ohne auch nur irgendetwas mehr zu können als vor Jahren ohne! Die letzte relevante Erweiterung war neben Ja/Nein auch Ja/Ungern/Nein Auswahl zu offerieren. Bonuspunkte gibt es dafür, dass sie auf die vielen "tut nicht mehr" Beschwerden nicht mit einsehen und vereinfachen reagieren, sondern mit einer "Hilfe" Seite in welcher sie selbst soweit gehen, Antiviren Software ausschalten(!) zu empfehlen, weil manche davon ihr defektes Zeugs als Gefahr einstufen und eliminieren und damit unabsichtlich sabotieren. Noch mehr Bonuspunkte dafür, dass sie inzwischen zwar einen "Fallback Modus" addiert haben, aber in diesem nur eine Zeile Eingaben annehmen können, aber nicht die Tabelle der bestehenden Einträge darstellen, weil sie laut Aussage dieser Seite nicht mal mehr eine Tabelle ohne JavaScript darstellen können, trotz es frühher gemacht zu haben! Besonders bedenklich, wie sie derart von Studentenprojekt zu Inkompetenzhaufen degenerieren konnten. Absolutes Posterkind schlechthin für alles was im modernen Web falsch lüuft. (Zum Glück ist deren Idee so einfach, und braucht null Infrastruktur oder aufwendig zu sammelnde Daten, dass es inzwischen viele Doodle Klone gibt, alle jederzeit im Web testbar. Ausserdem ist ein solcher Klone schreiben fast das ideal grosse "teste eine Web Technologie aus" Versuchsobjekt, was viele Klone erzeugte.)
Nebenbei: Etwas wie NoScript im Web wäre auch bei Mail (und beliebigen anderen Dateien von CD/DVD oder USB-Stick) sinnvoll, als einen analog funktionierenden "mehr als Virenscanner". Dieser sollte einfach bei beliebigen bekannt scriptbaren Dateiformaten (inklusive Office Dateien und HTML) alle darin enthaltenen Scripte (inklusive JavaScript) radikal beseitigen, womit auch mit unsicherer Software danach keine Gefahr mehr bestehen kann. Dieser würde dann nur noch Updates brauchen um neue Sorten gefährlicher scriptbarer Formate zu erkennen, und zu wissen wie diese zu durchsuchen und bereinigen sind, statt wie bei heutigen Virenscannern bei jedem spezifischen neuen Virus neue Signaturen nachlernen müssen. Dieser wäre damit auch weit sicherer, weil viel seltener von neuen unbekannten Viren umgangen. Da Scripte in Daten in den wenigsten Fällen legitim und bedeutend sind sollte das reichen, mit weit weniger Aufwand. Erst recht wenn nach der Verbreitung solcher Filter jegliche Scripte in Daten verpönnt werden.
Allerdings kann selektiv einschalten auch nur die Sicherheitsprobleme bei beliebigen Fremdsites lösen, nicht aber kaputte Designs bei solchen welche man kennt und gerne benutzen will, oder Datenprobleme auf solchen wie beim Cross Site Scripting. Ebenso kann es nicht bei manchen Spezialbrowsern für Blinde wirken, welche mit Textanalyse und als Sprache ausgeben funktionieren, weil diese jegliche Scripte prinzipiell nicht auswerten können (weil keine Ausgabe Anordnung sichtbar ist vor der Ausführung, und bei Ausführung kein linearer Zeit zu Anordnung Zusammenhang besteht), womit der Web Vorteil wieder verlorengeht, weil das Web damit zu nicht mehr behindertengerecht wird!
Aus all diesen Gründen wird JavaScript inzwischen von manchen als JavaShit bezeichnet. Also will man es definitiv "default ausgeschaltet" haben, oder besser gar komplett ausgeschaltet. Oder noch besser JavaScript und alles was darauf aufsetzt komplett herauszureissen, für etwa nur 1/3..1/10 an Codegrüsse, mit etwa 3 mal Geschwindigkeit, und nur 1/10 soviele Bugs. Logisch braucht man dazu Websites so gestaltet, dass sie auch ohne laufen.
Nebenbei: Daher habe ich JavaScript bewusst auf allen Rechnern ganz abgeschaltet, und bestehe auf Websites welche ohne funktionieren. Einige andere aufmerksamere Geeks machen dies ebenso. Inzwischen gibt es eine aktive anti-JavaScript Bewegung. So effektiv, dass sie manche Website Designer dazu gebracht haben, statt "Schalten sie JavaScript ein" Fehlermeldung, auch wieder ohne JavaScript zu erlauben, mit nur noch "Diese Site sollte nun wieder ohne JavaScript funktionieren, aber vielleicht tut etwas noch nicht" Warnung. Selbst Google Suche wurde nach ihrem Feb 2025 Entscheid zu nur-mit-JavaScript in nur wenigen Tagen dazu gedrängt diesen komplett zu reversieren.
Nebenbei: Einen absolut idealen Test für Website Designer habe ich im Web gefunden. Im englischen Original: "Go sit in an uncomfortable chair, in an uncomfortable location, and stare at an uncomfortably small screen with an uncomfortably outdated web browser. How easy is it to use the websites you've created?" Das ist übersetzt: "Geh und sitz in einem unbequemen Stuhl, in einer unbequemen Umgebung, und starre auf einen unbequem kleinen Bildschirm mit einem unbequem veralteten Webbroser. Wie einfach ist es, die Websites die du erzeugt hast zu benutzen?". (Hintergrund zu der Aussage war eine von ihren Eltern herausgeworfene junge Frau, sitzend auf einem Plastiksessel im Gang eines Hilfswerkes, mit nur einer geschenkt bekommenen PSP Spielkonsole, welche trotzdem die einfach designte Website des Hilfswerkes auf dessen Mikrobrowser benutzen konnte.)
Bis auf dass es Leute gibt, welche aus persönlichen Gründen wie "bessere" Methoden entdecken und verbreiten dies sabotieren wollen. Basis davon ist vor allem die um Bilder kompakt zu machen eingesetzte Datenkompressionen. Diese sind mathematische Methoden, um die wegen oft nahe beieinander liegende Farbe/Helligkeit von Nachbaarpixel im Bild auszunutzen, um diese in weniger Daten umzurechnen, zumeist mit in Durchschnittswert einer 8x8 Gruppe plus Verlaufdaten in 2 Richtungen. (Bei Video werden noch die nahe beieinander liegende Anordnung in Bildserien ausgenutzt.)
Logisch lassen sich bessere Methoden finden. Nur sind sie besser genug, um auf diese umstellen zu wollen, trotz um diese zu nutzen alle Browser weltweit mit mehr Datenformaten aufrüsten müssen? Dies ist bei JPEG so gut sein wie es ist praktisch nicht zu rechtfertigen. Leider haben die Macher hinter webp dies nicht begriffen, und dieses inzwischen so weit gestreut, dass manche Websites es zu benutzen anfangen.
Einerseits wachsen Diskplatz und insbesondere Netzbandbreite schneller als die Anzahl Megapixel. Wer dies nicht glaubt, soll sich daran errinnern, wie lange man früher bei Bilder herunterladen brauchte! Alte Browser hatten deswegen noch eine "keine Bilder holen" Option, mit dann auf eines der "fehlendes Bild" Icons klicken nur dieses eine Bild holen. Also besteht hier echt kein Bedarf.
Anderseits kann man die Megapixel auch herunterrechnen, durch Bilder auf niedere Auflösung reduzieren. Was erst noch die Bildqualität verbessert, weil es Pixel ausmittelt, damit thermisches Zufallsrauschen der immer kleineren Pixel eliminiert. Die heutige hohe Auflösung existiert ohnehin nur, weil sie erzeugen mit modernen Chips praktisch nichts kostet und man damit Ausschnitte aus einem Bild herauszoomen kann, ohne dabei zu geringe Auflösung zu bekommen. Nur sind heute zuviele Leute zu gedankenlos oder zu faul, um bei kein Ausschnitt schnell mal herunterzurechnen. Und Website Designer scheinen diese Funktion bei Bilder hinaufladen vergessen zu haben.
Herunterrechnen sollte man ohnehin machen, weil grossformatige Bilder ein Problem sind bei niedrigauflösenden Monitoren. Selbst FullHD Monitor sind nur 1920x1080 Pixel, also nur 2MPixel! Ein heute kleines 8MPixel Bild hat bereits soviele Pixel, dass es horizontal und vertikal halbiert werden muss. Ein 18MPixel braucht durch drei. Ein 32MPixel durch vier!
Und das ist selbst für FullHD mit Bild auf Vollbildschirm ohne Fenster ganz füllen. In ein Fenster passen braucht eher nochmals Halbierung in beide Richtungen, auf nur 0.5MPixel. Wer Details liefern will, kann ja das heruntergerechnere Bild als Link gestalten, welches bei anklicken dann die Vollversion ausliefert. Nur sind heute zuviele Leute zu gedankenlos oder zu faul, um solchen minimalen Aufwand zu treiben, der übrigens vor Jahrzehnten absoluter Standard war. Und Website Designer scheinen diese Funktion ebenfalls komplett vergessen zu haben.
Diese Seite ist von Neil Franklin, letzte Änderung 2025.04.02