Aloha ;)
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).
Klar.
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.
Richtig. Und um einen solchen nicht essentiellen Fix ging es auch im weiteren Verlauf.
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
Nur weil sich das Feature ändert heißt das nicht, dass der Fallback wegfällt.
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.
Nur, wenn du es unbedingt so drehen möchtest. Dann ist aber auch die Grundlage für https Misstrauen. Und für Verschlüsselung allgemein und und... es ging hier aber nicht darum, was die Grundlage für Verschlüsselung ist, sondern es ging darum, was die Grundlage der Arbeitsweise von PGP ist, und die ist nunmal Vertrauen.
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?
Aufgrund allerlei Gründen. Rechtliche Beschränkungen, Ressourcenfrage (Manpower / Kosten) usw. usf. Aktuelle Systeme sind heutzutage oft derart komplex, dass man nicht mehr umhinkommt, eben nicht mehr alles selbst zu machen.
Das ist auch der Grund für…
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?
…diese Aussage. Es geht nicht darum, dass man Nachteile hätte, wenn man Ressourcen selber hostet. Wenn man fixe Ressourcen hat, die man entweder einbinden oder selbst hosten kann, bin ich (bis auf eventuelle Argumente bzgl. Caching, die aber nicht entscheidungsrelevant sind) vollkommen bei dir, wenns darum geht, das selber zu hosten.
Es geht darum, dass man komplexere Dienste oder aufwändige Ressourcen, die man entweder einbinden kann oder selber erstellen oder unterhalten muss, heutzutage aufgrund der Fülle an Dingen, die man für ein optimales Nutzererlebnis benötigt, eben nicht mehr alles selber erstellen oder unterhalten kann.
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?
Potenziell ja. Du kannst eine Dienstleistung, wie remso sie dir bietet, nicht ohne großen Aufwand selbst machen und anbieten - nur als Beispiel. Also bist du für eine optimale User Experience darauf angewiesen, das einzubinden. Hier musst du dann den Weg nehmen, der sicherheitstechnisch akzeptabel ist und von remso auch angeboten wird.
Wir argumentieren hier auf zwei Ebenen. Du hast Recht - optimalerweise gibt es eine API für den serverseitigen Zugriff auf die blanke Information. Wenns die aber nicht gibt (oder ich nicht das Know-How habe, sie zu benutzen und auch nicht die Bereitschaft, jemanden zur Einrichtung zu bezahlen), muss ich mich mit etwas anderem zufrieden geben.
Und sofern ich remso vertraue wähle ich dann eben die js-Lösung mit iframe-Fallback, die dort angeboten wird.
remso wiederum möchte einen Service bieten, der möglichst gut aussieht, und verwendet dafür dann eben für die js-Nutzer keinen iframe, weil sich der nicht schick in die Seite integriert.
Nochmal: Du darfst das gerne anders sehen und anders halten, aber ich erwarte diese Toleranz auch gegenüber den genannten Standpunkten von remso, seinem „Kunden“, und uns, die remso bei einer technischen Fragestellung beraten.
Es wäre übrigens sehr sinnvoll gewesen, wenn du einfach deine Kritik inhaltlich vollständig auf den Punkt gebracht und irgendwo angebracht hättest - denn ganz offensichtlich hast du ja doch etwas sinnvolles beizutragen. Darüber war ich mir lange nicht im Klaren beim Lesen deiner Beiträge. Es bringt nichts, wenn du immer wieder nur kryptische Zweizeiler raushaust, in denen niemand was versteht außer blinden Rant! Es ist auch nicht wirklich sinnvoll, sich das aus der Nase ziehen zu lassen 😉 aber ich finde deine wortreicheren Beiträge jetzt gut und würde die in Zukunft lieber gleich lesen als nach mehrmaligem Nachfragen.
Auf dass wir uns hier konstruktiv auseinandersetzen können 😉
Grüße,
RIDER