Допустимо ли загружать оскорбительный контент на GitHub? [закрыто]

Я разработал оскорбительный контент-контроль для своего сайта и хочу опубликовать его на GitHub . Тем не менее, исходный код содержит много оскорбительного, расистского и иного противного содержания.

Источник полностью документирован, но я хотел узнать ваше мнение о том, допустимо ли публиковать такие работы на GitHub или оставить массив строк на усмотрение читателя ?!

Я должен не согласиться с решением ROT-13. Сокрытие своих запрещенные слов просто потому , что вид из них может обидеть кого - то это пустая трата времени.

Ваш словарь плохих слов / правил плохого слова в любом случае должен быть из отдельного файла (который может быть загружен во время выполнения или встроен как ресурс) . Запутывание этого файла просто затрудняет вам / другим разработчикам / вашим пользователям его изменение или исправление любых проблем. Кроме того, если бы я увидел файл «banned_words.txt» на моем жестком диске, я бы ожидал, что он будет содержать список оскорбительных слов.

«Все проблемы в информатике могут быть решены с помощью другого уровня косвенности». ( От David Wheeler ).

Ваши варианты не ограничены ни загрузкой, ни загрузкой, если принять во внимание, что вы можете кодировать контент, чтобы он не мешал читателям.

• Например, простое переключение на следующую букву (от A до B, от B до C и т. Д., Когда Z переходит на A для завершения кодирования) может превратить знаменитые четырехбуквенные слова в абсолютно безвредный Gvdl . Все, что вам нужно, чтобы использовать его в вашем приложении, - это сдвинуть его обратно в обратном направлении, к предыдущим буквам , с А, сместившимся на Z.

Как отмечалось в комментариях , подобный подход используется в шифре подстановки букв ROT13 , известном своим использованием «в качестве средства сокрытия ... оскорбительных материалов от случайного взгляда ...»

Для полноты рассмотрите возможность запуска своей программы проверки для закодированного словаря , чтобы убедиться, что выбранная кодировка не случайно превратила одно оскорбительное слово в другое.

_{При кодировании подобных вещей имеет смысл перепроверять, потому что никто не может достоверно предсказать вещи. В одном из моих прошлых проектов у нас был довольно серьезный перерыв в работе почты, когда неправильно настроенная программа проверки начала обнаруживать оскорбительный контент в случайных последовательностях символов (в uuencoded контенте ZIP-архивов).}

По сравнению с передачей простого текста, Gvdl , кодирование имеет существенное преимущество , заключающееся в полном избежании юридических проблем и всех связанных с этим рисков и зависимостей .

Просто подумай об этом. Скажем, особые условия обслуживания в определенном хранилище разрешают мой контент, хорошо.

Но что, если они решат изменить TOS ? Или, что, если я решу перейти на другой репозиторий с несовместимыми условиями. Что я собираюсь делать?

Заметьте, кстати, что даже находясь в «дружественном» хранилище, здесь и сейчас, все еще не полностью безопасно.

Что если кто-то не сможет загрузить мой контент из-за странного веб-фильтра ? Готов ли я отвечать на жалобы пользователей и объяснять, как исправить фильтр? Их фильтр ...

... Видите ли, я бы лучше подумать дважды, прежде чем я решу против кодирования. И даже если бы я решил, я бы удостоверился, что у меня есть очень, очень веская причина для этого.