SSIS Conditional Expressions (Lightbulb:On)

I’ve often been confused and frustrated by conditionals ( … ? … : … ) in SSIS expressions. The concept is straightforward enough, but the syntax made it really hard for me to keep track in nontrivial cases. Then yesterday I had an epiphany: it’s much easier to keep them straight if you write them on multiple lines. Continue reading “SSIS Conditional Expressions (Lightbulb:On)”

Time Limits on Browser Plugins?

When Steve Gibson talked on Security Now 398 about how few users’ Java plugins are actually up-to-date, this question hit me:

Should browser plug-ins have built-in expiration dates?

The problem with having all of these old Java versions running around is that attacks always get better. How much more sophisticated are the attacks of today than the attacks of just one year ago? Why, then, should anyone think a free browser plugin released today—even if it’s secure by today’s standards—will stand up to the attacks of one year from now?

Fix the ecosystem…

Of course, vendors need to continue to do their best to write secure code in the first place, and release timely updates to fix errors that do make it into the wild. We also need to work on the ecosystem to make it easy for users to stay current—figure out what Apple is doing right, what Android is doing wrong, and how to apply those lessons to the browser plugin market. (I’m not just picking on Java—I’m thinking of Adobe Flash and Reader, too.) I’m not sure how to get end users to care about keeping these plugins up-to-date, but the problem deserves attention. Obviously, the major plugins now auto-update, which will help, but it’s not foolproof (I’m envisioning malware that intercepts update checks to keep vulnerable plugins in-the-wild longer).

…and build in a time limit

What I’m proposing is that vendors build in an expiration date as a safety net, so if a user tries to run a 12-month-old plugin (which won’t happen if auto-update is working and the vendor is still maintaining the product), it displays an expiration message and instructions for how to get a new version. Obviously this doesn’t solve our current problems, but it should be part of a strategy to make sure we’re not still in the same boat a few years from now.

New Project: Backbone Reference App

Today I released a JavaScript reference application, built on Backbone, Marionette, and RequireJS.

I’ve learned a lot over the past several weeks, and at times the learning curve was steep, partly because I couldn’t find a good reference application that I could learn from. To-Do apps are the classic example, but they’re too trivial to demonstrate how to architect a larger application. I’m hoping this resource will help fill that gap.

I’m still learning this stuff and am certainly no expert, but I’m happy to share what I’ve learned.

Lessons in Bug Hunting

Yesterday’s lesson in bug hunting: don’t assume you’re an idiot. I spent a few days trying to figure out why my success callback wasn’t being called. It had been working before I updated to jQuery 1.9.0, and I didn’t think I had changed anything. After much head scratching I found out that jQuery 1.9.0 introduced an Ajax() bug where HTTP status 204 is considered an error. A fix is in the jQuery master branch and will be in jQuery 1.9.1.

Today’s lesson in bug hunting: don’t assume you’re not an idiot. I spent hours yesterday and this morning trying to get Mousetrap.js working. I triple-checked my code against Craig’s documentation, verified the library was loading in the browser, etc. It should have worked. But I set a breakpoint on the line that was throwing the error and there was simply no Mousetrap in the global namespace. Having ruled out an error on my part, in desparation I opened mousetrap.js, hoping to find the bug in there. Instead I found… nothing. Yep, something had gone wrong when I downloaded it, and the file was completely empty.

Bottom line: keep in mind that everyone makes mistakes.