Esta es una idea que da seguimiento a este breve intercambio sobre la desactivación de las incrustaciones de YouTube/Instagram/etc. de onebox: Disabling youtube and other embeds
Creo que tiene sentido exponer una preferencia de usuario para desactivar onebox y mostrar el enlace original en su lugar. Las incrustaciones de onebox ofrecen mucho valor para el caso general, pero los usuarios individuales pueden querer evitarlo. Las opciones actuales son desactivar onebox para todo el foro (según el enlace anterior) o que los usuarios individuales utilicen una extensión del navegador como uBlock Origin para bloquear dominios o iframes específicos por completo. El enfoque de la extensión es funcional pero no práctico. Deja grandes trozos de espacio vacío donde normalmente iría el iframe, no da ninguna indicación de lo que se supone que está allí, y si el usuario quiere ver el contenido, tiene que intentar encontrar la URL buscando en el código fuente.
Mi sugerencia es permitir a los usuarios optar por no ver (o quizás optar por ver) las incrustaciones de onebox, y en su lugar, que la publicación incluya el enlace original. Esto mantendría una apariencia consistente, indicaría mejor el contenido del enlace y eliminaría la necesidad de buscar en el código fuente para encontrar el enlace.
(Estoy publicando esto como un recién llegado al foro meta y sin mirar el código, así que no sé si es práctico, pero pensé que valdría la pena discutirlo. ¡Gracias!)
Gracias por la respuesta. Las preocupaciones son la privacidad y la seguridad, así como las cosas que los usuarios tienen implementadas para abordar esas preocupaciones.
Como menciona @hellcx9rv4, los iframes pueden ser un agujero de seguridad y, como se menciona en artículo en la publicación enlazada, los tipos de sitios que frecuentemente sirven incrustaciones (Google, Meta, etc.) deben considerarse poco confiables, y cada vez más lo son.
Es tranquilizador saber que los desarrolladores están pensando en esto, pero los usuarios preocupados seguirán siendo escépticos con los iframes en los sitios de Discourse, al igual que en otros sitios, y utilizarán los mismos mecanismos para abordar sus preocupaciones.
Por ejemplo, uBlock Origin tiene 6.4 millones de usuarios de Firefox y 10 millones de usuarios de Chrome según sus respectivos sitios web de complementos/extensiones. Si bien el bloqueo de iframes no está habilitado de forma predeterminada y dudo que sea posible saber cuántos usuarios lo tienen habilitado, estos números de uso indican que a un número significativo de usuarios web les preocupa este problema. Si la intersección de usuarios de Discourse y usuarios de uBO que bloquean iframes (o dominios de proveedores de iframes) es el 0.1% de esos números, todavía son 16,000 usuarios de Discourse afectados.
Sin embargo, por su propia admisión, ¿es probable que dichos usuarios paranoicos ya empleen alguna forma de solución de bloqueo en su máquina local? ¿Dichos 16.000 usuarios ya tienen una solución que funciona para todos los sitios web, en lugar de específicamente para discourse?
La solución aborda el iframe impidiendo que se activen sus solicitudes (al menos en el caso de uBO). Cuando el iframe está bloqueado, no hay contenido o hay un bloque de espacio vacío, lo que significa que falta una parte del contenido de la conversación. El problema es que el iframe está ahí porque Discourse ha reemplazado el enlace del publicador por él, y lo que sugiero es un mecanismo para dejar ese contenido “tal cual” para los usuarios interesados. (Algo como texto alternativo también sería útil, pero no creo que exista para los iframes).
Quizás, pero ese no es el problema. Mucha gente ha descubierto que los bloqueadores de contenido son su punto óptimo de relación valor-esfuerzo.
El texto de respaldo podría ser en realidad un enfoque más apropiado, ya que no requiere la preferencia del usuario (y sería transparente en los casos en que el iframe no se cargue por otras razones, por ejemplo, si el dominio de origen está bloqueado por la red). Si se puede encontrar una buena implementación, también podría ser más fácil de mantener. Una idea para una implementación: mostrar la URL original en el texto de la publicación, instanciar el iframe de onebox separado del DOM, reemplazar la URL con el iframe una vez que esté claro que el iframe se va a cargar.
Entonces, para mí, esta es una configuración para el administrador del sitio, aunque estoy de acuerdo en que sería bueno tener mejores opciones de recuperación para las cargas fallidas de iframe.
