私は自分のWebサイト用の不快なコンテンツチェッカーを開発し、それをGitHubで公開したいと考えています。ただし、ソースコードには多くの攻撃的、人種差別的、または不快なコンテンツが含まれています。
ソースは完全に文書化されていますが、GitHubでそのような作品を公開するのが許容できるのか、それとも文字列の配列を読者の想像力に任せるのかについて、あなたの意見が欲しかったのです!
私は自分のWebサイト用の不快なコンテンツチェッカーを開発し、それをGitHubで公開したいと考えています。ただし、ソースコードには多くの攻撃的、人種差別的、または不快なコンテンツが含まれています。
ソースは完全に文書化されていますが、GitHubでそのような作品を公開するのが許容できるのか、それとも文字列の配列を読者の想像力に任せるのかについて、あなたの意見が欲しかったのです!
回答:
私はROT-13ソリューションに反対しなければなりません。禁止された単語を難読化するのは、単にそれらの光景が誰かを怒らせるかもしれないからです。時間の無駄です。
悪い言葉/悪い言葉のルールの辞書は、とにかく別のファイルから取得する必要があります(実行時にロードするか、リソースとして埋め込むことができます)。このファイルを難読化すると、あなた/他の開発者/ユーザーがそれを変更したり、問題を修正したりすることが難しくなります。また、ハードドライブに「banned_words.txt」というファイルが表示された場合、不快な単語のリストが含まれていると予想されます。
「コンピュータサイエンスのすべての問題は、別のレベルの間接参照によって解決できます。」(によって デイヴィッド・ウィーラー)。
読者に迷惑をかけないようにコンテンツをエンコードできることを考慮すれば、オプションはアップロードするかどうかに限定されません。
指摘したように、コメントでは、上記のようなアプローチがで使用されているROT13文字置換暗号「隠れの手段...としての使用のために知られ、攻撃材料 ...カジュアル一目から」
完全を期すために、エンコードされた辞書に対してチェッカーを追加で実行することを検討してください。これにより、選択したエンコードが誤って攻撃的な単語を別の単語に変えないようにすることができます。
そのようなものをエンコードするとき、物事を確実に予測することはできないので、ダブルチェックすることは理にかなっています。私の過去のプロジェクトの1つで、誤って構成されたチェッカーがランダムな文字シーケンス(ZIPアーカイブのuuencodeされたコンテンツ)で不快なコンテンツを発見し始めたときに、かなり深刻なメールが停止しました。
プレーンテキストであるGvdlの受け渡しと比較して、エンコードには、法的問題および関連するすべてのリスクと依存関係を完全に回避するという実質的な利点があります。
考えてみてください。特定のリポジトリの特定の利用規約により、私のコンテンツが許可されます。
しかし、彼らがTOSを変更することに決めた場合はどうなりますか?または、互換性のない用語を使用して別のリポジトリに変更することにした場合はどうなりますか。私は何をするつもりですか?
ちなみに、「今のところ」「友好的な」リポジトリにいることでさえ、まだ安全ではないことに注意してください。
奇妙なWebフィルターが原因で誰かが私のコンテンツをダウンロードできないとしたらどうでしょうか?ユーザーの苦情に対応し、フィルターを修正する方法を説明しますか?彼らのフィルター...
...ご存知のように、エンコードを決定する前に、もう一度考え直したいと思います。そして、たとえ私が決定したとしても、私はそのための非常に非常に正当な理由があることを確認します。