I developed an offensive content checker for my website and want to publish it on GitHub. However, the source code contains many offensive, racist and otherwise nasty content.

The source is fully documented, but I wanted your opinion on whether it's acceptable to publish such work on GitHub or whether to leave the array of strings up to the imagination of the reader?!

  • 11
    The key question is likely "is it actually offensive? or is it just a 'dictonary'?" that gets into the github TOS - §7 suggests that they may (but are not under an obligation to) remove it. You may wish to have the strings extracted to another file, that is then rot13 encrypted or something of that nature to avoid offending the causal browser. – user40980 Oct 18 '13 at 16:53
  • 1
    I'd guess it's ok, just warn possible readers in Readme, there are lot of offensive words in others GitHub Repos. Plus, your case is of good faith. – jacktrades Oct 18 '13 at 16:55
  • 5
    Why not put all the words into a text file or database and load them at runtime. Then put a nice little disclaimer at the head of the file that the text below is not for the faint of heart. Your code is clean, and you can use different text files for different situations? – Ampt Oct 18 '13 at 17:00
  • @Sparticus thanks for your comment. I agree and think that's probably the best approach for me. – SimonGoldstone.com Oct 18 '13 at 19:23
  • 5
    A word on its own is not offensive. The intention behind it makes it offensive. – kaptan Oct 18 '13 at 21:34

I have to disagree with the ROT-13 solution. Obfuscating your banned words simply because the sight of them might offend someone is a waste of time.

Your dictionary of bad words/bad-word-rules should come from a separate file anyways (which could be loaded at runtime, or embedded as a resource). Obfuscating this file simply makes it more difficult for you/other developers/your users to alter it, or fix any issues. Besides, if I saw a file called "banned_words.txt" on my hard-drive, I would expect it to contain a list of offensive words.

  • I agree. I don't want to obfuscate the words. – SimonGoldstone.com Oct 18 '13 at 19:23
  • 5
    +1 @simon Such lists already appear: github.com/snipe/banbuilder – dcaswell Oct 18 '13 at 19:26
  • 2
    @simon I didn't mean that your project wasn't worthwhile, just that github allows people to store lists like you want to. The other answer doesn't have a yes or no, I just wanted to confirm to you that the answer was actually Yes. – dcaswell Oct 18 '13 at 20:24
  • 1
    "re inventing the wheel" is part of learning... it's most of whats taught in College. – WernerCD Oct 18 '13 at 20:52
  • 2
    Sometimes you run into people with... how shall we say... delicate sensibilities who may have some influence whether the distribution of the program stays or goes. If rot13ing the file means it stays, that helps the OP achieve his goal of having his code be on and stay on GitHub. That's not a waste of time in my book. – Blrfl Oct 19 '13 at 3:03

"All problems in computer science can be solved by another level of indirection." (by David Wheeler).

Your options aren't limited to either uploading it or not, if you take into account that you can encode content so that it won't bother readers.

  • As an example, simply shifting to the next letter (A to B, B to C, etc., with Z shifting to A to complete encoding) can turn famous four letter words into totally harmless Gvdl. All you need to use it in your application would be to shift it back in the opposite direction, to previous letters, with A shifting to Z.

As pointed out in comments, an approach like the above is used in ROT13 letter substitution cipher, known for its use "as a means of hiding... offensive materials from the casual glance..."



For the sake of completeness, consider additionally running your checker against an encoded dictionary, in order to ensure that the chosen encoding didn't accidentally turn one offensive word into another.

When encoding stuff like that, it makes sense to double check, because one can't reliably predict things. In one of my past projects, we had a fairly severe mail outage when a misconfigured checker began discovering offensive content in random sequences of characters (in the uuencoded content of ZIP archives).

Compared to passing around plain text, Gvdl​s, encoding has a substantial benefit of fully avoiding legal issues and all the involved risks and dependencies.

Just think of it. Say, particular terms of service at a particular repository allow my content, fine.

But, what if they decide to change the TOS? Or, what if I decide to change to another repository, having incompatible terms. What am I going to do?

Note by the way that even being at a "friendly" repository, here and now, still isn't fully safe.

What if someone won't be able to download my content because of weird web filter? Am I willing to respond to user complaints and explain how to fix the filter? Their filter...

...You see, I would rather think twice before I decide against encoding. And even if I decide, I would make sure that I have a very, very good reason for that.

  • 6
    Rot13 is sort of the de facto standard for that. Double rot13 is even better. :-) – Blrfl Oct 18 '13 at 18:52
  • 5
    @Blrfl just like triple DES is better than DES, triple rot13 is the way to go. – user40980 Oct 18 '13 at 18:53
  • 1
    I think there are plugins for many editors that make editing rot13 files no harder than editing any other file that's in a specialized format – JoelFan Oct 18 '13 at 19:43
  • 2
    @Simon its not so much that rot13 is obscufcation - but rather just a standard way of trivially hiding the text. Realize that some firewalls may be configured to block certain character patterns making it difficult to get at your text for the program's functionality. Its not the offensiveness thats the likely issue, but the other technological hurdles that may not realize the difference between "something you want to download" and "something you want to block". Yes, they can get the zip, but they won't be able to clone or fork or push. – user40980 Oct 18 '13 at 21:21
  • 2
    @ThomasEding Caesar shift cipher by one letter. The first character is originally an 'F'. – user40980 Oct 18 '13 at 21:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.