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.

“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.