I would have said "why bother" until this happened to us.
A customer rang us up in a fury because some demo/ random data that we generated happened to have the word "penis" in it. They were convinced we must have put it there because we thought he was a cock. It was very difficult to defuse the situation.
[0] https://en.wikipedia.org/wiki/French_Connection_(clothing)
I was doing a student event when I saw someone wear "K1SS MY 4RSE". I told him "What an obnoxious hoodie.". He meekly said "I thought it said 'Kiss my force'.". I later saw him in a corner praying. I should've asked him what Allah would've thought about him talking to him wearing that hoodie.
Aah, the good ole "one customer is unhappy, let's waste a week of time on this" approach to IT management. Takes guts to tell such customers "here's your refund, now piss off", but it is the right thing to do.
It's a simple solution. Sure, it is still possible for something to slip through that looks similar to something bad. But the potential to strongly offend is greatly reduced.
Also note that if you're too naive about checking for 'naughty' words, you get https://en.wikipedia.org/wiki/Scunthorpe_problem
> algorithm tries to avoid generating most common English curse words by never placing the following letters (and their uppercase equivalents) next to each other:
> c, s, f, h, u, i, t
https://hashids.org/#how-does-it-work
E: ah it was already mentioned later on, hadn't got that deep into the comments yet!
What is 'v' in this context?
Edit: thanks for the answers. It makes sense now.
the combo "cv" could then become problematic.
Edit: But I'll concede that when your outputs are only four characters long and end users will actively interact with them (write them down, type them again later, etc.), additional safeguards might be appropriate. Or simply omit all alphas and use only numerics.
You're still not out of the park with numerics - people with 1313 or 6660 or 4444 or something will complain a lot. The possibility of a 666 in some new biometric government IDs in my country rose a massive stink from church...
Yeah. An important, long-lived ID that will stick with an individual for their entire life, and that they may want to commit to memory. That seems like a good time to take a hypersensitive approach and adopt some kind of filter.
Also, have a feelin you meant to do 1312. What’s the issue with 4444, though?
> When Beijing lost its bid to stage the 2000 Olympic Games, it was speculated that the reason China did not pursue a bid for the following 2004 Games was due to the unpopularity of the number 4 in China. Instead, the city waited another four years, and would eventually host the 2008 Olympic Games, the number eight being a lucky number in Chinese culture.
Thought this was particularly interesting.
> What’s the issue with 4444
4 is pronounced similar to "death" in sino-japanese languages and dialects.
That works pretty well until you realize that some numerical combinations are common neo-nazi codes and may lead to ... unfortunate associations. The ADL lists a few of those^1, but the list is by far not comprehensive, codes actually differ based on locality, and accidental combinatory collision in a 10-character space than it is in an alphanumerical 36-character space.
[1] https://www.adl.org/education/references/hate-symbols/88
If the string is a url, imagine sending https://somesite/wanker to your client, when it actually could also be https://somesite/ay3ugd
It's random, I swear!
Edit: I'm being downvoted so I want to explain - the internet is a huge mishmash of different cultures and all I wanted to say is that it is allowed to swear because I though that maybe, in their local one, it is not and they think it's universal
It worked surprisingly well when we used it.
And this, ladies and gentlemen, is what it would show BEFORE the filter... but after (runs the code again, and prays it works) ... NO PROFANITY!
"Had we not done this work, that link would have been sent out to one of our users." was very well received.
Our main concern was whether we needed to increase the size to 26 to account for the loss of keys. After doing the math, a 25 digit random string has a ~5% chance of containing one of 150 three or four character inappropriate substrings. That 5% loss isn't that big of a deal. But we had to figure out the math as part of due diligence before shipping.
The hardest problem with the implementation was that with a long list you can't just search for a few dozen inappropriate words (like the Twitch implementation). It would be very expensive to do hundreds or even thousands of checks against every inappropriate word.
The solution we came to was to truncate all the inappropriate words to either 3 or 4 letters and store them in a big set. We then take our generated strings, which are usually 11 characters, and break them up into all possible substrings of lengths 3 and 4. For example, 1a2b3c4d5e6 would be broken down into 1a2 a2b 2b3 b3c 3c4 c4d 4d5 5e6 1a2b a2b3 2b3c b3c4 3c4d c4d5 4d5e d5e6. An 11 character string would always have 16 such substrings. We then check all 16 against the banned set. 16 lookups into a set is pretty cheap and as we have expanded the word set over time (e.g. add a new language) our performance hasn't changed.
One drawback to our approach is that we do have false positives but we did the math and our space was still large enough, the cost of generating a new one was pretty low, and customers never see it so it's just not a big deal to throw out false positives.