由于欧洲隐私法规，最好避免托管网站发起的请求到第三方域。使用 Discourse 实现合规性很困难，因为 Onebox 功能会让浏览器从原始网站获取缩略图，从而产生第三方请求。请看下面的已装箱文章：
您可以在开发者工具中看到图像是从第三方网站下载的。正如文章所指出的，即使请求没有 cookie，这也是一个 GDPR 问题。
目前我已禁用我的 Discourse 实例的 onebox 功能，但我希望以一种更严格地尊重隐私且不会导致罚款的方式重新引入它。
这些图像可以从主域或自定义域（如 cdn.mydomain.com）提供。
由于版权原因，您无法在自己的设置中保存第三方图片，而图片版权问题非常棘手（这也使得 Discourse 的一项功能颇具争议，但那是另一回事）。但 Oneboxing 并不违反 GDPR，也从未违反过。为了安全起见，通过链接告知涉及第三方是一个明智之举，而遵守 GDPR 是他们的责任。但您也不必这样做。
与此同时，Discourse 已经默默地抓取了此处 onebox 中使用的图片：
Oneboxing 本身并不违反 GDPR，但提供第三方资源明显违反 GDPR，请参阅上面的 Google Fonts 案例
也许我们可以通过 Discourse 服务器代理它们，这样第三方只会看到 Discourse 服务器的 IP 地址，而不是用户的 IP 地址？
嗯，这很有意思！这是某种插件还是我可以在我的实例上启用的设置？
Oneboxing 不会为第三方服务提供服务。GDPR 允许使用 Google Fonts，它必须告知用户——Google 也在遵守 GDPR。
但这根本不是 GDPR 的问题。问题在于 iframe。
这与其说是“告知”用户，不如说是需要一个法律依据，例如同意或合法利益。如果获得同意，您必须提供一种方便的方式来拒绝同意，然后该资源将不会加载。如果基于合法利益，您必须进行合法利益评估，而我（以及我想象中的许多其他 Discourse 主机管理员）宁愿不这样做，而是完全禁用 oneboxing，或者将用户的 IP 隐藏在代理后面。
这完全是关于告知。在收集、使用和存储用户的个人数据时，您需要获得同意。即便如此，您必须告知您做了什么、为什么这样做以及持续多久。
Oneboxing 不属于此列，但如果涉及第三方，您必须告知。而 oneboxes 仅仅是花哨的链接。
我的意思是：仅仅披露第三方请求的事实是不够的。根据 GDPR，您必须提供：
我们不能使用同意，因为 Discourse 不允许仅为同意的用户在 onebox 中显示外部图像。合法权益仍然需要让律师参与该过程，以正确进行平衡测试。如果软件不让浏览器向第三方发送请求（我们甚至无法在隐私政策中列出这些第三方，也无法指向这些第三方的隐私政策，因为互联网上几乎可以是任何人），那么我们就无需这样做，这将变得容易得多。
正如 GDPR 所见，它们不仅仅是链接，因为浏览器会在用户没有采取行动的情况下访问它们。
（顺便说一句，我不是凭空捏造的，我在职业生涯中从事 GDPR 合规工作，并且在欧盟的投诉和罚款方面拥有实践经验）
撇开法律讨论不谈，有些用户会阻止第三方资源，专门为了不向第三方透露他们的 IP 地址和浏览习惯。如果 oneboxes 对他们来说也能用就好了 
撇开法律方面的考虑，我认为在这个领域做些事情会很有用。
然而，我倾向于认为，解决方案是要求用户明确选择加入（opt-in）以显示外部媒体。我访问的许多德国网站都采用了这种做法，专门要求用户进行选择（下面有示例）。
我认为，在此基础上，由 Discourse 主机直接提供静态图像预览会很好，但我倾向于认为实际的选择加入是更重要的一步。
示例（Golem.de，德国IT新闻网站）：
文章：Minecraft 电影预告片的 Minecraft 版本征服了人心
无外部媒体选择加入：
有外部媒体选择加入：
我对这个感到好奇。我能理解 Google Font 的问题，因为它需要为每个用户从 Google 服务器实际获取字体。
然而，根据我的经验，“Onebox”的链接预览是静态的，除非你重建 HTML。我的意思是，根据我的经验，即使源更改了页面上的信息，onebox 仍然保持相同的预览信息。
根据我的经验，即使原始链接网站不再包含链接的内容，一些旧的 onebox 仍然保持完整。
另一方面，我认为 iframe 会像 @Jagster 提到的那样，在查看时为每个用户进行实时预览，就像获取 Google 字体一样。
至少根据我的理解。我想你还需要禁用嵌入，对吗？
我想可以创建一个插件来添加如下功能。
我明白为什么我在这里的加拿大德国朋友说最好阻止欧盟。
正如 @Firepup650 在上面所说，情况完全不是这样，因为 Discourse 会自动下载并提供 Onebox 的图片，这甚至是默认设置。
你甚至可以通过切换 block hotlinked media（阻止热链接媒体）来使其更加严格。
你不需要为此征得同意。
GDPR 并非如此看待。用户必须采取行动才能访问那里。
问题在于谷歌没有遵守 GDPR。这也是谷歌被欧盟处以巨额罚款的部分原因。但这并不是使用谷歌字体、Adsense 等网站的问题。这就是为什么谷歌会参与审判，而不是提供这些服务的网站。
我理解这种沮丧——欧盟的许多做法都是出于好意，但不一定执行得很好，而且常常让开发人员感到复杂。
在这种具体情况下，我喜欢人们所做的实现，因为它给了用户一个简单但有意义的选择。
如果这可以通过插件完成，那就更好了。我假设它需要在核心中完成，因为它会影响所有 onebox。
理由或虚构的理由开始偏离主题了。但这些规定在美国也是令人头疼的问题。而这些规定之所以必要，是因为美国的巨头公司根本不尊重用户的隐私，因为美国没有相关法规。或者我现在应该说……因为开发者们的生活没有那么复杂 
所以，不要感谢欧盟。给谷歌、亚马逊、微软、X、苹果等公司寄感谢卡吧。同时，你也可以想想它们有什么共同之处。
顺便说一下，我收到一条消息，说我不应该让任何13岁以下的儿童进入我的论坛。如果他们能读懂芬兰语，我肯定会让他们进来的，即使他们来自加利福尼亚 
结束（为什么没有麦克风掉落的表情符号……）
我并非质疑监管的必要性——我只是说，从“我们和我们 999 个受信任的合作伙伴将窃取您的数据”到弹出一个大大的窗口说“单击此处同意我们和我们 999 个受信任的合作伙伴将窃取您的数据”之间的步骤，有时感觉像是一种惨胜，我能理解为什么有些人会感到困惑 
但回到主要话题：
@kuba-orlik，如果这对您有效，那么我建议将功能请求重新措辞为“提供在显示外部媒体前要求用户同意的选项”（我将为此投票）。
如果您觉得当前的标题更适合您的请求，那也没关系。在这种情况下，我可能会自己再开一个。
好吧，这简直是走向了疯狂的极端。除非有所改变或被歪曲，我记得读到过，一家公司可能需要履行对硬件的保修，而终端用户通过拆卸和尝试修复来损坏了它。
更大的问题是，它为了保护人们免受愚蠢行为的侵害而走向了极端。
根据我的理解，插件确实可以完成这个任务，因为它修改的是服务器端的核心元素，而不是客户端/浏览器端的修改主题组件；Tamper Monkey 脚本有点像浏览器端安装的主题/组件。我以前在一个名为 Fallen Sword 的旧浏览器游戏中用过一个 Tamper Monkey 脚本来修改它在市场上订购商品的方式。
有趣的是，我没有收到这个主题的通知。
鉴于我们已经有了\n\nblock hotlinked media \n\n和\n\ndownload_remote_images_to_local\n\n，我不太理解这里的特性请求。所以如果你想要这个行为……将其设置为 true 和 false。\n\n\n这个特性请求是让我们在 Discourse 产品中构建一个一流的 HTTP 代理吗？
我不知道有这两个设置！它们目前似乎能很好地完成工作。我会进一步测试它们，谢谢！
