I've moved from this blog to my new location: Cocoaphony.

Neil Mix from Pandora contacted me today about the troubles I've had with the notification system. He showed me the code they use to text the API, and using that code has fixed a ton of problems. Anything based on knowing the current track is fixed in the 0.5.2. That includes growl, console log entries and Applescript. I'll have it out shortly.

I'm back into PandoraBoy development. Looks like Pandora changed something with their last UI update, and it's broken PB and maybe also Pandora.FM (who uses the same API as we do). We're just not getting events anymore from the API. So I've dropped a note to their support list and we'll see if they can help us out at all. This is why Growl is broken; Pandora doesn't know when tracks change.

I move between VS and XCode a bit without shuddering or fussing, which seems to make me a strange creature. In general, shocking as it is to say on a Cocoa list, VS is actually a much more powerful environment. Most who love XCode have little used VS (at least VS2005 or later, VS.NET is clunky IMO). But learning what actually is better about VS requires using XCode for quite some time. Most of the initial complaints are simply small differences between the two; many of which I prefer the XCode way. But then, XCode is a Mac app, and I generally prefer Mac UI.

As a regular user of both, here are some advantages of VS that do not wear off when you get used to XCode:

• Much deeper integration with its debugger. XCode and gdb play together, but they're not integrated the way VS is with its debugger. There are many important gdb features that can't easily be reached from XCode, and some (debugging with a core file) that you pretty much can't run XCode at all if you want to accomplish.
• The multi-tab interface makes it much easier to manage moving between many files, and the debugger is better integrated with the editor. XCode encourages you to have an explosion of windows, and the debugger is inconsistently integrated with the editor. The AllInOne interface for XCode goes too far the other way and makes moving between files a real pain.
• Mouse-over gives much better information in VS when editing. VS is always compiling your code, and so can give you access to information in the editor that is only available in the debugger for XCode. XCode technically also is always compiling your code (or it claims to), but it doesn't really make use of this fact.
• VS is better in nearly every conceivable way if you're programming in C++. XCode hates C++. If you use wstrings in C++, XCode will actually come out of the computer and slap you around (who knows, maybe it should). I dream of being able to easily display wstrings in the debugger. Yes, I've built the formatting plugins and from time to time they even work. Probably the biggest missing feature in XCode is good code completion for C++, especially with overloads, which VS does very well.
  

All that said, I still much prefer to work in XCode, but mostly because I prefer coding in Cocoa to .NET (.NET is actually pretty nice, but Cocoa is nicer). Apple's help documentation for Cocoa is far superior to Microsoft's documentation for .NET (which is infuriating to work with), and getting to the help in XCode is much more effective than in VS.

So to VS guys I say: Give XCode a chance. It's better than you think once you are used to Mac interfaces and if you're working on Cocoa apps (which XCode is highly optimized for). To XCode guys I say: until you've used VS for a while, don't assume that XCode has all the features it should. In the programming editor world, XCode is still kind of primitive.

A fie on useless attempts to stop hacking... At least that's my current assumption on why Microsoft did this. I'm a Cocoa guy, but I actually like .NET and hack a bit of it now and then. It's a pretty good framework, though you can see some of the seams where Microsoft didn't quite think it through when they were designing it and had to tack on later (the whole System.Text.Encoding namespace that's made up of methods that should exist on String; but then C# doesn't have ObjC-style categories so they probably also being more careful about throwing 10k methods on a single class the way Cocoa does, but I'm running off on a tangent here).

The point today is the headache that is the HttpWebRequest.Date property. What HttpWebRequest.Date property you might ask? That's right; there isn't one. It's a magical protected property that you can neither set nor meaningfully read. The system sets it for you when you make the connection and you can't do anything about it. Why? Most likely because messing with your date is a part of many kinds of attacks on web servers. But maybe they were just too lazy to implement it such that it would be automatically set only if you hadn't automatically set it. I'll assume for now that some misguided hope of improving security guided them on this. But it's a stupid approach.

The work around is to build a raw TcpClient that talks HTTP, which is a pain for legitimate developers, but not so much of a pain that it would barely slow down attackers. It's a pain if you want to talk HTTP correctly, because especially HTTP 1.1 is actually a bit tricky. But if you just want to replay a forged session, then it's not so bad.

But why would you want to screw with your date? For security reasons.... authentication in particular. I don't actually need to change my date; I just need to know what it is *before* I send the POST. When talking to Cerberus Web-API, the HTTP date header is one of the things they hash in their authentication token. That's a pretty good model; provides a decent defense against certain kinds of replay attacks. But it requires that you know exactly what time will be listed in your Date: header. If you guess using Datetime.Now, you can probably build a system that works most of the time. But if the second ticks over between the time you grab it and the time .NET assigns the Date header, you miss and don't authenticate. Classic race condition.

So I'm back to writing a full TcpClient so I can write all my headers, which isn't the end of the world, but is much more fragile and complicated than an HttpWebRequest. I'm going to have to dig into whether HTTP 1.0 will allow a Date header when talking to IIS. If it does (and it probably does because headers outside the standard are generally legal), then at least that will simplify things and I don't have to worry about GetChunked or any of the other little things you need to do to be a proper 1.1 client. As long as 1.0 will also work with virtual hosts and the Host header.... It's always something.

It's been a busy few weeks for PandoraBoy... well, for PandoraBoy's mailbox. I've been incredibly busy getting my day-to-day work out for months now and have barely looked at PandoraBoy since about February. The backlog of Issues has grown to a troubling level, and it's probably another few weeks before I'll be able to get back into PB development. But in the meantime I've been amazed at how much mail I've been getting on the subject. Mostly small bugs people are running into, but then, this just in:

PandoraBoy in French. Yes, Pierre Rudloff, out of the blue, sends me a fully translated lproj. I really appreciate it. I'll make sure to get it integrated into the next release. I probably won't get started on PB development until after WWDC because of other projects, but after WWDC it's top of my list. Especially all the annoying little bugs that have been creeping in (I suspect because of some backend Pandora changes).

The $10,000 Mac Hack

I recently read a comment about this hack wondering how long the author had sat on the exploit rather than reporting it to Apple. It's a very important point.

My opinion of these "security researchers" is well known: there's a difference between bird watching and research. Finding yet another buffer overflow isn't "research." Creating a new way to secure systems is research. Coming up with whole new classes of attack might be research (along the lines of bioweapon research). Those who hunt new instances of old bugs are collectors of exotic animals, weapon manufacturers, volunteer quality testers, or a half-dozen other categories that have little to do with science or research.

That said, it's not surprising that these guys would sit on the exploits they've found, and there are many lessons to be found in there. Reporting a defect to a vendor, at best, will get a terse "we'll look at it" and at worst will get federal agents at your door. There's no upside except that you might feel good about yourself and might not be punished for it. On the other hand, 0days are the currency of the underground. Even if you're just a collector, you need 0days in order to get other 0days. Every time you report one, you have less to trade.

Those who sell their services as pen testers need a cache of 0days so they can break in with undisclosed vulnerabilities when all else fails. If they disclose, then their customers' systems might actually be hard to break into and you don't look like a good pen tester. There is profit in showing you can break into systems. There's little profit in making everyone's systems safer.

Actual criminals of course aren't going to report that they've learned how to break into your system.

All of this is very important to keep in mind whenever you begin think a system is secure just because there aren't a lot of widely publicized exploits. The guys you most worry about are the least likely to tell you what they know.