这是继关于禁用 onebox YouTube/Instagram 等嵌入式链接的简短交流后产生的一个想法：Disabling youtube and other embeds
我认为为用户提供一个偏好设置来禁用 onebox 并显示原始链接是合理的。Onebox 嵌入式链接在一般情况下很有价值，但个别用户可能希望避免使用它。目前的选项要么是为整个论坛禁用 onebox（如上链接），要么是让个别用户使用像 uBlock Origin 这样的浏览器扩展来阻止特定域名或 iframe。扩展方法虽然有效但并不实用。它会在 iframe 通常出现的地方留下大片空白，没有指示表明那里本应有什么内容，而且如果用户想看到内容，他们必须通过查看源代码来寻找 URL。
我的建议是允许用户选择退出（或也许选择加入）查看 onebox 嵌入式链接，而是在帖子中包含原始链接。这将保持一致的外观，更好地指示链接的内容，并消除查找链接时需要查看页面源代码的麻烦。
（我以新用户的身份在元论坛上发帖，并且没有查看代码，所以我不知道这是否可行，但我认为值得讨论——谢谢！）
你能提供一些用户觉得这很可取或有必要的用例吗？
这是你需要说服人们提出有意义的功能请求的部分。
我可以，请阅读并测试iplogger。
攻击者可以使用此URL通过私信获取用户的IP地址，或者获取用于DDoS攻击的原始IP地址。Discourse没有允许信任域的设置。
https://meta.discourse.org/t/discourse-v3-0-is-here-join-our-live-webinar-january-24th-10am-pst/251997/11?u=hellcx9rv4
onebox 的内容会在服务器端缓存，包括图片，因此这并不会隐式暴露用户的 IP 地址。
感谢您的回复。这些担忧涉及隐私和安全，以及用户为解决这些担忧而采取的措施。
正如 @hellcx9rv4 所提到的，iframe 可能是一个安全漏洞，并且正如在链接帖子中的文章中所提到的，经常提供嵌入式内容的网站类型（Google、Meta 等）应被视为不可信，并且这种情况日益严重。
很高兴知道开发人员正在考虑这一点，但有顾虑的用户仍然会像对待其他网站一样怀疑 discourse 网站上的 iframe，并且他们将使用相同的机制来解决他们的担忧。
例如，根据其各自的附加组件/扩展网站，uBlock Origin 在 Firefox 上有 640 万用户，在 Chrome 上有 1000 万用户。虽然 iframe 阻止并非开箱即用，而且我怀疑有多少用户启用了它，但这些使用数字表明相当一部分网络用户关心这个问题。如果 discourse 用户和阻止 iframe（或 iframe 提供商域）的 uBO 用户之间的交叉部分占这些数字的 0.1%，那么仍有 16,000 名 discourse 用户受到影响。
然而，据你自己承认，那些多疑的用户很可能已经在他们的本地机器上采用了某种形式的阻止解决方案？这 16,000 名用户已经有了一个适用于所有网站的解决方案，而不是专门针对 discourse？
该解决方案通过阻止 iframe 的请求（至少在 uBO 的情况下）来解决 iframe 问题。当 iframe 被阻止时，要么没有内容，要么是一块空白区域，这意味着对话内容的一部分丢失了。问题在于 iframe 的存在是因为 discourse 用它替换了发帖人的链接，而我建议的是一种机制，让有兴趣的用户可以“原样”保留该内容。（类似 alt 文本的东西也会很有用，但我认为 iframe 没有这个功能。）
如果我担心泄露我的IP地址，我通常应该使用TOR / VPN。 
也许可以，但这并不是问题所在。许多人发现内容拦截器是他们性价比的“甜蜜点”。
备用文本可能是一种更合适的方法，因为它不需要用户偏好（并且在 iframe 因其他原因无法加载的情况下是透明的，例如 src 域被网络阻止）。如果能找到好的实现方式，它也可能更容易维护。一种实现思路：在帖子文本中显示原始 URL，将 onebox iframe 附加到 DOM 之外，一旦 iframe 加载成功，就用 iframe 替换 URL。
用户可以随时通过将链接包装在 < 中来禁用任何类型的嵌入
<https://discourse.org/>
同样，你也可以直接创建链接：
[discourse.org](https://discourse.org/)
精明的用户不需要这种设置，只需在创建内容时不嵌入即可。
我指的是用户阅读讨论，而不是用户发布到讨论。
那么对我来说，这是网站管理员的设置，尽管同意最好有更好的备用方案来处理失败的 iframe 加载。