Researchers at the University of Illinois at Urbana-Champaign build a new browser from scratch to help keep hackers at bay.
I was incredibly skeptical from the headline. It read to me like “team builds near-useless browser that is probably a bit harder to hack than an unpatched Windows box.” But it’s actually an interesting architecture. I like their early consideration of plugin issue. Rather than banning plugins, sandboxing them till they can’t do anything, or bemoaning that plugin writers will probably be stupid and break security but it won’t be the browser’s fault, these guys actually seem to have considered how to compartmentalize such that the plugin can be compromised without losing the farm. That’s a good security lesson for us all. It’s not about making sure nothing bad ever happens or banning everything that could ever let something bad happen. It’s about making sure that when bad things do happen (and they will), that the damage is contained to the piece that was compromised. And to this feature, wow:
The UIUI team has also designed a browser-level information-flow tracking system to enable post-mortem analysis of browser-based attacks.
That’s a team that “gets it.” You will get hacked. Designing for what you do after you get hacked is a sign of great security thinking.
Two posts in a day… but this was a completely different topic.
I’m beginning work on my first Leopard-only application, and so I’m trying out garbage collection. Sure, I’m excited about garbage collection. Sure, I have no great love of keeping track of my retain counts and autorelease pools. But….
It feels really, really weird to not release my variables. I tend to rely on autorelease a lot. I know there are some disadvantages, but I like the fact that it notes your intention when you allocate the memory. Read more…
It’s a lazy day for me. That means I’ll probably hack stuff all day.
One of my best friends in the world just sent me a note asking for a good Cocoa reference. I thought I’d pass on the same advice I gave him:
This is the book on learning Cocoa:
Cocoa Programming for Mac OS X
by Aaron Hillegass
Third edition is supposed to come out this summer. I’ve read the proofs of the 3rd edition, and it does add some good stuff, but if you’re anxious to get started, I’d get 2nd edition and get started. Read more…
To all you aspiring Cocoa developers….
If you want to make a private framework, you need to remember to set the install path for it to @executable_path/../Frameworks. Just copying it into your bundle isn’t good enough. Otherwise your app is going to think it’s in (~)/Library/Frameworks once you package it up and give it to other people.
In related news, PandoraBoy 0.5.1a is now released.
Yes it is true, a new version of PandoraBoy is up, 0.5.1. I haven’t put it into Sparkle yet, and probably will skip it because it only fixes a couple of things (most notably, paid accounts now work correctly). Technically there’s an entire full-screen mode in there now with a plug-in architecture and public framework, but I’ve disabled it because it’s still kind of flakey and doesn’t work very well. I’m going to focus for a while instead on some of the bugs that have been reported and get those cleaned up.
Maybe I’ll play with the new version of ShortcutRecorder that just came out thanks to OmniGroup’s contributions (great company, great products). Hopefully I can get rid of my IB2 dependencies and finally move 100% into XCode3.
And of course I’ve been promising improvements in Sparkle that will help PandoraBoy a little bit, and I more deeply need for my day job. I’ve been mostly working on those during what I consider “day job” hours, but right now core product features are far more pressing than automatic updates. And #1 on my list: collapse the current branch back down to trunk! Ah, subversion, thou viper. Linus was right. There’s no such thing as “CVS done right.” But in truth, it isn’t so terrible, it just isn’t so good either….
