I am here at the PDC in Los Angeles this week and have heard quite a bit of grumblings about UAC. The MS employees on stage and elsewhere are basically saying that UAC is a necessary evil so that clients do not become vulnerable due to unauthorized software install (and other admin level actions). The developer side of this argument is that UAC is a blunt instrument like a security guard in your house that keeps asking you for your passport. You can’t argue that this guard will make your house safer, but he is also going to drive you crazy until you decide to fire him altogether. That is what we are seeing in the field with so many people simply shutting off UAC. Now that Windows 7 is in sight it might be too late for my suggestion of how we might get the best of both worlds relative to secure software install. My idea is that when you go to install software you should be presented with a Capcha style challenge which ensure a real person is at the helm. Once that Capcha dialog is completed successfully the OS should track that this install is authorized and therefore exempt from future challenges since we know this is not malware (or at least not secretly installed malware). Since this idea just came up this morning I am guessing I am missing some aspects to this approach that are problematic, but on first look I think this approach could help make things more secure while not destroying user productivity. If you agree then bring this suggestion up to the people you know at MS. That is what I am going to try to do later today.

I have worked on many software development projects, both commercial and line of business and every single time I talk about optimization to a developer they always jump to the same conclusion. They think I mean speed of execution. I grant that the majority of the time when people talk about optimization that is what they mean, but it is not 100% of the time correct. Often I care more about the maintainability of an application especially if I know it is destined (or doomed) to morph quite a bit over the next year or so. In these case it is often an application that will be used by employees and many of the standard assumptions do not apply. Take our Intranet for instance. It is only used by employees and our closest contractors. We use it for tracking customers and projects, for forecasting sales and even timesheets. I don't care if it is 5% slower, I want it to be adaptable since we are an agile company. I don't mess with the code every week or even every quarter, but the code is written in such a way that I or any other developer on staff can go in and very quickly add a field or add other features very quickly. We didn't sacrifice security (that would be unacceptable), but we did forgo the multi tier architechure and stored procedures for parameterized queries. This is a sin in many circles, but if the application's backend is single use (only one application) then there is much less advantage to all the abstraction. I am sure the arguments will flow down on me now, but I see the same drive for complexity without purpose (real advantage I mean) in the Java world where code portability is everything and yet almost no one ever avails themselves of that costly feature. The next time someone asks you to optimize something ask them if they mean for performance or maintainability and let the funny stares begin...

Life changes pretty fast sometimes when you aren't watching. I woke up today and realized that much more of my work is involved in keeping projects on the straight and narrow and much less is spent making database fields show up in the right place and with the right user access set. For that reason I am changing gears and will leave most of the technical details of our projects to Duane Laflotte. He does it better on his blog anyways... That having been said you can expect me to pick up the blogging pen again, but this time I plan to write about management of technical projects including things like sales, process engineering, fixed bid proposal generation and the other things that I wish five or ten years ago I had found a blog to read. I also will likely talk alot about commercial vs. business programming and the impact of new technologies on a technical consulting practice. If this makes some of those that followed my blog leave then I am sorry, but I do think that this blog will be better for the change (at least now I will feel like I can vent here a bit). See you soon.

I have recently finished my last presentation here in Cairo at the EDC 2008 and wanted to start getting my presentations uploaded for all those who were asking about them. To make things run faster I am uploading them each in their own post especially since the AJAX example hasn't been packaged yet. I covered Indexing in SQL Server including what works and what does not work. I was very happy that my friend Mohammed Meshref from the Microsoft SQL Server team was on hand to both help and to be picked on ;) Thanks Patrick

EDC08 SQL Indexing and Perf Draft 2.ppt (546.5 KB)

I have often thought about the mindset required to be good at the security game. I hang out with Duane Laflotte alot and he has the whole hacker mindset which lends itself nicely to security even when you aren't trolling on the dark side. But it was an article that got picked up on Slashdot today about Bruce Schneier's thoughts on this subject that revived the thread for me. I have what I think is an interesting twist on this perspective in that I believe that the only way to teach what Bruce is holding out as unteachable is what I believe taught me to think this way. When I grew up I didn't think the way Bruce Schneier thinks. But I do now. The reason I believe is the military. When the Army trains infantry leaders it teaches them how to defend while looking always for ways to attack. The mild mannered programmer is taught to build, but if part of that training put in their mind that to be successful they had to tear down the abilities and infrastructure of the hackers then we might get a different result. There is nothing to make you think like a hacker than to stand on a hill and realize that you are defending it at dawn and if you fail you and all your soldiers die. It also makes you want to get that unfair advantage and lay traps for the enemy. During a major training exercise in Germany I put soldiers in foxholes with signal mirrors and had them flash the enemy armor to draw fire while our vehicles flanked and destroyed them. So I think if you want to be a hacker and you don't think like one I think the Army recruiter would be happy to help get you trained...