Archive for February, 2009

EMBED in OBJECT, and both in VIDEO

Mozilla staffer Chris Double has one of the best blogposts I’ve yet seen on using the currently-proposed VIDEO tag in a realworld environment. It’s more realistic than other markup I’ve seen in that it goes beyond a single-browser audience. I would have commented there, but he requires either Google notification, or OpenID (which has been funky for me), so I’ll make a larger blogpost about it instead.

One of the most interesting aspects is that he’s addressing the age-old nesting of OBJECT and EMBED tags by [drumroll] wrapping a VIDEO tag around them both… VIDEO tag on the outside, then an OBJECT tag, then on the inside an EMBED tag. It makes sense, considering how HTML4 blessed Microsoft’s later OBJECT while dysfunctionally deprecating Netscape’s original EMBED, but to see three nested tags just for one media element, I got a kick out of that, and you might too.

The real reason I wanted to comment was on Chris’s line about transport controls: “These fallback options don’t allow creating your own controls with JavaScript and using the nice HTML5 media API.” There’s hope… Flash, of course, has been providing the world’s computers with customizable UI elements for a very long time, no browser variance to worry about.

But you can still do it in JavaScript, if you prefer… the varied protocols for plugin/browser intercommunication have all been quickly supported by Flash, and it’s quite possible to have JavaScript control a Flash video. For practical work you’d also need to include the Microsoft protocols for browser/ActiveX intercommunication, to reach the majority of people on the web, but it’s doable.

(I know that other people have driven video from JavaScript before, but I’m not sure how to search it up… if you happen to know of existing libraries they might use, could you drop a note in comments here please?)

The unspoken question in all this, of course, is “Why?” Making two formats of a video is something that very few people would find worthwhile to do. But as an intellectual exercise it’s certainly novel… VIDEO enclosing OBJECT enclosing EMBED, the tagging inspires a certain perverse fascination. Check it out!

Acrobat Security update

There was a lot of press Friday on a new “malformed PDF can crash Reader, potentially leading to foreign execution code”. Unfortunately, there was far more press text than source text. The Adobe Security team has better source info in this blogpost.

If you regularly open PDF files from untrustworthy sources, it can help to disable JavaScript, but this does not address the root issue, for which Adobe will be issuing new versions of Reader and Acrobat.

Better than disabling JavaScript is to make sure that your security software is updated. The Adobe Security blog has a list of third-party vendors who have already updated their scanners to deal with such malformed PDF.

I do not know whether non-Adobe PDF renderers are vulnerable. I do know that folks within Adobe have agonized about the wait for public information disclosure, and that organizationally we’ll be able to move faster in the future, but (as the “disable JS” rumor showed) it’s vital to go past the surface issue to the root issue, and it’s vital to consult with industry partners to meaningfully improve the security situation.

Anyway, please accept my apologies for the delay, but solid info is now at hand. New software due in 14 days.

If Plugins Never Were

Thought experiment: What might the world be like today, if Netscape Navigator 2.0 hadn’t exposed a plugin API back in 1995?

The decision back then was based on sound history, of course… tools like Adobe Photoshop had already made third-party plugins popular… before that, the XCMD/XFCN extension mechanisms in Apple’s HyperCard proved useful and innovative, and Macromedia Director followed with cross-OS XObjects and then Xtras (one of which, XCMDGlue, let you bring in prior HyperCard extensions)… in the wider world before that there were COM, CORBA, and you could even see the hints in the UNIX “pipe” process. “Small pieces, loosely joined” was a proven model for the benefits of extensibility.

But suppose Netscape Navigator entered a parallel dimension, and stayed just one big isolated hunk of code, trying to do everything itself… how might history have turned out?

Microsoft Internet Explorer would likely have continued with ActiveX extension of their browser… their business drivers for third-party extensions were wider than just playing catch-up to Netscape at that point. At least one browser would still support open extensibility, but there wouldn’t be the cross-OS Netscape Plugins API.

In such a world you could extend the Microsoft browser, but not the other browsers. Microsoft’s relative openness would have been a significant advantage over other browsers.

But early on it probably wouldn’t have made much difference. There was an intense period of plugin exploration during the mid-90s, hundreds of browser extensions attempted, but few gained enough consumer support to make a difference. VRML authors would have just worked on the desktop, in networked applications, if they couldn’t extend the browsers. Shockwave is still one of the most popular plugins, with majority presence on consumer desktops, but there were few Shockwave apps which changed how people used the Web. Adobe Reader worked both in-the-browser and as a separate client application, so we’d probably still have Internet access to documents. Java has a number of roles beyond in-the-browser work, and it would have survived in different form. The inability to add third-party renderers would not have made much difference in the mid-90s.

Oddly, one of the most significant plugins in this alternate history of “a world without plugins” might have been Progressive Networks and its Real Audio. They did the first work in making audio available in browsers, only being eclipsed later by Shockwave’s inclusion of Fraunhoffer “MPEG 2 Layer-3” audio, and the later popularization of this as generic MP3 files. Real Video was constrained in its early years by bandwidth and decompression costs, but the whole MP3 revolution, which toppled empires, would not have been possible if third-party developers could not experiment around the edges of the browser core.

Think of the beauty of what Real offered… one codebase for Windows, one for Mac, and you could then use any browser you wished, so long as it supported the common Netscape Plugin API. Every browser had an equal chance to host hot new features… browser-makers were enfranchised, automatically, if your app could be extended.

But without a common extension mechanism, each browser would have to reinvent the wheel, and content developers would have to test against varying browser choices. New browser makers would have a higher hurdle before being able to compete.

The story takes a twist when we get to the late 1990s. Netscape 4 was as reviled by web designers then as Internet Explorer 6 is despised by web developers today.

Netscape dropped from the heights down to single-digit popularity in those dark days.

If Microsoft had added audio and video into its browser directly, rather than through a common extension mechanism, Netscape would have been even less able to compete. Being able to share in the innovation, through plugins for Apple’s QuickTime, Real Media, and even Windows Media, kept Netscape in the mainstream of capability.

And if the new Mozilla had been forced to license the codecs Microsoft supported before Firefox could attempt to play the world’s music or movies, well… they likely wouldn’t have made it.

In our world today you can surf The World Wide Web in Opera, Camino, Konqueror and so on… YouTube, Flash games, election charts, whatever. Those smaller companies didn’t have to engineer support for the world’s existing video and RIAs on their own. The stability, accessibility, and universality of common third-party plugin capability makes it easier for specialty browsers to participate in the full web.

Plugins enfranchise browsers.

And it goes beyond browsers. The Hypertext Markup Language is useful for desktop applications and embedded devices, not just web browsers. A hypertext markup spec which imposes specific video or drawing, synch or processing requirements on implementers would stunt experimentation and innovation.

If there were no plugins, you’d likely now be going to Internet Explorer to get your real work done. And considering what happened after Microsoft won the browser wars in our world, it’s a safe bet that in that “world without plugins” they’d still be at IE6, if that.

A world without shared plug-in capability… well, think about it, a little more, yourself. It’s bleak.

Here’s my main point. “Small pieces loosely joined” creates a supporting ecosystem of technology… living, breathing, decentralized decisions. But creating a few giant monoliths of feature-creep code is just plain not as lively. I think the Apple/Google drive behind the current over-ambitious HTML5 spec would lead first to confusion, then to anti-competitive barriers, and then to sterility.

I want the HTML planners to focus on making things easier and more predictable for web content publishers. I want a smart kid in a rural third-world village to have a chance to learn how to publish to the world. I want hypertext markup accessible to more creators.

I want the HTML planners to make the basics work right. Make it easy to create a browser. Make it easy for anyone to compete against today’s reigning browser brand.

I want webpages which can integrate third-party content with safety. Warn us about web beacons. Beat clickjacking, and give us back “What You See Is What You Click”.

I want browsers to improve their handling of plugins… clean up your OBJECT/EMBED hassles now, it’s 2009… improve JavaScript/Flash communication and make it consistent… take advantage of today’s video. Stop treating plugins as a second-class citizen or, worse, a refugee class.

I want “The Open Web” to work well with others.

I want “The Open Web” to open up, to be “small pieces loosely joined”.

I do not want a future where only a few mega corporations can afford to create a browser.

I want HTML to succeed. I do not want to see it fail through ambition and inefficiency, like Netscape did. I want HTML to get smarter by getting simpler. I want HTML to get sustainable, to succeed.

Imagine a world where plugins never existed. Can you picture it? Can you see how history would likely evolve, were cross-browser capability only up to the browser vendors?

Cross-browser plugins have made our web what it is today. They should be celebrated.

And what I want is for browser vendors to acknowledge plugins as first-class citizens.

“… because it ‘IS’ proprietary.”

… because it is sinful.
… because those are fattening.
… because they are witches.
… because he’s a stupid jock.
… because it is indecent.
… because they are sheep.
… because we are the chosen ones.
… because it is God’s will.
… because it is healthy.
… because it is perverted.

Because the territory “IS” the map.

Lots of bad things have happened on this planet, because labels were slapped onto realworld things, leading us poor humans to characterize the world in a binary “sinful/non-sinful” way.

“It’s our right, because it’s a dog-eat-dog world.”

“It is safe to drive, because the light is green.”

“That is not good, because it is proprietary.”

That’s what struck me in a conversation today. I’ve been reading up on Mozilla’s Bespin project, trying to understand it, and someone in comments (anonymous, unfortunately) raised the question I had been asking myself

On one hand, we have folks, at Mozilla and elsewhere, telling people that open standards like HTML5, CSS, SVG, the DOM etc. are the way to go for building advanced interfaces on the client side, instead of using proprietary solutions like Flash or Silverlight.

On the other hand, we have other folks, also at Mozilla, saying that none of that stuff was good enough for them, so they had to go straight to 2d drawing primitives and rebuild everything from scratch. At which point, there is no technical reason not to do it with Flash instead, and get the additional benefit of running on all browsers now, with no compatibility concerns.

Two replies followed: “Actually, canvas is an HTML 5 standard, not a proprietary solution. It’s a peer to any other feature of HTML.”

Also: “There are huge differences between canvas and Flash: canvas IS an open standard (see HTML5) and there are multiple interoperable implementations, even multiple excellent open-source implementations.”

I reacted pretty strongly, mostly about the “is a standard” distortion offered as justification.

But the more I thought about it on the walk home, the more concerned I grew with the structure of the communication, beyond its particular factual details.

“This is this, and that is that, and it’s all very clear and distinct” is a useful mental tool in some situations. It makes things easier to learn, for one.

But such binary labeling can become a trap as well. In online debate, many use the phrase “because it’s proprietary” as a cheap way to stop thinking. I’ve been trying in good faith for years and years to pierce past that sophisticated-sounding “proprietary” label, to little result.

Still, the map is not the territory. The menu’s not the meal. Slapping a label on something doesn’t substitute for thinking it through.

I think it’s better to evaluate specific risks and specific benefits of various offerings, and not just reject “because it is dirty”. Your labels are your traps. Free yourself.

If you think that “because it’s proprietary” is sufficient argument, then please do continue be careful in intersections. “Because the light was green” may not prove quite enough to protect you from reality.

Reading notes on Barcelona announcements

Big news yesterday… even further industry support of Open Screen Project, redistributable Player for Nokia and Microsoft smartphones, new Acrobat Reader for mobile with reflow layout, a $10M fund for mobile projects, more. Here are the press releases.

I spent most of yesterday reading commentary. Here are some quotes which caught my own interest — not an overview, more like reading notes — background info up towards top, third-party reactions down toward the bottom.

The one-sentence summary? Computerworld phrased it well: “Google, Microsoft, Palm and Nokia are all expected to release systems or phones next year that will be able to display the same videos and applications as the most recent Flash 10 player for desktop computers.” That’s the new cross-device runtime, beyond the old and very successful Flash Lite runtime. Big momentum now.

On stats, you may have heard that “one billion Flash Lite devices shipped” phrase when it broke into news a few weeks ago… Adobe delayed a press release until this World Mobile Congress event, in case you were wondering about deja vu. There was also a stat of “Flash Lite shipped on 40% of all new handsets in 2008” which was new to me, and which I haven’t seen sourced… I’ll be trying to lock that down, get a link.

[Update, 02/24/09: The stats both came from Strategy Analytics, in this PDF: “We estimate that over the next 2 years alone, around 1.5 billion Flash Lite enabled phones will be shipped globally, taking the cumulative total to over 2.4 billion handsets by the end of 2010. Flash Lite is being installed in a greater number of handset models from more OEMs than ever before and penetration is expected to grow from 40% at the end of 2008 to over 61% by the end of 2010.”]

The Reader Mobile news didn’t get as much play as the Flash announcements, but it’s significant… the concept of “PDF reflow”, where existing PDF can change its layout to display efficiently on small screens, is huge… adds one of the benefits of HTML to the predictable-layout capabilities of PDF. There’s also support for the EPUB standard (digital books) and Adobe Content Server (protected documents). The press release lays out the significance, and Bill McCoy is a good source for news.

I don’t know the support structure for the Redistributable Player — who handles an update if something goes wrong, etc. It’s apparently limited to machines with an operating system which supports live updating, and is geo-restricted.

“Consumers using supported Windows Mobile and S60 phones in India, Italy, Spain, UK, and the U.S. can easily download applications.” [Adobe Labs]

Mark Doherty [an Adobe employee] added “OTA is available in US, UK, India, Spain and Italy with more following quickly, anyone can download the player from Adobe Labs if OTA is not available.”

In Silicon Valley press, many wove in lines about Apple iPhone. (I didn’t find any statements from any Apple employee anywhere about the event.) Adobe’s Anup Murarka had the best quote on the simple realities:

“‘We would love to see [Flash] on the iPhone, too,’ said Anup Murarka, director of Technology Strategy and Partner Development for Adobe. ‘But it’s Apple’s decision on when and how they support any new technology. So we will continue to work on it.'” [CNET]

And for RIM BlackBerry: “…Adobe is at an even earlier stage with RIM. ‘We’ve had some initial conversations and are evaluating different approaches to be taken,’ [Adobe’s Anup Murarka] said. ‘There is a lot of interest from BlackBerry enterprise customers to be able to build Flash apps. But there is no working solution yet.'” [Computerworld]

Adobe’s goal is simple — we want to make it easy to publish to any screen. Any screen.

One of the oddest phenomena of the past year has been how Flash Lite paying licenses have blown past expectations — even after Adobe announced that the older mobile engine would be replaced by the desktop version and would not require license fees! I credit Apple’s iPhone for raising the bar, and proving to manufacturers and operators that consumers enjoy better experiences. (I guess we can now bury last year’s meme that Flash Lite licensing fees were holding it back. 😉 A representative quote in The Standard:

“Adobe’s Flash Lite multimedia player is spreading like wildfire on mobile phones, according to third-party statistics released by the company on Monday. According to market researcher Strategy Analytics Inc., Flash Lite will have been shipped on 1 billion phones by the end of March this year, one year ahead of Adobe’s earlier target… ‘The take up of Flash Lite has been staggering to be honest,’ Strategy Analytics’s Stewart Robinson said in an e-mail… ‘I think it also comes down to the fact that competition is almost non-existent,’ Robinson said, adding that he expects another 1.5 billion smartphones with Flash Lite to ship in the next two years.”

Windows Mobile 6.5 was announced, and the “deathmatch” rhetoric of the blogosphere got trumped by the realities of everyday life:

“The latest version of Windows Mobile is shipping with Flash Lite, but there’s no word on when or if Microsoft will debut its Silverlight on mobile.” (Other quotes confirm that Silverlight 1.0 for Mobile will be on Windows Mobile eventually… there may have been dates offered in the past, but no date was offered this week.) [Wireless Week]

“Perhaps the most interesting part of Microsoft’s new OS is an updated version of Internet Explorer for Windows Mobile. The company said the new Internet browser features the same ‘engine’ as Microsoft’s browser for desktop computers, and can render Adobe Systems’ Flash technology… Strangely, Windows Mobile 6.5 does not support Silverlight, which stands as Microsoft’s answer to Adobe’s Flash on the Internet. Microsoft executives hinted that Windows Mobile would support Silverlight at a later date.” [RCR Wireless]

Some of the expert quotes contained jarring notes… I have no idea what the speaker might have intended with this “look how long it took Macs to get Flash” line:
“The other reason, at least with Apple, is business. ‘Apple wants to push its own technology, in this case, QuickTime,’ Gold said. ‘It has its own interests at heart. Look at how long it took to get Flash onto Macs. I honestly don’t think you will see Flash on the iPhone anytime soon.'” [Computerworld]

Some made simpler, more direct, and more observable points:
“Say what you will about Flash, it’s unquestionably a significant component of today’s ‘real Web,’ and I’ve spent enough time being frustrated by its absence that I’m anxious to see how it translates onto a tiny screen.” [Harry McCracken]

At The Boy Genius Report, the comments were not deep, but were excited… it was the emotional tone which struck me here. People were involved and committed to a consumer device… doesn’t always happen.

Now, for the bobos…. 😉

Erick Schonfeld’s TechCrunch article is snarky, but he gets outdone by the head-in-buttiness of the comments… sample:
“The fact that they left Flex 3 out of CS3 premium suites left me SO BITTER, that I think JavaFX will have to take it’s place.”

The most negative (and unrealistic) assertions were from Apple fanboys — while reading through the comment section at A VC from NYC I wanted a little webcam to see how these anonymous spouters of balderdash lived their days:
“Last time I checked, flash is not an open standard. HTML 5 is open and handles 95% of what flash is used for.”
“Mobile flash is nerfed (I believe Steve called this out), and I’m about 99% positive that the version of flash on Nokia and Palm will not support Flex/AIR apps.”
“Because Flash is a proprietary technology, while HTML 5 is an open standard. When it comes to the Web, open standards will prevail. Flash is the past, HTML 5 is the future.”
“As a number of commenters have pointed out, Flash is a hog.”

Just goes to prove that internet text is bloated, I guess. 😉

I’ll keep reading today, and will update this post if I find anything significant. If you caught a novel perspective or useful news, or have questions about any of the announcements, please drop a note here, thanks!

Make Me A Millionaire

Inspiring story at WIRED today, of someone making 320,000 sales of a $3 game distributed by Apple iPhone App Store. He quit his dayjob, saying “I’m not going to be a millionaire in the next month, but I’d be shocked if it didn’t happen at the end of the year.”

Varied takeaways here:

  • Sales didn’t really start until a free version was available… it’s easier for a customer to say “I’d like more of this” than “I think I may like that”.
  • Large potential audiences are not always as necessary as being able to reach enough of the right people… 17 million iPhones yielding 2.4 million leads and 320 thousand purchases was enough.
  • It’s great that Apple has provided a way for individual developers to receive a check. (I hope that the consortium involved in the Open Screen Project can help bring about similar models for wider audiences in the future.)

The title? The State of California has its own television show, to encourage gambling in its game. It’s fun for both winners and the hopeful to discuss how they’ll spend the money, even though the odds preclude as many winners as hopers. If he quit his job before getting the first check, then….

Still, this person now has new possibilities open, thanks to an indy development project. Inspiring.

Clickjacking awareness

How did the recent “Don’t Click” clickjacking attack on Twitter come about? Pretty innocuously, according to this report… a funny hack went viral, and refused to be defused. (I haven’t confirmed the author’s account, but it seems plausible, and is interesting in its own right.)

“Clickjacking” is when third-party content tricks a webpage visitor into making an undesired click. Complete remedies are difficult, because DHTML added JavaScript page-rewrites, and Web2.0 added unvetted third-party content. Browser makers are now struggling to find ways to guarantee that What You See Is What You Click.

A novel aspect of the Twitter-jacking is that the third-party content was introduced via URL-shortening services. Fixes have been attempted, and rebuffed. Check out the explosive growth in this chart.

This “Don’t Click” isn’t a serious exploit in itself, but it’s a serious step along an existing vulnerability. Stay tuned.

Geek Safety

Sort of off-topic, sort of not. Tech photographer James Duncan Davidson got mugged outside the TED conference. Fortunately he came through okay, with nothing more than bruises and new things to think about.

No judgment here on how James handled it… none of us can know how we’d do in a situation until after we actually go through it. But some of the comments there alarmed me greatly — “yeah yeah fight fight!” is a loser’s game. Geeks are good people, valuable to the rest of the world, and it would be a shame to lose any more.

After sleeping on it, I think there are three important points: acknowledge that you’re a likely target; stay aware of what’s going on around you; and defuse rather than escalate any confrontation.

You are a target, and a fat, easy, rewarding target at that. Geeks have more income than street predators, and are usually carrying popular, easy-to-fence goods. Geeks have more cubicle-sense than street-sense, and most of their experience with physical violence has been at the movies. Convention areas are filled with tired, distracted travellers. Stop thinking “it can’t happen here”, and accept the predator’s logic that you’d make a good meal. (Bob Mah shows some additional reasons you may be a target.)

Pay attention. Know who’s around you and what they’re doing. Over the last six months in San Francisco there has been a dramatic increase in the number of people wandering around the sidewalks, staring at the device in their hands. Newspapers have told of cellphone vehicle accidents, and iPods snatched on buses — if you’re out in traffic you need to stay aware of your surroundings, can’t afford “device blindness”. Put yourself in a mugger’s shoes, and you’ll see who the easiest targets are on the street each day. Don’t be sorry, just Be Here Now.

You’ll lose at violence. If someone has been tracking you and already has you at a physical disadvantage, then this is not the best time to exercise your strong sense of moral outrage. He wouldn’t have taken you on unless he knew he had the edge. He wants a conference badge, your wallet, whatever, give it to him. Even if you beat the odds you’re subject to a Bonfire of the Vanities afterlife. If you weren’t alert enough to avoid a bad situation, and are trapped, your main goal is to get out safely.

Next time you’re in a geek-rich area — a workspace, a restaurant, a convention, even a sidewalk — look around at how other people are managing their attention. Some may be looking at their hand, others swerve without checking first — lots of accidents waiting to happen. When a wolf circles a flock, it’s the ones on the edges most at risk. Just by watching other geeks, and avoiding the more self-absorbed behavior you see, you can do a lot to increase your own odds.

Keep an eye on the street — staying aware and alert makes it easier to avoid problems. And if you can’t avoid a situation, then work to defuse it, reducing the risk rather than escalating it. Physical training can help beyond that, but your first steps are always awareness, avoidance, and defusing.

Not paying attention to your current surroundings is a good way to get targeted. And an empty sense of moral outrage is then a good way to get hurt.

We need every good geek we’ve got. Please stay safe out there!

Concise bulletproofing guide

Excellent security resource here: “2009 CWE/SANS Top 25 Most Dangerous Programming Errors”. Lots of apps get burned by improper input validation, SQL injection, cross-site scripting. But it’s hard enough to make stuff, much less defend against all the ways to break stuff.

Here’s an efficient way to protect yourself. Read through each of the 25 “discussion” paragraphs first, to see the most frequent ways sites are attacked… get the big picture, fast. You can then drill into any particular topic if you want. Very efficiently organized.

Thanks to Brian Prince at eWeek for the tip, in “Keeping an Eye on Adobe Flash Security Means Catching Common Programming Errors”. Related recent story: IBM Rational AppScan.

The work of the OSP

Great interview at EffectiveUI from Doug Schmidt (of Dryerfox fame 😉 as Adobe’s Anup Murarka discusses the goals and progress of the Open Screen Project.

It’s a long interview — printed out for me at 13 pages — and seems to have flown beneath-the-radar since published two weeks ago. I’m remixing some of the highlights topically below, but I’d urge you to read the original conversation too… OSP is an ambitious yet convincing proposal to gain the ability to write to any display, and I think this interview will help you predict the shape of the next few years.

What are the goals of the Open Screen Project? To make it both practical and economical to deploy to any digital screen.

We’ve centered on two key goals. First is the development and distribution of a consistent runtime that’s available across all sorts of screens, not just the desktop, but also mobile, television, set-top, and other consumer electronic products.

Second, is the notion that it needs to be easier to publish and distribute content to those screens, not just from a technology perspective, but also from the business relationship perspective. Too often, Adobe hears horror stories from developers about how hard it is to get their content to a mobile phone or to a television. Companies in the Open Screen Project would like to see that become easier.

… The Open Screen Project is really more about allowing developers a much greater level of flexibility to design and move assets from one screen to another without having to rebuild applications every time.

We’ve got to improve, not just the technical capabilities, but also the business realities. That’s why such a diverse partner list is needed:

When the Project was originally announced, we had companies from all segments of technology ecosystems participating. We have companies at the silicon layer actively participating — organizations like Intel and ARM. We also have OEMs, including all of the top five mobile OEMs: Nokia, Samsung, Motorola, LG, Sony Ericsson, and also companies from other industry segments that build other a wide range of consumer products — like Cisco and Toshiba.

We have service providers NTT DoCoMo, Verizon Wireless, and Comcast who most recently joined the effort, as well as major studios, content producers, and media brands including NBC Universal, MTV Networks, a division of Viacom, and others. We see the Open Screen Project as a very broad industry collaborative effort rather than just something that is applicable only to software companies… Since the original public announcement, we reached a very significant milestone in seeing some additional companies join the effort.

Why is such a diverse consortium of stakeholders so necessary? Examples here from service providers and hardware manufacturers:

One of the key Open Screen Project goals is to allow for over-the-air and over-the-wire updating of the core run time, just as we allow for that on the desktop now with Flash Player. If we can make that a seamless process and as easy to use as it is on the desktop, we think developers will get really excited and they’ll be able to do even more wonderfully creative things.

That’s why it was essential to have service providers participate in the project from the start — to help guide how we would do this successfully. The idea of tens of millions of wireless subscribers suddenly doing simultaneous downloads over a network is frightening. Consumers can undoubtedly overwhelm the network. So it’s something that has to be done carefully, and again, that’s why we wanted to make sure that we had partners in the project that could educate us on what the risks and struggles will be.

… One of the most complex problems we’re seeing right now is getting ActionScript 3 running in low-end, mass-market devices. It’s not easy. We’d love developer participation there. It’s going to require a lot of energy. We’ve had a number of the Open Screen Project partners participating in that — companies like ARM, Intel, and Qualcomm — working on getting a well-performing, just-in-time compiler working on current and future processors. There’s a lot of juicy work to be done in that regard…

One example is the announcement we made with ARM stating that Adobe is working with ARM directly to optimize Flash Player 10 for playback on processors. So much of the early engineering work is happening at the very low hardware levels in order to take advantage of hardware acceleration. ARM has made key contributions to the Tamarin project by getting the just-in-time compiler working with ARM processors instead of just desktop X86 processors. These optimizations are for core Flash Player 10 and Adobe AIR.

Adobe’s motivations and business goals?

As we shipped millions of units of Flash Player onto various mobile phones, we didn’t see real global success in terms of broad amounts of content being available everywhere. We saw many little ecosystems, smaller silos that made it challenging for Flash developers to see their content become globally available. If you look at the way Flash content has grown on the desktop and the Web, comparing that to growth outside of the desktop, it has been slow to develop.

We’d like to accelerate that. We’ve certainly played a role to some extent for mobile, particularly in Japan, in parts of the U.S., and parts of Europe. But we’d like to see mobile become a more consistent environment that developers can take greater advantage of.

… We don’t want designers to worry if Flash Player 10 on devices shipping now will work on devices that ship three years from now. I think this is a key aspect of what we’ve heard from Flash Lite developers over the last several years.

… We see consumers demanding greater access to the content they enjoy and the services they want. Rather than forcing developers to learn a completely new set of APIs, a completely new set of capabilities, we think if they have a common tool set, and a common language to deliver those applications and services, they’re much more likely to make them consistent and make them available on a wide range of screens so that experiences can move with users and not be dependent on a desktop in any one location.

Again, our goal is to make Flash more open and more appealing to developers around the world. That represents a significant step to allow for new innovation and for faster development to happen.

What about commitments and progress?

We’ve made some significant commitments to the Open Screen Project, as well as financial commitments by agreeing to waive the royalty fees, for example, for device-based implementations of Flash Player technology.

… We published the first round of specifications and details for development, as well as a schedule for releases that would be ‘Open Screen Project compatible.’ These future releases of Flash and Adobe AIR will really move the the Project’s goals forward.

… We’ve also published Flash information, including Flash technology specifications. We’ve made available various protocols over the course of the last year, such as the FlashCast client server protocol. The goal for that portion of the effort was to ensure that companies didn’t feel locked into some other piece of Adobe technology just because they wanted access to this runtime. Our other products and solutions, tools, and server services will compete on their own merits and not just because there’s any sort of proprietary lock-in to the Flash Player runtime.

… One of the exciting elements of dealing with ActionScript 3 is the fact that the Tamarin Project and Tamarin-tracing have been created as open source projects of the Mozilla Foundation. The Tamarin project is incredibly essential to making this effort one that’s going to truly be multi-screen.

Specifications, roadmaps, timelines?

For the desktop, nothing really changes. For smart phones, we think the specs are somewhere in the 300 to 400 MHz processor range — the really high end of the smartphone category for now. That means devices like the G1 or the iPhone, or some of the higher end series 60 devices are the best — basically the PDA class of devices.

The lower-end smartphones and mass-market phones won’t get all of the same desktop compatibility that we’re offering. They’ll miss some of the class libraries or actual APIs, but the core runtime will be identical. It will be better than what you have with Flash Lite today, but still not 100 percent equal to the desktop.

We think the profile is going to be somewhere in the 300 MHz range for the device processor on, let’s say, a quarter VGA, half VGA screen. We’re also targeting a similar footprint for set top boxes and mass-market TVs, although with some hardware acceleration.

… Schmidt: Did you say that you foresee the first Open Screen Project devices coming to the market in Q4 of 2009?

Murarka: That’s our hope, and things look like they’re on track for that. But ultimately it’s in the OEM and service providers’ control. So I think that’s certainly the target that we’re all trying to work towards, but I would expect the volume of the products to be available in 2010.

What’s the general strategy for developing atop common runtimes spanning diverse device types?

Today, Flash Lite developers have to consider the specific device and the specific operator, and what version of Flash Lite is in use. Our hope is that all these Open Screen Project devices will be able to support a consistent ActionScript environment and a consistent Flash environment. Yes, the physical differences of the device will still be there. Is there going to be a keyboard, is there going to be a mouse, is the screen resolution going to be HD resolution or is it going to be a quarter VGA on a small phone? Designers have to worry about those things even today on the desktop, although not quite as extensively.

We want to simplify the language constructs, we want to simplify the class libraries, we want to make sure that the same authoring tool is in play — and ideally even the same Flex framework and SDK in the future.

But today, many of the richer tool sets that are available to desktop developers are not available to Flash Lite developers. We think that’s a big obstacle to overcome — one that will help simplify the development process for all different screens.

… One of the biggest challenges that developers have described to us is trying to keep track of all the many different devices, and all the different implementations of software on them… The idea of testing everywhere is cumbersome, it’s expensive, and Device Central is a great way to help mitigate some of that cost in time and money. We expect that to continue; Device Central is going to be just as useful as it was before to help designers get a feel for what’s available across devices, but the big steps are really to try to close the gap.

The core focus is on the “big three” screens (laptop, mobile, television), but the principles and capabilities should also extend to any upcoming types of Internet-enabled digital display:

Adobe Flash technology has been used in such a wide range of devices — from digital signage to ATM machines, to toys to informational gadgets, and developer platforms like the Chumby. There is broad adoption of Flash across devices, but it has not reached the penetration and mass-market consumer awareness that televisions, phones, and desktop computers have.

We talk about those three categories most because they are the three largest consumer products categories, but the technology evolution we’re undertaking should benefit other industries and other segments over time. So you can imagine car navigation systems utilizing some of the same benefits that we’re working on for these other three categories of desktops, mobile, and television.

Just as PostScript made it easy to publish to any printer, Flash must make it easy to publish to any screen. I’ve been waiting for this convergence a long time, and the strength and diversity of its ecosystem makes the Open Screen Project look capable of realizing this goal. Nothing’s shipping yet, but if you want to better predict where we’re going, then Doug’s interview of Anup offers a very good return on investment.