Microsoft suggests Chromium team to get rid of "potentially offensive terms” such as “blacklist”

Reading time icon 2 min. read


Readers help support MSpoweruser. We may get a commission if you buy through our links. Tooltip Icon

Read our disclosure page to find out how can you help MSPoweruser sustain the editorial team Read more

Ever since Microsoft announced that they will be switching to Chromium, they have been actively contributing to the framework. Around a month ago, Microsoft announced that they have identified the root cause of battery drain on Chromium-based browsers and is working on fixing it.

Now, Microsoft is urging the Chromium team to get rid of “potentially offensive terms”. Microsoft has already filed a bug (via ReclaimTheNet) on the Chromium website indicating their desire to do away with words like blacklist and whitelist. The Chromium team has welcomed the idea with open hands and is currently working with Microsoft to improve the language used in the codebase.

This sounds like a good strategy to me, thanks for doing this! We certainly have never intended for anything in the codebase to be potentially offensive, but I’m also not aware of anyone making an effort to find them all.

In particular, I agree that non-behavior-impacting changes should be non-controversial and pretty easy to quickly get through code review without debate over whether some word is “potentially offensive” or not. If it’s on the standard Microsoft list, then that’s “potentially” enough for me – at least for anything in platform (content, blink, etc.), I can’t speak for //chrome code myself.

Of course behavior-impacting cases like UI and command-line flags will require a trade off to be made of some sort, so separating those out and discussing the trade off on a case-by-case basis sounds right to me.

– Google

While scrubbing off old “potentially offensive” words is certainly not a priority for companies, it’s good to see that both Microsoft and Google are making an effort to improve the codebase. We expect Google to make changes to the codebase slowly as one wrong move can break the code.

User forum

0 messages