Referer付きでリモート画像をダウンロード（プラグイン可能？）

開発
1

Discourse への移行に取り組んでおり、SiteSetting.download_remote_images_to_local については知っています。それは素晴らしい機能です。

しかし、それらをすべてダウンロードするために（低速で）リベイクすると、Photobucket がリファラーに応じて透かし入りの画像を配信していることに気づきました。

軽く調べたところ、ダウンロードは /lib/final_destination.rb で処理されているようです。移行後のリベイクのためだけに一時的にパッチを当てることは可能かもしれませんが、それ以降も画像ホストが悪い場合に画像をホットリンクする hypothetical な状況には対応できません。まともな人間なら今や Photobucket を使わないことはわかっていますし、透かしを入れる他のサービスも知りません。なので、大した問題ではないかもしれません。

私の質問はこうです。誰かがすでにこれを解決しましたか？そして、これはプラグインで実現可能でしょうか？ まだプラグインの仕組みについては学んでいません。

あるいは、リモート画像をダウンロードする際に、常にリファラーを scheme://domain/ に設定するのは悪い機能提案でしょうか？ Discourse がそれを実行することに、いつ問題があるでしょうか？

もし何について話しているか見たい場合は、以下をご覧ください。

https://i1111.photobucket.com/albums/h475/scoobystuff/Stereo/S1080033.jpg

# 透かしあり:
curl -LO \
  'https://i1111.photobucket.com/albums/h475/scoobystuff/Stereo/S1080033.jpg'
# 透かしなし:
curl -LO --referer 'https://i1111.photobucket.com/' \
  'https://i1111.photobucket.com/albums/h475/scoobystuff/Stereo/S1080033.jpg'

800×533 74.5 KB

2

私は彼らがする透かしがあまり好きではありませんが、無料アカウントの要件の1つとして、ホスティングにそれらを使用する際に透かしを含めることが定められているため、透かしを隠すために偽の参照元を送信することは、実際にはPhotobucketの利用規約に違反することになります。有料アカウントには、これらの透かしは追加されません。

「いいね！」 1
3

何ですか？

どのようにその結論に至ったのですか？アカウントなし（または認証なし）で画像をダウンロードしただけで、当事者が同意したToSはありません。または、その当事者に提示されたことさえありません。

ToSはアップローダーに適用されます。具体的には：

無料アカウントでは画像ホスティングは許可されていません。当社の単独かつ絶対的な裁量により、無料アカウントで画像をホストすることを許可した場合、その画像には、画像が当社によってホストされていることを示すPhotobucketの透かしが含まれます。無料の画像ホスティングを許可した場合、当社は、当社の単独かつ絶対的な裁量により、画像をブロックするか、画像をぼかして透かしを入れる権利を留保します。無料アカウントの所有者は、第三者ホスティングを許可する有料アカウントにアップグレードすることを強くお勧めします。

さらに、これは単にアカウントの機能を通知する声明です（「無料アカウントでは画像ホスティングは許可されていません…無料の画像ホスティングを許可した場合…」）。同意することにより、アカウント所有者はそれに気づいただけです。もし私が無料のPhotobucketアカウントを持っていて、その画像をアップロードしていた場合、その言語は私がそのような行為をしないことに同意しなければならないことを意味しないため、このトピックでそれをホットリンクしても違反にはなりません。この声明の目的は、無料アカウントの所有者が、例えば、サービス拒否でPhotobucketを訴えることができないようにすることです。

実際のToSには表示されない、私が作成した次の声明と比較してください。

無料アカウントの所有者は、アカウントを画像ホスティングに使用しないこと、および他の場所で画像をホットリンクしないことに同意します。

4

友人はあなたの提案したことを自分のインスタンスで実行したところ、Photobucketが彼のサーバーをブロックしました。彼らに送られたメールのコピーを探してみます。

「いいね！」 1
5

法的には利用規約違反ではないと思いますが、フォトバケットは契約上の義務がない限り、自由に使用を拒否できます。メールの内容を見てみたいです。フォトバケットは彼のサーバーの連絡先セクションから彼のメールアドレスを入手したのでしょうか？

警告ありがとうございます！最終的な移行時にすべてのフォトバケット画像をプルするときは、プロキシなどを介して行うようにします。まあ、どちらにしてもあまり関係ありませんが、笑。もう誰もフォトバケットを使用していません。本番サーバーにリファラーのスプーフィングを残すこともありませんが、今後の新しいものには必要ないことを願っています。

6

著作権で保護された画像へのアクセスを保護するために使用される方法や、元の画像へのアクセスを制御する方法を回避することは、利用規約違反にはなりませんが、DMCA違反（または他国の別の著作権法の違反）になる可能性があります。

リファラーヘッダーの偽装は「良いウェブ市民」とは言えないと思いますし、DMCAが適用される場合、そのようなソフトウェアを配布することは違法でさえあります。

多くのインポートスクリプトには、添付ファイルのダウンロード用の独自のコードがあります。正規表現を作成し、リファラーを含めて、インラインのPhotobucket画像にもそのロジックを適用することを検討しましたか？

7

このケースでは、利用規約でアップローダーがすべての権利を保持すると記載されているため（ただし、一部の地域では何らかの法律が発動する可能性はありますが）、著作権侵害や回避は適用されないと思います。しかし、標準的なブラウジング動作を尊重し、「良いウェブ市民」であることについては、ご指摘の通りです。そのように考えると、Refererスプーフィングを公式機能として出荷するのは意味がないと思います。

はい、私の移行のために（透かしなしで）画像をプルインできるようになるはずです。phpbbインポーターの場合、リモート画像をダウンロードする際にRefererをスプーフィングするようにdiscourse自体を一時的に変更し、インポーターが（アバター以外で）リモート画像を保存できないため、リベイクするのが最も簡単だと思います。

私は主に、この問題に取り組んだ経験のある人から話を聞きたかっただけです。また、プラグインでそれが技術的に可能かどうか（まだ疑問ですが）、そしてdiscourseが公式にそのような機能を搭載することが理にかなっているかどうか（そうではありません）についても興味がありました。

「いいね！」 1
8

アップローダーがその権利（コンテンツの使用方法や配布方法を管理する権利を含む）を保持しているという事実をもってしても、他者が許可なくコンテンツを変更したり、ウォーターマークを削除したりする権利を与えるものではありません。

DMCAはアクセス制御もカバーしており、これはここでは適用されます（つまり、広告に囲まれている場合にのみ、ウォーターマークなしでその画像を提供する権利があり、そのメカニズムを削除することは、彼らがあなたにそうしてほしい方法とは異なる方法で画像にアクセスすることになります）。

「いいね！」 1
9

はは、たぶんね。でも、youtube-dlのようなものがまだgithub上にあることを考えてみてほしい。リファラーのスプーフィングなんて、それに比べれば無邪気なものに見えるだろう。信じてほしいが、RIAAはあれを削除させようと本気で試みたんだ。そういうニュースを追っていれば、しばらく「ニュース」になっていたはずだ。

10

言い換えますと、youtube-dl はまだ稼働しているのではなく、停止させられていた後で、復旧しました。

11

そして、それは正当なユースケースが存在するからにすぎません。

だからといって、すべての用途が正当であるという意味ではありません。

画像に対する権利を所有しているわけではないことを認識してください。

12

すべてに対する権利を所有していないかもしれませんが、ユーザーは所有しています。それがどこにつながるのかはわかりませんが。リンク切れから保護したいという彼らの要望も表明しています。

「いいね！」 1
13

haha。皆さんと激しい議論をしようとしているわけではないことを理解してください。私たちは皆、ここで良い関係です :slight_smile: :heart:。しかし、私の細部にこだわる見解はこうです。

ええ、しかし、それは脅しによって停止されただけです。彼らの主張に対しては、正当な法的議論があります。いずれにせよ、GitHub で誰もそれ以上追求せず、それは何かを物語っています。RIAA ほど強欲で意地悪な団体はありません。

もしあなたが EFF の回答 を、GitHub が RIAA の（偽の）主張を拒否するよう説得/ embolden した、支配的な法的議論/理論と見なすなら、本当の理由はそれよりも複雑であり、実際には回避の主張さえ否定しています。

法務専門家が youtube-dl が DMCA 1201(a) の回避の定義に違反していると考えていないのであれば、リファラーを偽装することがそのような回避と見なされることは surely ありません。

14

もちろん、必ずしもそうとは限りませんが、少なくともユーザーはフォーラムに投稿した時点であなたにライセンスを与えたと仮定できるため、それは彼らの問題であり、あなたの問題ではありません。したがって、このユースケースは正当であり、私はそのことに100％確信しています。

しかし、まともなオープンソースプロジェクトは、たとえ彼らが正しかったとしても、または正しくなったとしても、そして苦情を申し立てた人がそうでないとしても、法的な議論のために一方的な削除のリスクを冒すことはありません。したがって、インポートスクリプトがこれに適した場所だと思います。

「いいね！」 1