Voici une idée qui fait suite à cet bref échange concernant la désactivation des intégrations onebox YouTube / Instagram / etc. : Disabling youtube and other embeds
Je pense qu’il serait judicieux d’offrir une préférence utilisateur pour désactiver onebox et afficher le lien original à la place. Les intégrations onebox apportent beaucoup de valeur dans le cas général, mais les utilisateurs individuels peuvent vouloir l’éviter. Les options actuelles consistent soit à désactiver onebox pour l’ensemble du forum (voir le lien ci-dessus), soit pour les utilisateurs individuels à utiliser une extension de navigateur comme uBlock Origin pour bloquer des domaines spécifiques ou des iframes complètement. L’approche par extension est fonctionnelle mais pas pratique. Elle laisse de grands blocs d’espace vide là où l’iframe irait normalement, n’indique rien sur ce qui est censé s’y trouver, et si l’utilisateur veut voir le contenu, il doit essayer de trouver l’URL en fouillant dans le code source.
Ma suggestion est de permettre aux utilisateurs de refuser (ou peut-être d’accepter) de voir les intégrations onebox, et d’inclure plutôt le lien original dans le message. Cela conserverait une apparence cohérente, indiquerait mieux le contenu du lien et éliminerait le besoin de fouiller dans le code source de la page pour trouver le lien.
(Je publie ceci en tant que nouveau venu sur le forum meta et sans avoir regardé le code, donc je ne sais pas si c’est pratique, mais j’ai pensé que cela valait la peine d’en discuter – merci !)
Le contenu de la onebox est mis en cache sur le serveur, y compris les images, donc non, cela n’expose pas implicitement l’adresse IP de l’utilisateur.
Merci pour votre réponse. Les préoccupations concernent la confidentialité et la sécurité, ainsi que les mesures que les utilisateurs mettent en place pour répondre à ces préoccupations.
Comme le mentionne @hellcx9rv4, les iframes peuvent être une faille de sécurité, et comme mentionné dans l’article dans le post lié, les types de sites qui servent fréquemment des intégrations (Google, Meta, etc.) devraient être considérés comme peu fiables, et le sont de plus en plus.
Il est rassurant de savoir que les développeurs y réfléchissent, mais les utilisateurs préoccupés se méfieront toujours des iframes sur les sites Discourse tout comme ils le font sur d’autres sites, et ils utiliseront les mêmes mécanismes pour répondre à leurs préoccupations.
Par exemple, uBlock Origin compte 6,4 millions d’utilisateurs Firefox et 10 millions d’utilisateurs Chrome selon leurs sites web respectifs d’extensions. Bien que le blocage des iframes ne soit pas activé par défaut et que je doute qu’il soit possible de savoir combien d’utilisateurs l’ont activé, ces chiffres d’utilisation indiquent qu’un nombre important d’utilisateurs du web se soucient de cette question. Si l’intersection des utilisateurs de Discourse et des utilisateurs de uBO bloquant les iframes (ou les domaines des fournisseurs d’iframes) représente 0,1 % de ces chiffres, cela représente toujours 16 000 utilisateurs de Discourse affectés.
Cependant, d’après vos propres aveux, les utilisateurs paranoïaques emploient probablement déjà une forme de solution de blocage sur leur machine locale ? Ces 16 000 utilisateurs disposent déjà d’une solution qui fonctionne pour tous les sites web, au lieu de spécifiquement pour Discourse ?
La solution aborde l’iframe en empêchant le déclenchement de ses requêtes (dans le cas de uBO au moins). Lorsque l’iframe est bloqué, il n’y a soit aucun contenu, soit un bloc d’espace vide, ce qui signifie qu’une partie du contenu de la conversation est manquante. Le problème est que l’iframe est là parce que discourse a remplacé le lien de l’afficheur par celui-ci, et ce que je suggère est un mécanisme pour laisser ce contenu “tel quel” pour les utilisateurs intéressés. (Quelque chose comme du texte alternatif serait également utile, mais je ne pense pas que cela existe pour les iframes.)
Peut-être, mais ce n’est pas le problème. De nombreuses personnes ont constaté que les bloqueurs de contenu représentent leur point idéal entre valeur et effort.
Le texte de remplacement pourrait en fait être une approche plus appropriée car il ne nécessite pas la préférence de l’utilisateur (et serait transparent dans les cas où l’iframe ne parvient pas à se charger pour d’autres raisons, par exemple si le domaine src est bloqué par le réseau.). Si une bonne implémentation peut être trouvée, elle pourrait également être plus facile à maintenir. Une idée pour une implémentation : afficher l’URL d’origine dans le texte du message, instancier l’iframe onebox détachée du DOM, remplacer l’URL par l’iframe une fois qu’il est clair que l’iframe va se charger.
Alors, pour moi, c’est un paramètre pour l’administrateur du site, bien que je sois d’accord qu’il serait bon d’avoir de meilleures solutions de repli pour les chargements d’iframe qui échouent.
