1. Liebe Forumsgemeinde,

    aufgrund der Bestimmungen, die sich aus der DSGVO ergeben, müssten umfangreiche Anpassungen am Forum vorgenommen werden, die sich für uns nicht wirtschaftlich abbilden lassen. Daher haben wir uns entschlossen, das Forum in seiner aktuellen Form zu archivieren und online bereit zu stellen, jedoch keine Neuanmeldungen oder neuen Kommentare mehr zuzulassen. So ist sichergestellt, dass das gesammelte Wissen nicht verloren geht, und wir die Seite dennoch DSGVO-konform zur Verfügung stellen können.
    Dies wird in den nächsten Tagen umgesetzt.

    Ich danke allen, die sich in den letzten Jahren für Hilfesuchende und auch für das Forum selbst engagiert haben. Ich bin weiterhin für euch erreichbar unter tti(bei)pcwelt.de.
    Dismiss Notice

Microsoft, Mozilla & Co.: Der Browser-Krieg ist beendet

Discussion in 'Ihre Meinung zu Artikeln auf pcwelt.de' started by Joa, Apr 19, 2007.

Thread Status:
Not open for further replies.
  1. Joa

    Joa Kbyte

    Lieber Himmel, warum soll denn ein Browser mit Gewalt zur eierlegenden Wollmilchsau gemacht werden?
    Ein großer Teil der Anwender will mit dem Browser sicher surfen und sonst nichts. Dafür soll der Browser aber schnell starten, stabil laufen und irgendwelchen bedenklichen Schnickschnack gerade nicht unterstützen.

    Sollen doch die „immer leistungsfähigeren Web-Applikationen“ das bißchen klassische Browserfunktion, das sie benützen, selbst mitbringen, oder die Betriebssysteme dafür eine eigene Anwendungsschnittstelle bekommen. Dann kann jeder selbst entscheiden, was er nutzen will – und erlebt nicht die böse Überraschung, daß die neuen Möglichkeiten bloß für besonders lästige Werbeeinblendungen mißbraucht werden.
     
  2. kalweit

    kalweit Hüter der Glaskugel

    Das will niemand. Aber ein Browser eignet sich wunderbar, um Anwendungen vom Desktop ins Netz zu verlegen. Der Browser wird damit zu einer Laufzeitumgebung. Nur ist diese viel flexibler als es .net oder java je sein könnten, da die eigentliche Arbeit auf einem optimierten System unabhängig von den Möglichkeiten des einzelnen Clients erledigt wird - d.h. eine Anwendung läuft automatisch auf allen Systemen, für die es einen passenden Browser gibt.
     
  3. NoBurt

    NoBurt Byte

    Was für ein toller Beschluß.

    Mir würde es reichen, wenn alle Browser wenigstens kompatibel wären und man nicht ständig Hacks und unterschiedliche Styles beachten muss. Da fängt für mich die Gemeinsamkeit an, nicht in der Unterstützung von Webapplikationen ...

    Als Webprogrammierer wird man heutzutage mit einfach zu vielen unterschiedlichen Standards bombardiert. Das frustet schon sehr, wenn man Stunden benötigt, um die Webseiten in allen Browsern halbwegs gleich aussehen zu lassen. Die Zeit wäre für andere Dinge besser geeignet ...
     
  4. kalweit

    kalweit Hüter der Glaskugel

    ...was in der Konsequenz aber auf das Gleiche hinaus läuft.
     
  5. Die abgeklärte scheinbare Übereinstimmung der Browserhersteller täuscht darüber hinweg, daß es tatsächlich viel zu tun gibt.
    CSS 3 muss implementiert werden, die XML-Unterstützung kann ausgeweitet werden, Scripting kann sicherer gemacht werden und die Umsetzung einfachster Standards (CSS 2) ist zumindest bei MS immer noch nicht vollständig. Darüber hinaus ist eine syntaktische Angleichung von JS und MS-JS anzustreben, die seit langem aus lizenzrechtlichen Gründen seitens NS verhindert wird.

    Darüber hinaus fehlt generell eine Möglichkeit - hier sind die Standardprägenden Organisationen wie der W3C gemeint - clientseitige Verschlüsselung ohne Einsatz von JS oder Zertifikaten zu ermöglichen. Bei Einsatz von JS ist clientseitsig ggf. nicht die Möglichkeit gegeben (z.B. Screenreader interpretieren kaum JS), mit Einsatz von Zertifikaten ist noch lange nicht gewährleistet, daß die Daten serverseitig verschlüsselt gespeichert werden und daß sie dort ggf. von Personen ausgelesen werden können.

    Sicher, Crossbrowser-Programmierung ist auf allen Ebenen einfacher geworden. Aber für eine solch abgeklärte Meldung ohne selbstkritische Analyse am Produkt ist es wirklich etwas früh.
     
  6. kalweit

    kalweit Hüter der Glaskugel

    Das ist wohl kaum die Baustelle eines Browsers ;) - zudem müssen die Daten serverseitig erst mal entschlüsselt werden, sonst kann man sie ja nicht verarbeiten.
     
  7. Sorry, ich meinte die Passwörter.
    Und diese brauchen nicht entschlüsselt werden, weil einfach die Schlüssel miteinander verglichen werden können, ohne daß die Passwörter unverschlüsselt übertragen werden müssen.
    Wer sich mit Passwörtern beschäftigt hat, weiss daß man entweder die Passwörter barrierefrei unverschlüsselt oder mit JS verschlüsselt übertragen kann.
    Eine Verschlüsselungsmethode ist nicht möglich, ausser man arbeitet mit SSL, aber dann können alle Daten serverseitig entschlüsselt werden, somit auch die Passwörter.
    Deswegen halte ich ein Formularelement für sinnvoll, das Passwörter ohne Einsatz von JS verschlüsselt überträgt. Und das ist in erster Linie Baustelle des W3C und sekundär der Browserhersteller.
     
  8. kalweit

    kalweit Hüter der Glaskugel

    Aha. Warum dann noch den Argumentationsschanz hinten dran? Egal:

    Was in jedem Fall Mittel der Wahl sein sollte und existiert.

    Wobei das kein wirkliches Problem ist, wenn das Passwort nur zur Nutzung der Applikation selbst dient. Die Sicherheitsrisiken ergeben sich ausschließlich aus der Bequemlichkeit der Nutzer.

    ...ob ich das Passwort im Klartext oder den Hash selbst durch's Netz jage ist doch Wurst. Wenn ich auf Serverseite eine Einwegverschlüsselung verwenden will, gibt es keine Alternative und der Hash wird selbst zum Passwort -> auch wieder im Klartext - vielleicht ein Grund, warum es dein Element nicht gibt ;)
     
  9. Nicht ganz, Problem der unverschlüsselten Passwörter ist, daß Backendbenutzer (Administratoren, Redakteure, Moderatoren, je nach CMS bzw. Seite) die Passwörter verwenden könnten, um sich mit der Kombination aus Username und Passwort woanders als der eigenen Seite einloggen könnten. Sicherlich kann ein User das unterbinden, indem er bei jeder Seite ein anderes Passwort verwendet, aber das machen mit Sicherheit die wenigsten, da man sich sonst sehr viele Kombinationen aus Passwörtern und Usernamen merken müßte.
    Übrigens gibt es bereits viele Personen, die serverseitige Verschlüsselung fordern. Da Administratoren theoretisch momentan eingehende Daten unverschlüsselt auslesen können, auch wenn die Daten verschlüsselt in der Datenbank gespeichert werden, ist idealerweise eine verschlüsselte Übertragung empfehlenswert - auch wenn der Anwender kein JS verwendet.

    Es mag bei den Detailfragen sicher Probleme geben, nämlich daß ein Admin evtl. auch den Hash verwenden kann um sich anzumelden. Dies klappt aber vorraussichtlich nur bei der eigenen Seite oder bei fremden Seiten, die nicht ausreichend gesichert sind. Aber Detailfragen können sicherlich gelöst werden, wenn wenn erst einmal die grundsätzliche Notwendigkeit anerkannt wird.
     
  10. kalweit

    kalweit Hüter der Glaskugel

    ...steht bereits oben.

    ...ja schön, dass sie das fordern. Das ist die selbe Preisklasse wie der Bundestrojaner. Was du als "Deteilfragen" bezeichnest, ist schlicht ein Grundsatzproblem, welches mit den Rahmenbedingungen NICHT LÖSBAR ist.

    Quatsch. Auch aus einem Hash lässt sich ein gültiges Passwort ermitteln (dafür gibt es sogar fertige Tabellen) - es ist zwar nicht unbedingt das, welches der User ursprünglich verwendet hat. Aber das ist unwichtig, da in Webapplikationen im Grunde nur ein Verschlüsselungsverfahren zur Anwendung kommt.
     
  11. Ich habe nicht damit gerechnet, daß PC-Welt die richtige Plattform ist, um dieses Thema auf den Weg zu bringen.
    Wenn jemandem das Verständnis zu gewissen Problemen fehlt, hängt das möglicherweise nicht nur mit dem Thema selbst, sondern auch damit, daß das Thema für ihn momentan nicht akut ist.

    Unter diesem Aspekt kann ich durchaus verstehen, wenn jemand etwas als Quatsch abtut.
    Ich persönlich sehe das Problem durchaus als akut an und sehe auch Möglichkeiten flexible Verschlüsselungslogarithmen in Standardelemente einzubinden, die nicht über Tabellen ausgelesen werden können -sofern man den Logarithmus nicht kennt.

    Sicherlich sind viele Zweifel an meinem Vorschlag die erwähnt wurden berechtigt, aber das ändert meiner Ansicht nach nicht an der generellen Notwendigkeit eines solchen Elements. Unsicherheiten und Detailfragen werden - sofern ein solch wichtiges Element auf den Weg gebracht werden soll - möglicherweise von großen Organisationen und Firmen entworfen, entwickelt und getestet, deswegen mache ich mir über die erwähnten Zweifel zwar nicht weniger Gedanken, halte sie jedoch durchgehend für lösbar.

    Prinzipiell ist der erste Widersstand wahrscheinlich gar nicht schlecht - eine erste Vorbereitung was mir bevorsteht, wenn ich den Vorschlag bei den entscheidenden Stellen einreiche. Unter diesem Aspekt ist sicher auch wichtig, daß ich meine Argumentation weitgehend wasserdicht gestalte.

    Serverseitige Verschlüsselung der Passwörter ist übrigens bei sehr viel Foren (wahrscheinlich auch bei PC-Welt) bereits Standard - führt allerdings im Hinblick auf Barrierefreiheit zu Problemen durch Ausgrenzung von Personen, die kein JS verwenden wollen oder können.
     
  12. kalweit

    kalweit Hüter der Glaskugel

    Ja nee, ist klar. Ich geb's auf. Wie kommst du eigentlich darauf, dass du der Erste mit der Idee bist? Aber egal: viel Glück.
     
  13. Falls Du Quellen hast zu Vorschlägen die das gleiche Ziel verfolgen, wäre ich Dir dafür sehr dankbar. :)
     
Thread Status:
Not open for further replies.

Share This Page