Czy dopuszczalne jest przesyłanie obraźliwych treści do GitHub? [Zamknięte]

Opracowałem obraźliwe narzędzie do sprawdzania zawartości mojej witryny i chcę opublikować je na GitHub . Jednak kod źródłowy zawiera wiele obraźliwych, rasistowskich i nieprzyjemnych treści.

Źródło jest w pełni udokumentowane, ale chciałem poznać Twoją opinię, czy można opublikować taką pracę na GitHub, czy pozostawić tablicę ciągów wyobraźni czytelnika ?!

Muszę się nie zgodzić z rozwiązaniem ROT-13. Zaciemnianie zakazanych słów po prostu dlatego, że ich widok może kogoś urazić, to strata czasu.

Twój słownik złych słów / złych reguł powinien w każdym razie pochodzić z osobnego pliku (który można załadować w czasie wykonywania lub osadzić jako zasób) . Zaciemnienie tego pliku po prostu utrudnia jego / innym programistom / użytkownikom zmianę lub naprawienie jakichkolwiek problemów. Poza tym, gdybym zobaczył plik o nazwie „banned_words.txt” na moim twardym dysku, oczekiwałbym, że zawiera on listę obraźliwych słów.

„Wszystkie problemy w informatyce można rozwiązać przez inny poziom pośredni”. ( autor: David Wheeler ).

Twoje opcje nie ograniczają się do przesłania go lub nie, jeśli weźmiesz pod uwagę, że możesz zakodować treść, aby nie przeszkadzała czytelnikom.

• Na przykład po prostu przejście do następnej litery (A do B, B do C itp., Z Z przejściem do A w celu pełnego kodowania) może zmienić słynne czteroliterowe słowa w całkowicie nieszkodliwy Gvdl . Wszystko, czego potrzebujesz, aby użyć go w swojej aplikacji, to przesunięcie go z powrotem w przeciwnym kierunku, do poprzednich liter , z przesunięciem A do Z.

Jak wskazano w komentarzach , podejście takie jak powyższe jest stosowane w szyfrze zamiany liter ROT13 , znanym z tego, że „służy do ukrywania… ofensywnych materiałów przed przypadkowym spojrzeniem…”

Ze względu na kompletność rozważ dodatkowo uruchomienie programu sprawdzającego przeciwko zakodowanemu słownikowi , aby upewnić się, że wybrane kodowanie nie zamieniło przypadkowo jednego obraźliwego słowa na drugie.

_{Podczas kodowania takich rzeczy sensowne jest podwójne sprawdzenie, ponieważ nie można w wiarygodny sposób przewidzieć rzeczy. W jednym z moich poprzednich projektów mieliśmy dość poważną awarię poczty, gdy źle skonfigurowany moduł sprawdzający zaczął odkrywać obraźliwe treści w losowych sekwencjach znaków (w nieokreślonej zawartości archiwów ZIP).}

W porównaniu z przekazywaniem zwykłego tekstu, Gvdl , kodowanie ma znaczną zaletę polegającą na tym, że w pełni unika się problemów prawnych i wszystkich związanych z tym zagrożeń i zależności .

Pomyśl o tym. Powiedzmy, określone warunki usługi w danym repozytorium zezwalają na moje treści, w porządku.

Ale co, jeśli zdecydują się zmienić TOS ? Lub co jeśli zdecyduję się zmienić na inne repozytorium, mając niezgodne warunki. Co ja mam zrobić?

Zauważ, że nawet przebywanie w „przyjaznym” repozytorium, tu i teraz, wciąż nie jest w pełni bezpieczne.

Co się stanie, jeśli ktoś nie będzie mógł pobrać mojej zawartości z powodu dziwnego filtru internetowego ? Czy jestem gotów odpowiedzieć na skargi użytkowników i wyjaśnić, jak naprawić filtr? Ich filtr ...

... Widzisz, wolę przemyśleć dwa razy, zanim zdecyduję się nie kodować. I nawet jeśli zdecyduję, upewnię się, że mam bardzo, bardzo dobry powód.