Microsoft’s release yesterday of Office 365, a suite of cloud-based services for small and mid-sized businesses (SMBs) and enterprises, has been getting a lot of attention in the press. One egregiously poor decision by Microsoft, though, has not been talked about quite as much. Ed Bott over at ZDNet, though, picked up on it:

If you sign up for one of the Office 365 Enterprise plans, all your users can connect to SharePoint using secure (HTTPS) connections. If you have a Professional (small business) plan, you don’t get that capability. For a small business that deals with sensitive documents, that’s a potentially dangerous configuration.

Let me be very clear about this: baseline security is not an option, and it shouldn’t be sold as a value-added feature. Microsoft claims “Office 365 comes with the robust security and reliability you need to run your business, all for $6 per user per month.” Offering SharePoint, which provides businesses with document sharing and other intranet capabilities, without protecting the confidentiality of data transmissions to and from the server, is not “robust security.”

One has to wonder what other security trade offs Microsoft made with Office 365 that are not yet evident. Until Microsoft demonstrates that it really stands behind its “robust security” claims, SMBs would be well advised to avoid this new offering.

Over at InfoWorld, Galen Gruman posted a column with the ludicrous title “Android is a malware cesspool—and users don’t care.” The entire premise (or premises) of the column are so flawed that I almost didn’t bother writing a response. But because they reflect ideas I’ve heard/seen mentioned elsewhere, I felt it was worth commenting.

First, Android is not a “malware cesspool.” Yes, it’s a popular open platform, and the combination of openness and relatively little effort by Google to “tend the garden” has led to some malware popping up. But we’re talking about a few dozen malware apps out of a few hundred thousand available. And, while some have lingered longer than they should in the Android Market, they do eventually get removed and, in some cases, even uninstalled from users’ phones. Though accurate numbers are difficult to find and compare, every indication I’ve seen says that malware is far less prevalent on Android phones than on Windows PCs at this point. And, even with years of history of malware issues, most people don’t consider Windows a cesspool.

The idea that “users don’t care” is also off base. Of course they do. No one wants to have his money stolen or his phone ruined. The evidence that Gruman provides to bolster his case is that users don’t carefully scrutinize applications’ permissions before installing, and that users haven’t flocked to download a specific app that seeks to warn users of dangerous apps. Even if we fully (and foolishly) assumed that users were aware of all the potential risks and how best to protect themselves, neither of these arguments holds up.

The permissions feature used in Android provides broad, confusing information about what an application is requesting permission to do once installed. There’s no easy way to get further information or to discuss with other users or the vendor any questions that arise when faced with the choice of whether to accept the permissions. And users have to make a cost-benefit trade-off: do I scrutinize these permissions, which takes time and thought on the chance that they might make me think twice about installing this app that I want to install? Even if a user cares about the risk, it may be rational to skip or skim the permissions and then click “install.”

As for security apps, Gruman first argues that mobile security apps are mostly a waste, and then bemoans the fact that users haven’t expressed interest in a particular security app. Again, even if we assume that the users are aware that the security app might help them, they may be unfamiliar with the product, the vendor, and how well this particular product would help protect them.

Of course, the assumption that users know the full range of risks and threat vectors doesn’t hold up, either. Part of the implication embedded in “users don’t care” is that they know about these risks and just aren’t interested in avoiding them. The reality, though, is much different. Many users have no idea what might happen, how likely it is to happen, what they can do to reduce the risks, how to prioritize those defenses, etc. Heck, I’m not sure I know the answers to all those questions, and I do this stuff for a living!

I should give Gruman credit for one great point towards the end of his column. He emphasizes that user education shouldn’t just come in the form of lectures, but in the form of in-your-face intervention. He gives the example of an IT department trying to phish its users, and then letting the victims know when they’ve fallen for it. This “just in time,” real-world learning can be very effective, and can help users comprehend the risks, which leads to better decisions. Which, of course, is only true because they care.

“It’s the customer’s fault. He’s not using the product the way he’s supposed to.”

What a frustrating thing to hear. Fortunately, when I heard this today, it was being quoted by an executive who was fighting the use of such statements by other employees within his company. He recognized the truth of things: if your product allows people to do something they shouldn’t do, some of them will do it. And if you don’t want them complaining about the effects of doing it, you need to change your product’s design.

For example, it used to be the case that car cigarette lighters (now known as 12V sockets) continued to draw power when the car wasn’t running. Guess what happened? People left things plugged in, which drained their car’s battery, causing them to be unable to start the car a day or a week later. Sure, you can blame people for leaving things plugged in, but come on… who hasn’t left something in the car on occasion? The better solution, which fortunately has been adopted by most car companies nowadays, is to power off the 12V sockets when the car is turned off. That way, the battery can’t be killed by a predictable user behavior. Instead of blaming the customer, change the design!

The Safari web browser has an option to automatically “open ‘safe’ files after downloading.” The recent Mac Defender family of scareware exploited this by looking safe and thus automatically opening for users with this option checked. You could argue that Mac users shouldn’t have checked the option if they’re concerned about security. But, really, why is this option there in the first place? Apple’s own safety tips page urges users:

Always use caution when opening (such as by double-clicking) files that come from someone you do not know, or if you were not expecting them. This includes email attachments, instant messaging file transfers, and other files you may have downloaded from the Internet.

If you want users to think twice about opening files, and knowing that an automated system will never be certain what a “safe” file is, why offer an option to automatically open files that have been downloaded by a web browser? It’s certain that plenty of Safari users without a good sense of what they should and shouldn’t open would turn on this option, and the outcome is entirely predictable. Design flaw.