Below The Radar

Remember Google's fascination with massive data analysis?

Now behold the power of traffic analysis, applied to your phone records.

Java Security Model Fail

Java 2 was introduced in 1999, along with its revolutionary security model.

There was just one problem: nobody wanted to use it.

It's been almost 10 years since its introduction, and even though there were nice extensions like JAAS, I don't remember ever seeing applications that were, in fact, relying on Java security model.

Part of the problem, of course, was the fact that it was a pain in the neck to implement. Parts of the implementation were working outside of the security manager, and the bootstrap was neckbreaking. By the time I abandoned attempts to use Java security model (about 2003, having grokked it fully by then) because none of my employers were willing to support it, there were no available common sense implementations such as LDAP security manager, and anything more complicated than a policy file was out of question because you needed to implement it first. I believe this greatly contributed to the overall failure of the security model - Sun should have paid more attention and provided at least basic implementations.

Another part is a perceived performance degradation. Sure there is some, but there is also total absence of hard proof, which, in turn, is caused by total absence of visible implementations that actually used the security manager... Hence, I call bs until I see the actual hard statistics (not that I'm holding my breath for that).

This, however, is complicated by the fact that if you can really compare the performance of a system with the security manager and without one, that'll mean you're doing it wrong. Security manager is much more than simply checking for access, that'll be like using the microscope to hammer nails. Properly using security manager means that it is completely integrated into your application and is an integral part of it.

But I don't think this is happening or will ever happen, except for maybe a few niche products.

Too bad, it was a good start.

---

Update: To be fair, all above is pertinent only to a part of what is declared to comprise the security model today, namely, Authentication and Access Control. Other parts either didn't exist, or weren't officially the part of the security model at the time.

Mark My Words: Google Apps Leasing

There is a major factor limiting the Google Apps acceptance: fear.

Small companies and individuals are able to comprehend the scope, security and privacy implications of Google Apps pretty easily - O horror! Big Brother is watching you! Duh, as if The Holy Triad (Equifax, Experian and Transunion) didn't already sell your intimate financial details to everyone and their uncle.

On the other hand, big corporations are neck deep in quagmires of existing policies - hardware and software procurement and user base, information access and security, legal retention and audit, cost to exit for existing obligations to name a few.

The most important issue in the context of Google Apps is information security and privacy. The very thought of trusting the crown jewels (or, at least, what they perceive them to be) to the outside entity causes a condition close to a heart attack for those that will be held responsible for the decision that's been made. Corporate officials don't like that. They prefer to keep the status quo and, ideally, not change anything at all. Or, at the very least, to deal with known threats.

Consequently, the hell with freeze over before corporations will trust^H^H^H^H^Hturn over their corporate data to Google.

How can Google get out of this predicament? I see two ways.

One, provide the user accessible API that will make sure that the only way to store the corporate data on an outside server is the encrypted way. This, however, introduces the whole issue of key and/or certificate management, which is somewhat familiar (albeit annoying) to IT folks, but which is going to kick the non-IT personnel out of their socks, no matter how simple it seems for the IT enabled. I don't see this happening anytime soon.

Two, allow corporations to physically lease the hardware that hosts Google Apps, like it does it for Google Mini. This will give them the warm and cozy feeling of being in a familiar environment, never mind that the people supervising the installation will probably orders of magnitude less experienced than Google would've dedicated to support tasks. It's BAU (Business As Usual) for them, which gives them an illusion that they can deal with it like they used to, which, in turn, makes them more likely to accept this sort of nuisance.

I've been expecting this to happen since the first time this topic was brought up in a water cooler conversation, about a year ago. Let's see how long it takes Google to deliver.

Mobile Integration: Turn Off The Damn Phone!!!

There are few among as that can say that they always mute the phone before entering a meeting, a movie, or the library, or any other place where the hysterical hollering of the ring tone is at least unwelcome, and at most, sometimes, dangerous to your life (imagine the screeching brakes ring tone that your driver is exposed to - not good).

There are even fewer that actually do.

So I thought, wouldn't it be nice if your calendar had a "change ringer settings" feature that would help you to remember and actually put the phone on mute or vibrate or whatever is appropriate for the occasion...

Of course, it opens the usual can of worms - you don't want everybody and their uncle arbitrarily changing your phone settings due to a vulnerability or simple lack of diligence in the implementation, and of course, the protocol must use strong cryptography supporting trust relationship between your cloud applications and your mobile devices - but I hope that mobile API providers either already have this available, or are working on publishing it anytime soon...

Update: Not a complete solution (in particular, it's not integrated with the calendar), but definitely a step in the right direction: Android Locale.