"NSA collects millions of e-mail address books globally”
via Bruce Schneier via Washington Post.
They capture address books and contact lists in transit over unsecured or MiTMed webmail responses. Yahoo!, waaaaay too late to the game with https (come on guys!) is a prime offender, but they manage to capture Hotmail, Facebook, and GMail contacts as well.
This gets under my skin, in a way that some of the other surveillance doesn’t. E-mail address books — leave Facebook aside for now — are built dynamically from emails received and responded to. As anyone who is on a LISTSERV knows, you end up with a lot of contacts in your address book who you do not actually know.
In fact, there are all kinds of reasons you might respond, innocently enough, to an email from someone you don’t know. I’ve gotten a lot of misdirected email over the years, and responded to some of the more sentient messages with a “sorry, wrong address” reply. Now that sender is in my address book. Or consider that one of the best things about email, as opposed to walled-garden services like AOL and Facebook, is that anyone in the world can contact you to ask a question or make a comment about something you’ve done or said or offerred. People write to me, out of the blue, about open-source software I wrote ten years ago. I don’t know who they are, but I’m happy to answer their questions if I can. And now they’re in my address book.
Do I think the NSA doesn’t know this? Well, I would hope they do, but consider that Google themselves, who should have quite a bit more knowledge about their own products, infamously decided one day that you would want everyone in your contacts list to see links you’d selective shared with others in another product. No distinction between strangers, acquaintances, friends, work colleagues, clients, ex-lovers, family, fellow parents, friends of parents, members of your church/softball team/book club, or any of the thousands of other shades and distinctions in a real-life social graph.
This is the curse of metadata analysis: it only reveals a tiny piece of the elephant, and your algorithms and operatives have to infer the rest.
I have a server where for months the CPU load average has never dipped below 1.0. Since the server hosts a busy website that was programmed by someone else, I just figured poor coding practices were to blame. The system didn’t seem particularly slow.
So I was musing on it today, watching top. No processes were claiming unruly amounts of CPU time. I killed Apache, no change. Killed MySQL, no change. Oops, I guess it’s not the website. I ran checksums on top and ps to see if they were hacked binaries installed by a rootkit or something… nope.
It turns out there was a USB hard drive (formerly used for backups) plugged into the server but powered off. And this was causing the USB thread to freak out.
External hard drive unplugged, CPU load average is now down to 0.03. Now why didn’t I think of that before?
I haven’t spent nearly enough time working with HTML5 video. Man, it’s easy! No video.js or other player needed, you just drop the tag in the page and go.
One thing that made it easier: Miro’s free Video Converter. Encodes html5-ready mp4, ogg, and webm video for that cross-platform, plays-anywhere experience.
I’m still upset that you need to post three files to play one video. But the ease of using (and scripting) the MediaElement makes up for it.
The thing that’s going to send my whole operation to The Cloud is that I will *never* have to deal with another gosh-darned APC UPS again.
The short answer: you take the case apart. Good luck!
And don’t short the battery terminals while you’re prying it out of there with your all-metal Leatherman tool…
It’s hard to prove that a binary was compiled for a particular set of source code. So even though we can audit the source, we have no idea if the binaries we use are safe, without doing a lot of forensic investigation.
A truly secure distribution would build their binaries in a such a way as to be fully reproducible from source on end-user systems.
Like me, you don’t use iCloud most of the time. But you don’t want to turn it off completely, because you like to sync iWork documents to your iPad.
Here’s the command that stops iCloud from being the default save location:
defaults write NSGlobalDomain NSDocumentSaveNewDocumentsToCloud -bool false
New documents will use the standard file save dialog on first save. You can select iCloud from the places dropdown if you need it, but otherwise you’re back to your normal file structure. Ahhhhh.