Чи прийнятно завантажувати образливий вміст на GitHub? [зачинено]

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

Джерело повністю задокументовано, але я хотів, щоб ваша думка щодо того, чи прийнятно публікувати таку роботу на GitHub, чи залишити масив рядків під уяву читача ?!

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

Ваш словник поганих слів / поганих слів-правил повинен у будь-якому випадку надходити з окремого файлу (який може бути завантажений під час виконання або вбудований як ресурс) . Пошкодження цього файлу просто ускладнює вам / іншим розробникам / вашим користувачам змінити його або виправити будь-які проблеми. Крім того, якби я побачив на своєму жорсткому диску файл під назвою "banned_words.txt", я би очікував, що він містить список образливих слів.

"Усі проблеми з інформатики можна вирішити іншим рівнем непрямості". ( Від David Wheeler ).

Ваші параметри не обмежуються або завантаженням, чи ні, якщо врахувати, що ви можете кодувати вміст, щоб він не турбував читачів.

• В якості прикладу, просто перехід до наступної букви (А до В, В до С, і т.д., з Z переходом в до повного кодування) може перетворити відоме чотири літери слово в абсолютно нешкідливий Gvdl . Все, що вам потрібно використати у вашій програмі, - це перенести її назад у зворотному напрямку, до попередніх літер , з A переміщенням на Z.

Як зазначалося в коментарях , такий підхід застосовується в шифрі на заміщення букв ROT13 , який відомий тим, що його використовують "як засіб приховування ... образливих матеріалів від випадкового погляду ..."

Для повноти розгляньте додатково запуск вашої шашки проти кодованого словника , щоб переконатися, що вибране кодування випадково не перетворило одне образливе слово на інше.

_{Кодуючи подібні речі, є сенс повторити перевірку, оскільки не можна надійно передбачити речі. В одному з моїх минулих проектів у нас був досить важкий відключення пошти, коли неправильно налаштована перевірка почала виявляти образливий вміст у випадкових послідовностях символів (у невкодованому вмісті архівів ZIP).}

На відміну від простого тексту Gvdl , кодування має істотну користь у повному обсязі уникнення юридичних проблем та всіх пов'язаних із цим ризиків та залежностей .

Просто подумайте. Скажімо, конкретні умови надання послуг у певному сховищі дозволяють мій вміст, штрафувати.

Але що робити, якщо вони вирішать змінити TOS ? Або що робити, якщо я вирішу перейти на інший сховище, маючи несумісні умови. Що я збираюсь зробити?

Зауважте до речі, що навіть перебуваючи у "доброзичливому" сховищі, тут і зараз, все ще не повністю безпечно.

Що робити, якщо хтось не зможе завантажити мій вміст через дивний веб-фільтр ? Чи готовий я відповісти на скарги користувачів і пояснити, як виправити фільтр? Їх фільтр ...

... Розумієте, я б краще подумав двічі, перш ніж вирішуватись проти кодування. І навіть якщо я зважусь, я би переконався, що у мене є дуже, дуже вагомі причини для цього.