On "whitelisting" and "blacklisting"

As a straight white guy from middle-of-nowhere Tory Brexitland I'm sure I am supposed to say something about political correctness gone mad, but this is worth a read and makes some fine points. Upshot:

It's fairly common to say whitelisting and blacklisting to describe desirable and undesirable things in cyber security. For instance, when talking about which applications you will allow or deny on your corporate network; or deciding which bad passwords you want your users not to be able to use.

However, there's an issue with the terminology. It only makes sense if you equate white with 'good, permitted, safe' and black with 'bad, dangerous, forbidden'. There are some obvious problems with this.

I agree.

From now on, the NCSC will use 'allow list' and 'deny list' in place of 'whitelist' and 'blacklist' on our website.

I propose not referring to notional "lists" at all. This will invariably make your writing clearer.

Let's take an example from the article. "An allow list of applications" is clumsy (let alone the alternative form, "an allow listed application"). It is much terser and accurate to refer to "trusted applications" for ones you know to be good, and "malicious" for ones you know to be bad. No lists required! (Adjust the terminology to your use case as required.)

For the example of passwords, of course you only ever check against a list of known-compromised ones; you certainly don't have a list of ones that are safe to use. Again, you can almost always get rid of notional "lists". Some examples:

• This password is blacklisted 🡒 This password is known to be weak
• This function checks the given password against a blacklist 🡒 This function checks if the given password is known to be weak

It is fine to refer to lists when there are actual lists; if your program is supplied with or downloads a set of textual rules for allowing & denying access to something, for example. Here again, though, you are discussing an implementation detail rather than what actually happens, which is generally not good form in anything but documentation dedicated to discussing implementation details.

I am reminded of a ticket from a few months ago in the Django project:

We'd like to add aliases for the trans and blocktrans template tags which do not have connotations to the transgender community. An initial proposal would be to add translate and blocktranslate as aliases.

The lazy counter to this would be that "translate" shares the same "trans" root as "transgender", and who is to say that it's only a valid contraction of one of them?

I say "lazy", because the reporter handed the Django a great opportunity for improvement: why pick a tag name like trans when it could cause confusion with something else? Even when there is no scope for confusion, we're not limited to MS-DOS filenames these days (and don't get me started on "i18n"). You can and should use whole English words; {% translate %} makes for better and clearer code than {% trans %}.

You should definitely improve your terminology to be more inclusive - it's a low-effort way of making the world a little bit better. And do use that opportunity to write stronger and more clearly while you are there.