IMHO, the only legitimate points in this gentleman's post are: (1) a compromised browser defeats OAuth, and (2) OAuth isn't mobile-friendly because it requires browser interaction to gain user consent to grant access.

While both of these are true, Web browsers are ubiquitous; OAuth is a Web standard. You can abuse it slightly to make it work with mobile devices (see "access code grant") but really, it not was intended to be a be-all end-all authorization mechanism.

Likewise, claims that the protocol isn't "enterprise-friendly" are somewhat silly. OAuth was not intended for fine-grained authorization within an authentication or trust domain. It's for cross-domain (cross-application) grants, between unrelated apps, under the assumption that all three parties in the transaction are basically unrelated.

If an executive wants to delegate calendar permissions to his secretary, he should *just do it* by clicking a checkbox on Microsoft Outlook or whatever product they use for scheduling, which no doubt has its own rich permissions system and obviously has its own authentication mechanism. There's no need for a Web standard to facilitate this use case!

As for claims that "there is no standard" -- that's entirely true. There is a draft standard, which presumably will eventually be ratified by IETF once we have all had a chance to play with the technology and suggest improvements. Standards are not an item of worship; they're just a way to ensure that a protocol has had a reasonable degree of scrutiny, has no undisclosed patent encumbrances, etc. I've heard people accuse OAuth of being complex or flawed, but never fundametnally insecure.

Frankly, anyone who thinks the OAuth draft RFC is complex, should choose a dozen or so documents from the SAML protocol suite, relax in a hot bath, and read through several hundred pages of THAT claptrap. Then we can talk about complexity.

(Disclaimer: yes, I do read security standards in the bath, and I create toy implementations of security protocols and algorithms for fun. That probably makes me mentally ill.)

A separate password for each application, is exactly what an OAuth refresh token is. The user is free to revoke the corresponding grant at any time.

Rather unfortunate timing for the headline of this article, considering today's news item about a literal bulldozer that did not fall short...

http://www.latimes.com/news/nationworld/world/middleeast/la-fg-israel-corrie-verdict-20120829,0,4476903.story

Cops are public servants working in public spaces; given that the justification for speeding cameras and CCTV has always been that there is no reasonable expectation of privacy for someone in a public space, why should the public-spaces rights of policemen be any different from those of the general public?

If you are in public, regardless whether you're on the job, you must accept the notion that you could be observed, by people or recording devices. Bear in mind that most COPS have recording equipment in their squad cars and frequently videotape traffic stops.

If the concern were merely about videotaping police work, police departments would be worrying about their own recordings. It seems to me that their concern is about OTHER people recording police work, when said recordings are outside of the police department's control.

No doubt, cloud is a huge buzzword at the moment. No reason you can't use that to your advantage, however.

"Cloud computing" in common parlance means at least three things at the moment:

* A marginal-cost pricing model for compute resources (pay for only what you use)
* Making use of virtualization in one's app architecture
* Pervasive use of automation in the architecture and throughout the software lifecycle (dev/test/deploy)

#1 is a bit of a fad; some workloads can be shoved out into a public cloud with no risk to security or availability, but many workloads will never be suited for that.

However, #2 and #3 are here to stay for the next decade -- and even if computer architecture makes another massive swing (e.g. massive parallelism or quantum computing or some hooey) and virtualization is no longer as sexy as it is right now, automation always has been, and will always continue to be, a key component of successful IT operations. Automation = productivity!

Even a large part of what we call the "virtualization benefit" is actually due to automation-related productivity. The fact that I can take my pre-built OS + app stack and deploy it on whichever hardware I wish -- and in some cases even migrate it between two differently-capable host systems WHILE my guest is running! -- is all a flavor of automation. We've always been able to migrate servers, but it used to require a screwdriver and lots of patience.

So -- my advice is, don't look down your nose at the sudden cloudiness! Take advantage of this buzzword-laden atmosphere to justify your sound technical decisions to the businessfolk, in terms that their feeble minds can understand. ;-)

The quote, actually, is "information wants to be free."

There's no _should_ about it. It's not a value judgement; it's an expression of one of the natural properties of information: that it tends to replicate itself in any way it's able, subject only to the constraints of the underlying medium (and of course to any artificial constraints placed on it, though those have a track record of working badly).

Even "information wants to be free" is a bit imprecise because it anthropomorphizes the information. Data has no intent, there's no "want" there; it just seems that the natural state of information is to propagate, and to mutate as it propagate.

Also, keep in mind that "free software" doesn't necessarily mean free as in beer. If you have heard someone saying "software should be free," they may have been referring to the fact that the source code to the software that runs your life should not be a trade secret locked away in someone's corporate vault.

As numerous generations of software pirates, malware authors and hackers have shown us, to someone of sufficient skill, the machine code to a piece of software yields enough information to mutate or copy that software. Protecting source code is an attempt to create artificial scarcity -- or security through obscurity, if you prefer -- and it doesn't work very well.

Maybe my argument convinces you; maybe it doesn't. It's not really my concern. I'm employed by an open-source software company whose business is growing tremendously year-over-year -- in the middle of a recession, no less! -- and one of the main reasons for our success is that our products are _open_.

Our customers are free to inspect, modify, ask questions regarding, and contribute improvements to the tools we sell them. Because we try whenever possible to leverage open-source dev tools, we enjoy the same openness in our infrastructure and development toolset. We are able to adapt our tools to work well for us, and contribute the improvements back to the community when we're done.

"Free as in beer" is not "free as in freedom." If your industry ignores this fact, it does so at its own peril. Don't be surprised if a lightning-fast innovator comes along and disrupts everyone. And if they do, look for open source to be greasing the wheels of their productivity.