A lesson from Chrome

As you will surely know by now, Google launched its own browser, Chrome.

I won't discuss how it is only available on Windows (guys, most people see you like a "Microsoft alternative", wake up!) or if it makes sense or not to have another browser.
I'd like to elaborate a little on a very nice article on TechCrunch.

Chrome does not support Lively (remember? Google's Second Life). Google analytics does not know about Chrome.
If you look for chrome into Google you don't get it as a first result (ok, we know it's google's policy but yet..).

There's something we should learn from that. We have a huge company, building dozens of products at the same time, but we can see similar things happening in smaller companies with just half a dozen products. It's about development awareness: what's the rest of the company doing? How will my new software integrate with what we already have?

You cannot afford to have a "standalone solution with is somehow integrated with the rest but still" - well, unless you're Google of course. It's exactly what just happened to Google, and what keeps happening everytime a new software is launched.

You're not developing for Mainframe anymore! Start thinking about the environment. Build your external API before even finishing your GUI, think about integration before completion.

Trojanize yourself for deniability

I know this has been discussed a thousand times before (since 2003 at least!), but a recent assignment has made me think again about this. Let's just presume you're on a forensic task, and you're surfing through the suspect's computer. You end you finding the contents you were looking for, but meanwhile you start the routine antivirus scan. Ding, you hit a well known trojan.

It's password protected, and was obviously installed before the data you were looking for were downloaded.
You dig deeper, and discover the trojan will actually start at boot and be exposed to the internet.

That's it, the suspect has not lowered its security level during normal operations - assuming the trojan is actually safe and the password was hard enough to guess - and you are left wondering who has actually put that data into place. How can you tell it wasn't the remote aggress controlling the suspect's computer?

Sure, you can try to retrieve some more data to uncover the truth, but carefully leveraging this trivial issue (think about actually giving it encryted commands from time to time using a different account to confuse even a 100% sniffed wiretapping) is enough to obtain plausible deniability.

It seems too easy: I'll keep thinking about that - I've got an assignment at hand, remember? - but any idea is really welcome!

Understanding High Availability

I've just finished a course on High Availability, more of an overview on different HA technologies on various platforms.
What I have noticed is that is really, really hard to have people understand that you cannot plan high availability as a "one night affair". Most organizations have their border routers under VRRP, and their Oracle database running on application cluster, but yet they seldom have layer 2 redundancy ( the "oh my god, a loop! kill it, kill it!" syndrome) or any redundancy on "less-important" systems.

Like an old friend said, "if it's worth having it, it's worth having it all the time". With the new virtualization techniques available there's really no excuse for not achieving HA on most of your infrastructure.

Need an easy to manage yet featureful HA firewall? Go for pfSense. You can name almost any software, an HA solution is there for free or for the time you need to build it: if it's running on Linux, then you have DRBD (150-160Mb on two bonded nics) and Heartbeat and many others, if it's under Windows you have tons of choice - not to forget a scheduled VMware converter run which might not be HA but yet it's far more than most organizations actually have.

One of our clients had an hardware failure last Friday, which resulted in a complete halt of business for the weekend. Hard to tell how much damage was actually done, but does it make any sense to work in such a way when HA solutions are so cheap?

Yes, you need skills to do HA. But what we don't need anymore in our business is IT people without skills: we have far too many of those around...

PS: As you might or might not have noticed, this is the first post since a lifetime. Long story short, more posts will come from now on ;)

Location aware social networks

Yet another step in the direction of tight realworld-internet integration: the number of startups proposing cell-phone based location aware software is skyrocketing. We've already discussed linkedin going mobile and the current problems of actually using cellphones to do social networking, but now the market is getting crowded.

The most straightforward use of such a network, and probably the one with the best ROI as of today, is the "Mobile dating" slice. MeetMoi and limejuice are doing it right now, but more will surely join in the future.

While some other startups are going in a "one network fits all" approach, like MobiLuck, Imity,aka-aki, often using a bluetooth powered engine to detect nearby user or leveraging GPS (like Loopt), there is space for more specialized networks.

Think about a gaming platform, think about hobbists who seldom meet each other and so on. While a clone of facebook would likely result in a huge mess in any city as soon as it reaches critical mass, a focused application only connecting some kind of people could do the job: meeting even one new person into the "70s-singers-wearing-only-black-shirts-from-Losanna" fanclub would be enough a payback to have the application installed.

Meanwhile the first IPhone powered social network is almost ready...