Podcast: Play in new window | Download

Apple has been criticizing Adobe Systems lately for what Cupertino perceives as poor performance and design deficiencies in Adobe’s Flash web media technology, which it darned well wants to keep off the iPhone and iPad. Adobe, in turn, has been defending Flash, however gently, citing it as a great enabling technology that has got the web in large part to where it is today. Both companies are correct, and that’s the point that seems to be missed by most of the pundits standing around pointing at the fight. Flash has been vital to the success of the web, but Flash is old.

Apple’s preferred media architecture, HTML5, is the future of the web.

Web browsers have swallowed up most every app you used to have to install on your PC. Something like TurboTax needs forms to input data, display tables of numbers, and store your returns on their server. But if you want to have forms smart enough to know what’s a date and what’s a dollar; to draw piecharts; or store your W-2 on your laptop, then you need a new browser.

Flash always picked up where the browser left off, but it can’t talk to your webcam, store local files, or draw pixels directly to your screen. Now, for the first time, a cluster of technologies known as HTML5 allow a standards-based pathway to busting those barriers with canvas graphics, drawing video onscreen, smarter forms, and local storage for private data. So who needs Flash?

John Gruber is right: Flash is responsible for most of the crashes of my Mac. I can hardly blame Adobe for defending its very successful Flash franchise, though it feels strange coming from that nerdiest of nerdy companies. And I admit there are still a few things that Flash can do but HTML5 can’t, but the evolutionary path here is clear.

Where Flash a decade ago enabled browsers to do more, I can see a time coming soon when Flash will force browsers to do less than they might.

It’s time for a change.

Podcast: Play in new window | Download

As we’ve all read, Google recently experienced a massive attack on its network, probably from China, and has threatened to leave the Chinese market as a result. I’ve written about that aspect before (Google taking its ball and going home) but this column is about the attack itself and Google’s internal plans for how to deal with future such problems, because of course this will happen again. I’m frankly trying to understand what Google is up to in its response to the Chinese threat — a response that doesn’t make much sense to me given the details of the attack as published.

First reports of the attack blamed a security flaw in an attached PDF file. Later reports blamed a vulnerability in Microsoft’s Internet Explorer browser. Adobe denies the PDF vulnerability, though the company not long ago issued a security patch for that product. Microsoft confirmed the IE vulnerability. But what’s interesting to me is that I understand from inside Google that the company plans to respond to this Chinese threat by changing its log-in process for web apps to one using a secure secondary server. That’s great, but it wouldn’t have stopped the most recent attack.

Is there something here we aren’t being told?

The most popular secure secondary server access system is called SiteKey and is used by Bank of America and many other financial institutions. The way SiteKey works is you log on to your bank’s computer, for example, by first typing an account identifier which causes one server to generate a picture and another server to generate a pass phrase which together don’t identify you to the bank but rather identifies the bank to you. Trapped as it is in a hash table, nobody at the bank can even tell you what picture you chose but you know it (the pass phrase too) so you can be pretty sure the server you are logging into is the one you want and not some phishing site. If the picture and phrase are satisfactory you can then type in your real password and you are there.

I’m told that Google will soon roll-out a similar system for Google Apps.

But I can’t see how using secure secondary authentication would have had any impact at all on the recent Chinese malware incident.

So I went to a friend who manages data security for a huge defense contractor and he agreed. “Authentication helps, ” he said, “but that was the second part of the attack, the original piece was a carefully crafted PDF file that was executed by the user. No amount of authentication helps against an authorized user. Don’t get me wrong, I am a believer in strong X. 509 based authentication, just it would not have helped against a malicious attachment.”

Adobe says it wasn’t a PDF problem at all. Yet my friend, who is privy to a flow of information the rest of us are not, says Adobe may be technically incorrect in this assertion.  I don’t know for sure, nor do I think it really matters in this case.

“The IE use was a secondary effect (to download the malware using an allowed program), ” he explained. “I’m not sure what they are calling a vulnerability (it might be a feature). The initial vector was the PDF. Typically such an attack is limited in just how large a program can be in the initial attack (hidden inside the attachment).  It has to be just enough to pull the real root kit. Early ones used their own network app but most systems are now protected by personal firewalls that would disallow or alarm. Use of IE would probably avoid this (and explains why large corporations are going to gateway white lists). Bottom line: the attack requires an executable program to be running on the workstation. Once that is in place, anything can be done. ”

The best defense against this sort of attack would have been two-fold. First, strip all e-mail attachments from messages and replace them with a URL. Send one copy of the attachment to a dedicated server that can be set to paranoid. Take as much time as needed to vet the attachment including emulation to see if it is malware or not. Once complete, the URL embedded with the forwarded e-mail becomes active and the attachment can be downloaded.

Google owns Postini, which could implement just such a technique, so we should probably expect that they will do so, making Google apps more secure and therefore more attractive in the process.  In Google’s move to make itself ever more essential to the net they may well offer such a quarantine service as a standalone product, too.

The second part of this solution unfortunately died with Windows Vista — the hated User Access Control (UAC). Temporary privilege escalation with logging, which is what Vista’s UAC provided along with some user grief, is the way to go.

Remember that all the authentication in the world will not protect against a privileged user doing the wrong thing. It’s just that logging may help to determine what happened after the fact.

We have known for years how to fix this, but nobody cared.

Podcast: Play in new window | Download

This morning Google announced it was spending $106 million in stock to buy On2, a maker of audio and video compression software.  The very logical question I don’t hear being asked, though, is why would Google spend money for something it is already getting pretty much for free?  It’s to turn yet another partner into a competitor, this time Adobe Systems.

Google already uses On2 codecs in Adobe’s Flash video, which is the very heart of its YouTube video streaming service.  On2 powers YouTube’s so-called High Quality or HQ service, which due to competitive pressures on YouTube is likely to soon become YouTube’s standard codec.

It is important to remember that Flash video was not a significant competitor until it was embraced by the pre-Google YouTube.  Flash video simply wasn’t that good.  It relied on an antiquated H.263 codec that was originally intended for video conferencing and, while fast, was of not particularly good quality.  But quality didn’t matter to the early YouTube, just fast and reliable streaming connections, which a video conferencing codec could provide.

The lower quality of streaming video had the industry broadly turning away from streaming, moving to the download delivery model championed by Apple with iTunes.  Then YouTube changed everything seemingly overnight.

The important Internet video standards then were Windows Media and QuickTime with Flash video an also-ran.  But how times have changed!  In terms of total connections and streams, Flash video is now the Big Kahuna by a long shot.  And while both QuickTime and Windows Media have moved up-market a bit with their superior H.264 and VC-1 codecs, Flash isn’t far behind with On2 and H.264, itself.

But it isn’t for YouTube alone that Flash must die.  Flash is a combination of an interpreted runtime application environment AND various media containers and codecs.  Well Google has its own runtime environment now in Javascript VM to take on both Adobe’s Flash and Microsoft’s Silverlight.

Adobe and Google have been on a collision course for some time.  Adobe competes with Google Docs, for example, and now they’ll compete on video, too.  And with more than half of all Internet video already going through one Google platform or another, this is an instance where Google probably has the advantage.

With Google finally under some earnings pressure and Internet advertising flat, the company has to enter new markets with new services to gain new profit centers.  It happens all the time in maturing companies.

Just as YouTube gave Flash video its huge success, so Google is now trying to take it away.

I had intended to write a post about Google’s Chrome Operating System, but then the New York Times called looking for an Op-Ed piece on exactly that so I gave it to them.  Look for the column to appear Monday and I’ll put a link to it here.

The Times column is here.

Beyond the broader implications of the Chrome OS, one reader asks about the strategic involvement of Adobe Systems in the project, since Adobe is in the short list of companies mentioned in the Chrome OS FAQ.  Why is Adobe on this list, asks the reader, and is Google likely to buy Adobe?

I have no inside information here, just the usual informed guesswork.  The logical acquirer for Adobe, if the company is to ever be acquired, is still Apple, which would gain some real synergies in its entertainment endeavors as well as some needed technical depth.

What Google needs from Adobe is primarily Flash video.  Remember that YouTube made Flash video a factor in the streaming market and Google now owns YouTube.  Remember, too, that Apple’s iPhone has specifically shunned Flash, somewhat to its detriment.  Apple’s reasoning — that Flash takes too much horsepower for smart phones — no longer really stands with the iPhone 3GS shipping.  So Google’s embrace of Flash video for the Chrome OS AND Android helps YouTube while differentiating both products from Apple.

But does Google also need Adobe’s Flex and AIR platforms?  That is less clear.  Both Flex and AIR are runtime environments for cross-platform applications (Open Source applications in the case of Flex). Knowing a bit about how Google thinks, it is very possible that Flex and AIR will be seen as too heavy and — more importantly — too non-Google.  So we might see Flex but not AIR, for example.  I simply don’t know.

But I seriously doubt that Google will be buying Adobe or, for that matter, making ANY huge acquisitions in the months ahead.