nicht angemeldet
TS
Gunnar Bittersmann
Gunnar Bittersmann
Rolf b
Gunnar Bittersmann
MudGuard
Auge
Gunnar Bittersmann
JürgenB
Gunnar Bittersmann
Julius
es gibt fast nur noch Webseiten, die nicht ohne Scripte funktionieren. Es nervt!
Hello,
es gibt fast nur noch Webseiten, die nicht ohne Scripte funktionieren. Es nervt!
Dass das nervt, da stimme ich Dir zu. Denn JavaScript ermöglicht immer ausführliche Fingerprints des Clients, und das mag ich auch nicht wirklich. Cookies wären also eigentlich gar nicht mehr notwendig.
Aber das ist erst die Vorstufe.
Websocket ist auch mächtig im Anrollen und dann wird es erst richtig spannend.
Liebe Grüße
Tom S.
@@Regina Scheißklug
es gibt fast nur noch Webseiten, die nicht ohne Scripte funktionieren. Es nervt!
Was sich darin widerspiegelt, dass es fast nur noch Stellenanzeigen für Frontend-Entwickler gibt, die nicht ohne JavaScript funktionieren. Das nervt!
Kenntnisse in HTML und CSS sind kaum gefragt. (Dafür gibt’s ja Bootstrap.)
Wie jetzt, unsere Seite überladen? Hat doch jeder Nutzer DSL oder 4G!
LLAP 🖖
Hallo Gunnar,
Wie jetzt, unsere Seite überladen? Hat doch jeder Nutzer DSL oder 4G!
nur kapieren die nicht, dass die Probleme nicht durch das Datenvolumen entstehen, sondern durch die Vielzahl und Komplexität der ablaufenden clienstseitigen Scripte. Fühle mich gerade bei den "großen" Anbietern/Seiten wie Chip, Spiegel, welt, etc. wie vor 15 Jahren, PC müht sich mit den Seiten ab. Die verstehen bis heute nicht, dass eine Seite schnell und problemlos zu laden sein sollte. Seinerzeit habe ich Yahoo mehrfach angeschrieben, dass diese Überfrachtung nicht zu ertragen ist und natürlich nie ein Antwort bekommen habe, aber nicht einmal aus dem logischen Erfolg des Google-Minimalismus haben die es bis zum endgültigen AUS kapiert. Da wurden dann reihenweise hochdotierte Manager abgelöst und eingesetzt ohne die offensichtliche Problematik zu erkennen.
Gruss
Henry
@@Henry
Wie jetzt, unsere Seite überladen? Hat doch jeder Nutzer DSL oder 4G!
nur kapieren die nicht, dass die Probleme nicht durch das Datenvolumen entstehen, sondern durch die Vielzahl und Komplexität der ablaufenden clienstseitigen Scripte.
Beides.
„Es gibt Menschen bei uns um die Ecke und auf der ganzen Welt, die sich nicht das neuste und beste Gerät leisten können, die sich keinen großen Datenvolumentarif leisten können, die sich keine schnelle Netzverbindung zuhause leisten können.“ (Tim Kadlec)
S.a. Nachdenkliches zum Wochenende: Den Schwerpunkt auf das Bedeutsame legen
LLAP 🖖
Hallo Gunnar,
manche können nicht, andere (wie ich) wollen nicht.
Schreckliches Beispiel für einen Datenstrudel: http://weihnachtsfeierparty.de, da geht es um Infos zu einer kölschen Weihnachtsfeier. Das Ding zieht beim Aufruf vom Desktop 14 MB, auf meinem Handy hat es 8 MB gezogen, aber vermutlich nur, weil ich hastig "Zurück" getippt habe. Mein Monatsbudget ist 200MB, 4% weg durch eine Startseite - sowas gehört abgeschaltet. Alles auf eine Seite, und riesige Bilder - enä, dat isset nit.
Rolf
@@Rolf b
Das Ding zieht beim Aufruf vom Desktop 14 MB, auf meinem Handy hat es 8 MB gezogen, aber vermutlich nur, weil ich hastig "Zurück" getippt habe. Mein Monatsbudget ist 200MB, 4% weg durch eine Startseite - sowas gehört abgeschaltet.
Am besten vom Browser. Browser sollten eine Datenvolumengrenze pro Webseite haben (ein halbes Megabyte sollte vollkommen reichen). Wird diese überschritten, stoppt der Browser den Ladevorgang und fragt den Nutzer, ob er weiterladen soll.
Der Meldungstext sollte deutlich machen, dass es kein technisches Problem ist, sondern dass der Seitenbetreiber zu blöd ist, seine Inhalte vernünftig anzubieten.
Wenn die Seitenbetreiber mitbekommen, dass Nutzer nicht bereit sind, unnötig riesige Datenmengen runterzuladen, werden sie vielleicht doch mal drüber nachdenken, wie sie die Datenmengen reduzieren. Von alleine ohne Zwang kommen sie nicht drauf.
Bei manchen Webseiten (Videoportalen bspw.) will man größere Datenmengen inkaufnehmen. Der Browser könnte eine Whitelist von Websites führen, bei denen er nicht mehr nachfragt.
Alles auf eine Seite, und riesige Bilder - enä, dat isset nit.
Richtige Bildformate verwenden und Bilder webtauglich machen sollte zum Handwerkszeug eines Frontend-Entwicklers gehören (wenn schon nicht eines Grafikdesigners). Kann aber kaum jemand. Wie ich schon sagte, sind Qualitäten eines Frontend-Entwicklers ja nicht gefragt. *seufz* Hauptsache, das neuste JavaScript-Framework …
LLAP 🖖
Hi,
Bei manchen Webseiten (Videoportalen bspw.) will man größere Datenmengen inkaufnehmen. Der Browser könnte eine Whitelist von Websites führen, bei denen er nicht mehr nachfragt.
Und auch eine Blacklist. Warum soll ich jedesmal beim Besuch von Seite x wieder bestätigen, daß ich den noch nicht geladenen Rest nicht haben will? (ggf. ist ja die für mich interessante Information schon vorhanden, bevor die dicken Brocken kommen ...)
cu,
Andreas a/k/a MudGuard
wie der Name schon sagt, bin ich absoluter Anfänger…
kurze Frage, gibt es eine einfache Methode angezeigt zu bekommen, wieviel Daten übertragen werden? Kann natürlich vorher schauen, was ich an Datenvolumen habe und nach Besuch der Seite das ergebnis vergleichen, aber einfacher wäre es wenn es eine Einstellung im Browser gibt, die das Datenvolumen einer Seite anzeigt…
@@Absolute Beginner
kurze Frage, gibt es eine einfache Methode angezeigt zu bekommen, wieviel Daten übertragen werden?
Entwicklungswerkzeug deines Browsers, Reiter „Netzwerk(analyse)“.
LLAP 🖖
Hallo Gunnar,
bei dieser Partyseite war das aber mühsam, weil die eine Riesenkiste voller Requeste raushagelt. Eine Summenanzeige habe ich im Chrome nicht gefunden, und irgendwie hat der Windows 10 Taskmanager auch die Gesamtzahl empfangener Bytes nicht mehr drauf. Ich hab's für dem Desktop dann über den Statusdialog der LAN-Verbindung im Freigabecenter rausgekriegt :)
Bei einem Mac wäre das bestimmt viel einfacher gewesen. Und unter Linux hätte ich sicherlich ganz einfach mit 3 Kommandozeilentools und 2 Daemons eine Antwort erhalten.
Rolf
Aloha ;)
bei dieser Partyseite war das aber mühsam, weil die eine Riesenkiste voller Requeste raushagelt. Eine Summenanzeige habe ich im Chrome nicht gefunden, und irgendwie hat der Windows 10 Taskmanager auch die Gesamtzahl empfangener Bytes nicht mehr drauf. Ich hab's für dem Desktop dann über den Statusdialog der LAN-Verbindung im Freigabecenter rausgekriegt :)
Meine uMatrix meldet mir 90 Requests, von denen 10 geblockt wurden, weil sie bei meinen Standardfiltern durchfallen (die da wären: von Drittanbieter-Domains nur CSS und Grafiken zu laden).
Ich kann uMatrix empfehlen (für Desktop-Browser) - ist zwar manchmal ein wenig nervig, hilft aber ungemein dabei, Tracking zu vermeiden oder mal mitzubekommen, was für ein Schmu von weiß-der-Henker-wo eingebunden wird. Ich verfluche es immer wieder, es gehört aber inzwischen zu meiner Standardausstattung.
Links: uMatrix für firefox, [uMatrix für Chrome](https://chrome.google.com/webstore/detail/umatrix/ogfcmafjalglgifnmanfmnieipoejdcf?, hl=de), fefe über uMatrix
Grüße,
RIDER
Hallo,
...aber einfacher wäre es wenn es eine Einstellung im Browser gibt, die das Datenvolumen einer Seite anzeigt…
Soweit ich weiß (theoretisch allerdings möglich durch Proxy Voraufruf oder sowas) nein, wäre aber auch wenn es das geben würde sinnlos, weil viele Seiten nicht mehr statisch sind, oft werden Inhalte nach Userinteraktion(scrollen zb.) nachgeladen und sind damit nicht mehr berechenbar,
Gruss
Henry
Hallo
kurze Frage, gibt es eine einfache Methode angezeigt zu bekommen, wieviel Daten übertragen werden? Kann natürlich vorher schauen, was ich an Datenvolumen habe und nach Besuch der Seite das ergebnis vergleichen, aber einfacher wäre es wenn es eine Einstellung im Browser gibt, die das Datenvolumen einer Seite anzeigt…
Mir ist eine solche einfache Anzeige in keinem Browser bekannt. Ich kann mir aber vorstellen, dass es passende Addons/PlugIns für jene Browser gibt, die eine entsprechende Schnittstelle haben. Zudem gibt es, zumindest für den Firefox, noch die nicht ganz so einfache Methode über die Seiteneigenschaften (Rechte Maustaste⇒Kontextmenü=>Seiteneigenschaften), in denen du zumindest die Größe der Seite und der geladenen Medien ablesen und diese dann addieren kannst. Änliches geht mit den in wohl jedem (?) Browsertyp vorhandenen Entwicklertools. Dort gibt es einen Punkt, der Netzwerkanalyse (oder ähnlich) heißt und unter Anderem die Ladezeiten und -größen ausgibt. Um das Addieren kommt man auch dort nicht herum.
Tschö, Auge
Tach!
Mir ist eine solche einfache Anzeige in keinem Browser bekannt. Ich kann mir aber vorstellen, dass es passende Addons/PlugIns für jene Browser gibt, die eine entsprechende Schnittstelle haben.
Bei denen kann ich mir genausowenig wie bei anderen im Browser sitzenden Messverfahren vorstellen, dass sie korrekt im Sinne der Fragestellung arbeiten. Zu dem vom Provider gezählten Volumen zählt doch garantiert auch der Overhead vom TCP/IP-Datenverkehr mit und nicht nur der Payload von HTTP und aufwärts. Den Overhead bekommen Anwendungsprogramme üblicherweise nicht zu Gesicht. Aber als Näherung mag das Payload-Volumen eine verwendbare Aussage liefern.
dedlfix.
Hello,
kurze Frage, gibt es eine einfache Methode angezeigt zu bekommen, wieviel Daten übertragen werden? Kann natürlich vorher schauen, was ich an Datenvolumen habe und nach Besuch der Seite das ergebnis vergleichen, aber einfacher wäre es wenn es eine Einstellung im Browser gibt, die das Datenvolumen einer Seite anzeigt…
Im Prinzip nein! Ein einfache Methode gibt es nicht.
Ein Browserdokument setzt sich zusammen aus vielen Einzelkdokumenten:
Der Browser müsste also zuerst die Kopfinformationen (Metadaten) über das Primärdokument anfordern, sehen was ihm mitgeteilt wird, und wenn es ihm nicht hier schon zuviel ist, das Primärdokument anfordern.
Anschließend müsste er die Kopfinformationen (Metadaten) aller im Primärdokument refernzierten Dokumente anfordern und diese gleichermaßen auswerten. Anschließend könnte er dann sagen "Nee, Sekundärdokumente über 1kByte ignoriere ich" und nur den verbleibenden Rest die vollständigen Dokumente anfordern.
Das würde zwar vielleicht helfen, das Trafficvolumen zu vermindern, nicht aber die Anzahl der Requests. Die Anzahl würde mindestens auf das Doppelte steigen.
Liebe Grüße
Tom S.
Hallo,
Es nervt!
weiß zwar nicht was du damit meinst, aber finde lustig was der Link zeigt. Dass Google offensichtlich auch nicht den Unterschied zwischen Javascript und Java kennt, eine Sache die hier im Forum, gefühlt, tausendmal den Leuten näher gebracht wurde 😉
*(zum Forum) Wie kriege ich hier nur einen größeren Abstand zwischen Bild und Text?
Gruss
Henry
Hallo Henry,
*(zum Forum) Wie kriege ich hier nur einen größeren Abstand zwischen Bild und Text?
Gar nicht. Du kannst das Bild in einen eigenen Absatz stecken, das hast du getan. Du kannst keine leeren Absätze erzeugen, ich kenne zumindest keinen Weg. Und das ist imho auch gut so.
Bis demnächst
Matthias
Hi,
Gar nicht. Du kannst das Bild in einen eigenen Absatz stecken, das hast du getan. Du kannst keine leeren Absätze erzeugen, ich kenne zumindest keinen Weg. Und das ist imho auch gut so.
Wirklich
nicht?
😉
cu,
Andreas a/k/a MudGuard
Es nervt!
Das muss es nicht.
mir scheint, du hast nicht verstanden, worum es geht...
mir scheint, du hast nicht verstanden, worum es geht...
Vermutlich um die uralte Debatte über den sinnvollen Einsatz von JavaScript. Mich störte nur, dass das hier im Thread so einseitig diskutiert wird, wo die aktuelle Debatte schon 20 Jahre weiter ist. Deshalb habe ich mich zu dieser provokanten und inhaltsleeren Antwort hinreißen lassen. Natürlich nerven Werbe-Popups, schlecht gestalte modale Dialoge, unnötige Animationen, aufgeblähte Skripte, die die Performance einer Seite wahrnehmbar negativ beeinträchtigen, Formulare, die man nicht mehr ohne JavaScript absenden kann, Tracking-Skripte, und und und…
Aber es gibt auch bereits seit 20 Jahren eine Debatte über unobstrusive JavaScript, progressive enhancement und graceful degradation. Um mitzureden müssen wir uns auf die Schultern von Giganten stellen und nicht immer wieder alles auf Anfang setzen. JavaScript trägt heute auch einen erheblichen Teil zum Funktionieren™️ des Internets bei: Service-Workers, IndexedDB, Offline-Storage, WAI-ARIA, Schnittstellen für Kameras, Mikrofone, Touch-Eingaben, Virtual und Augmented Reality Devices, Kryptographie, Navigation-Timing und und und…
Wenn man JavaScript deaktiviert, dann ist klar, dass eine Seite nicht mehr uneingeschränkt funktioniert, weil progessive enhancement dann halt auch nicht mehr greift. Zum Beispiel, funktioniert eine clientseitige Formularvalidierung dann eben nur noch eingeschränkt, weil man mit reinem HTML5 unter Umständen nicht alle Regeln für das Formular kodieren kann. Und natürlich funktioniert auch kein Service-Worker mehr, der beim Wegfall der Internet-Verbindng dafür Sorge trägt, dass das Formular seinen Weg zum Server findet, sobald wieder eine Internet-Verbindung besteht. Auf Mobil-Geräten wird JavaScript bspw. auch für Gesten-Steuerungen verwendet, das würde auch Wegfallen und schränkt die Bedienmöglichkeiten der Seite weiter ein.
Hallo
… es gibt … bereits seit 20 Jahren eine Debatte über unobstrusive JavaScript, progressive enhancement und graceful degradation.
Und obwohl diese seit 20 Jahren laufende Debatte zu nichts führt, darf man sich nicht über Websites echauffieren, die beweisen, dass die Debatte eben zu nichts führt?
Wenn man JavaScript deaktiviert, dann ist klar, dass eine Seite nicht mehr uneingeschränkt funktioniert, weil progessive enhancement dann halt auch nicht mehr greift.
Ich glaube nicht, dass beim hiesigen Publikum das Problem ist, dass eine Seite ohne JS nicht uneingeschränkt funktioniert. Das Problem sind eher die vielen Seiten, die ohne JS überhaupt nicht funktionieren oder Seiten, die Funktionen, die per HTML und/oder CSS nativ bereitgestellt werden, mit JS kaputtmachen, so dass sie unnötigerweise nicht funktionieren. JS als Replacement statt als Progressive Enhancement.
Und so stehen wir nach einer 20-jährigen Debatte weiterhin an deren Anfang. Mit JS kann man soviele für den Seitenbenutzer und den -betreiber sinnvolle Dinge erledigen aber in sehr vielen Fällen wird damit nach wie vor leider nur Schindluder getrieben. Schade für die Technik und schade für die Debatte.
Tschö, Auge
Und obwohl diese seit 20 Jahren laufende Debatte zu nichts führt, darf man sich nicht über Websites echauffieren, die beweisen, dass die Debatte eben zu nichts führt?
Klar darf man, und man darf darüber geteilter Meinung sein. Nach meinem ersten Patzer, habe ich deshalb ja auch nochmal den Versuch gewagt, die Debatte doch noch ernsthaft zu führen.
Ich glaube nicht, dass beim hiesigen Publikum das Problem ist, dass eine Seite ohne JS nicht uneingeschränkt funktioniert. Das Problem sind eher die vielen Seiten, die ohne JS überhaupt nicht funktionieren oder Seiten
Genau diese Differenzierung ließ sich aber bisher vermissen, und das hinterlässt bei mir auch einen Eindruck von JavaScript-Verdrossenheit - von der ich unsere Community leider auch nicht freisprechen kann, sowie du.
Und so stehen wir nach einer 20-jährigen Debatte weiterhin an deren Anfang.
Darüber bin ich anderer Auffassung, ich denke dass das Bewusstsein für progressive enhancement seit 20 Jahren deutlich gestiegen ist. Das zu verkennen, ist für viele Advokaten gewiss auch ein Schlag ins Gesicht und der Debatte nicht förderlich.
@@1unitedpower
Das zuvor Gesagte war in Ordnung, aber ab hier
Wenn man JavaScript deaktiviert, dann ist klar, dass eine Seite nicht mehr uneingeschränkt funktioniert, weil progessive enhancement dann halt auch nicht mehr greift.
wird’s Quatsch. Zunächst einmal ist nicht JavaScript deaktivieren das Problem.
Und ich frage mich, ob du progressive enhancement verstanden hast.
Zum Beispiel, funktioniert eine clientseitige Formularvalidierung dann eben nur noch eingeschränkt, weil man mit reinem HTML5 unter Umständen nicht alle Regeln für das Formular kodieren kann.
PE ist nicht zu sagen: Feature X funktioniert nicht. PE ist zu sagen: Die Anwendung funktioniert auch ohne Feature X.
In diesem Beispiel ist die Grundfunktionalität: ein Formular abzuschicken. Clientseitige Formularvalidierung gehört nicht zur Grundfunktionalität. Was nicht heißen soll, dass man die Nutzereingaben nicht schon clientseitig prüfen sollte. Sollte man – das ist progressive enhancement obendrauf.
Man muss das Formular freilich so bauen, dass das Abschicken in der Grundfunktionalität ohne JavaScript funktioniert. Erst wenn das zur Validierung nötige JavaScript geladen wurde und ausgeführt wird (nicht: wenn JavaScript aktiviert ist), kann man das standardmäßige Verhalten unterdrücken und erst nach erfolgreicher Validierung die Daten abschicken.
Du nanntest:
Schnittstellen für Kameras, Mikrofone
Auch hier muss man sich erstmal fragen: Was ist die Grundfunktionalität? Ein Photo, Video, Audio zu übertragen? Das leistet <input type="file">. Man kann Photos, Videos, Audios aufnehmen und danach übertragen. Die Anwendung funktioniert – auch ohne JavaScript.
Freilich ist es komfortabler, wenn das Photo, Video, Audio direkt aus der Kamera/dem Mikrofon kommen kann. Diesen Komfort packt man mittels JavaScript obendrauf – progressive enhancement.
Und natürlich funktioniert auch kein Service-Worker mehr
Ja, und? Service worker sind progressive enhancement. Die Anwendung muss auch ohne funktionieren – schon im Hinblick darauf, dass service worker nicht nur auf alten Geräten nicht laufen, sondern auch auf Edge und Safari (iOS und macOS) noch nicht.
Auf Mobil-Geräten wird JavaScript bspw. auch für Gesten-Steuerungen verwendet, das würde auch Wegfallen und schränkt die Bedienmöglichkeiten der Seite weiter ein.
Bei progressive enhancement geht es nicht um Wegfallen, sondern um Hinzufügen (enhancement). Nochmal in Kürze von Mr. Jeremy “PE” Keith:
LLAP 🖖
Hallo Gunnar, hallo 1unitedpower,
ich glaube, ihr seid mit eurer Meinung garnicht so weit auseinander.
Gunnar ist der Meinung, das eine Seite durch progressive Enhancement besser wird, und 1unitedpower, das der Wegfall von progressive Enhancement die (durch PE besser gewordene) Seite (wieder) schlechter macht.
Gruß
Jürgen
@@JürgenB
Gunnar ist der Meinung, das eine Seite durch progressive Enhancement besser wird, und 1unitedpower, das der Wegfall von progressive Enhancement die (durch PE besser gewordene) Seite (wieder) schlechter macht.
Ich bin der Meinung, dass es sowas wie „wieder schlechter machen“ in der Progressive-enhancement-Denke überhaupt nicht gibt. Die Grundfunktionalität ist gut so wie sie ist. Und man macht sie für Geräte/Browser/…, die bestimmte Features unterstützen, noch besser.
Bei PE schaut man nicht zurück, sondern immer nach vorn. „Vorwärts immer, rückwärts nimmer!“
Beim Testen schaut man natürlich doch zurück, ob denn die Grundfunktionalität noch funktioniert oder ob man sie mit JavaScript (oder CSS) kaputtgemacht hat.
LLAP 🖖
Hallo Gunnar,
Bei PE schaut man nicht zurück, sondern immer nach vorn. „Vorwärts immer, rückwärts nimmer!“
wenn aber etwas durch PE besser wird, muss es bei Wegfall von PE wohl auch wieder schlechter werden, eben genau so gut wie vorher.
Daher soll jeder für sich überlegen, ob beim Einsatz von JS die Vor- oder Nachteile überwiegen. Hier im Entwicklerumfeld sollte man dahingehend wirken, dass JS sinnvoll eingesetzt wird, und nicht pauschal "Ich habe JS abgeschaltet und es läuft alles viel besser" rufen.
Gruß
Jürgen
Hallo
Bei PE schaut man nicht zurück, sondern immer nach vorn. „Vorwärts immer, rückwärts nimmer!“
wenn aber etwas durch PE besser wird, muss es bei Wegfall von PE wohl auch wieder schlechter werden, eben genau so gut wie vorher.
Wird es schlechter, weil es „bloß“ funktioniert?
Daher soll jeder für sich überlegen, ob beim Einsatz von JS die Vor- oder Nachteile überwiegen. Hier im Entwicklerumfeld sollte man dahingehend wirken, dass JS sinnvoll eingesetzt wird, und nicht pauschal "Ich habe JS abgeschaltet und es läuft alles viel besser" rufen.
In vielen Fällen lautet (nach meiner Beobachtung) das Argument nicht, dass JS abgeschaltet wird, damit etwas besser funktioniert, sondern damit man weniger unter Beobachtung steht. Was da von vielen Seiten aus -zig oft auch fragwürdigen Quellen eingebunden wird, geht ja auf keine Kuhhaut.
Tschö, Auge
Wird es schlechter, weil es „bloß“ funktioniert?
Entscheide selbst, welche Lösung ist besser:
Welche Lösung ist besser?
@@1unitedpower
Entscheide selbst, welche Lösung ist besser:
- Formular lässt sich ohne JavaScript nicht abschicken.
- Formular lässt sich mit und ohne JavaScript abschicken.
Welche Lösung ist besser?
- Formular lässt sich ohne Internet-Verbidnung nicht abschicken.
- Formular lässt sich mit und ohne Internet-Verbindung abschicken.
Die Frage steht so nicht.
Die bessere Lösung ist: Formular lässt sich sowohl ohne JavaScript als auch ohne Internet-Verbindung abschicken. (Aber nur eins von beidem, nicht beides zusammen.)
LLAP 🖖
Hello,
Die Frage steht so nicht.
Die bessere Lösung ist: Formular lässt sich sowohl ohne JavaScript als auch ohne Internet-Verbindung abschicken. (Aber nur eins von beidem, nicht beides zusammen.)
Und da besteht immer noch meine Frage von gefühlt 1999, was macht man auf Backendseite, um zu erkennen, dass der Client sich mitten im Verarbeitungsgang (Vorgangsbearbeitung) dazu entschieden hat, etwas an seinen Einstlellungen zu ändern (Cookies aus, JS aus, oder umgekehrt)?
Liebe Grüße
Tom S.
Tach!
Und da besteht immer noch meine Frage von gefühlt 1999, was macht man auf Backendseite, um zu erkennen, dass der Client sich mitten im Verarbeitungsgang (Vorgangsbearbeitung) dazu entschieden hat, etwas an seinen Einstlellungen zu ändern (Cookies aus, JS aus, oder umgekehrt)?
Ist es den Aufwand wert, sowas erkennen zu wollen? Es gibt noch genügend anderes Potenzial, dass der Anwender Dinge macht, die dem Vorgang nicht dienlich sind. Beispielsweise falsche aber plausibel aussehende Daten eingeben. Wenn man Mist macht, kommt Mist raus. Das wird der Anwender schon sehen, wenn plötzlich sein Warenkorb leer ist, weil seine Session nicht wiedergefunden werden kann. Aber welcher Anwender macht sowas mitten im Tun? Das wird sich wohl eher in Richtung "keiner" bewegen, und dann schließt sich für mich der Kreis zur ersten Frage.
dedlfix.
Hello,
Und da besteht immer noch meine Frage von gefühlt 1999, was macht man auf Backendseite, um zu erkennen, dass der Client sich mitten im Verarbeitungsgang (Vorgangsbearbeitung) dazu entschieden hat, etwas an seinen Einstlellungen zu ändern (Cookies aus, JS aus, oder umgekehrt)?
Ist es den Aufwand wert, sowas erkennen zu wollen? [...]
Es fragt sich dan noch, ob er das selber wollte oder ob seine Datenpakete von Anderen gefiltert/manipuliert wurden.
Liebe Grüße
Tom S.
Hallo Tom,
Es fragt sich dan noch, ob er das selber wollte oder ob seine Datenpakete von Anderen gefiltert/manipuliert wurden.
Einfach HTTPS einsetzten 😀, dann würde so etwas erkannt und der Anwender ggf. gewarnt.
Gruß
Julius
Hallo
Und da besteht immer noch meine Frage von gefühlt 1999, was macht man auf Backendseite, um zu erkennen, dass der Client sich mitten im Verarbeitungsgang (Vorgangsbearbeitung) dazu entschieden hat, etwas an seinen Einstlellungen zu ändern (Cookies aus, JS aus, oder umgekehrt)?
Ist es den Aufwand wert, sowas erkennen zu wollen? [...]
Es fragt sich dan noch, ob er das selber wollte oder ob seine Datenpakete von Anderen gefiltert/manipuliert wurden.
Ist das wirklich eine Frage, auf die du serverseitig eine Antwort geben kannst oder willst? Ist das nicht eher eine Frage, die der Client bzw. (so vorhanden) der Mensch am Client beantworten sollte?
Tschö, Auge
Hello,
Es fragt sich dan noch, ob er das selber wollte oder ob seine Datenpakete von Anderen gefiltert/manipuliert wurden.
Ist das wirklich eine Frage, auf die du serverseitig eine Antwort geben kannst oder willst? Ist das nicht eher eine Frage, die der Client bzw. (so vorhanden) der Mensch am Client beantworten sollte?
Im Prinzip: Ja, der Server-Prozess sollte das erkennen können.
Wenn z. B. bei einer mit AJAX zerbastelten Seite zeitweise die Netzwerkverbindung ausfällt, sollten sowohl Server als auch Client das erkennen und darauf reagieren.
Da kann man dann den gesamten Vorgang wegschmeißen, oder aber (vielleicht) über die Fallbackdaten erkennen, wo man mit der Bearbeitung wieder aufsetzen kann.
Liebe Grüße
Tom S.
Hallo
Es fragt sich dan noch, ob er das selber wollte oder ob seine Datenpakete von Anderen gefiltert/manipuliert wurden.
Ist das wirklich eine Frage, auf die du serverseitig eine Antwort geben kannst oder willst? Ist das nicht eher eine Frage, die der Client bzw. (so vorhanden) der Mensch am Client beantworten sollte?
Im Prinzip: Ja, der Server-Prozess sollte das erkennen können.
Wenn z. B. bei einer mit AJAX zerbastelten Seite zeitweise die Netzwerkverbindung ausfällt, sollten sowohl Server als auch Client das erkennen und darauf reagieren.
Nun, der Client sollte erkennen, wenn sein Request unbeantwortet bleibt (time out). Aber eine zeitweise ausgefallene Netzwerkverbindung bei einem statuslosen Protokoll wie HTTP? Widerspricht sich das nicht schon im Ansatz?
Tschö, Auge
Hallo
Wird es schlechter, weil es „bloß“ funktioniert?
Entscheide selbst, welche Lösung ist besser:
- Formular lässt sich ohne JavaScript nicht abschicken.
- Formular lässt sich mit und ohne JavaScript abschicken.
Ich verstehe deine Auswahl der Antworten nicht. Welchen Bezug hat sie zur Frage, die ich Jürgen stellte?
Tschö, Auge
Ich verstehe deine Auswahl der Antworten nicht. Welchen Bezug hat sie zur Frage, die ich Jürgen stellte?
Meine erste Frage ist ein Standardbeispiel für einen misslungen Einsatz von JavaScript. Ein Formular muss selbstverständlich auch ohne JavaScript absendbar sein. Meine zweite Frage ist ein Standardbeispiel für progressive enhancement, ein Formular sollte Service Worker nutzen, um auch bei instabiler Internetverbindung weiter zu funktionieren. Um konkret auf deine Frage zu antworten: Ja, ein Formular ist schlechter, wenn es bloß funktioniert, aber nicht so gut, wie es mit progressive enhancement möglich wäre. Meine Idee hinter dieser Fragerei war es zu zeigen, dass die selbe Argumentationskette, die man bei der ersten Frage dazu benutzt, um den schlechten Fall zu verteufeln, bei der zweiten Frage nutzt, um progressive enhancement als richtige Antwort auszumachen.
du schreibst wirr. Stellst hier dauernd nicht existierende Zusammenhänge her.
Hallo,
Wird es schlechter, weil es „bloß“ funktioniert?
schlechter im Sinne von „genauso schlecht bzw. gut, wie ohne PE“.
… Was da von vielen Seiten aus -zig oft auch fragwürdigen Quellen eingebunden wird, geht ja auf keine Kuhhaut.
das wird aber auch ohne Javascript gemacht. Bilder, CSS, Fonts, etc. können auch zum bespitzeln verwendet werden.
Gruß
Jürgen
PE ist nicht zu sagen: Feature X funktioniert nicht. PE ist zu sagen: Die Anwendung funktioniert auch ohne Feature X.
Ich habe nicht gesagt "Feature X funktioniert nicht", ich sagte "Feature X funktioniert eingeschränkt", womit ich in deinen Worte meine, die Grundfunktionalität ist da, die potenziellen Zusatzfunktionen nicht.
@@Gunnar Bittersmann
Ja, und? Service worker sind progressive enhancement.
Und bitte nicht falsch verstehen. In Jeremy “PE” Keith’ Worten: „When I say ‘this is an enhancement’, don’t think I’m saying ‘this is just an enhancement’.“
Service worker und offline first sind großartige Dinge, um Performanz im Speziellen und UX im Allgemeinen enorm zu verbessern. Man sollte das implementieren, auch wenn Edge- und Safari-Nutzer noch nicht in deren Genuss kommen. (Nach dem nächsten Update kommen sie es womöglich schon.)
LLAP 🖖
du führst lauter Spezialfälle auf, von denen hier gar nicht die Rede ist. Wenn ich einfache Bilder nicht angezeigt kriege, Links und Formularbuttons nicht funktionieren, obwohl das alles HTML-Bestandteile aus der Urzeit des WWW sind, hat das rein gar nix mit "progressive enhancement" (fortschrittlicher Erweiterung/Verbesserung) zu tun.
Und wenn ich dann Scripte aktiviere, kriege ich jede Menge Scheiß mitgeliefert, den ich nicht bestellt habe. Im NoScript wird mir doch immer angezeigt, was da alles gesperrt wurde: nicht selten 20 Nachladeadressen...
du führst lauter Spezialfälle auf, von denen hier gar nicht die Rede ist.
Das war meine Absicht: Differenzieren zwischen produktiven und kontraproduktiven Anwendungsfällen von JavaScript. Man darf und soll ja sagen, was einem nicht passt, was schlecht ist, aber dann sollte man auch dazu sagen, wie man es besser macht, wie man es gut macht - ansonsten führt man halt einen Rant.
Hallo
… ansonsten führt man halt einen Rant.
Ach. In welche Richtung weist deiner Meinung nach — abgesehen vom doch recht eindeutig formulierten, kurzen Text — der Titel „mannmannmann...“?
Tschö, Auge
Hallo Auge,
… ansonsten führt man halt einen Rant.
Ach. In welche Richtung weist deiner Meinung nach — abgesehen vom doch recht eindeutig formulierten, kurzen Text — der Titel „mannmannmann...“?
Und deshalb kann man nicht versuchen dem ganzen einen positiven Spin zu geben? 😉
LG,
CK
Hallo
… ansonsten führt man halt einen Rant.
Ach. In welche Richtung weist deiner Meinung nach — abgesehen vom doch recht eindeutig formulierten, kurzen Text — der Titel „mannmannmann...“?
Kann man versuchen, aber genauso, wie im RL, funktioniert das typischerweise nicht, wenn sich jemand einfach nur auskotzen will oder, wie @1unitedpower es nennt, einen Rant führt [1].
Man lasse den Ranter ranten und bringe Argumente an anderer Stelle bzw. zu anderer Zeit an. Das funktioniert meiner Erfahrung nach besser. Regina Scheißklug ist ja grundsätzlich Argumenten zugänglich, auch, wenn sie manchmal (auch außerhalb eines Rants) angepisst reagiert.
Tschö, Auge
Überhaupt, führt man einen Rant? ↩︎
Und deshalb kann man nicht versuchen dem ganzen einen positiven Spin zu geben?
versucht er doch gar nicht...
Doch, das hat er.
nein :-)
man darf..., man sollte...
eigentlich habe ich nicht wirklich auf Erziehung durch dich gewartet ;-)
Außerdem gibt es an meinem Ausgangsbeitrag nix zu differenzieren. Ich schrieb UNMISSVERSTÄNDLICH von Seiten, die ohne Scripte überhaupt nicht mehr funktionieren. Ich schrieb NICHT, daß JavaScript schlecht ist. Keiner hier AUSSER DIR (!) hat die Behauptung in den Raum geworfen, daß JavaScript schlecht ist.
Hallo Regina,
es gibt fast nur noch Webseiten, die nicht ohne Scripte funktionieren. Es nervt!
Es gibt aber auch Seiten, die funktionieren erst, wenn man JavaScript deaktiviert:
Gruß
Julius
Hallo Regina,
Ich nutze neben vielen anderen Addons für so etwas hauptsächlich Yarip. Da kann ich dann das Laden von Ressourcen unterbinden oder auch den Seiten-Stream tweaken und z.B. unerwünschte Script-tags auskommentieren.
Leider scheinen die neuesten Firefoxe dieses Addon nicht mehr zu unterstützen. Und auf Privoxy oder Proxomitron kann ich auch nicht mehr zurückgreifen, weil heute jede Furz-Seite https verwendet, womit diese Tools leider nicht klarkommen. Und selbst wenn https mir meine Tools nicht kaputtmacht, machen html-5-Elemente mit optionalen end-tags Probleme.
Es wird leider heute viel dafür getan, Nutzern das Modifizieren des Quellcodes zu erschweren. Für mich ist das nichts anderes als ein Modifizierschutz durch die Hintertür. Und so kann fein weiterspioniert werden, weils eben zu schwer für Normal-Nutzer ist, die suspekten Elemente zu entfernen.
Mir fehlt ein einfach zu benutzender Proxy der auf Protokoll-Ebene arbeitet und solche Ärgernisse wegabstrahiert. So eine Art Visual-Proxomitron 2.0 für Dummies :-)
Gruß, Nils
Hallo,
Mir fehlt ein einfach zu benutzender Proxy der auf Protokoll-Ebene arbeitet und solche Ärgernisse wegabstrahiert. So eine Art Visual-Proxomitron 2.0 für Dummies :-)
vielleicht brauchst Du das gar nicht. Ich nutze teilweise CLIQZ und die verschiedenen hauseigenen Blocker arbeiten schon sehr effizient, sogar so gut, dass in der stärksten Einstellung, Seiten wie Bild.de nicht mehr angezeigt werden. Auch die Auswertung des Browsers, was so alles im Hintergrund abläuft, sehr gut.
Allerdings, ich nehme ihn dennoch selten, was daran liegt, dass ich vielleicht schon zu IE-gewöhnt bin, dann am langsamen Start und letztendlich, dass er von Burda ist. Das sind natürlich subjektive Empfindungen und deshalb passt er eventuell doch vielleicht zu dir.
Gruss
Henry
Hallo Nils-Hero,
Und auf Privoxy oder Proxomitron kann ich auch nicht mehr zurückgreifen, weil heute jede Furz-Seite https verwendet, womit diese Tools leider nicht klarkommen. Und selbst wenn https mir meine Tools nicht kaputtmacht, machen html-5-Elemente mit optionalen end-tags Probleme.
Jede Site sollte nur noch über HTTPS erreichbar sein. Nur so lassen sich Sauereien wie manipulierende Hotel-WLANs und Verizons Supercookies sinnvoll erkennen bzw. verhindern (entweder sie fassen den HTTPS-Verkehr nicht an oder riskieren, dass die Nutzer eine dicke Warnung angezeigt bekommen). Natürlich kann man sich lokal einen Proxy hinstellen, der den Verkehr untersucht und dann wieder neu verschlüsselt, dann musst du halt in deinem Browser das Zertifikat dieses Proxys als vertrauenswürdig hinzufügen. Allerdings sollte man das aus Sicherheitsgründen besser sein lassen. HTTPS und bei dir im Browser installierte Plugins wie uBlock, NoScript und Self-Destructing Cookies schützen deine Privatssphäre besser als der bloße Verzicht auf HTTPS (dein Provider kennt dann nur noch die Domain, aber nicht die genaue von dir aufgerufene Seite), damit du Filter-Proxies einsetzen kannst. Falls deine Beweggründe bei Handys zu suchen sind: Viele AddOns lassen sich auch unter Firefox für Android ausführen.
Du kannst natürlich immer noch die DNS-Abfragen filtern, um beispielsweise klar als Spione bekannte Domains (Facebook und andere Ad-Netzwerke, z.B. doubleklick) für alle Geräte auszusortieren.
Es wird leider heute viel dafür getan, Nutzern das Modifizieren des Quellcodes zu erschweren. Für mich ist das nichts anderes als ein Modifizierschutz durch die Hintertür.
Vor allem ist es ein Modifizierschutz im Sinne der Nutzer – ein Browser kann deinen Proxy nicht von einem Man-in-the-Middle-Angriff unterscheiden, der ihnen die PayPal-Daten abspenstig machen möchte. Die Mehrheit der Nutzer nutzt keine Proxies und dort schützt der vermehrte Einsatz von HTTPS sie vor Missbrauch ihrer Daten (→ Privatsphäre, Datenschutz). Dass viele Anbieter dutzende Tracker integriert haben, ist nicht das Problem von HTTPS.
Und so kann fein weiterspioniert werden, weils eben zu schwer für Normal-Nutzer ist, die suspekten Elemente zu entfernen.
Der normale Nutzer setzt sich auch keinen Proxy auf, sondern installiert – höchstens – einen Adblocker, weil er das wilde Geblinke nicht ertragen kann. Dass sein Verhalten genaustens beobachtet wird, merkt der Durchschnittsbenutzer dagegen nicht wirklich.
(Dislaimer: Ich bin weder ein Befürworter von Digital Right Management aka DRM noch würde ich es nicht auch gerne sehen, wenn sich mehr Nutzer um Datenschutz und IT-Sicherheit bemühen würden.)
Gruß
Julius
Hallo Tabellenkalk,
Hotel-WLAN
und immer schön die AGB lesen!
Super Aktion, hab schon bei Heise davon gelesen. Zumal sie ja auch die AGBs vorher auf 260 Wörter gekürzt hatten, aber selbst das war einigen offensichtlich zu lang...
Gruß
Julius
Hallo Julius,
Natürlich kann man sich lokal einen Proxy hinstellen, der den Verkehr untersucht und dann wieder neu verschlüsselt, dann musst du halt in deinem Browser das Zertifikat dieses Proxys als vertrauenswürdig hinzufügen.
Und wo gibts Tutorials, die erklären, wie´s gemacht wird?
ein Browser kann deinen Proxy nicht von einem Man-in-the-Middle-Angriff unterscheiden
Das ist schlicht ein Bug. Bei CSP hat man z.B. auch localhost weissgelistet, so einen Mechanismus sollte es auch bei https geben.
Ich bin – wenn es mir aufgezwungen wird – gegen Verschlüsselung. Und damit bin ich nicht alleine.
Gruß, Nils
Hallo Nils-Hero,
Natürlich kann man sich lokal einen Proxy hinstellen, der den Verkehr untersucht und dann wieder neu verschlüsselt, dann musst du halt in deinem Browser das Zertifikat dieses Proxys als vertrauenswürdig hinzufügen.
Und wo gibts Tutorials, die erklären, wie´s gemacht wird?
Vermutlich (ich würde mir so ein Ding nicht aufsetzen); als ich nach „SSL interception proxy“ gesucht habe, kam einiges, was mir nach Tutorial aussah – ob es für dich brauchbare sind, kann ich natürlich nicht beurteilen.
ein Browser kann deinen Proxy nicht von einem Man-in-the-Middle-Angriff unterscheiden
Das ist schlicht ein Bug.
Nein, das liegt in der Natur der Sache: Man kann schlicht keine „gute“ und bösartige Manipulation des Datenverkehrs unterscheiden, nur erkennen, dass manipuliert wurde.
Bei CSP hat man z.B. auch localhost weissgelistet, so einen Mechanismus sollte es auch bei https geben.
Das ist aber nicht vergleichbar mit deiner Forderung danach, Daten statt über HTTPS immer optional auch unverschlüsselt abrufen zu können. Dass man auf localhost auf das Blocken von aktivem Mixed-Content verzichten kann, liegt daran, dass der localhost generell als sicher zu bezeichnen ist (was für das öffentliche Internet aber nicht gilt) – wenn dort ein Programm unerwünschterweise Daten mitschneidet, hat man ganz andere Probleme...
Es wäre sicher irgendwie möglich gewesen, HTTPS so auszulegen, dass es optional wäre, aber dieses Vorgehen würde unnötige Risiken einführen: Ein Man-in-the-Middle-Angriff könnte quasi stellvertretend für dich HTTPS abschalten ohne dass du es merkst (dagegen gibt es HSTS). Nur damit eine Minderheit HTTPS abschalten könnte, würde man die Sicherheit der Mehrheit der Nutzer ganz sicher nicht aufs Spiel setzen.
Ich bin – wenn es mir aufgezwungen wird – gegen Verschlüsselung.
Warum willst du keine Verschlüsselung? – Dass du Scripte und Tracker auch anderweitig blocken kann, hatte ich ja bereits erläutert. Auch scheinst du mir Verschlüsselung mit DRM gleichzusetzen, ohne zu beachten, dass Verschlüsselung dich und deine Daten schützt, während DRM bedauerlicherweise Inhalte vor dir schützt. Du hast bei Verschlüsselung weiterhin die Freiheit, dir einen Proxy dazwischenzuschalten, obwohl man das besser nicht machen sollte.
Und damit bin ich nicht alleine.
Die Kritik unterstützt deine Position aber nicht wirklich, dort argumentiert man nicht direkt gegen Verschlüsselung selbst sondern gegen den damit verbundenen Konfigurationsaufwand, die (geringe) benötigte Rechenleistung und die Probleme beim Verteilen von Zertifikaten an eingebettete Geräte. Von daher finde ich es gut, dass die Browserhersteller Verschlüsselung im Zusammenhang mit HTTP/2 erzwingen – quasi mit Zuckerbrot und Peitsche. In dieses Umfeld passen auch die Maßnahmen, bei unverschlüsselt übertragenen Seiten mit Passwort-Feldern eine Warnung anzuzeigen (bringt wahrscheinlich noch Einige zum Nachdenken) und bestimmte JavaScript-APIs nur noch in sicheren Kontexten zugreifbar zu machen.
*[DRM]: Digital Right Management (von Richard Stallman oft als „Digital Restrictions Management“ bezeichnet)
Gruß
Julius
Hallo Julius,
Das mit dem Sicherheitszertifikat würde mich sehr interessieren, geht das mit Privoxy oder Proxomitron? Oder nehme ich da besser einen anderen Proxy? kannst Du mal ein bischen konkreter werden?
Was mich auch sehr wundert, ist, wieso Du so vehement für https und Co. votierst, wenn auf der ersten Seite der von Dir empfohlenen Suche nach "SSL interception proxy" Artikel wie dieser zu finden sind. Zitat:
The fact that “SSL inspection” is a phrase that exists, should be a blazing red flag that what you think SSL is doing for you is fundamentally broken.
Und das auch HSTS eine tolle Methode ist, den Nutzer auszuspähen (siehe hier und hier), weißt du sicherlich auch. Und im Standard steht nichts darüber, wie das verhindert werden kann. Da existieren offensichtlich Datenschutz-Löcher, die in großem Umfang von den üblichen Verdächtigen – Werbeagenturen, Geheimdienste, AV-Hersteller – nachweislich genutzt werden.
Also, wieso tust Du so, als ob Du meine Skepsis nicht verstehst? Diese 'Schutz'-Mechanismen tun doch das genaue Gegenteil:
Sie unterbinden meine eigenen Schutzmechanismen, aka, meine lokalen Proxies.
Sie erlauben mich mitzuloggen, selbst im Inkognito-Modus. Und nicht trotz dieser Schutzmechanismen, sondern wegen dieser Schutzmechnismen. Und das wird auch getan. Und da kann ich nix machen, weil die Verschlüsselung ja vom Browserhersteller – unabschaltbar – erzwungen wird, obwohl es so nicht im Standard steht.
Sie steigern die Komplexität, und machen es dadurch wiederum dem unbedarften Nutzer schwerer, einen eigenen Schutz zu implementieren.
Die Konsistenz in der Datenübertragung, die diese 'Schutz'mechanismen herstellen, ist kein Vorteil, sondern ein Nachteil. Etwas das fest ist, kann ich leichter kontrollieren und ich kann damit besser Geld verdienen. Und ich glaube, das das der Hauptgrund ist, daß man diese Veränderungen durchgeboxt hat.
Gruß, Nils
Hallo Nils-Hero,
kannst Du mal ein bischen konkreter werden?
Nein, ich habe nur nachgesehen, ob so etwas generell geht bzw. es Software dafür gibt. Wie man den Kram einrichtet, habe ich mir mangels Bedarf nicht näher angesehen (zur generellen Funktionsweise und den Problemen scheint aber der von dir verlinkte Artikel einiges zu erklären).
Was mich auch sehr wundert, ist, wieso Du so vehement für https und Co. votierst, wenn auf der ersten Seite der von Dir empfohlenen Suche nach "SSL interception proxy" Artikel wie dieser zu finden sind. Zitat:
The fact that “SSL inspection” is a phrase that exists, should be a blazing red flag that what you think SSL is doing for you is fundamentally broken. Compounding the problem are the mistakes that SSL inspection software authors are making.
Ich verstehe das von dir zitierte Zitat (ich habe mir erlaubt, den zweiten und letzten Satz zu ergänzen) so, dass sich der Begriff „SSL inspection“ nicht mit der Idee hinter SSL (Vertraulichkeit, Integrität, Authentizität) verträgt und dass zusätzlich die dafür geschriebene Proxy-Software oft fehlerhaft ist.
In wie fern ist das ein Argument gegen HTTPS? Dass der „Endpunkt“ der Verschlüsselung nicht zwangsläufig der Browser sein muss und einige dann schlampig programmierte SSL Interception Proxies dazwischen schalten, lässt sich nicht verhindern – ohne Hinzufügen eines zusätzlichen (selbst generierten) Root-Zeritifikats zum Pool der vertrauenswürdigen Zertifikate im Betriebssystem oder Browser wird der Nutzer auch weiterhin vor Manipulationen gewarnt.
Und das auch HSTS eine tolle Methode ist, den Nutzer auszuspähen (siehe hier und hier), weißt du sicherlich auch. Und im Standard steht nichts darüber, wie das verhindert werden kann.
Es ist wohl leider auch nicht sinnvoll zu verhindern, man könnte höchstens die dafür benutzten Domains in die Filterlisten der Tracker-Blocker aufnehmen, wie es mit klassischen Tracking auch gemacht wird. Hast du auch schon JavaScript (Canvas) und Caching (E-Tag) deaktiviert (damit kann man dich auch tracken!)?
Das Problem dürfte sich allerdings durch HSTS Preload (Liste mit verschlüsselt erreichbaren Websites, die mit allen Browser ausgeliefert wird und daher auch überall gleich ist) und die zunehmende Verbreitung von HTTPS (HTTPS als Standard, vor HTTP wird gewarnt) irgendwann auflösen.
Da existieren offensichtlich Datenschutz-Löcher, die in großem Umfang von den üblichen Verdächtigen – Werbeagenturen, Geheimdienste, AV-Hersteller – nachweislich genutzt werden.
Hast du einen Beleg für den Missbrauch von HSTS als Super Cookie in der Praxis?
Also, wieso tust Du so, als ob Du meine Skepsis nicht verstehst?
Nein, ich tue nicht so. Ich werte bloß den konkreten Sicherheitsgewinn durch HTTPS höher als eine theoretische Möglichkeit, mich zu tracken. Neben Cookies geht das auch über die Inhalte bzw. aufgesuchten Sites selber.
Diese 'Schutz'-Mechanismen tun doch das genaue Gegenteil:
- Sie unterbinden meine eigenen Schutzmechanismen, aka, meine lokalen Proxies.
Dann solltest du deine lokalen Proxies anpassen oder deine Sicherheitsmechanismen und ggf. dort ansetzen, wo sowieso entschlüsselt wird (im Browser, warum ist das für dich keine Alternative?), anpassen.
- Sie erlauben mich mitzuloggen, selbst im Inkognito-Modus.
Hättest du den von dir verlinkten Artikel von golem bis zum Ende gelesen, wüsstest du, dass das zumindest auf Firefox nicht zutrifft:
„Allerdings verzichtet die neueste Firefox-Version 34.0.5 darauf, auf die Datenbank im privaten Modus zuzugreifen, so dass ein Nutzertracking dadurch nicht mehr möglich ist. "Anders als Google Chrome hat Firefox entschieden, die Privatsphäre über die Sicherheit zu stellen und nicht länger HSTS in private Fenster mitzunehmen", sagte Greenhalgh.“
Und das wird auch getan.
Quelle?
Und da kann ich nix machen, weil die Verschlüsselung ja vom Browserhersteller – unabschaltbar – erzwungen wird, obwohl es so nicht im Standard steht.
- Sie steigern die Komplexität, und machen es dadurch wiederum dem unbedarften Nutzer schwerer, einen eigenen Schutz zu implementieren.
Nochmal: Der unbedarfte Nutzer (geschätzt >95% der Nutzer des Internets) wird durch die Verschlüsselung nicht im geringsten beeinträchtigt, er hat sich auch in Zeiten von geringer Verbreitung von HTTPS keine Proxies (solche, die die eigentlichen Inhalte anfassen müssen) installiert. Für ihn stellt HTTPS eine klare Verbesserung dar.
Die Konsistenz in der Datenübertragung, die diese 'Schutz'mechanismen herstellen, ist kein Vorteil, sondern ein Nachteil.
Falls du damit meinst, dass es ein Nachteil ist, überprüfen zu können, ob die Inhalte unterwegs manipuliert wurden, dann ist das schlicht Unfug.
Etwas das fest ist, kann ich leichter kontrollieren und ich kann damit besser Geld verdienen.
Was ist denn an einer über HTTPS ausgelieferten Website unveränderlich? Du kannst immer noch mit ein paar Klicks einen ${xyz}-Blocker in deinem Browser installieren.
Gruß
Julius
Hallo Julius,
Zuerst mal:
Ich interessiere mich für die meisten Konzepte hinter HTTPS und Co. herzlich wenig. Normalerweise halte ich mich dann aus solchen Themen heraus.
Aber hier macht mir jemand meine Werkzeuge (=Proxies) kaputt, mit denen ich gerne in meinem Garten (=Protokoll-Ebene) rumgebastelt habe. Er erklärt mir nicht, wie ich Sie wieder funktionsfähig machen kann (=Tutorial, wie man Sicherheitszertifikate im Browser registriert und den Proxie entsprechend konfiguriert) und gibt mir keinen vollwertigen Ersatz (=HTTPS fähiger Proxy). Alles was er mir sagt ist: "Also ich brauche deine Werkzeuge ja gar nicht. Und so toll ist dein Garten auch nicht. Du kannst ja gerne in einer von x Konzern-eigenen Werkstätten (=Firefox, Chrome, ...) meine eigenen Werkzeuge (=Browser Plugins) benutzen. Natürlich nur, wenn die Werkzeuge auch funktionieren (=Browser Plugins, die nach Update des Browsers nicht mehr lauffähig sind)."
Mit dem Argument wird also der Umstand abgekanzelt, daß https und Co. lokale Proxies kaputt gemacht haben. Das ist natürlich ein Ärgernis.
kannst Du mal ein bischen konkreter werden?
Nein (...)
Siehst Du?
Ich verstehe das von dir zitierte Zitat (ich habe mir erlaubt, den zweiten und letzten Satz zu ergänzen) so (...)
Das kannst Du Dir zurechtlegen wie Du willst, aber der Satz ist an der entscheidenden Stelle eindeutig: "das, was Du denkst, was SSL für Dich macht, ist fundamental kaputt." Du willst mir also etwas, dessen Funktionsweise fundamental kaputt ist, als eine unverzichtbare Notwendigkeit verkaufen.
Es ist wohl leider auch nicht sinnvoll zu verhindern (...)
Doch! man verschlüsselt nicht! Ist ja auch für 95% der Webseiten gar nicht notwendig. Und der so begeistert zitierte Mann in der Mitte interessiert sich für diese Webseiten überhaupt nicht.
man könnte höchstens die dafür benutzten Domains in die Filterlisten der Tracker-Blocker aufnehmen, wie es mit klassischen Tracking auch gemacht wird.
Es erzeugt also einen zusätzlichen Arbeitsaufwand.
Das Problem dürfte sich allerdings durch HSTS Preload (Liste mit verschlüsselt erreichbaren Websites, die mit allen Browser ausgeliefert wird und daher auch überall gleich ist) und die zunehmende Verbreitung von HTTPS (HTTPS als Standard, vor HTTP wird gewarnt) irgendwann auflösen.
Also eine globale Liste, wo sich jeder registrieren muss, der im Internet mitmacht. Aktiv oder ungefragt passiv durch das Besuchen der registrierten Webseite. Und der Schlüssel liegt an einer einzigen Stelle. Da freut sich die CIA.
Da existieren offensichtlich Datenschutz-Löcher, die in großem Umfang von den üblichen Verdächtigen – Werbeagenturen, Geheimdienste, AV-Hersteller – nachweislich genutzt werden.
Hast du einen Beleg für den Missbrauch von HSTS als Super Cookie in der Praxis?
Das habe ich auf TLS bezogen.
Nein, ich tue nicht so. Ich werte bloß den konkreten Sicherheitsgewinn durch HTTPS höher als eine theoretische Möglichkeit, mich zu tracken.
Wenn es theoretische möglich ist, wird es auch passieren. Und daß Google dieses Tracking nicht unterbindet, spricht Bände. Und da ich den Chrome aus Performanz-Gründen für manche Webseiten nutze, ist es keine Hilfe daß der Firefox vermeintlich dieses Schlupfloch schließt.
Der unbedarfte Nutzer (geschätzt >95% der Nutzer des Internets) wird durch die Verschlüsselung nicht im geringsten beeinträchtigt, er hat sich auch in Zeiten von geringer Verbreitung von HTTPS keine Proxies (solche, die die eigentlichen Inhalte anfassen müssen) installiert. Für ihn stellt HTTPS eine klare Verbesserung dar.
Das ist falsch. Jeder wird beeinträchtigt.
Stell Dir das unverschlüsselte HTTP als einen Fluss vor, die Informationen sind das Wasser. Jeder kann Wasser reingießen und jeder kann daraus trinken. Sicher, einige können auch in den Fluss pinkeln, aber so ein Fluß ist groß und hat gute Selbstheilungkräfte. Ein bißchen Pisse kann sogar gut sein. Dann lernen die Leute, besser auf das Wasser zu gucken bevor Sie es trinken.
HTTPS packt das Wasser nun in Kisten und versieht Sie mit einem Schloß. Sicher, nun kann keiner mehr reinpinkeln. Aber wer Zugang zum Wasser haben will, braucht den Schlüssel. Man kann auch gut sehen von wo das Wasser kam und wo es hingeht. Man muss nur die Kisten mitloggen.
Dann willst Du auch noch den Schlüssel für die Kisten an einer einzigen Stelle hinterlegen. Jeder der trinken will, oder eine Kiste verschicken will muss diesen Schlüssel benutzen. Nun muß jeder, der kontrollieren will, was in den Kisten ist, ein Staat zum Beispiel, nur an diesen Schlüssel gelangen. Du kannst dann sogar das Wasser in der Kiste durch anderes Wasser vertauschen, dem Du ein Schlafmittel beigefügt hast, damit die Leute schön ruhig bleiben. Sicher, Du konntest vorher auch schon Schlafmittel in den Fluß kippen, aber die Leute konnten ihr Wasser einfach weiter oben trinken, wo Du keinen Zugriff hast.
Der Schlüssel ist zwar kostenlos, aber in ferner Zukunft, wenn alle vergessen haben, daß Wir mal einen frei fließenden Fluss hatten, kannst Du dann langsam die Daumenschrauben anziehen. Du kannst anfangen eine Gebühr für den Schlüssel oder für den Gebrauch der Kisten zu erheben. Oder Du kannst sagen, ok, Leute, wir sollten nicht jedem den Schlüssel geben. Wer uns zu radikal ist, der sollte keinen Schlüssel bekommen. Nur wer konform handelt, darf den Schlüssel benutzen.
Schließlich hast Du dann eine ordentliche Kontrolle über etwas erreicht, das vorher frei floss. Du kannst zuverlässig das, was dich stört, unterbinden. Das was vorher ein natürlicher Fluss war, aus dem man kostenlos trinken konnte, ist nun eine staatlich kontrollierte Wasservergabe.
Klar, 95% der Nutzer stört das nicht, weil sie mit dem Aufschließen der Kisten und dem Versand nie in Berührung kommen. Aber die 5%, die sich fragen, "Was ist das eigentlich für Wasser und wer baut diese Kisten und wer macht den Schlüssel?" Die können nun nur noch das hinnehmen, was man ihnen anbietet. Versehen mit der Plakette "Sicheres Wasser!". Filtern können Sie nur das Wasser was in der Kiste ist, und Sie können auch nur die Filter benutzen, die mit der Maschine, die die Kiste öffnet kompatibel sind. And der Kiste selbst oder am Schlüssel können Sie nichts ändern.
Das ist das Problem mit HTTPS und Co und anderen 'Schutz'mechanismen. Es sind Kontrollmechanismen die sich als Sicherheitsmechanismen tarnen.
Gruß, Nils
Hallo Nils-Hero,
Ich interessiere mich für die meisten Konzepte hinter HTTPS und Co. herzlich wenig.
Das scheint mir auch dein Hauptproblem zu sein: Du siehst an jeder Ecke die CIA, den BND und die Illuminaten, verkennst aber konkrete Sicherheitsprobleme. Dagegen hilft nur, sich umfassend zu informieren.
<Vergleich, nicht zitiert, weil ich sonst an das Zeichenlimit des Forums gestoßen wäre... 😂>
Der Vergleich hinkt.
Du nutzt eine Eigenschaft (keine Verschlüsselung) eines Protokolls (BTW: HTTP hängt historisch eng mit HTML zusammen) aus, das zu Verwendung in sicheren Kontexten (in der Anfangszeit des Internets war man noch „unter sich“) gedacht war, anfangs noch kaum Interaktionsmöglicheit mit sensiblen Daten (Formulare wurden erst 1995 mit HTML2.0 eingeführt) – das Web2.0 musste sich erst entwickeln und nicht zuletzt waren die kryptografischen Möglichkeiten der 90er – nicht zuletzt wegen des Kryptowars – beschränkt. Dieser Mangel wurde erkannt und wird konsequent ausgemerzt.
Natürlich nur, wenn die Werkzeuge auch funktionieren (=Browser Plugins, die nach Update des Browsers nicht mehr lauffähig sind)."
Bisher haben die jedes Browser-Update überlebt (es ist ja nicht so, dass die Entwickler ihre Software nicht mit den Beta-Versionen der Browser testen) und selbst wenn sie nicht mehr weiter entwickelt würden, würde jemand anderes sie forken – der Bedarf ist da. Der Bedarf an leicht einzurichtenden HTTPS-Proxys aber anscheinend nicht.
Mit dem Argument wird also der Umstand abgekanzelt, daß https und Co. lokale Proxies kaputt gemacht haben. Das ist natürlich ein Ärgernis.
kannst Du mal ein bischen konkreter werden?
Nein (...)
Siehst Du?
Was ist daran verkehrt? Ich habe so ein Ding mangels Bedarf noch nie aufgesetzt und kann daher nicht mit Erfahrungen dienen. Die allgemeine Vorgehensweise, dass du praktisch eine eigene Certificate-Authority aufsetzen musst und dann deren Root-Zertifikat in deinem Browser als vertrauenswürdig hinterlegen musst, hatte ich ja bereits im Ansatz erklärt und wäre auch problemlos in jedem zweiten Artikel über SSL-Interception zu finden gewesen.
Ich verstehe das von dir zitierte Zitat (ich habe mir erlaubt, den zweiten und letzten Satz zu ergänzen) so (...)
Das kannst Du Dir zurechtlegen wie Du willst, aber der Satz ist an der entscheidenden Stelle eindeutig: "das, was Du denkst, was SSL für Dich macht, ist fundamental kaputt." Du willst mir also etwas, dessen Funktionsweise fundamental kaputt ist, als eine unverzichtbare Notwendigkeit verkaufen.
In dem Artikel, aus dem das Zitat stammt, geht es um „SSL inspection software“ und ihre Probleme. In dem Absatz, aus dem das Zitat stammt, heißt es „SSL and TLS do not provide the level of end-to-end security that users may expect.“, was aber nicht bedeutet, dass TLS und Verschlüsselung allgemein komplett nutzlos und sind, was scheinbar deine These ist.
Es ist wohl leider auch nicht sinnvoll zu verhindern (...)
Doch! man verschlüsselt nicht!
Unverschlüsselt kann jeder beliebige Dritte (und das sind viele!), der auf dem Weg zwischen dir und dem Server mit den Inhalten steht, alles mitlesen und nach Belieben verändern – und du machst ernsthaft dir Sorgen um eine theoretische Möglichkeit von vielen (die nichts mit HTTPS zu tun haben), dich zu tracken?!?
Ist ja auch für 95% der Webseiten gar nicht notwendig. Und der so begeistert zitierte Mann in der Mitte interessiert sich für diese Webseiten überhaupt nicht.
Woher willst du das so genau wissen? Nicht du bestimmst, was man aus den über dich gesammelten Daten an Informationen gemacht wird, sondern deine Feinde.
Die einzige Gegenmaßnahme ist hier, so wenig wie möglich preiszugeben (die Möglichkeit, über HSTS zu tracken, ist Pillepalle gegenüber den möglichen Angriffvektoren bei unverschlüsselter Kommunikation!).
man könnte höchstens die dafür benutzten Domains in die Filterlisten der Tracker-Blocker aufnehmen, wie es mit klassischen Tracking auch gemacht wird.
Es erzeugt also einen zusätzlichen Arbeitsaufwand.
Genauso wie das Aufsetzen eines Proxys, der mit heutigen Technologien klar kommt? – Wasch mich, aber mach mich nicht nass!?
Um dich über HSTS bzw. allgemein sinnvoll (im Sinne des Trackenden) über mehrere Seiten hinweg tracken zu können, müssen schon mehrere Websites mitmachen und diese Technologie zum Tracken verwenden. Das fällt garantiert auf und die landen dann auf Tracking-Listen, das Vorgehen dürfte kein anderes sein, als den neusten Tracker eines Werbenetzwerks zu bannen. (Ich war letztens überrascht, dass uBlock sogar die Tracking-Pixel im golem-RSS-Feed erkennt, sie also auf einer Liste stehen müssen.)
Das Problem dürfte sich allerdings durch HSTS Preload (Liste mit verschlüsselt erreichbaren Websites, die mit allen Browser ausgeliefert wird und daher auch überall gleich ist) und die zunehmende Verbreitung von HTTPS (HTTPS als Standard, vor HTTP wird gewarnt) irgendwann auflösen.
Also eine globale Liste, wo sich jeder registrieren muss, der im Internet mitmacht. Aktiv oder ungefragt passiv durch das Besuchen der registrierten Webseite.
Müssen tust du nichts. HSTS-Preload dient dem besseren Schutz deiner Nutzer. Es kostet dich nichts, du musst keine persönlichen Daten angeben und die registrierte Domain muss nur die technischen Anforderungen erfüllen und dann stehst du sofort auf der Liste.
Der Punkt ist aber nicht unbedingt, dass es diese Liste zwangsläufig geben muss. Sie ist nur ein Notbehelf, irgendwann wird die Zeit kommen, wo man vor HTTP warnen kann, weil 99% der Seiten verschlüsselt erreichbar sind.
Und der Schlüssel liegt an einer einzigen Stelle. Da freut sich die CIA.
Wieso sollte die CIA hier eingreifen und beispielsweise Domains von der Liste entfernen? Der HSTS-Header würde ja weiterhin gesendet und die Nutzer sind damit auch ohne HSTS-Preloading geschützt. Ergebnis: Nichts. – Mach dir mal lieber Gedanken, ob dein Browser, der – oh Schreck – von US-amerikanischen Firmen bzw. Instutionen entwickelt wird, nicht vielleicht doch kompromittiert ist.
Da existieren offensichtlich Datenschutz-Löcher, die in großem Umfang von den üblichen Verdächtigen – Werbeagenturen, Geheimdienste, AV-Hersteller – nachweislich genutzt werden.
Hast du einen Beleg für den Missbrauch von HSTS als Super Cookie in der Praxis?
Das habe ich auf TLS bezogen.
Aber wo geht es da um das Datenschutz-Problem von TLS? Es geht um gravierende Sicherheitsprobleme von Software, die unsauber mit TLS in einer Weise umgeht, die so nicht geplant war. Um davon betroffen zu sein, muss man aber diese Software einsetzen.
Nicht abzustreiten ist, dass TLS Probleme hat (noch zu geringe Verbreitung, intransparente Certificate-Authorities), aber hier ging es bisher um den Sinn von Verschlüsselung im Allgemeinen. Und da ist HTTPS trotz aller Probleme ein Fortschritt gegenüber unverschlüsseltem HTTP. Stück für Stück wird TLS verbessert und Probleme aus dem Weg geschafft. Um das Web oder Internet zu verbessern, bedarf es kleiner evolutionärer Schritte, Revolutionen funktionieren meist nicht.
Nein, ich tue nicht so. Ich werte bloß den konkreten Sicherheitsgewinn durch HTTPS höher als eine theoretische Möglichkeit, mich zu tracken.
Wenn es theoretische möglich ist, wird es auch passieren. Und daß Google dieses Tracking nicht unterbindet, spricht Bände.
Die Frage war, ob es relevant und machbar ist und die hat man sich bei Google wohl auch gestellt und verneint. Bei Mozilla war man anscheinend etwas vorsichtiger, was ich für keine schlechte Entscheidung halte.
Wird denn aktuell über HSTS getrackt? Bitte liefere einen Beweis, Murphy vorzuschieben, wenn man etwas nicht konkret belegen kann, ist schwach.
[…] Jeder wird beeinträchtigt.
Stell Dir das unverschlüsselte HTTP als einen Fluss vor, die Informationen sind das Wasser. […]
Das Beispiel hinkt gleich an mehren Stellen:
Eine bessere Veranschaulichung für die Wirkung von TLS wäre folgende:
Im Sinne von HTTP stellt man sich auf den Markt und feilscht dort öffentlich mit dem Händler. Falls man nicht möchte, dass andere, ggf. sogar Konkurrenten mitbekommen, was und zu welchen Konditionen man kauft, kann man den Händler auf dem Markt bitten, sich in einem abhörsicheren Raum (der Raum hat aber Prinzip-bedingt nur Platz für zwei Personen ⇒ zwei Kommunikationspartner bei TLS) zu treffen und dort die eigentlichen Geschäfte zu machen, zusätzlich kannst du sicherheitshalber die Papiere des Händlers inspizieren (Ausweis, Gewerbeschein ⇒ Zertifikat überprüfen).
Wenn du nun jemanden Drittes einbinden möchtest, zum Beispiel damit er die Verhandlungen führt, weil er das besser kann als du, kannst du ihn im Falle von HTTP einfach mit auf den Markt nehmen und ihr geht zusammen zum Händler. Bei HTTPS und dem geschlossenen Raum geht das nicht mehr so ohne Weiteres. Ihr löst das dann so, dass dieser Dritte mit dem Händler im Raum sitzt und dann ab und an zu dir in einen anderen abhörischeren Raum geht.
Das ist das Problem mit HTTPS und Co und anderen 'Schutz'mechanismen. Es sind Kontrollmechanismen die sich als Sicherheitsmechanismen tarnen.
Du irrst und kommst nicht aus deiner Filterblase heraus.
Kennst du die Electronic Frontier Foundation, die sich für Grundrechte im Digitalen Zeitalter einsetzt? Wie passt es in dein Bild von HTTPS, dass sie HTTPS für ihre Website einsetzen, ja sogar erzwingt – und noch viel arger – sogar auf der HSTS-Preload-Liste steht? Und es kommt noch besser: Sie entwickeln eine Browser-Erweiterung, die die Verbreitung HTTPS fördert.
Gruß
Julius
Hallo Julius,
Das ist ja alles sehr interessant gewesen, und mit der Verschlüsselung hatte ich wohl unrecht – Aber mein Proxy funktioniert nicht mehr!
Gruß, Nils
Hello Nils,
Das mit dem Sicherheitszertifikat würde mich sehr interessieren, geht das mit Privoxy oder Proxomitron? Oder nehme ich da besser einen anderen Proxy? kannst Du mal ein bischen konkreter werden?
Das geht auch schon mit einer Erweiterung für den SQUID.
Allerdings bekommt auch hier der aufmerksame Client eine Warnung, dass das Zertifikat und die damit ausgehandelte Verschlüsselung nicht stimmen kann.
Liebe Grüße
Tom S.
es gibt fast nur noch Webseiten, die nicht ohne Scripte funktionieren. Es nervt!
... und welche die überhaupt nicht mehr funktionieren. Das nervt jedoch nicht!
Camping_RIDER
Henry
Matthias Apsel
Tabellenkalk