Ten Problematic Tech Terms

The tech world has been a-buzz recently. Following the Black Lives Matter riots across the USA, some tech firms have declared their intention to help eradicate racism - by erasing problematic language from their code bases. The overall objective is to be inclusive and avoid insensitive references.

How this is going to help exactly, remains a mystery to many of us. It's tempting to simply dismiss all this as just another poorly-disguised attempt at virtue-signalling. But in the spirit of joining in the fun, let's take a look at some of the terms slated for erasure and their proposed replacements. And some terms that haven't yet had the dubious honor.

1. Master/Slave

This term is used in tech to describe situations where one process or entity controls another, or where one is an original and the others (the "slaves") take reference from it. Ostensibly, tech such as GitHub, Python and Twitter (and even MySQL!) have decided that they will no longer use the terms "master" or "slave" in their code repositories. Instead, terms such as "main" and "replica" will be used.

No more master-slave relationships!

It's a bit of a stretch of the imagination to equate a "Master" branch in GitHub with slavery, but what do I know, right? I'm not a marginalized race in the US. Hell, I don't even live in the US!

2. Black/White

Google claims that the terms "blacklist" and "blackhat" have negative connotations associated with the color, and this is somehow denigrating African-Americans. Instead, we should be using terms such as "rejectlist" and "allowlist" to replace "blacklist" and "whitelist", respectively.

We can't be blackhats
anymore?

To be fair, "rejectlist" and "allowlist" are a lot more obvious than "blacklist" and "whitelist". It's objectively a good change. I just think the reasons behind it feel kind of forced. It's almost like someone's trying a little too hard not to offend black people.

3. Chief Technical Officer

Hey, how about "Chief" Technical Officer? Or "Chief" anything? Isn't that insulting to Native Americans who actually earned that title? Non-native Americans, you can do better.

So Sioux me!

Native American cultural appropriation is a real thing, yo. Just ask Chris Hemsworth.

4. Ninja

Eradicating the word "ninja" from tech vocabulary will be welcome. That's also cultural appropriation. Imagine how the real ninjas feel, having that term co-opted by a bunch of computer geeks who probably couldn't throw a shuriken worth a damn.

Won't someone please
think of the ninjas?

Also, it's incredibly lame to describe yourself as a "code ninja". Please just fucking stop.

5. Kanban

Another case of cultural appropriation. The Kanban was originally used in manufacturing operations in Japan. Then this got taken to the USA, and some time later, the tech industry took to using this to manage software development processes. We can still use Kanban boards, though maybe we should start calling them something else?

Yeah, call 'em something else!

I seriously doubt the Japanese are anything less than smug that the Kanban got adopted by the Americans. But wait... does this whole movement actually have anything to do with the feelings of other cultures, or is it just an excuse to make tech companies feel all progressive and shit?

6. Sanity Check

The term "sanity check" is usually in the context of testing. However, the word "sanity" might be sensitive to people who suffer from mental illness. I'm no expert here, and far be it for me to sound unsympathetic, but could that be because they suffer from mental illness?

Who're you
calling insane?!

The term "smoke test" has been suggested as a substitute. But it appears that the term already exists, and there's actually a difference. You know what, this is crazy (no pun intended) and I'm just gonna let the experts sort this out.

7. Dummy

A "dummy" anything is usually used in software development as a stand-in for the real thing. A dummy account. A dummy file. Dummy content. Just like crash-test dummies are used in place of real people.

I surrender to the awesome power
of your Wokeness.

But no, what if it triggers people who are, say, not the brightest bulb in the chandelier? We want to be inclusive, right? Twitter has suggested "placeholder", which actually isn't that bad. Unlike the case of "blacklist" and whitelist", however,  the term "dummy" was actually pretty obvious already and I don't think it needed changing.

8. Throttling

In software, "throttling" is the process of regulating the rate of processing, because sometimes you gotta slow stuff down in order for things to go smoothly. After all, resources are limited, and we don't want the system to bite off more than it can chew.

Just choking, folks!

But geez, this term is just so violent. It brings to mind wringing of necks and MMA chokeholds. Why such a hostile term? How about "hugging"?

9. Penetration Testing

This is actually a term used in computer security, to assess the defenses and robustness of any particular system. But it's kind of lewd, isn't it? Penetration?

Such penetrating insight!

Think of all the locker room jokes we computer nerds could make if this term were still in use. How about we just scrap it so people don't feel, y'know,  uncomfortable?

10. Alpha/Beta

Alpha release. Beta release. These terms are commonly used to describe software versions. You know what else they're used to describe? Males.

That's Alpha AF.

Maybe usage of this term encourages toxic masculinity. Should we chance it? I mean, if we're going to deprecate the use of "master" and "slave", surely this is next!

Conclusion

Yes, I'm being really facetious here. But let's be real for a minute.

Naming things is one of the great struggles of software development. Congratulations, we just made it a whole lot harder.

It's not that I think tech terms are set in stone and shouldn't change at all. Obviously, some change is for the better. Even more obviously, it would be better if they were done for the right reasons. If done to improve clarity or sustainability of maintenance; some objectively beneficial metric, yes I'm all for it.

But if it's done just for the sake of appealing to the Social Justice mob, I think it's ill-advised. Because there's no end to this sort of thing. People are always going to be offended by something or other. The world doesn't revolve around the USA and their great struggle with racism and their history as slave-owners, and it's time people realized that.

Now that's a master main stroke!
T___T

Tech Terms and why we should use them right

Tech is full of terms specific to the industry only. Buzzwords, jargon, phrases - they're all part of the tech terminology. Terminology is important.

Years ago, I was in a company that used Team Foundation Server (TFS) for version control. I never knew what it was called. Sure, I knew that it was called "TFS" and that I had to check in my code after I was done with it, but I never knew the specific term for this. And it came back to haunt me years later when interviewers asked me if I had ever used a code repository. It never occurred to me, until much later, that a "code repository" was this thing called "TFS" which my team used to collaborate on code, and check on different versions of the code base. I had been using it for a year and didn't even know this much! All I had been doing was working day in and out without any thought to the larger picture. Like it or not, this suggested a lot of things about my professionalism, none of them particularly flattering.

This is not the only example. For years, I worked on CSS without understanding the term "CSS Box Model". I wrote code in a certain way to guard against threats, not knowing what I did was "whitelisting". And I never knew my preferred style of placing curly brackets was known as the K&R style. I just wrote code, and I knew it worked. End of story.

See, this is why terminology is important. Using the correct terms puts you in the same league as the professionals. You share a language. Instant cred.

This is a double-edged sword, though...

The problem with instant cred

You see, plenty of people have figured out the path to "instant cred" too. Pepper their dialogue constantly with tech buzzwords that ultimately don't mean anything in the wrong context. Drop jargon like it's going out of fashion. Join conversations they have no business joining because they haven't done the damn work. These are the pretenders who are trying to sound like they know the industry without having worked a single day in it. They don't have to know anything; just sound knowledgeable.

"So we simply need a Separation Of Concerns in order to follow the Don't Repeat Yourself Rule and Stand On The Shoulders Of Giants to avoid Duplication of Effort."

Feel nauseous yet?

*urk*

When I was younger, I tended to think the world was full of these snake-oil salesmen. In fact, anyone who used terminology too liberally, was immediately classified as some poseur who was trying way too hard to impress people. Maybe get promoted to management or something.

Well, I wasn't completely wrong then, but neither was I completely right. The world is full of these poseurs. But that does not negate the importance of using the right terminology.

Earlier this year, I talked about the difference between parameters and arguments. A lot of techs I know like to say things like "pass in those parameters to the function", which is incorrect. These techs aren't stupid or incompetent; but like me, their training was not totally structured. Whatever we knew, we picked up along our career paths. Bits and pieces of a large scattered picture. The correct terminology wasn't important as long as we understood each other.

To some extent, that works. But it's hard to be effective at what you do if you can't communicate, and you can't count on being in the same team all your life. You will work with other teams who will use the correct terminology, and you will end up confusing the living heck out of each other.

Being pedantic much?

No, I'm not advocating being pedantic at all. In fact, I have nothing but disdain for people who keep correcting me to nitpick on a word I might have incorrectly used when trying to explain a concept, especially when they know damn well what I meant.  Collect your achievement award and get over yourself, why don't you?

But making an effort to use the correct terms is important because it tells people you're not a total idiot. Especially when you're not a total idiot. Don't let a couple of incorrectly used words detract from the brilliance of your ideas. That's all I'm saying.

Using the correct terms gives you insight into the bigger picture. It makes you think about what you're doing instead of simply doing it, which can be dangerous.

Don't take things to extremes though...

There's a happy middle ground in all of this. You don't have to drop buzzwords just to show people you know your shit, but you do have to understand technical terms because, ultimately, they're one of the things separating you, the professional programmer from the rest of the garbage.

The solution to this? Don't just code. Read. Question. Learn.

Till next time, one good term deserves another!
T___T

No Internet for Public Sector?

Come July 2017, all public service computers will be detached from the internet.

Much has been made of the hubbub surrounding Infocomm Development Authority of Singapore (IDA)'s controversial decision last week. Shots have been fired, and a new waves of memes circulated.

Courtesy of SGAG

I have refrained from commenting thus far because it is way too easy to get caught up in criticizing the Government (not that they don't deserve it) before one has all the facts. And because - bear with me here - this might not be as crazy as it sounds.

Public servants still get to use the Internet - through use of their personal handheld devices and specially designated workstations. The aim is to keep the Internet separate from the government's Intranet, which doubtlessly contains all manner of data no mere mortal should ever access.

The technique in question here is called "air-gapping", and it is not in the least new. Singapore's certainly not the first nation in the world to do this.

The public fallout was fairly predictable. There were cries of derision pointing to Prime Minister Lee Hsien Loong's speech about a Smart Nation last year.  There were concerns about what such a drastic gesture might mean for those in Public Service. And noticeable silence from pro-Government fanboys who probably quietly worried if their idols were going bonkers. Laymen were, for the most part, appalled.

Reactions of those in the IT Sector were somewhat mixed, with some lambasting the Government for "stupidity", others reacting with approval. But from those in tech security, I have seen little comment. Were they, like myself, reserving judgment? Or did they know something the rest of us don't?

This brought to mind an episode I recently had with a hacker buddy. I had set up a website and was boasting about the security features I had set in place, and the cheeky fellow had bet me fifty bucks that he could bypass them all to hack my database. I upped the ante to a hundred bucks, and it was on. Within a couple hours, my friend admitted defeat and asked me what database I was using.

"None," was my innocent response. "This is a static website."

The murderous look on his face is something I remember fondly.

But isn't that the essence of all zen-like chop-cocky martial arts flicks? Meet an incoming force, not with resistance, but with emptiness. The Empty City Strategem. And all that crap.

Feel that emptiness yet?

Long story short - if you know it's a game you can't win, make sure you don't ever need to play that game. Which is why aging footballers leave the Premier League and go to MLS - physically, they can't compete on stamina and strength with their younger counterparts any more. Which is why I never negotiate during a job interview - not only is haggling beneath me, I cannot hope to out-haggle professionals whose main skillset is haggling. Play the game you're good at. Don't play the game you will lose.

Because cyber-security is a game one is doomed to lose at some point or other. You can only defend against an existing and known threat. Which means the threat will always exist before the solution does. Which, in turn, means that you're always playing catch-up. Bear in mind that it is possible for a threat to exist long before it makes itself known - probably by compromising some poor sod we hopefully don't care about.

How about other measures?

Of course, there are a multitude of other measures the Government could take - firewalls, domain whitelists and blacklists, user training, to name a few.

But no one is suggesting that these not be in place. By themselves, all these security measures come with their own limitations. They should be in place as complementary measures, rather than primary ones.

What's your position on this?

Whoops. Rambled on a bit there, didn't I?

So, I think the Government might have something there. And the fact that they will be taking at least one year to fully implement it, shows that this decision was not made in haste.

Not that this will stop people from making fun of the Government, mind you. Neither should they. What use is a Democracy if you can't mock the people in charge, whether or not it's deserved? Jeer away. Have fun doing it! But don't imagine for a moment that buying an anti-virus software license once every year makes you some kind of expert on the matter. That is exactly the kind of mentality that gets systems compromised.

The Million Dollar Question

This is an extreme move, which will no doubt cause loads of inconvenience to employees in the Public sector. Why now? What threats has the Government encountered, to even contemplate such a move and deem it necessary?

I would prefer to trust that the Government knows what it's doing. Because the alternative is just too awful to contemplate.

Stay safe,
T___T

Data Transport Methods Across Webpages (Part 1/2)

Web developers all know that there the Internet is a stateless medium and to mitigate that unfortunate fact, there are two basic ways of transporting data across pages - GET and POST. While this is bread-and-butter stuff for all who deal with the web, ultimately not every developer understands GET and POST as well as they should, mostly operating on a vague understanding of which to use, and when.

And that is why, today I'll be dealing with both cases.

The GET method

The GET method is the default way of transporting data. In a HTML form, if the method attribute is not specified in the form tag, the browser automatically assumes a GET. Here's an example. Pay attention to the form tag.

<form>
    <input name="x" value="test">
    <input name="y" value="12345">
    <input type="submit" name="btSubmit" value="submit">
</form>

is the same as

<form method="GET">
    <input name="x" value="test">
    <input name="y" value="12345">
    <input type="submit" name="btSubmit" value="submit">
</form>

The GET method of transporting data basically embeds the data in the URL in data-value pairs separated by ampersands. Assuming that this form is in a page named tt_test.asp, submitting the form would give you a URL of:

tt_test.asp?x=test&y=12345&btSubmit=submit

This also means that you can use the GET method to transport data without using a form.

Pros

Quick and dirty - As mentioned, you don't need a form to send data via the GET method. You merely need to formulate the URL properly.

Caching - Since GET is essentially a URL, it follows that pages generated from the GET method may also be cached, and this shaves valuable time off page loads. URL caching in turn facilitates pages generated using the GET method being crawled by search engines, which leads to better Search Engine Optimization. And this is the one thing that cements GET its place as a viable method of data transport despite its obvious inferiority to POST in many areas.

Cons

Size limitations - The URL can hold only that much data. Therefore using GET to send long strings of data (over 1000 characters including the URL, depending on browser) is not advisable.

Format - GET can send only text data. Even then, special characters have to be encoded. If, for example, you wanted to send an ampersand as part of your data, you would have to be very careful that the it is not mistaken as a separator.

Security - The data appears in the URL. Duh.

Use GET for...

... simple data that can be easily sanitized and whitelisted.

... data that does not need to be private.

Do not use GET for...

... data that should be hidden, such as passwords.

... complex data

... long strings

Absolutely do not use GET for...

... entire SQL queries (Jesus Christ, do you have a death wish or something?!)

tt_test.asp?query=SELECT x from table_y WHERE id=3

Next

We take a look at the POST method.

Whitelisting - a Paler Shade of Security

URL parameters are an easy and convenient way for web pages to pass data to other pages. And, where SEO is concerned, it's a plus because URLs can be cached. But sometimes it can be too convenient. People tend to forget that such methods are open to abuse and appropriate measures can (and should) be taken against said abuse.

Below are some instances of URL parameters, where products is the page name, and id and type are the parameters, and "34400" and "cars" are their respective values.

products.php?id=34400&type=cars
products/cars/34400

Obviously, some of the security risks are SQL Injection and XSS. I'm writing this with the assumption that you know what that is, and on the off-chance that you don't, check out an explanation of SQL Injection and XSS.

There are plenty of ways to deal with such threats, some at script level (depending on language), some at database level (depending on database). But these aren't under discussion today, because there is a simple and non platform-specific solution at the logical level: whitelisting.

What's Whitelisting?

Whitelisting is a technique that ensures that the values of the parameters conform to a specific range of values. At its simplest, here is a preliminary example. (All examples are in PHP)

URL: products.php?id=56700

<?php
$productid = $_GET["id"];
$productid = intval($productid);
?>

The above example ensures that the variable productid, when taken from the URL, is an integer, by converting the value of productid to its integer equivalent. With this, it's not possible to enter malicious code into the parameter, and the usability of the data is preserved. If I wanted to be pedantic about this, the above could be termed sanitization instead of whitelisting.

To take this further and to see a more comprehensive example of whitelisting, see the following.

URL: report.php?month=11&year=2011

<?php
$reportmonth = $_GET["month"];
$reportmonth = intval($reportmonth);

if ($reportmonth<1) $reportmonth=1;
if ($reportmonth>12) $reportmonth=12;

$reportyear = $_GET["year"];
$reportmonth = intval($reportmonth);

if ($reportyear<1969) $reportyear=1969;
if ($reportyear>year(date)) $reportyear=year(date);
?>

See what went on there? The variables reportmonth and reportyear were forced to conform to a range of values. reportmonth had to be a value from 1 to 12. reportyear had to be a value from 1969 to the current year. This makes it impossible for the values to do any damage if written as part of an SQL string.

What if input is a string? 

Well, in that case we can't convert the value to integer. But, we can still make input conform via an array. URL: products.php?type=cars

<?php
$producttype = $_GET["type"];

$wl_producttype = array();
$wl_producttype[] = "buses";
$wl_producttype[] = "cars";
$wl_producttype[] = "vans";
$wl_producttype[] = "lorries";

if (!in_array($producttype,$wl_producttype)) $error=true;
?>

With this, we ensure that the value of producttype is either "buses", "cars", "vans" or "lorries". All else produces an error.

What if there's no range to conform to? 

That can happen, yes. If, for example, the parameter is a search string and thus can theoretically be any value, then there's no conformity to speak of. Therein lies the limitation of whitelisting. Simple and elegant, but applicable only to very specific instances such as those outlined.

Why go to that trouble, then?

You'd be surprised, though, how many web developers don't bother with this, hoping that more advanced techniques will catch any monkey business. I think that's terribly short-sighted. It's good to secure your code at a logical level to weed out any possible exceptions before letting more advanced security techniques do their job.

messagetype=goodbye&article=whitelisting
T___T