Steve (GRC) Gibson's Blog

Responsible Disclosure?  Ummm, not so much…Sharable Shortlink

On March 17^th, 2011, Art Coviello, RSA Security‘s Executive Chairman, posted a disturbingly murky statement on their website disclosing their discovery of an “APT” (Advanced Persistent Threat). In other words, they discovered that bad guys had been rummaging around within their internal network for some time (persistent) and had managed to penetrate one of their most sensitive and secret databases.  Here is the most relevant piece of Art Coviello’s disclosure (you can find the whole piece here):

As you can see, it would have been difficult for any bureaucrat to be less clear about what they know. But science is science, and the simple realities of what must be going on doesn’t accommodate much bureaucratic wiggle-room:

RSA’s SecureID devices are known to be designed around a cipher keyed with a 64-bit secret. The 64-bit secret is used to encrypt a realtime counter which generates an effective 22-bit value. While this is not many bits of time, the clock is incremented slowly, only once every 30 or 60 seconds, so 22-bits (4,194,304 values) is sufficient to outlive the expected life of the device and the timer would never be expected to wrap around.

One of several forms of the RSA SecurID Token

Each SecureID has an external serial number (printed on the back) that is used to identify and register it with an authentication service.  Hopefully, there is no “algorithm” of any sort for determining the internal secret key from the device’s serial number, since the discovery of such an algorithm would instantly kill the security of the entire system.

In the absence of a mapping algorithm, at the time of manufacture individual SecurID devices would be assigned a secret internal random or pseudo-random 64-bit key and a database would be maintained to forever map the device’s externally visible serial number to its internal secret 64-bit key.

This public-serial-number-to-secret-key mapping database then becomes “the keys to the kingdom”. It is RSA’s biggest secret to keep, since a full or partial disclosure of the database would potentially allow attackers to determine a device’s current and future display values and would therefore, of course, break any authentication protection.

To carry out a successful attack, an attacker would need to obtain its target device’s public serial number as well as one or more current output samples, at a known time, to determine the current state of the device’s 22-bit realtime clock. From that point on, an attacker could reliably determine the device’s output at any time in the future.

What can be deduced from what (little) RSA has disclosed?

• If “the keys to the kingdom”—the public serial number to secret key mapping database—had NOT been compromised, there would be zero danger to users of RSA’s SecurIDs.  But we know at least that the danger is not zero.  Therefore, the most reasonable conclusion to reach is that RSA believes that at least some of  ”the keys to the kingdom” have been compromised. (Because that’s their system’s only real vulnerability.)
  
  
• Users of SecurID, and other multifactor authentication systems, typically do not provide the device’s public serial number when they are using it for authentication … though neither is that number intended to be kept secret (since it is printed on the back of every device.)  This means that an attacker would need to either have brief physical access to a device to obtain its serial number (which would also presumably allow them to obtain a few output samples to determine the clock counter’s current realtime position), or also have compromised RSA’s authentication account registration database which presumably maps user accounts to their device’s SecurID serial number.  Unless RSA discloses more, we won’t know how much more than the secret key mapping database may have been compromised.  Thus, it’s not possible to assemble a comprehensive threat model.
  
  
• RSA may not want to do the responsible thing because it would be very expensive for them… but given the only deductions possible from what little RSA has said in light of the technology, any company using RSA SecurID tokens should consider them completely compromised and should insist upon their immediate replacement.

RSA is understandably embarrassed.  And mistakes do happen.  If employees of a security company are using today’s incredibly insecure desktop toy operating systems, bad guys are going to be able to find a way to penetrate even the most carefully guarded connected networks.

RSA therefore needs to step up to the plate and take responsibility for what has happened. That means recalling every single SecurID device and replacing them all.  No company can consider RSA’s existing deployed SecurID devices to be secure.

You may CLICK THIS LINK to view this blog posting by itself so you can see replies and add your own.

This is what it takes to effect change…Sharable Shortlink

At Noon on Sunday, October 24th, 2010, during the final day of the 12th annual Toorcon Security Conference held in San Diego, two Seattle, Washington-based hackers, Eric Butler and Ian Gallagher, brought web session hijacking to the masses with their release of “Firesheep” … and the world was changed forever.

In case you’ve been somewhere off the grid, and have somehow missed the news, Firesheep is an incredibly easy to use add-on for the Firefox web browser that, when invoked while connected to any open and unencrypted WiFi hotspot, lists every active web session being conducted by anyone sharing the hotspot, and allows a snooping user to hijack any other user’s online web session logon with a simple double-click of the mouse. The snooper, then logged on and impersonating the victim, can do anything the original logged on user/victim might do.

Firesheep’s creators will be the first to tell you that what it is doing is not rocket science. The hacking capability to do this has been known and freely available within the hacking community for many years while the security community has been screaming into deaf ears about the need to fix the easily remedied configuration problems that make this possible. But thanks to Firesheep, reports are now coming in of people seeing other people using Firesheep in public WiFi hotspot settings.

Foreseeably, we will soon be hearing reports — many reports — of all sorts of mischief befalling the accounts of innocent users after they logged onto their accounts from open and unencrypted WiFi hotspots. At that point the implications of these long-standing security issues will finally hit home… and loud end-user complaints will drive the long-awaited changes the security community has been seeking for years.

The ease and simplicity of using Firesheep has transformed web session hijacking from a mysterious command-line driven black art into something for the masses. This is huge.

I said above “the world was changed forever” because I can’t see how it could remain the way it has been in the face of point-and-click web session hijacking.

What needs to change? … Exactly two things:

• 1. WiFi hotspots must encrypt. Period. They can still remain free and open, but they must use WPA encryption to protect their users from casual eavesdropping. As I wrote in my previous blog posting, this is not difficult. The hotspot’s WPA password does not need to be secret in order for all of the hotspot’s users to be protected from casual passive eavesdropping by each other and any other outsiders. For example, Starbucks could simply adopt the password “starbucks” throughout their entire coffee shop chain and have it known to all users. Users get the benefit of knowing that their traffic is encrypted in return for the minor one time burden of entering the “starbucks” password when prompted by their computers.

  Is this perfect protection? No. Because robust endpoint authentication will always be missing from any public-access WiFi system, complex active “man in the middle” attacks can still be mounted, but simply switching to encrypted WPA protocol raises the attack bar very much higher with near zero effort. And, importantly, switching to WPA encryption can be done immediately to offer significant protection to ALL users of such encrypted hotspots, not only just those who might be targeted by Firesheep. It’s just the right thing to do, and it’s SO simple.

• 2. The bigger change that must also be made is for all vendors of web services to switch their connections over to using the SSL/TLS protocol exclusively. Only inertia and laziness has prevented this from being done long ago. It is my hope that the appearance of a tool as popular and easy-to-use as Firesheep will provide the incentive that has been missing for so long. The mischief it will cause should cause end users to demand this enhanced security from their web service vendors.

  Even when a user is not in the process of logging on, they have a reasonable expectation that their interactions with a remote server will be relatively private, not literally broadcast to anyone with an antenna … like a passing Google mapping car. And when those interactions contain the user’s logged on state cookies, as they must for the user to be recognized as currently logged on, a user’s unencrypted session becomes readily hijackable and hackable, making the situation even worse.

Isn’t switching over to SSL/TLS difficult and expensive?

No. The belief that switching to using pure SSL/TLS is any burden was obsoleted years ago with the addition of SSL/TLS Session Resume. Session Resume allows a particular client and server to perform the high-overhead public key negotiation just once (which they always need to do during the secure SSL/TLS logon anyway) and to then reuse those negotiated credentials for all future SSL/TLS connections being made. Since the credential reuse duration is typically 24 hours, very little additional burden is placed upon either the client or the server as a consequence of using SSL/TLS pervasively across a web site … always and for everything.

ALWAYS Authenticated & Encrypted – It’s WAY past time.

The idea of using SSL/TLS pervasively has been growing slowly but has, until now, been slow to catch on due to inertia more than anything else. Various client-side add-ons, such as the Electronic Frontier Foundation’s (EFF) HTTPS-Everywhere add-on, or Force-TLS, attempt to induce the client to push for SSL/TLS from its end. And the emerging HTTP Strict Transport Security (HTTP-STS) extension would allow web sites to enforce their own intention to only accept secure connection from clients.

This is all good, but someone needs to light a fire under the WiFi hotspot providers and web service vendors to make this happen … which is precisely why I am so pleased that “Firesheep” has finally happened.

The ground has already been prepared for the move to pervasive authentication and encryption. Let’s hope that the user, press, and provider communities will become upset enough over the appearance of Firesheep that these long-awaited security changes will finally be made. If that could happen, the world wide web be a far better and more secure place to hang out and play.

What any open hotspot can do to protect its users…Sharable Shortlink

For example, Starbucks could simply set their password to “starbucks”, Peets Coffee to “peets”, Panera Bread to “panera” … and every user of those free wireless hotspots would be protected from the Firesheep threat … and from much more. Or, by general agreement, all free and open WiFi access points could simply use the password “free”, which would work just as well.

As long as the universally supported WPA encryption protocol is used, each individual user receives their own private “session key” that absolutely prevents eavesdropping between users, even through they are all using the same WiFi password.  It’s just that simple.

Hotspots only need to switch from “no encryption” to WPA and post or publish any static WPA password … and a large part of the problem, and more, is solved.

I have posted a following-up to this blog posting with a detailed look at Firesheep, and why I think it is such a fantastic thing to have happened. But before I wrote that I wanted to quickly publish the idea of simply encrypting with WPA under any simple static password, since that will instantly lock down any public WiFi hotspot.

What the evidence indicates is going on…Sharable Shortlink

On Friday, June 25th, I tweeted a link to a YouTube video created and posted by one of my Twitter followers — @antio — whom I have every reason to believe is legitimate and well meaning. In this brief (53 second) video we see a convincing and rather horrifying demonstration of what appears to be a serious design flaw in the brand new iPhone. For your reference, here’s the YouTube video link:

iPhone 4 Antenna Problem is Caused By a Design Flaw, Not Signal Blockage

Mentions back to me from new iPhone 4 owners were mixed, with some confirming Anthony’s demo and others unable to confirm it and being suspicious of the results.

However, as an engineer I can propose a useful theory to explain what everyone is seeing, and not seeing — and even why Apple shipped the iPhone as it is — as follows:

In other words, say for example that the iPhone is able to deliver a good clear conversation when receiving only 5% of the signal strength that you might have when standing in the shadow of a cell tower. Even though 5% signal strength is far less than 100%, if it delivers a strong and clear conversation, it’s enough. So Apple’s engineers calibrated their digital “5-bars” digital display to show all 5-bars at any signal strength from 100% all the way down to 5%. It’s only when the received signal strength begins to drop below 5% that conversations suffer, calls get dropped, and Apple starts to take bars away from their 5-bar display.

Now imagine that “bridging” the cellular and WiFi antennas by placing one’s hand across the black insulating antenna gap causes a 5% drop in received signal strength.  If you initially had, say, 80% strength, now you would be down to 75%… and you’d still have all five bars, since you still have way more than the 5% required for clear calls.  Thus, you would see and hear no effect from either deliberate or inadvertent antenna bridging.  But if you only had 5% incoming signal strength with the antenna completely in the clear — thus no remaining signal strength margin even though you were seeing 5-bars — and you then bridged the antenna, dropping the signal strength by 5% down to 0% … you would see exactly what Anthony’s video demonstrates.

It’s unfortunate that we don’t have a useful “full range” signal strength display showing us the true received power throughout its entire possible range from 100% all the way to 0% — because I believe there would be much less confusion if people could see what was actually going on.  But for now we don’t.

Whatever the case, it does appear that Apple’s latest phone, with its externalized and perhaps too accessible antennas, should be wrapped in an insulating case of some sort in order to not only keep it safe from bumps and bruises, but also to allow its antennas to operate without the attenuation created by direct contact with the phone’s owner’s body.

UPDATE: Don’t miss the comment to this posting by Simon Byrnand who adds some great real world numbers and confirms my engineering theory.

ONLY NECESSARY for Windows XP and Server 2003Sharable Shortlink

A bit of background:
On Saturday, June 5^th, Tavis Ormandy, a security researcher employed by Google, provided acknowledged proof to Microsoft of a previously unpublished and unknown vulnerability affecting the XP and Server 2003 versions of Windows (neither Vista nor Windows 7.)

Then, five days later, breaking from the “Responsible Disclosure” tradition of providing a software publisher time to research and repair the problem prior to disclosing its existence to the world, Tavis did just that in a high visibility posting on Thursday, June 10^th.

A predictable fracas has arisen because Tavis’ employer, Google, and Microsoft are increasingly seen as competitors in “the race to the cloud” as personal and corporate computing move from the desktop and into “the cloud” of the Internet and the Web.

For his part, Tavis appears to be no big fan of the Responsible Disclosure paradigm, preferring the “Full Disclosure” approach. Tavis suggests that anyone interested consider the published opinion of the much-respected security researcher and cryptographer, Bruce Schneier:
http://www.schneier.com/essay-146.html
http://www.schneier.com/crypto-gram-0111.html#1

Tavis attempts to explain that he performed this research — and made this disclosure — on his own behalf and not under the auspices of his employer, Google. But neither he nor Google are getting off so easily. (It occurs to me that he could have easily made the disclosure anonymously if he had wanted the information out there without dragging Google into the controversy. But, for whatever reason, he chose to employ his public persona.) Microsoft has also gone public with their unhappiness, making it clear that Tavis is a Google security researcher.

Why does any of this matter to us?
Unfortunately, the surprising amount of noise created by the details of this disclosure have lifted “just another 0-day vulnerability” (which would be bad enough all by itself) well into the spotlight, making it all the more likely to be exploited. Google News (note the irony) currently finds 207 separate articles on this topic! How can malicious hackers resist this one? They won’t.

And the second bit of bad news is that this is the worst sort of vulnerability: Trivial to cause malicious code to run on the users’ computer, with a public, very complete and thorough description including sample code. Since Microsoft was given very little notice, and since their monthly “Patch Tuesday” occurred just two days before the vulnerability disclosure, it’s unclear whether the world of XP users will need to wait a month, more than a month, or less … But it could be a while.

Therefore, XP users may wish (and would probably be well advised) to immediately disable their system’s “hcp” protocol handler simply by renaming its Key in the Windows registry. (I prefer renaming, Microsoft offers several more complex workarounds. See the link under “Workarounds”.)

If you choose to follow my simple renaming suggestion, do the following:

1. Run XP’s “Regedit” registry editor by clicking on “Start” then choose “Run”, enter “regedit” in the Open field, then click “Ok.”
2. Find the “HCP” protocol key by searching the registry: Using the Regedit application, select “Edit” from the menu, then “Find…” As shown in the sample below, enter “HCP” into the “Find what:” field, then uncheck “Values” and “Data” and check “Match whole string only”. With the “Find” dialog set as shown below, click the “Find Next” button…

   …some time will pass while Windows searches through the registry to locate the “HCP” key…

3. Once the search stops, you should see the “HCP” key highlighted as shown below:

   

   Verify that the correct “HCP” is highlighted by checking the lower-left status line which should show “My Computer\HKEY_CLASSES_ROOT\HCP” just like the sample above.

4. Right-click on the “HCP” key, choose “Rename” from the pop-up menu, then change the key’s name to “HCP-OFFLINE” (or whatever you like other than “HCP”).

Following the simple instructions above will immediately (no reboot required) eliminate your system’s ability to launch the vulnerable and defective Help Center application in response to an “hcp://” style URL link — now you’re safe. That’s what you want until Microsoft updates and repairs the newly public vulnerability in Windows Help Center.

You can test it too!
If you’re a belt & suspenders sort of person (as I am) you can test your system’s vulnerability to the exploit both with the “HCP” key named “HCP” and also “HCP-OFFLINE” (or whatever you may have named it). Under the “Consequences” section of Tavis’ original posting to seclists.org, he provides proof-of-concept links for users having IE7 and IE8 (and the IE8 link was effective with my Firefox system).

But please remember!, this is admittedly a horrendous kludge that you will need to remember to “undo” — by restoring the renamed HCP key back to “HCP” once Microsoft repairs their code. Still, it’s all we have for now and it’s arguably better than having our machines taken over remotely.

Consider immediately upgrading to Adobe Flash v10.1.Sharable Shortlink

SECURITY ALERT: The threat posed by the new zero-day (no warning, discovered by its active exploitation “in the wild” against users) flaw in all released versions of Adobe’s FLASH player — on all OS platforms — which can also be vectored through malicious PDF files to invoke FLASH, appears to be growing rapidly.

The bad guys are jumping on this one hard and fast.

Given that Adobe first learned of this problem a little after 10 AM Friday morning, June 4^th, and that their quickest previous response to a similar threat was 15 days, the world may be waiting several weeks for a fix from Adobe.

Two things must be done for you to be safe:

• First: The good news is that the next major release of FLASH, version 10.1, is reportedly NOT vulnerable to this attack. Although v10.1′s release is not yet official, it has had seven release candidates and is currently very stable and usable. Therefore, anyone whose Internet usage might subject their machines to malicious FLASH content (depending upon how widely you surf the web) would be well advised to install the next major release of Adobe’s FLASH player, version 10.1, immediately. You can find additional information, and everything you’ll need at the following Abode Labs link:
http://labs.adobe.com/technologies/flashplayer10/

• Second: (Windows ONLY) Both Adobe’s Reader and Acrobat contain their own built-in and equally vulnerable copies of FLASH in a file called “authplay.dll” (and most people have Adobe’s free Reader installed.) This allows PDF documents to contain and “play” embedded FLASH content — even though only malicious hackers ever do that. If by any chance you are still using version 8 of Reader or Acrobat, you are safe. But any 9.x and later versions are vulnerable. Therefore, the best thing to do would be to rename any copies of “authplay.dll” on your system to “authplay.xxx” so that your system won’t be able to find them. Once new versions of Reader and Acrobat are available they will bring a repaired copy of “authplay.dll” and all will be fine (at least until the next vulnerability is found). The “authplay.dll”s are typically found at:
C:\Program Files\Adobe\Reader 9.0\Reader\authplay.dll for Adobe Reader or
C:\Program Files\Adobe\Acrobat 9.0\Acrobat\authplay.dll for Acrobat.
You may also wish to search your system drive for any files of that name and rename them. Adobe’s vulnerability advisory is available here:
http://www.adobe.com/support/security/advisories/apsa10-01.html

They’re being called “Media Tablets,” I call them the future.Post’s Permalink

Announcing my new “Pad-oriented” Twitter Account: @SGpad
I am splitting my Twitter Tweeting into two separate accounts: @SGgrc for non-Pad notes, thoughts, comments, observations and news… and a new account: @SGpad for Pad-specific content — And I don’t mean only “iPads,” I mean ALL pads. If the industry’s new “media tablet” computing phenomenon leaves you cold, please do not follow me at @SGpad — I don’t want to worry that I’m annoying you with endless drivel about which you couldn’t care less. But if you ARE as interested in the birthing of this truly significant new computing paradigm as I am, please DO follow me at @SGpad — and I won’t worry about pad oversharing.

It is so rare for us to be present to witness the birth of a major new computing paradigm. But we are at the beginning of one today. “Pads” are no more a passing fad than the Internet. A portable, long battery life, instant-on, color, responsive personal tablet that’s always connected to the Internet makes so much sense. Apple has demonstrated a new product category and most of the world has “gotten it” instantly.

Whether you’re a staunch Apple advocate who waited in line to be among the first to acquire an early iPad, or if you are holding out to see what’s next from Google with Android, RIM’s Blackberry pad, Hewlett Packard’s WebOS pad, or who knows what … pads are happening.

My previous posting “The Obvious Genius of iPad” outlined why I believe the “pad” paradigm represents a major breakthrough for the personal computing industry. You have likely heard by now that Apple sold more than 2 Million iPads in less than the first two months of the device’s availability. Analysts are now scurrying around revising their “numbers” (way upward) in the wake of that news. And we’re seeing a stream of articles by people who, after using their iPads somewhat skeptically at first, have confessed their conversion (much as I did after a few hours).

(I initially purchased the cheapest iPad since “Jobs was not going to get me.” But after playing with it for three hours, I jumped online to pre-order the most expensive one since… “this thing rocks!”)

Again, note that when I say “pad” I am deliberately NOT saying “iPad.” My intention is to use the generic term “pad” to refer to any long battery life (all day), instant on (very long standby), cellular connected, thin (pad-like) portable device which is more oriented toward consuming Internet media than producing it.

Although Apple showed the way with their iPad, this new product category will be getting very crowded very quickly. There will inevitably be many failures along the way, with companies throwing anything they can cook up against the wall to see what sticks. (And, believe me, there will be some real stinkers.) But don’t let the many failures confuse you; this is a bona fide new personal computing category that everyone wants in on, and there will be room for as many players as there have been for laptops … if not more.

I have spoken my peace on the topic for the time being, so I won’t be belaboring the point endlessly here. You know what I believe. If you do want to follow along with my future discoveries and observations, my new Twitter account @SGpad, will make that easy.

Whatever happens, and however it all shakes out, I know we’re in for some great fun!

Thank goodness Apple can’t patent what it got right…Post’s Permalink

…because now the entire world “gets it” and we’re off to the races. In plenty of time for Christmas 2010, Apple’s iPad will only be one among many successful tablet devices.

Why? Because although no one else saw what to do beforehand, everyone can see what to do now. Now it’s obvious. Apple deserves genius-level credit for showing the way, but has no means for preventing everyone else from following. And follow they will. As many as 40 me-too pads are already in the works. They won’t all acquire critical mass, but many will. And many will dramatically undercut the cost of Apple’s higher-end iPads while offering significant additional features.

Pads, “i” or otherwise, can obviously succeed merely by up-sizing a touch-based smartphone OS — just as Apple did. Today we have Google’s already successful Android OS with deployment in smartphones now exceeding that of the iPhone. And we have the might of Hewlett-Packard to bring Palm’s WebOS to market. Both alternatives are ready-to-scale touch-based operating platforms capable of driving any non-Apple pad. And that’s precisely what they’re going to do.

Apple’s biggest problem is that the iPad was only incredible until the first moment of its existence. This explains why the world was instantly split in its opinion of the device. Yes, it’s spectacular, and also … No, it’s not.

Do I love my two iPads? Absolutely — more than any other gadget I can remember. But that’s only because, today, the iPad is the only pad available. A year from now I may well be more in love with an Android- or WebOS-based pad — because it’s the “Padness” that’s the point. And the likelihood of my disaffection from the iPad is increased dramatically by Apple’s self-defeating decisions, such as its obvious war with Adobe creating serious product deficiencies. Steve Jobs exaggerated when he said the iPad gives us the whole Internet. Without Flash, parts of the Internet everyone else has are offline and out of reach. And, of course, Apple’s famously horrible single-carrier (U.S.) choice of AT&T demonstrates just how much pain, and how high a price, the world is willing to pay to have Apple’s goodness. But that undeniable hubris only succeeds in the absence of alternatives.

There can be no denying that Apple does may things right. But in return for delivering world-class fit and finish Apple extracts a steep price from the consumer. And it’s not just the one-time cost of the device at retail, but the ongoing cost of having an important piece of highly used technology locked up behind the wall of iTunes. This operational model made sense when iTunes only provided DRM (digital rights management, i.e. copy-protection) for iPod music. And it still mostly worked after the iPhone and the App store were added. But for a device that is trying so hard to be a computer, locking up the iPad behind iTunes really starts to chafe.

So for the record, to help all of the me-too pads also get it right, exactly what did Apple get right?

• More than any other single thing, what Apple got right about the iPad is its more than twelve-hour battery life. People feeling the heft of the iPad for the first time are often a bit surprised by its weight. It weighs what it does because the iPad is best described as “a large flat battery with a screen.” If you’ve seen photos of the iPad’s innards you’ll have noticed that the entire interior, except for a small processor board, is filled by two batteries. That all-day-sucker battery life, coupled with cellular connectivity, dramatically increases the device’s value and utility.

• Long-term standby or “Instant On” [I added this 6/1/2010 since I forgot it initially!]
Just the thought of waiting to boot a Windows laptop is enough to squelch quick and casual connection to the Internet. So the importance of the iPad’s “instant on” always-ready-to-go availability cannot be overstated.

• The stunning In-Plane Switching (IPS) LCD display is another of those subtle things that Apple’s engineers got right. The color-faithful wide viewing angle of the iPad’s display lends a great deal to the feeling that this isn’t like other screens.

• And the “central committee” design of the iPad’s user interface delivers a uniquely coherent, highly usable, largely discoverable, and infrequently frustrating user experience. This is very important, and it is where the me-too wanna be pads are most likely to suffer: Android based pads, being inherently open and highly ad-hoc, are likely to be, like the Android phones, sort of a mess.

Regardless, non-Apple pads will be here very soon. They will be much less expensive, much less restrictive, loaded with many more features, and could arguably be called the pads for the rest of us. Until then, I’ll be using and loving my Apple iPads, not because they are from Apple, but because Apple was absolutely right about the previously unappreciated need for a large-screen, long battery life, touch-based Internet-connected appliance. That’s all the iPad is; nothing more, nothing less. Not magic, but a touch of obvious genius that everyone else now sees.

Cold-blooded Calculations for Corporate ProfitPost’s Permalink

The truth is, it is neither a corporation’s mission nor its obligation to serve its customers. A corporation exists as a soulless synthetic legal entity whose singular purpose is to maximize its shareholders’ wealth. This is something the public too often and so easily forgets in the wake of the mind-numbing marketing created specifically to cause us to misunderstand the corporation’s true raison d’être.

McDonald’s doesn’t serve hamburgers to feed us, they feed us to serve themselves.

When tension arises between the needs, rights, and expectations of the corporation’s customers and that corporation’s goal of wealth maximization, simple economics prevails: “What will make the company the most money?”

Anyone who was at least a teenager in the early 1970′s will recall the rather horrific case of the Ford Pinto: When the Pinto was “rear ended” in an auto accident, sharp pieces of the rear bumper system often pierced the gasoline tank, located just inboard of the rear of the car, causing it to catch fire and often incinerating the car’s occupants.

When this seemed to be happening more often than it “should,” it came to light that Ford’s management had long known of this literally fatal design flaw in their car. But many of these defectively designed Pintos had been manufactured and sold. Ford’s infamous “cost-benefit analysis” — subsequently obtained by the press — revealed that the company would be more profitable if it paid the statistically predicted number of wrongful death claims that it knew were likely to arise in the future, rather than recall the Pintos for an $11-per-car modification. That must have been some board meeting.

What does any of this have to do with Facebook?

Just this: Facebook is not working for the interest of its 400 million users. Facebook is a corporation like any other, whose sole mission is to maximize its corporate profits. Unfortunately, the only “asset” Facebook has to monetize is the wealth of personal information that has been poured into the system by every one of those 400 million users. Facebook has understood this from day one, its user community has not.

The public relations disaster Facebook brought upon itself by overreaching and overstepping might not have occurred. They might have gotten away with it. Or it might not have been so bad. Or it might have blown over. Or, or, or. But you can bet your last dollar that what just happened wasn’t a mistake. This was a calculation like any other — a calculated asset leveraging they hoped to get away with.

What was their mistake? They were too impatient. They pushed too far too fast. In retrospect, they would have been wiser to creep these changes out incrementally and more slowly, allowing each one to be digested and giving the world time to grudgingly accept the creeping loss of Facebook privacy and control.

So, that’s what they’ll do now, they’ll fall back to Plan ‘B’.

Facebook still has only one asset — its community’s personal information. Sooner or later that asset will be fully monetized. It now looks like it’s going to be a little bit later.

Yes, it’s true…

Sheesh!   What’s next?   First it was Twitter accounts for GRC and me (@GibsonResearch and @SGgrc respectively) and now blogs for both?  Hmmmmmmmm.  But fear not, the world as we know it is not coming to an end.  er… or at least not for this reason (there’s always the annoyance of the random massive asteroid.)

But no, there does appear to be a method to my madness:

It all began with my wanting some means for letting people follow along with the development of the CryptoLink VPN product, which will be GRC’s next major offering (see the GRC Corporate News blog for additional information about CryptoLink). My plan is to deliberately take a development path that will quickly create a useful and workable product, rather than waiting until the end to have something finished. This approach will allow me to get feedback from early adopting users all along the way, will involve CryptoLink’s users by giving them an active say in the shape of the final product, and won’t make everyone wait years for a totally finished product. (My plan is to add a lot of features, but to do it incrementally with a large number of releases.)

But that approach meant that I needed to have some good means for communicating to an audience larger than the interested subset of people who hang out in the GRC newsgroups.

Another completely separate motivation for these blogs was that GRC’s own eMailing list had grown so ridiculously large (793,975 members at the time of this writing) that it had become impossible for me to send anything out through it without it being instantly shut down for eMail spamming the Internet.

So I figured that if I were to create Twitter accounts I would be able to send out news of updates, and anyone wanting to keep track of what was happening with GRC and me could subscribe to receive notices of updates to this blog. So GRC’s eleven year old eMailing system will soon be migrated to a modern blog-based model.

• Subscribing to this personal blog…
If you are curious to know more about what’s going on with me — a more “behind the scenes” view — you can subscribe to this personal blog (see subscription field in the upper right of this page) to be notified whenever I have posted anything here. You can also “follow” my personal twitterings (tweets) through Twitter at @SGgrc.

• Subscribing to GRC’s Corporate News blog…
For purely GRC work-related information and updates, you can subscribe to the GRC Corporate News blog (at blog.grc.com) to receive notices of any updates I post there. You can also “follow” my GRC work on Twitter at @GibsonResearch.

So, if you should choose to tag along, I think we’re going to have a LOT of fun! And, either way, thank you so much for your interest and support of GRC and of my efforts here.