They say they want your phone number to enhance your security.
Then they sell it to advertisers.
Two-factor authentication is hardly a phrase to set your pulse racing, but it’s the latest craze in the tech world. It even has its own TLA, (that’s an acronym for Three-letter Acronym for all you non-geeks), namely “2FA”.
Passwords don’t work because most people are idiots. Wikipedia even lists the most common passwords year by year. It shows the passwords “password” and “123456” have vied for the top slot for the last seven years running. If your password happens to be on the 2017 list, I refer you to the start of this paragraph …
Passwords are essentially “1FA” – one-factor authentication – which is to say, something only you know (hopefully). The three “FA” levels are often put like this:
Something you know: like a password.
Something you own: like an access card or a mobile phone number.
Something you unique to you: like a fingerprint or a retina scan.
Obviously, two factors are better than one. If your Gmail password is stolen for example, how do you prove it to Google? Clicking the Send Me a Password Reset link is pointless as they’ll just email the link to the account you can no longer access. But if your 2FA is a mobile phone number, they can send you a reset code that you can enter online and take back control of your account.
(Yes, your mobile phone number really is unique since it’s prefixed by a country code.)
There are other uses for 2FA too. I sincerely hope your bank uses it before granting you online access to your accounts. The most common “second factors” here are the Entrust Datacard or Vasco’s Digipass.
So all in all, 2FA is a Good Thing.
It now appears that Facebook are taking your second-factor ID (your mobile phone number) and adding it to the bundle of personal information they sell to advertisers. According to this report from the Electronic Frontier Foundation, the number you give to Facebook for security purposes “can become fair game for advertisers within weeks”.
It’s important to stress that this is NOT a problem with two-factor authentication.
[T]his is a problem with how Facebook has handled users’ information and violated their reasonable security and privacy expectations.
Partway through a big compile, the process died with “No space left on device”. Aaarrgh! What to do?
The Pi had an 8GB card and check with df -h showed this:
Filesystem Size Used Avail Use% Mounted on
/dev/root 7.2G 6.8G 34M 100% /
So that’s me stuffed. Or is it?
Use a bigger memory card; 16GB, 32GB … Yeah, great. I’m 30% through a compile based on a complicated setup using lots of downloads and additions. Either I’d have to start again from square one or image the existing card and copy it onto the new one. Helluva hassle. Besides, first I’d have go out and buy a new card. Not an option.
Want to make a fortune in IT? Simple, sell a system to the New Zealand Police.
Whoa! you’re thinking. The police? Is he nuts?
No, seriously, those guys will buy anything. Back in 1999 they paid $100 million for “little more than a highly expensive e-mail system and a number of terminals”, and last week it was revealed that they’ve blown $56 million on a new human resources and payroll system. What’s more, it’s still not ready, and the delay is costing a further $2 million a month. (Not ready? I hear your say. An IT project not delivered on time? Does that ever happen, anywhere…?) It’s now due for completion in September, by which time it will have cost $64 million.
The INCIS project, for anyone who cares to remember it, has its own Wikipedia entry and occupies a key chapter in the book Dangerous Enthusiasms: E-government, Computer Failure and Information System Development, by Robin Gauld and Shaun Goldfinch, (Otago University Press, 2006, reprinted 2012). As an Integrated National Crime Investigation System, it was going to be a world-beater, and the money flowed into it like water for five long years.
I had a former colleague splashing about in those waters back in 1998. I remember him boasting he was earning $85 an hour for reading the project’s spec. It took him months. Why? Because the original specification was 4,000 pages long. Yes, 4,000 pages. I heard there were a further 2,000 pages of amendments.
If you have a problem getting your head around documents of that size, remember that a ream of regular office paper (500 sheets) is about 5cm thick. So placed on your desk, the original spec would have measured 40cm (16 inches) high and weighed at around 19kg – without covers or binding. Or the amendments.
How do projects get so ridiculously out of hand? Three words: IT project managers. It’s that simple.
I’ve spent 25 years in IT, and in all that time I’ve worked with two, maybe three, competent project managers both here and overseas, on large projects and little ones. All the other PMs I’ve encountered have been bunnies, ranging from gullible fools unable to read a Gantt chart through to the wilfully malicious, there to parrot whatever senior management wants to hear1 while padding out their own fat contracts.
But how do you spot a BPM (Bunny Project Manager)? After all, the whole profession is based on the ability to give glib answers and make calming predictions about deliverables based on no data at all.
One simple technique is to employ what I modestly call the Palmer Protocol: just drop the name Fred Brooks into the conversation, or make a passing mention to mythical man-months. If you’re met with the question “Who does he play for?” or a straightforward bewildered look, run for it!
More than 40 years ago, Fred Brooks2 wrote the book on IT project management. Literally. His slim volume, The Mythical Man-Month: Essays on Software Engineering, was first published in 1975 and is still in print. In it, Brooks reflected on his experiences working on a Really Big Project – the programming behind IBM’s OS/360 mainframe operating system – and all the mistakes he observed.
In The Mythical Man-Month, he describes what’s become known as known Brooks’ Law, the somewhat counter-intuitive, “Adding manpower to a late software project makes it later.” The reason it does so is because complicated programming projects can’t be broken down into discrete units and farmed out to individuals, but most BPMs still operate on the basis that they can.
The rationale goes like this. If one man can cut an acre of wheat in a day, then ten men can clear a ten acre field in a day. And they can. But cutting wheat isn’t cutting code. Programmers need to communicate with each other. Adding new staff – no matter how competent – means that your existing, already over-taxed staff have to take time out to bring them up to speed and then keep everyone updated with each others’ progress. There’s even a simple equation for calculating the effect, called the group intercommunication formula, where n is the number of staff:
n(n − 1) / 2
That means that a ten-person team will have 45 channels of communication [10 x (10 -1) / 2], while a twenty-person team will have 190. 30 people will have 435 channels, 40 people, 780, 50 people, 1,225, and so on.
The book is filled with other observations, still timely 40+ years on. There’s the Second-System Effect – “the tendency of small, elegant, and successful systems to have elephantine, feature-laden monstrosities as their successors due to inflated expectations.” There’s the tendency towards an irreducible number of errors. (All complex systems have bugs, but after a certain point, squashing them simply results in more bugs.)
Then there’s progress tracking. “How,” Brooks asks, “does a large software project get to be one year late? Answer: One day at a time!” Incremental slippages accumulate, eventually producing a large overall delay. It’s the project manager’s job to set small individual milestones and ensure they’re met.
At the end of the book, Brooks makes a couple of suggestions for lowering software development costs. Both seem obvious, but as we all know, commonsense isn’t common, particularly amongst BPMs.
The first says don’t hire implementers until the architecture is complete. (My spec-reading former colleague was a programmer, but the bit he was supposed to working on wasn’t ready.)
The second – and here one wonders how uniquely complex the NZ Police’s payroll and human resources needs really are – is even more obvious. Don’t develop software at all, just buy it “off the shelf” wherever possible. At $64 million, (and it will almost certainly come in higher than that), the NZ Police could have bought the whole damn store.
1 One report into the INCIS systems’ prospects reckoned that Police would save $517 million over 8 years in “efficiency benefits” – whatever the hell they are.
2 Fred Brooks’ book has been called the Bible of Software Engineering because, he reckons, “Everybody quotes it, some people read it, and a few people go by it”.