About

I'm Mike Pope. I live in the Seattle area. I've been a technical writer and editor for over 35 years. I'm interested in software, language, music, movies, books, motorcycles, travel, and ... well, lots of stuff.

Read more ...

Blog Search


(Supports AND)

Feed

Subscribe to the RSS feed for this blog.

See this post for info on full versus truncated feeds.

Quote

It’s [an editor's] job to make writing clear and effective, but I don’t think it’s necessarily our job to hold the line against changing usage or to defend the language from its own users. That is, nobody hired us to be in charge of the English language.

Jonathon Owen



Navigation





<February 2025>
SMTWTFS
2627282930311
2345678
9101112131415
16171819202122
2324252627281
2345678

Categories

  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  

Contact Me

Email me

Blog Statistics

Dates
First entry - 6/27/2003
Most recent entry - 9/4/2024

Totals
Posts - 2655
Comments - 2677
Hits - 2,727,093

Averages
Entries/day - 0.34
Comments/entry - 1.01
Hits/day - 345

Updated every 30 minutes. Last: 8:29 PM Pacific


  08:22 AM

Not long ago we were working on some security documentation, where one of the writers had written about a whitelist. This term was created by analogy to blacklist. In the context of security, a blacklist contains a list of terms or entities that you want to disallow (block). A whitelist, in contrast, contains a list of only the terms or entities that you will allow. (Whitelists are considered more secure, because it's almost impossible to define a blacklist that will anticipate — hence block — all the entities that malicious users might try to attack your site with.)

Our style guide (MSTP) is unequivocal about the terms blacklist and whitelist: "Do not use." They insist that we write around the terms, using alternatives like these:
  • Blocked Senders list (for blacklist)
  • Safe Recipients list (for whitelist)
  • blocked or safe programs
The style guide doesn’t explain its recommendation. It's not like the terms are unknown in the industry; whitelist gets more than 8 million hits on Google. In fact, it's arguable that whitelist is a more recognized term than the recommended alternatives:

Us: This program lets you define a safe senders list.
Them: Do you mean a whitelist?
Us: Yes.
Them: Then why didn't you say so?

The ban is instead for geopolitical reasons. The term blacklist has various unsavory connotations anyway, but the real problem is that the terms whitelist and blacklist suggest a dichotomy in which white=safe/accepted/good and black=unsafe/undesirable/bad. One of my writers raised a mild objection to this, arguing that the audience for our security documentation would not infer any sociological undertones from its use.

Maybe. It's always a tough argument to make that other people won't interpret something in some particular way. But anyway, you can see why as a corporation we want to stay well away from anything like this that might raise unsavory issues.

But that puts us in a bit of a dilemma. The fact is that because the term whitelist is well known in the industry, people will search our documentation for it. And if the term never appears, what then?


P.S. The style guide does not appear to have an entry for white-hat hacking (versus black-hat hacking). I guess that doesn't come up enough to warrant its own entry.

Presumably because no color-based dichotomy is implied, it is not adamant about other color-based terms. For example, it does disrecommend the following, but only because they're jargon:
  • black box ("a unit of hardware or software in which the internal structure is unknown, but its function is documented")
  • black hole ("a condition of an internetwork where packets are lost without an indication of the error")
And of course there's no issue with white space.

[categories]   ,

[4] |