hallo
Naja, davon gehe ich nicht per se aus. Aber es sind nunmal zwei Fälle, von denen einer gravierender ist als der andere, und der gravierendere liegt nicht vor. Mein gesamtes Posting plädiert dafür, dass es eben keine vollständige Sicherheit gibt, sondern dass immer ein Restrisiko bleibt, das einzuschränken, aber nicht notwendigerweise auszumerzen ist.
Vollständig Sicherheit ist eine Illusion, das ist klar. Wir reden hier in den meisten Fällen von http/https Kontext. Dass Server oder Browser an sich kompromitiert sein können sollten wir im Hinterkopf behalten.
http genügt.
Ich will dir nicht per se widersprechen, weil ich nicht davon ausgehe, die Weisheit mit Löffeln gefressen zu haben - aber das musst du mir näher erläutern. HTTPS ist im Prinzip ja nur eine verschlüsselte HTTP-Verbindung. Die einzige Art und Weise, wie man da jetzt an Schadcode kommen könnte, (die mir einfällt), wäre ein Man-in-the-Middle-Angriff.
Über man-in-the-middle müssen wir glaube ich heute nicht mehr diskutieren. Die Frage ist lediglich, in welchem Kontext diese auch wahrscheinlich und aussichtsreich ist.
Im Fall von remso.de ist nicht nur die Datenauslieferung, sondern auch die Datenerstellung an sich für solche Angriffe offen.
Nur, dass HTTPS da auch nicht immer schützt.
https muss man natürlich abhärten. Das kann man mit entsprechenden Headern erreichen insofern diese die Header verstehen.
Nein. Du hast das originale Posting offensichtlich nicht ansatzweise gut genug gelesen! Ich zitiere daraus:
Da die Mutterseite eine .js Datei von mir lädt, lässt sich vielleicht was machen?
ist dir aufgefallen, dass dieses Datei nicht im geringsten relevant ist fr Abfragen, die innerhalb des iframes getätigt werden (das heisst, Abfragen funktionieren bei blockiertem Javascript).
Die Einbindung von JavaScript in die Seite bestand also sowieso schon, das war nichts, was von uns ins Spiel gebracht wurde.
Nein, sie besteht nur aus kosmetischen Gründen, um einen nicht essentiellen Fix durchzuführen.
Genausowenig soll die iframe-Lösung abgelöst werden (als Fallback soll sie nach unserer Meinung vorhanden bleiben), sondern sie soll für die, die kein JS aktivieren wollen, vorhanden bleiben. Es macht also niemand bestehende Funktionalität kaputt.
Der wunsch wurde schon mal geäussert: https://forum.selfhtml.org/self/2017/mar/5/im-iframe-blaettern/1689017#m1689017
Schon mal von PGP (Pretty Good Privacy) gehört? ... Nein. Das ist ein Beispiel für Vertrauen. PGP basiert auf der Idee des Web of Trust. Dabei geht es im wesentlichen darum, dass Vertrauen in Zertifikate bekannter (und selbst vertrauter) Kommunikationsteilnehmern an unbekannte Kommunikationsteilnehmer vererbt wird, und das ist ziemlich genau das, was hier auch passiert.
Die Grundlage von PGP ist Misstrauen. Es existiert weil die Vertrauenswürdigkeit bezüglich Sender und Empfänger so essentiell ist.
…
Ich sehe mich bereits dabei, einen font zu clonen, die Interna zu prüfen und ihn dann selber zu hosten.
…das ist eine Schlussfolgerung, die im Internet und insgesamt in der IT heutzutage nicht mehr funktioniert.
warum nicht?
Damit bleibt man vielleicht (an dieser Front!) unangreifbar,
also funktioniert es an dieser Front.
kann sich dann aber doch irgendwann im Garten vergraben, weil man so nicht in der Lage ist, mit Bedürfnissen und Möglichkeiten, sowohl von Kunden (allgemeiner: Benutzern) als auch von Konkurrenten, mitzuhalten.
Kannst du bitte genauer ausführen, wo sich jemand, der selber Ressourcen hostet, Nachteile aufbürdet, oder Usern Nachteile bietet?
…
Und damit können wir die Frage angehen: Unter welchen Umständen wäre ich bereit, remso in meine Website einzubinden? Denn wenn ich jemandem
…
Das security-plus hier möchte ich gar nicht abstreiten…
Aber eventuell würde ich auch einen server-server Datenaustausch vorziehen, indem mein Server selber eine API auf remso.de benutzt, und das Resultat selber cacht. Für den Client wäre ich da selber verantwortlich, und könnte somit selbstverantwortlich bezüglich der Datenintegrität vorgehen.
…ebensowenig hier.
Aber mit beidem gibst du jeweils auch Dinge auf, vorrangig: Komfort, auch in der User Experience (sogar gar nicht so wenig), und das dürfte den meisten Webentwicklern dieses security-plus begründeterweise nicht wert sein.
Bitte nochmals ausführen: Wenn ich also Usern nur Inhalte biete, für die ich auch rechtlich und inhaltlich einstehe, gebe ich also eine schlechtere user-experience… Wenn ich (server-server Variante) also Inhalt so ausgebe, dass er als von mir selber gehostet erscheint, gebe ich eine schlechtere User-experience…
Kannst du das bitte genauer erklären?