Dies ist eine Idee, die auf diesem kurzen Austausch über die Deaktivierung von YouTube/Instagram/etc.-Einbettungen folgt: Disabling youtube and other embeds
Ich denke, es ist sinnvoll, eine Benutzereinstellung anzubieten, um Onebox zu deaktivieren und stattdessen den ursprünglichen Link anzuzeigen. Die Onebox-Einbettungen bieten einen großen Mehrwert für den allgemeinen Fall, aber einzelne Benutzer möchten dies möglicherweise vermeiden. Die aktuellen Optionen sind entweder, Onebox für das gesamte Forum zu deaktivieren (siehe obiger Link) oder einzelne Benutzer verwenden eine Browsererweiterung wie uBlock Origin, um bestimmte Domains oder iframes komplett zu blockieren. Der Ansatz mit der Erweiterung ist funktional, aber nicht praktikabel. Er hinterlässt große leere Bereiche, wo der iframe normalerweise wäre, gibt keinen Hinweis darauf, was dort sein soll, und wenn der Benutzer den Inhalt sehen möchte, muss er versuchen, die URL durch Durchsuchen des Quellcodes zu finden.
Mein Vorschlag ist, Benutzern die Möglichkeit zu geben, sich von den Onebox-Einbettungen abzumelden (oder vielleicht anzumelden) und stattdessen den ursprünglichen Link im Beitrag anzuzeigen. Dies würde ein konsistentes Erscheinungsbild beibehalten, den Inhalt des Links besser anzeigen und die Notwendigkeit umgehen, den Quelltext der Seite zu durchsuchen, um den Link zu finden.
(Ich poste dies als Neuling im Meta-Forum und ohne den Code angeschaut zu haben, daher weiß ich nicht, ob dies praktikabel ist, aber ich dachte, es wäre eine Diskussion wert – danke!)
Der Inhalt der Onebox wird auf dem Server zwischengespeichert, einschließlich Bildern, sodass dies die IP-Adresse des Benutzers nicht implizit preisgibt.
Vielen Dank für die Antwort. Die Bedenken betreffen den Datenschutz und die Sicherheit sowie die Maßnahmen, die Benutzer ergreifen, um diese Bedenken auszuräumen.
Wie @hellcx9rv4 erwähnt, können iframes ein Sicherheitsloch sein, und wie in dem Artikel im verlinkten Beitrag erwähnt, sollten die Arten von Websites, die häufig Einbettungen bereitstellen (Google, Meta usw.), als nicht vertrauenswürdig eingestuft werden und werden es zunehmend auch.
Es ist beruhigend zu wissen, dass die Entwickler darüber nachdenken, aber besorgte Benutzer werden iframes auf Discourse-Websites genauso misstrauisch betrachten wie auf anderen Websites, und sie werden dieselben Mechanismen verwenden, um ihre Bedenken auszuräumen.
Zum Beispiel hat uBlock Origin laut den jeweiligen Add-on-/Erweiterungs-Websites 6,4 Millionen Firefox-Benutzer und 10 Millionen Chrome-Benutzer. Während die iframe-Blockierung nicht standardmäßig aktiviert ist und ich bezweifle, dass man wissen kann, wie viele Benutzer sie aktiviert haben, zeigen diese Nutzungszahlen, dass einer erheblichen Anzahl von Webbenutzern dieses Thema am Herzen liegt. Wenn der Schnittpunkt von Discourse-Benutzern und uBO-Benutzern, die iframes (oder iframe-Anbieter-Domains) blockieren, 0,1 % dieser Zahlen beträgt, sind das immer noch 16.000 betroffene Discourse-Benutzer.
Aber nach Ihrer eigenen Aussage setzen diese paranoiden Benutzer wahrscheinlich bereits eine Form von Blockierlösung auf ihrem lokalen Rechner ein? Haben diese 16.000 Benutzer bereits eine Lösung, die für alle Websites funktioniert, anstatt speziell für Discourse?
Die Lösung adressiert das Iframe, indem sie verhindert, dass dessen Anfragen ausgelöst werden (zumindest im Fall von uBO). Wenn das Iframe blockiert wird, gibt es entweder keinen Inhalt oder einen leeren Bereich, was bedeutet, dass ein Teil des Gesprächsinhalts fehlt. Das Problem ist, dass das Iframe vorhanden ist, weil Discourse den Link des Posters damit ersetzt hat, und was ich vorschlage, ist ein Mechanismus, um diesen Inhalt für interessierte Benutzer “so wie er ist” zu belassen. (Etwas wie Alternativtext wäre auch nützlich, aber ich glaube nicht, dass es für Iframes existiert.)
Vielleicht, aber das ist nicht das Problem. Viele Leute haben festgestellt, dass Content-Blocker ihr optimaler Punkt für Aufwand und Nutzen sind.
Fallback-Text wäre möglicherweise ein besser geeigneter Ansatz, da er keine Benutzereinstellung erfordert (und transparent wäre, wenn das iFrame aus anderen Gründen nicht geladen werden kann, z. B. wenn die Quell-Domain vom Netzwerk blockiert wird). Wenn eine gute Implementierung gefunden werden kann, könnte sie auch einfacher zu warten sein. Eine Idee für eine Implementierung: Zeigen Sie die ursprüngliche URL im Beitragstext an, instanziieren Sie das Onebox-iFrame vom DOM getrennt, ersetzen Sie die URL durch das iFrame, sobald klar ist, dass das iFrame geladen wird.
Dann ist dies für mich eine Einstellung für den Website-Administrator, stimme aber zu, dass es schön wäre, bessere Fallbacks für fehlgeschlagene iframe-Ladevorgänge zu haben.
