ヨーロッパのプライバシー規制のため、ホストしているウェブサイトから開始されるサードパーティドメインへのリクエストは避けるのが最善です。Onebox機能により、ブラウザがサムネイルを元のウェブサイトから取得するため、サードパーティのリクエストとなり、Discourseでのコンプライアンス達成は困難です。以下の一箱化された記事を参照してください。
開発者ツールで、画像がサードパーティのウェブサイトからダウンロードされていることがわかります。記事が指摘しているように、リクエストにCookieがなくてもGDPRの問題となります。
現在、DiscourseインスタンスでOneboxを無効にしていますが、プライバシーをより厳密に尊重し、罰金につながる可能性のある方法を開かないような方法で、再び導入したいと思います。
画像はメインドメイン、またはcdn.mydomain.comのようなカスタムドメインから提供できます。
著作権のため、独自のセットアップにサードパーティの画像を保存することはできません。画像の場合、これは非常に困難です（そして、それがDiscourseの機能の1つを非常に疑わしいものにしていますが、それは別の話です）。しかし、OneboxingはGDPRに違反しておらず、これまで違反したことはありません。安全策として、リンクを通じてサードパーティが関与していることを伝え、GDPRを遵守するのは彼らの責任であると伝えるのが賢明な動きです。しかし、それも必要ありません。
一方、Discourseはすでに、ここでワンボックスに使用されている画像をサイレントに取得しています：
ワンボクシング自体は違反ではありませんが、サードパーティのリソースを提供することは明らかに違反です。上記のGoogleフォントのケースを参照してください。
代わりに、ディスコースサーバーを介してプロキシすることはできませんか？そうすれば、サードパーティはユーザーのIPではなく、ディスコースサーバーのIPしか見ることができません。
へえ、それは面白いですね！それは私のインスタンスで有効にできるプラグインか設定ですか？
Oneboxingはサードパーティサービスを提供していません。また、GDPRはGoogleフォントの使用を許可していますが、ユーザーに通知する必要があります。GoogleもGDPRを遵守しています。
しかし、これはまったくGDPRの問題ではありません。問題はIframeです。
これはユーザーに「伝える」というよりも、同意や正当な利益といった法的な根拠を持つことが重要です。同意を得る場合は、同意を拒否する便利な方法を用意する必要があり、その場合リソースは読み込まれません。正当な利益を得る場合は、正当な理由評価を実施する必要があります。私（そして多くの他のDiscourseホスト管理者も同様だと想像できます）は、それをやりたくないので、ワンボクシングを無効にするか、ユーザーのIPをプロキシで隠すことを選択します。
それはまさに説明についてです。ユーザーの個人データを収集、使用、保存する際には同意が必要です。それでも、何をするか、なぜするか、どのくらいの期間するかを伝えなければなりません。
ワンボクシングはその一部ではありませんが、第三者が関与している場合は、そこに伝えなければなりません。そして、ワンボクシングは単なる派手なリンクです。
私が意味したのは、第三者のリクエストがあるという事実を開示するだけでは不十分ということです。GDPRの下では、以下を提供する必要があります。
Discourseでは、同意したユーザーのみにoneboxで外部画像を表示することができないため、同意を使用することはできません。また、正当な利益は、適切なバランステストを実施するために、プロセスに関与する弁護士を必要とします。ソフトウェアがブラウザに第三者にリクエストを送信させない場合、それははるかに簡単になります（プライバシーポリシーに記載することも、それらの第三者のプライバシーポリシーを指すこともできません。インターネット上の誰でもあり得るため）。
GDPRで見たように、それらは単なるリンクではありません。ユーザーの操作なしにブラウザによってアクセスされるためです。
（ちなみに、これは空から引っ張ってきたものではありません。私は専門的な生活でGDPRコンプライアンスに取り組んでおり、EUでの苦情や罰金がどのように機能するかについての実践的な経験があります）
法的な議論はさておき、第三者にIPアドレスや閲覧習慣を明らかにしない目的で、サードパーティのリソースをブロックするユーザーがいます。ワンボクシングが彼らのために機能すると良いのですが 
法的な考慮事項はさておき、この分野で何かを行うことは有益だと思います。
しかし、私は、ユーザーに外部メディアを表示するための特定のオプトインを求めるのが解決策である傾向があります。私が訪れる多くのドイツのウェブサイトは、これについてユーザーに具体的に尋ねる習慣を採用しています（例は以下のとおりです）。
これに加えて、Discourseホストから直接提供される静的な画像プレビューがあれば良いと思いますが、実際のオプトインがより重要なステップである傾向があります。
例（Golem.de、ドイツのITニュースサイト）：
記事：Minecraft-Version des Minecraft-Filmtrailers erobert Herzen
外部メディアのオプトインなし：
外部メディアのオプトインあり：
これについて興味があります。Googleフォントの問題は理解できます。各ユーザーのために実際にGoogleのサーバーからフォントを取得する必要があるからです。
しかし、私の経験では、「ワンボックス」では、HTMLを再構築しない限り、リンクのプレビューは静的なままです。私が言いたいのは、ソースがページ上の情報を変更しても、私の経験ではワンボックスは同じプレビュー情報でそのままということです。
私の経験では、ワンボックスは、元のリンクされたサイトがリンクされたコンテンツを保持しなくなっても、そのまま残っていました。
一方、iframeは、Googleフォントを取得する場合と同様に、ユーザーごとに表示されるときにライブプレビューとして、@Jagsterが言及した方法で更新されると信じています。
少なくとも私の理解では。また、埋め込みも無効にする必要があるのではないでしょうか？
プラグインを作成して、以下のような機能を追加できると思います。
カナダにいる私のドイツ人の友人が、EUをブロックするのが一番良いと言う理由がわかります。
上記 @Firepup650 が述べたように、これはまったく当てはまりません。Discourse は Onebox 画像を自動的にダウンロードして提供するため、これはデフォルトの設定です。
block hotlinked media を切り替えることで、さらに厳格にすることもできます。
それには同意は必要ありません。
GDPRはそのように見ていません。そして、ユーザーはそこへアクセスするためにアクションを起こす必要があります。
問題はGoogle側にあり、GDPRを遵守していませんでした。それが、GoogleがEUからかなりの罰金を科された訴訟の一因です。しかし、GoogleフォントやAdsenseなどを使用したサイトの問題ではありませんでした。そのため、裁判の対象となったのはGoogleであり、これらのサービスを提供したサイトではありませんでした。
お気持ちは理解できます。EUの多くの取り組みは善意から始まっていますが、必ずしも適切に実施されておらず、開発者にとっては複雑な問題となることがよくあります。
この特定のケースでは、人々が実装したものを気に入っています。なぜなら、ユーザーにシンプルでありながら意味のある選択肢を与えてくれるからです。
プラグインでこれが可能であれば、さらに良いでしょう。すべてのoneboxで実行されるため、コアで実装する必要があると思っていました。
理由や想像上の理由は、もはやトピックから外れています。しかし、これらの規制はアメリカでも問題となっています。そして、これらの規制が必要なのは、アメリカの巨大企業がユーザーのプライバシーを全く尊重しなかったからであり、アメリカには規制がないからです。あるいは、今言うべきでしょうか…開発者の生活はそれほど複雑ではないから🤣
ですから、EUに感謝しないでください。Google、Amazon、Microsoft、X、Appleなどに感謝状を送ってください。そして同時に、それらに共通するものを考えてみてください。
ところで、13歳未満の子供を私のフォーラムに入れないようにというメッセージを受け取りました。フィンランド語が読めるなら、カリフォルニアからでも必ず入れますよ😜
以上（なぜマイクドロップ絵文字がないのか…）
規制の必要性については議論していませんが、言いたいのは、「私たちと999の信頼できるパートナーがあなたのデータを盗みます」から「私たちと999の信頼できるパートナーがあなたのデータを盗むことに同意するにはここをクリックしてください」という大きなポップアップへの移行は、時にピュロスの勝利のように感じられ、なぜ人々が首をかしげるのか理解できるということです:slightly_smiling_face:
しかし、本題に戻ると：
@kuba-orlik、これがあなたにとってうまくいくなら、機能リクエストを「外部メディアを表示する前にユーザーの同意を要求するオプションを提供する」に言い換えることをお勧めします（そうすれば、私はそれに投票します）。
現在の見出しがあなたのリクエストにより適していると感じるなら、それも問題ありません。その場合、おそらく自分で別のものを作成します。
それは非常識な極端な例です。変更されていないか、歪曲されていない限り、エンドユーザーが分解して修理しようとして損傷したハードウェアの保証を企業が尊重する必要があるかもしれないと読んだことを覚えています。
より大きな問題は、それが単なる愚かさから人々を保護するために極端な手段に訴えていることです。
私の理解では、プラグインは実際にこれを達成することができます。なぜなら、それはサーバー側でコアの要素を変更するのに対し、クライアント/ブラウザ側で変更するテーマコンポーネントとは異なり、Tampermonkeyスクリプトはブラウザ側でインストールされたテーマ/コンポーネントのようなものだからです。以前は、Fallen Swordという古いブラウザゲームで、マーケットでのアイテムの並び順を変更するためにTampermonkeyスクリプトを使用していました。
興味深い余談ですが、このトピックの通知を受け取っていませんでした。
ここでの機能リクエストが理解できません。すでに以下の機能があるためです。
block hotlinked media
そして
download_remote_images_to_local
したがって、この動作が必要な場合は…これを true と false に設定してください。
Discourse 製品にファーストクラスの HTTP プロキシを構築することが機能リクエストなのでしょうか？
この2つの設定については知りませんでした！今のところ、うまく機能しているようです。さらにテストしてみます。ありがとうございます！
