I'm sorry if the humor didn't come across. It was not meant as any kind of substantive criticism, it was meant to make light of the fact that you are talking over the heads of probably 98% of the people who read what you wrote. I have no way of knowing if what you said was accurate or not, and that wasn't even part of what I was trying to communicate. If anything, I was teasing you for using such dense language with such little context. Really, though, what happened is that I read what you wrote, thought to myself, "this is what engineers experience when they hear management using highly specific language to describe business models", and I thought of that funny buzzword generator. It's funny, right?!

No offense, and I'm sorry that my terse comment was misunderstood.

Is there some physics version of the Web Bullshit Generator?

I have heard it said that at some point the military would not buy software that required a mouse, so MS made an OS that didn't require one. I don't know how true this is, but MS has obviously put an enormous amount of effort into allowing their GUI to be run without a mouse. There are probably dozens of people who work on this aspect of Windows/Explorer exclusively.

I had a company-issued blackberry for about a decade. Each year or 18 months or so they would get refreshed, and I'd get the latest model. The early models were solid and great in almost every way, but each subsequent model was worse than the one it replaced. They haven't made a decent keyboard in at least 5 years. Their screens got more pixels and more colors each year, but the overall quality of the screens got slowly worse. My employer supports iOS now, and I'm happy to never have to touch a blackberry again.

I also did some app development for blackberry devices, and I can tell you without a doubt they have the worst platform, the worst tools, and it's obvious they never cared about making development workable. I only ever saw one third-party non-game app that was decent, and I estimate it took 15 people 6 months to build that. Compare this to some of the iOS and Android apps that a single person can put out with a couple weeks worth of effort.

Going with Android seems like it would be akin to starting over. I don't see what assets they have that HTC or Samsung don't have. They have their Enterprise Server thing, but I don't understand what advantage that has over Exchange + ActiveSync which every other platform seems to support. I would be happy to be enlightened about what advantages Rim might have left.

I am certainly not trying to say that the operating system had no api prior to the release of the sdk, and I am certainly not trying to indicate that my opinion is rooted in facts.

I have done very limited os x development, but it is enough for me to see the overlap, as well as the mysterious divergences, in the two apis. You are right that there is no direct evidence that a public api and app store were in the pipeline. I just don't think it is possible to turn an internal api into a public api with all the supporting infrastructure and tools in such a short period of time. In casual conversations with other developers, this is a widely held belief.

There is no way that the SDK was released as a capitulation to developers. The iOS SDK was released 8 months after the iPhone. If you have done any iOS development or otherwise taken a look at it, you would know that it is impossible to build such an SDK and supporting materials in such a short period of time. The SDK and App Store were clearly in the works when they initially released the iPhone. Perhaps they were behind schedule, or perhaps there was another reason for staggering their releases.

Since it didn't say in the summary:

Is there any concrete information that the problem was that the url was /AccountDetails?AccountNumber=123? I haven't seen any.

There are a ton of understandable (but still inexcusable) reasons for an organization to subvert it's own security measures. Perhaps this online banking site had a requirement to display account information from two different backends that are otherwise unaware of each other. Perhaps this was implemented using javascript or flash "drm" or "cryptography". Perhaps a vulnerability those libraries allowed the attackers to compute some hash 2 billion times which yielded 200k valid account numbers.

This obviously reeks of a hacky shortcut of something that should have been implemented properly, but I haven't read any credible facts that it was as simple as you put it.

Again, I'm not trying to excuse anyone. Just saying it's probably more complicated than you are making it out to be. And this guy was probably quoted out of context and probably was not being understood by the reporter.

Give some benefit of the doubt. Keep in mind this is a New York Times article -- it is written in way that they feel should be understandable to any 8th grader in the country. Add onto that, that the reporter is almost certainly not understanding anything this guy has to say. Add onto that, this guy is actively working on the investigation, and he might not be willing or able to divulge any actual information. Add onto that that the New York Times readers (staff included) are generally outraged at the banking industry, so there is no doubt a bias to roast a big player in that industry.

Some questions: Is this guy the original source? What does "security expert" mean? CISSP? Manager of the "security department" that is running the investigation? Outside consultant? Who knows, if the article contained this information it did a bad job of conveying it.

The way I read it, it seems to me that this guy is probably referring to the criminals. When I first read it, he was conveying to me, "The last place criminals will look for an entry point is the front door. When they found it, they seemed prepared with a sophisticated and fast way to drain as much info as they could prior to detection." It's almost as if he is suggesting that it was an inside job without coming out and saying it. Correct me if I'm wrong, but there is nothing that suggests that the account numbers were in the url in plaintext. Perhaps they were ROT13ed or similar, or perhaps the key was in a script on the client, or perhaps the key was the remote ip address or something equally dumb. This would still be unforgivable from an architecture point of view, but it easy to see how something like this could escape notice during day-to-day code reviews. "What's that string for?" "Oh, that's our session id."

There are a million contexts and situations where what this guy said could make good sense. Why the New York Times is publishing truncated sound bites of opinion from anonymous sources is the baffling thing here. The New York Times might be able to corroborate facts from an insider, or otherwise trust the information, but in my mind they should not be printing opinion or speculation from an unnamed source with an obvious interest in the outcome.

The use case is this: iPhone 4 comes out, iOS dev team needs to test the app on that device. No team member has an iPhone 4. The only way for the team to acquire an iPhone 4 is to get a 2 year contract with AT&T. It's technically possible to do this, but most IT procurement teams are not set up to do this, so you need exceptions all over the place, it takes forever, etc etc. It's also far more expensive than it should be. It ends up costing $1000s for a ~$600 chunk of hardware.

Again, the locked phone/contract never blocked work getting done, it was just a giant pain to deal with.

I am kind of amazed that Apple's U.S. enterprise/corporate customers have put up with locked phones for so long. I remember some previous models were available unlocked (or at least contractless -- I forget the details). But the majority of the iPhone timeline these phones have required a contract and a phone number. I have worked for two different iOS dev shops, and in each case it was either a complete PITA to get devices, or the devs/qa just used their personal devices because there was no other effective way of getting hardware from a corporate procurement point of view. The provisioning has improved over the years, but getting an actual device has been probably the biggest pain in doing corporate iOS work. Hopefully this will make that situation better.

It's a line from Raising Arizona.

That's a little bit misleading. This project is basically instrumentation that you add to an asp.net 4.0 webapp. It does not seem to be usable by any other kind of webapp. It doesn't even look like it would be easy to port to the other major platforms.

I disagree. I don't mind ads, mostly. But am I ever going to buy Framemaker? Am I ever going to use Groupon? Am I ever going to deploy IBM's application virtualization infrastructure to my cloud? No. The problem is that this ad network sucks, in almost every dimension. I'm pretty sure that this is the worst ad network that I see on regular basis. (OK, maybe Conde Naste's "let's cover the entire page of our own content with an ad" is worse, but not by much. At least it's just one click to get rid of it.) It seems painfully obvious to me, but I'll say it out loud -- If your ads make your content worse, accepting them is a bad move. Find another way.

I am kind of astounded at how easily people give away access to their email accounts, no matter how harmless the intent of the email is. I got swamped by invites from facebook when several of my friends gave it access to their address books. Now that's just annoying, but is this guy's security up to the same level as gmail's? I tend to doubt it...

As an aside, what the hell happened to slashdot? A couple days ago it was its usual tolerable self, but now I have the most garish ads for Adobe authoring tools and groupon and nonsensical cloud virtualization things, and it's slow as hell. I am happy to co-exist with ads if they pay the bills, but these ads kind of ruin everything. Is slashdot on its last legs?