documentation is thoroughly hard
Documentation is good, so therefore more documentation must be better, right? A few examples where things may have gotten out of control.
more...
Documentation is good, so therefore more documentation must be better, right? A few examples where things may have gotten out of control.
more...
Why don’t unix commands have any vowels in the name? cp and mv are obviously devoweled standins for copy and move. But they’re less intuitive for new users. The user wants to copy a file. Why shouldn’t the name of the command be exactly the operation the user wants to perform?
What exactly does the user want to do? Instead of copying files, maybe I want to link two files. What does that mean? In unix, we have hard links and symbolic links. If I replace the “original” file, do I want the link to refer to the original file or the replacement? Or maybe what I mean by link two files is to combine two object files into an executable. Do we call that loading instead? ln is the name of a command, but link is the name of a concept. And sometimes the concept evolves over time. The linker is called ld because it used to be the loader. (I think.)
grep is a remarkably useful tool, but with a most unintuitive name. Why not call it find like Windows does? I want to find some text, I run find. So obvious. But some users may want to find files in the filesystem, not strings in a file. What command do they run? Probably locate.
There may be a great deal of historical accident in the names of commands (what if the inventors of awk had different initials?), but that doesn’t mean we can’t recognize the value of unique and precise identifiers.
Yes, actually harmful.
The file utility can be useful. Don’t know what program to open a file with? Run file and it will tell you. Of course, sometimes file will be wrong and misidentify the file type. This may be inconvenient, but at least as a user you still have the option of trying to run another program.
Except when you don’t. What happens when file (or its programmatic buddy, libmagic) is not a hint, but a gatekeeper? What happens when some application determines its behavior based on the output of file?
What happens is you can’t print on Tuesday.
Or you can’t print particular documents that contain inappropriate phrases.
Or you can’t launch a browser and consequently prevent Firefox from providing ASLR enabled builds.
Something tells me these won’t be the last three bugs.
A program that helps users is useful. A program that restricts users is harmful. Run file on your computer all you want, but don’t use file to limit what I can do.
For the past few months, my iPhone has had a peculiar bug. Apple services didn’t work in my house. I could listen Amazon music, but not Apple music. I could update my Facebook status, but not the Facebook app itself. I could read Apple’s website and learn about security updates in the latest version of iOS, but not download them.
more...
Ripped straight from the headlines, thrilling tales of things gone wrong because nobody asked for things to go right.
You may not write assembly, but you probably use libraries from people who do. Did they remember to insert the right magic flag?
ImageMagick can and will do lots of things you neither expect nor desire. Unless, of course, you configure it otherwise.
When using node.js and socket.io, don’t forget the default is unverified sockets.
By default, Telegram uses a sophisticated identity verification system known as text the user.
If you really don’t want logging, say nop nop nop three times.
Remember, it’s all there in the manual if you just take the time to read it. Tune in next week to learn what other documentation you should have read!
Personal thoughts. To each their own.
more...
A few grumpy remarks about the amazing tale of Slack bot tokens on GitHub. Auth tokens used for business accounts get committed into Jurassic Park quote bots saved on GitHub, allowing random passersby to eavesdrop on your paradigm shifting startup’s latest pivot? That didn’t happen back in my day! Of course, since then multiple changes have combined to change the world. A perfect storm of convergence and disruption.
more...
What is a name, really?
more...
In addition to earbuds, I have a tendency to lose padlocks. As a result, I tend to go through more of them than I should. Note to locker designers: place the loop on the inside frame instead of on the outside of the door so that after I open the door, I have somewhere to hang the lock where I won’t forget it.
Cheap combo locks have never been that secure, but since things have gone from bad to worse, I figured I’d try a new lock. Enter the Master Lock Speed Dial.
Instead of numbers, the combination is a sequence of cardinal directions. The packaging promises I can pick any combination of any length, though I doubt they have really invented an infinite data storage device. The default sequence length is only four inputs, which is far too short for my comfort and they should recommend at least eight. 4^8 combinations just tops the 40^3 of a very precisely machined 40 digit combo lock (to say nothing of less precise models). Despite the length, with very little practice it’s easy to enter the combo quickly and accurately. Trying to spin a dial too fast I would frequently over rotate and have to start again. The speed dial can be consistently unlocked one handed in about five seconds.
Programming the lock is a little weird and error prone. The sequence of unlocking, resetting, and locking must be performed in exactly the correct order or you get a lock with the wrong combo. Or no combo! Fortunately, this video explains two common mistakes, which I definitely experienced first hand.
For a look at the insides of the lock, this video reveals a little more about how it works. Also a toool.nl PDF.
Initially, the lock was very stiff to open. I couldn’t tell if I’d done the combination right or not (pretty important right after purchasing), but after some use it pulls open much more readily. On the downside, the casing is rather large and won’t fit everywhere that a smaller lock is expected to.
There’s a widespread belief that validating user input prevents security vulnerabilities. This is true as far as it goes, but doesn’t tell the whole story. Consider the following example, distilled from any number of real world examples.
if (!valid_input(buffer)) {
free(buffer);
error = BADSTUFF;
goto ungood;
}
error = process_input(buffer);
ungood:
free(buffer);
return error;
A not uncommon mistake. A vulnerability report may, quite accurately, say something like “Invalid inputs may result in remote code execution.” However, further input validation won’t fix this bug, nor will tweeting “This is why you always validate your inputs!” prevent future occurrences.
Lots of problems may share similar or even identical descriptions without sharing fixes. It’s a small point, really, but no less important. And of course, hardly limited to the field of security.