Geek Drivel

I’ve seen lots of “squirrel-proof” bird feeders before. In most cases, the squirrels managed to work around them and get the bird food anyway. But this one looks like it just might work. And it’s a lot less expensive than the others I’ve seen too.

I had trouble believing this headline when I first read it, but when you read the entire article, it makes a lot of sense.

Geek Drivel is suddenly ridiculously popular with would-be blog spammers. I’m told that my primary defenses have blocked more than 400 automated spam messages in the last week, and maybe a dozen have gotten past them — all caught by my secondary defenses, I’m happy to say.

I’m not sure what prompted this sudden surge of interest, but the spammers are welcome to give up at any time.

I’ve dealt a lot with software piracy issues, primarily with Project Badger (detecting and preventing piracy is one of its primary purposes). And I didn’t have to learn the hard way that you have to be very careful before calling any user a pirate, or allowing your software to do so — paying customers don’t like being accused of theft. If there’s any chance at all that you could be wrong about it, you have to give the customer the benefit of the doubt.

For some reason, Microsoft did have to learn that the hard way. Their first antipiracy attempt, three or four years ago, was secretly installed onto systems disguised as an “important security update.” And it “caught” far too many of their legitimate, paying customers, baldly and unapologetically calling them thieves. It was clumsy and heavy-handed, too — it essentially made the system unusable until the “caught” person called Microsoft to correct the problem. Even if you didn’t experience it yourself, it’s easy to see how that could royally piss people off.

But by the sound of it, they’ve fixed all of those problems. They’re going out of their way to be open and honest about the process now; the false-detection problems seem to be fixed; and when it does think that it has caught someone, it allows the system to continue working as normal, simply informing the user of the problem.

I still don’t particularly like Windows, but it’s easier to deal with it now.

It’s a very long article, so I’ve only skimmed the answers that their chosen experts gave, but it’s very odd to me that the answers were so varied. Market share was brought up several times, as an argument for a Mac (or Linux, though that was barely mentioned), but others said that market share matters a lot less now than it used to. Others mentioned that applications are the important ingredient nowadays, not OSes. And several pointed out that social engineering works the same on any OS.

Probably the most interesting response, to me, was the one from independent researcher Dino Dai Zovi:

Neither. Consumers should see if Apple’s iPad or the forthcoming devices based on Google’s Chrome OS suit their needs because both are significantly more secure than any general-purpose desktop system, Linux, Mac, or PC.

He’s got a point, but I can’t recommend an iPad, at least right now. The same features that make it “significantly more secure” also make it significantly less useful, in my opinion.

In brief: those who control the domain name server system are going to roll out DNSSEC on it this year. Excellent news, from a security perspective.

An interesting glimpse into the many and varied defenses of the plant kingdom.

I like the hosting company that we use for Oak Circle (and this blog). I’ve been a customer for about ten years, with various websites, and in that time, they’ve consistently improved what they offer, without raising their prices. But with my yearly renewal coming up next month, it was time to decide whether I was going to stay with them. Why? It all came down to secure FTP.

As anyone who knows me (or reads this blog) knows, I’m fairly paranoid when it comes to computer security. My hard drives are heavily encrypted, so that if they’re stolen, the thief won’t be able to get to my files. I do my web-browsing on a virtual Linux machine. My wireless network uses the strongest encryption currently available. I employ GPG-encrypted e-mail with anyone who’s willing to use it. All of my e-mail connections are made through an encrypted tunnel so that anyone who might manage to eavesdrop on the connection can’t get anything from them. There’s only one known hole remaining in my defenses: my hosting company only supports unsecure FTP.

Why does that matter? If anyone is watching the connection between me and the server when I’m using it, they’ll get my username and password with zero effort. And don’t try to tell me how unlikely that might be; I’m usually on the road several times a year, and have to use unencrypted wireless connections in hotels and such, prime targets for that kind of thing. And at home I’m using a cable Internet connection, which is easy for anyone on the same cable branch to eavesdrop on.

The owner of the hosting service adamantly refuses to allow SFTP or SCP because, he says, that would require shell access — a security no-no on a shared host. I’ve seen refutations of this, but I don’t know enough about the issue to judge who is right, so I’ll give him the benefit of the doubt.

However, it seems that he has recently bent to the demands from the paranoid, and implemented “FTP over Explicit TLS/SSL” (generally referred to as FTPS). That’s where the problem comes in, because although I can connect through that, I cannot get anything done. Uploads, downloads, even simply listing the contents of a directory — all of them fail.

I spent pretty much all of a sixteen-hour Sunday, and most of Monday, trying to work with the technicians there to isolate the problem. They refused to consider the possibility that it was on the server’s end, repeatedly instructing me to set up my FTP program a different way, or use a different program, or a different version, or a different machine, or that it was my router or firewall. And every few hours there would be a shift change, and I’d get a new technician who would only skim the beginning of the case before firing off a “solution” from the hip — one that (had he read the whole thing) would obviously not solve the problem, or that I’d already tried and documented, or that was completely irrelevant. It was very hard to keep my temper and respond politely a few times, explaining the problem YET AGAIN, when what I really felt like doing was screaming “I TOLD YOU PEOPLE THAT THAT THREE TIMES ALREADY, NOW STOP DROOLING ON YOURSELF AND GO READ THE F’ING CASE, YOU F’ING LAZY-ASS MORON!”

(Especially when I was finally bumped up to level two support, after dealing with four level-one techs, and the first thing the level-two guy did was show me his log proving that SFTP — i.e. FTP through SSH — worked just fine. Great, think I in his direction, but I don’t have access to SFTP and am not talking about it! I’m saying that FTPS is failing!)

Finally, late yesterday evening, I managed to prove that it wasn’t anything on my end that was causing it. It wasn’t easy: I had to use three different machines, two versions of FileZilla, two other FTP programs, and rope Ploni into helping to do it (thanks, Ploni), but there was nothing left on my end that they could blame, not even my ISP, and I could prove it.

So what do I find in my e-mail this morning, but a message that says they’ve tested it, and it works for them. Basically: “you’re screwed, nothing we can do, better luck next time.” Not even a suggestion of any alternatives I could try, not that I think there are any.

Will I stay with them? I don’t know yet. From what I hear, nearly every other hosting company can be even worse, and often is. And the ones with the least negative publicity cost three to four times as much as I’m paying now. So all told, I’d really rather stay with this one, if at all possible. But I simply refuse to do that while there’s no way to securely upload files.

We’ll see how this turns out. I may be able to find (or write) a script that will let me do what I need to. But don’t be shocked if the site has a few days of downtime in the near future, while I move it to a different provider.

ADDENDUM, 11pm: It turns out that there’s an easy way around the problem: I just connect to their CPanel file manager via SSL and use the upload option there. It’s something of a pain when you need to upload multiple files, but the file manager can handle archives, so I can always zip them up, upload the zip file, and unpack it on the server.

As my friend Gene pointed out via e-mail, after I told him about it:

The only downside is that approach probably uses form PUT which has binary data base64 encoded. For small files it won’t make that much of a difference but for large files…

(Base64 encoding, for those not privy to the knowledge already, reads groups of three binary bytes and writes out groups of four text-only bytes for them. It’s a great way to send binary files on a text-only interface, but the files take 33% longer to send than they would over a binary transport mechanism like FTP.)

I rarely find any need to upload large files, so I think I can put up with that, for now. Next January I’ll re-evaluate the situation.

I guess this beats having a sadistic guard do a body cavity search on you every time you need to fly somewhere — which is where things have been headed for the last decade or so.

This does look like a problem. Here’s an idea for an easy solution, though.

In the address bar, the browser could display both the address (as it does now) and the script name. Unicode is split up into different well-defined sections for different language scripts, so this shouldn’t be very difficult to implement. In the case of the Russian “raural” text that the article shows, you’d be able to tell that the site wasn’t really PayPal because you’d immediately see that it was from the Cyrillic section of Unicode, not the Latin section (which English uses) that you expected. Or you’d see that it was from mixed scripts, which would be a huge red flag in most cases.

It’s not a perfect solution, but it would allow moderately savvy Internet users protect themselves from this kind of thing.

If no one else attempts this, I might try writing a Firefox extension that does it, once Unicode domain names are possible.