不快なコンテンツをGitHubにアップロードすることは認められますか?[閉まっている]


12

私は自分のWebサイト用の不快なコンテンツチェッカーを開発し、それをGitHubで公開したいと考えています。ただし、ソースコードには多くの攻撃的、人種差別的、または不快なコンテンツが含まれています。

ソースは完全に文書化されていますが、GitHubでそのような作品を公開するのが許容できるのか、それとも文字列の配列を読者の想像力に任せるのかについて、あなたの意見が欲しかったのです!


11
重要な質問は、「実際に攻撃的ですか?それとも単なる「ディクトナリー」ですか?」これはgithub TOSに入ります-§7は、それを削除することができる(ただし、義務ではない)ことを示唆しています。文字列を別のファイルに抽出したい場合があります。このファイルは、rot13暗号化されているか、原因ブラウザーを攻撃しないようにするためのものです。

1
大丈夫だと思います、Readmeの読者に警告するだけです。他のGitHub Reposには不快な言葉がたくさんあります。さらに、あなたのケースは誠実です。
ジャックトレード

5
すべての単語をテキストファイルまたはデータベースに入れて、実行時にそれらをロードしてください。次に、ファイルの冒頭に、以下のテキストが心の弱い人向けではないという素敵な免責事項を付けます。コードはきれいで、さまざまな状況に応じてさまざまなテキストファイルを使用できますか?
アンプト

@Sparticus、コメントありがとう。私はこれに同意し、おそらく私にとって最良のアプローチだと思います。
SimonGoldstone.com

5
言葉自体は不快ではありません。その背後にある意図は、それを攻撃的にします。
カプタン

回答:


45

私はROT-13ソリューションに反対しなければなりません。禁止された単語を難読化するのは、単にそれらの光景が誰かを怒らせるかもしれないからです。時間の無駄です。

悪い言葉/悪い言葉のルールの辞書は、とにかく別のファイルから取得する必要があります(実行時にロードするか、リソースとして埋め込むことができます)。このファイルを難読化すると、あなた/他の開発者/ユーザーがそれを変更したり、問題を修正したりすることが難しくなります。また、ハードドライブに「banned_words.txt」というファイルが表示された場合、不快な単語のリストが含まれていると予想されます。


同意する。私は言葉を難読化したくありません。
SimonGoldstone.com

5
+1 @simonこのようなリストはすでに表示されています:github.com/snipe/banbuilder
dcaswell

2
@simon私はあなたのプロジェクトが価値がないという意味ではありませんでした。GitHubがあなたが望むようにリストを保存することができるというだけです。他の答えには「はい」または「いいえ」はありません。答えが実際に「はい」だったことを確認したいだけです。
dcaswell

1
「車輪の再発明」は学習の一部です...それは大学で教えられていることのほとんどです。
WernerCD

2
時には、プログラムの配布が継続するか継続するかに何らかの影響を与える可能性のある繊細な感性を持つ人々に遭遇します。ファイルをrot13することでファイルが保持されることを意味する場合、OPはコードをオンにしてGitHubに保持するという目標を達成するのに役立ちます。それは私の本では時間の無駄ではありません。
Blrfl

16

「コンピュータサイエンスのすべての問題は、別のレベルの間接参照によって解決できます。」によって デイヴィッド・ウィーラー)。

読者に迷惑をかけないようにコンテンツをエンコードできることを考慮すれば、オプションはアップロードするかどうかに限定されません。

  • 例として、単純に次の文字にシフトすると(AからB、BからCなど、ZがAにシフトしてエンコードが完了する)、有名な4文字の単語を完全に無害なGvdlに変えることができます。アプリケーションで使用する必要があるのは、AをZ にシフトして、逆方向に前の文字に戻すことだけです。

指摘したように、コメントでは、上記のようなアプローチがで使用されているROT13文字置換暗号「隠れの手段...としての使用のために知られ、攻撃材料 ...カジュアル一目から」

 

http://upload.wikimedia.org/wikipedia/commons/thumb/3/33/ROT13_table_with_example.svg/320px-ROT13_table_with_example.svg.png


完全を期すために、エンコードされた辞書に対してチェッカーを追加で実行することを検討してください。これにより、選択したエンコードが誤って攻撃的な単語を別の単語に変えないようにすることができます。

そのようなものをエンコードするとき、物事を確実に予測することはできないので、ダブルチェックすることは理にかなっています。私の過去のプロジェクトの1つで、誤って構成されたチェッカーがランダムな文字シーケンス(ZIPアーカイブのuuencodeされたコンテンツ)で不快なコンテンツを発見し始めたときに、かなり深刻なメール​​が停止しました。


プレーンテキストであるGvdlの受け渡しと比較して、エンコードには、法的問題および関連するすべてのリスクと依存関係を完全に回避するという実質的な利点があります。

考えてみてください。特定のリポジトリの特定の利用規約により、私のコンテンツが許可されます。

しかし、彼らがTOSを変更することに決めた場合はどうなりますか?または、互換性のない用語を使用して別のリポジトリに変更することにした場合はどうなりますか。私は何をするつもりですか?

ちなみに、「今のところ」「友好的な」リポジトリにいることでさえ、まだ安全ではないことに注意してください。

奇妙なWebフィルターが原因で誰かが私のコンテンツをダウンロードできないとしたらどうでしょうか?ユーザーの苦情に対応し、フィルターを修正する方法を説明しますか?彼らのフィルター...

...ご存知のように、エンコードを決定する前に、もう一度考え直したいと思います。そして、たとえ私が決定したとしても、私はそのための非常に非常に正当な理由があることを確認します。


6
Rot13は、そのための事実上の標準の一種です。ダブルrot13はさらに優れています。:-)
Blrfl

5
トリプルDESと同様に@BlrflはDESよりも優れており、トリプルrot13が最適です。

1
rot13ファイルの編集を、特殊な形式の他のファイルの編集より難しくしない多くのエディター用のプラグインがあると思う
-JoelFan

2
@Simonは、rot13が難読化されるほどではありませんが、むしろテキストを簡単に隠す標準的な方法です。一部のファイアウォールは、特定の文字パターンをブロックするように構成されており、プログラムの機能のためにテキストを取得することが困難になっていることを認識してください。それは、起こりそうな問題である攻撃性ではなく、「ダウンロードしたいもの」と「ブロックしたいもの」の違いを認識できないかもしれない他の技術的ハードルです。はい、Zipを取得できますが、クローンを作成したり、フォークしたり、プッシュしたりすることはできません。

2
@ThomasEding シーザーシフト暗号 1文字。最初の文字は元々「F」です。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.