InfoWorld Takes Fresh Look at SafeCentral

I was enormously encouraged to find Authentium SafeCentral front and center on the home page of InfoWorld, next to a subheadline saying "was it (i.e. their recent recent review of SafeCentral) a misunderstanding about what the product actually does?"


Thank you, InfoWorld! And thank you, Roger Grimes - it takes a really big-hearted reviewer to take a second look at a product.

Note: In case you're new to this story, Roger originally tested a number of products for their ability to "shield" users from malware, or "sandbox" their activities. We scored poorly on this - mainly because we didn't stop malware from "entering the sandbox".

As I've explained in my previous blogs since, we don't do that. When we designed SafeCentral, our core objective was not to try and stop malware per se, but allow users to compute safely in the presense of it.

Our objective was to let folks go about their banking, buying, or information sharing safely - even in the presense of the most horrible viruses or spyware. Let me tell you why that concept is so powerful - and revolutionary. But first, an analogy:

Here's how antivirus software works: you are surrounded by bodyguards, highly-trained experts hired to recognize threats and deal with them before they can harm you. But if so much as one bullet skips through... you're dead.

Here's how SafeCentral works: you are invisible. You can surround yourself with bodyguards if you wish, but you don't really need them. Because the bullets have no target. They can't see you, can't have any effect on you. There is no such thing as "the bullet that slips through".

This was the revolutionary idea that myself and my co-patent developers had, and that our engineers and ops team have since matured into a ground-breaking product and service. If you want to try it for yourself free, just head over to www.safecentral.com.

If we have one problem that we need to solve with this product, it's getting the message out about how much this product changes the game. You can't fault Roger Grimes or InfoWorld for not seeing what we're doing if we're not advertising it correctly.

You might think that advertising an easy, invisible, but highly-effective technology that doesn't need updating shouldn't be hard, but advertising anything new is a challenge.

Twenty five years ago, when I was a copywriter at George Patterson Advertising (now Bates) in Adelaide, my first boss used to say "Your first responsibility is to make sure it says 'tuna' on the can". In our case, that means making sure "reverse sandboxing" is part if our messaging to users - and reviewers.

The good news is, based on the discussion I'm seeing around this point, people are starting to "get" what it is we're actually doing. Now we just need to figure out how to broadcast this news on a wider scale.

Of course, front page of InfoWorld is a pretty great start. ;-)

A Little Bit of Knowledge

A couple of years ago, I decided to get better acquainted with basic software programming, as a means of better understanding the challenges faced by my developer colleagues.

This had an unexpected effect. Since then, I've become a bit of a weekend addict. As Professor Richard Dawkins has noted, there is something incredibly satisfying about stringing together a bunch of conditional statements against a set of inputs and desired outputs - and then seeing the result pop up in front of you.

When it all works, it's a lot of fun. But I'm starting to suspect that in addition to the thrills described by Dawkins, there are other benefits that occur when someone from the corporate, or 'sales and marketing' side of the house starts playing with conditional statements on the weekend.

One of them is a more tangible level of respect. I've always had a ton of respect for developers, but that respect has sharpened now. I now also have an increased level of understanding of the challenges.

One example: I used to get exasperated whenever developers would talk about not being able to find a bug that was holding up delivery.

I would say, "Why can't you find it? Why is this so hard?"

Not any more. Developers, you are forgiven. Now, I too have sat for hours some weekends staring blankly at the screen in front of me - only to have it dawn on me that I didn't close a statement properly or call the right resource, after the hundreth walk through the code.

Lesson One: Bugs happen - we're only human.
Lesson Two: Code review should be done by someone other than the guy writing the code.

I also have learned the hard way why developers often insist on writing solutions from scratch. Yes, mash-ups can be fun - but they can also be unpredictable, and pieces of seemingly stable code can interact in weird ways.

And sometimes, unexpected updates (from the developers of one side of your code mashup) can destroy everything you've written (just ask a Facebook Apps developer) and take your project into a direction you never intended to go. No, it isn't always a good idea to 'buy it'.

Lesson Three: If it's fundamental to the business, write it yourself.

Documentation? Guys and girls, please spend all the time you like documenting your code - I get it now. Those little comments are worth their weight in gold - the more the merrier. Dev wikis, toolkits and forums can expand your developer network exponentially - providing the documentation is there.

Lesson Four: Documentation is as critical as the code to success.

The other benefits are a greater understanding of the way developers work. I now understand the requirement that when you're faced with something hard, you really need to bolt yourself down for 18 hours (or 36 hours) and have someone feed you Coke and pizza - because when you're working towards the middle of two ends of a two thousand line piece of code, it can be really hard to 'pick up the thread' (that's a developer pun) if you stop.

Lesson Five: Create a workplace for coders that is free from distractions.

One other thing I've learned is that coding and rocket science are similar in that they are not necessarily difficult (having worked extensively with both rocket scientists and coders, I feel qualified to make that statement) - but they do require a ton of knowledge. The more up-to-date and extensive that knowledge the better. Fewer things will blow up.

Note: If you can find a development manager capable of winning respect based on their past experience, willing to 'manage' rather than code, and willing to share knowledge with your young team and mentor them, I suggest that you pay them very very well. There is no greater value.

Lesson Six: Experience is critical. Put a "hands off" grown-up in the room with your young wizkids.

Finally, a word on testing. Too many people think quality assurance (QA) testing is finished once you've fired up a clean VM image and tested your software. This is BSQA - if you're not testing your code in the real world, with real users, on real machines, you're fooling yourself as to its quality and value to end users.

Lesson Seven: Real coders test on real machines using real users.

I should emphasize that my own coding efforts remain just a hobby (my stuff sits on an outside hosting company server, not at the company) - and my understanding remains a helicopter-level appreciation at best. But the experience has been very valuable and has given me a greater appreciation of the depth of skills we have at our company.

And as for the aphorism "a little bit of knowledge is a dangerous thing", my response is this: a little bit of knowledge is only dangerous when the person with that little bit of knowledge remains ignorant of the sheer amount of knowledge that exists outside that subset.

In my case, I believe my little bit of knowledge has led me to an enhanced understanding and greater appreciation of the scale of knowledge we have in our organization, the real time required for quality work to be done, and the kind of specialized skills that are needed to create great software.

And that's a good thing.

Effortless Security

Getting the messaging right around a new product offering takes time - especially when that product is as new and as game-changing as Authentium's SafeCentral.

The tradition view of security - that you're only as secure as the last set of virus definition files you downloaded - has been around since the dawn of the Internet. Security companies have all spent a ton of money driving that message home. Reveiwers still base most of their reviews on IT security products on a score out of 100.

The difference between this defensive model, and what we're doing with SafeCentral, is night and day. SafeCentral is "effortless security" - or as Corey O'Donnell, our head of Marketing likes to say, it's "Security Made Simple".

We designed SafeCentral so you can transact securely irregardless of what kind of malware has infected your PC, or infected the DNS servers upstream of you.

This design allows us to protect people in the "real world" of drive-by downloads, hacked wifi hotspots, teenagers that borrow your PC, and ever-more-sophisticated social engineering attacks.

SafeCentral creates a situation where staying secure becomes effortless. No worries about updates, vendors missing a virus, no "zero day attack" concerns. It doesn't matter if there is a keylogger on your PC. With SafeCentral running, it can't get at your data.

Compared to the cost and inefficiency of ongoing treatment, immunization provides an effective defense that is almost effortless in comparison. That's what we're aiming to do here - easy, effortless, effective security.

Think of it as immunization versus a surgical mask. That's the message that we'll be working on improving in the coming months, and folks start to get used to the idea of a future without virus definition files, filters, and walled gardens.

Note: It's no secret that most banks now have initiatives around protecting consumers and are actively looking for software to enable this.

We believe banks and other financial insitutions would be smart to consider the wisdom of an effortless, highly-effective, holistic solution like Authentium SafeCentral versus traditional higher-maintenance alternatives.

Sandboxing Is Not What We Do

One of my favorite sources of information and smart advice on the web is InfoWorld and one of my favorite IT writers there is Roger Grimes. So it was a pleasant surprise yesterday when I received a Google alert that Roger had done a review on us.


Unfortunately, the review turned out to be a general review of "sandboxing" products - one that we should never have been included in. Sandboxing is not what we do.

Sandboxing, defined as the attempted creation of a computing environment free of malware, tries to keep certain apps and processes free of malware using various defensive techniques reminiscent of traditional approaches to security.

What we do is entirely different - as Ray Dickenson, our CTO, is fond of saying, we do "reverse sandboxing":

"Authentium’s SafeCentral service delivers secure web browsing even on computers that are compromised with data-stealing malware."

In other words, SafeCentral allows consumers to safely bank or transact from computers that teenagers have downloaded horrible, horrible things onto.

This is poles apart from most defensive strategies and traditional approaches, such as walled garden-style sandboxing - and in my view, is much closer to what consumers need.

Note: I'm not negative on sandboxing as an approach. All security technologies have a role to play and there are some outstanding sandboxing technologies - Prevx being one such example. But what these guys do and what we do is very different.

IT folks - and marketing executives - looking for complimentary approaches should consider the virtues of both - our approach, and the approach of the sandboxing companies. I happen to think "reverse-sandboxing" is a much more consumer-friendly and effective approach to keeping folks safe.

Note: If you'd like to learn more about why SafeCentral is different, Ray's white paper on Reverse Sandboxing can be downloaded from here - please scroll to the bottom of the page for the link.