Thursday, 27 August 2009

Is Adobe holding back Flashplayer features for strategic business reasons?

Acrobat Connect Pro

I originally posted this via the Adobe Bug site and tried to contact Adobe  in May 2009. I got no response but this is still quite relevant.

Being arguably the most requested feature on Adobe's own bug tracking site and already present in an internal fork of Flashplayer, Adobe has so-far dodged all questions regarding this. I'm now mid-development on an alternative browser plugin to make up for these short comings. (More on that in weeks to come.)

First, a little explanatory rant...

For about two years now I've been using Flash's excellent streaming audio/video and publishing features on a hobby project language learning project that has recently turned into the language study website you see here today. Since the beginning, I searched and searched for ways to enable Accoustic Echo Cancellation (AEC) in Flash and since Flash 8 I've held my breath hoping for support in both Flash 9 and 10 but to no avail. Out of desperation, I registered as a member of Adobes bug tracking site and voted on a low priority bug/enhancement to get AEC added to flash. I no longer look after the flash part of our website so now I tend to forget about this frustrating fact until a student or teacher comes along and complains about a single student causing echo chaos for all the others. Anyway...

It was two days ago that I noticed a comment by Sivakirian stating the Adobe Connect Pro had actual AEC support,and whats more, it was running from within Flash. This souned like a mistake to me at first. Flash doesn't provide direct access to the microphone. Was it server-side? How was this being done?! I had to find out... If true, this is clearly not a fair competitive environment and someone aught to start blowing some whistles...

Confirming the AEC beast exists!

Step 1 - Find this mythical AEC and test it. So I headed on over to adobe connect pro website, sign up for an account, log in and create myself a meeting.

I had heard of breeze before it became "Connect Pro" and it seemed pretty good. It already had lots of features that I was/am in the process of implementing in my own system and some more that I decided against because they made things a little too complicated for my intended market.

The first thing I notice is the app asking me to install something for screen sharing. I click "install" and get the familiar Flash Security dialog box asking me if its OK to download "Adobe Connect Pro" from the internet. I click "ok" and then with a bit of whiring my page reloads in a separate window (Notably called "Adobe Connect Pro" until it refreshes with my meeting details).

Running through the Audio Connection Wizard and getting to the "Advanced" option at the end gives a "Use Enhanced Audio" option with, sure enough, Full-Duplex AEC, along with auto gain control and echo cancellation quality controls. Selecting the best of everything I could, I fire up a PC in another room without a headset and start yelling - no echos.I remove my headset - no echos.. Hmm.. This thing works - well!

Deengineering Adobe Connect Pro

My aim was simply to find out if I could use this plug-in myself. Using Firebug to figure out what URLs this meeting software was loading, I first stumble onto this file. The notable lines being:

<m id="addInVersion" platform="Windows">9,1,268,0</m>
<m id="addInVersion" platform="Mac OS 10">9,1,268,0</m>
<m id="addInName">connectaddin</m>
This is interesting. The add-in has a version number similar to the versioning scheme of flash itself. Now I don't know of a version of flash labelled The latest 9.x version recommended for users who can't upgrade to 10.x was which was dated mid-December 2008. I am currently running the latest 10.x in any case so maybe its something between 9 and 10? Something unreleased? I'll have to take a bit more of a look.

I fire up my trusty HP SWFScan and run it on the first SWF URL I an find in Firebug:

The decompile of this shows a line something like:

var product = new System.Product(_global._s("addInName"));

This is the second interesting part. What is thie "System.Product" business? I can't find it in the SWF specification, in the official Flash compiler (CS4) it gives an error. HaXE doesn't support it. Even swfc doesn't like it. A bit of searching turns up a site stating that System.Product installs third party apps from Macromedia. Sure enough, in C:\Users\<username\Roaming\...\\bin\ I see a directory called "connectaddin", the same name as addInName in the XML file I first found.

The version number on the EXE in this directory states it to be "Adobe Acrobat Connect Plugin 9.1 r299" and it was released 3 days ago. I have version 9,1,299,0 which is above the required 9,1,268,0 listed in the XML file. Running the EXE gives me a standalone window with "Flash Connect Pro Loading" in it. No signs of any way to force load it.

I decide to confirm my suspicions that this just a modified standalone player by comparing it to my flash 10 plugin. From my flash 10 NPSWF32.DLL I pull some random strings from the imports table:

From the connectaddin.exe file:

Hmmm. Interesting. Some left over paths here clearly show this to be a branch of the main flash player. This branch happens to have lots of fancy cool things though like AEC, cryptography functions and screen sharing - maybe more but I am not really interested in anything else. I press on.

Launching the plugin

This turned out to be a massive pain. In short, heres how I called "new System.Product("connectaddin")":

  1. Create a simple SWF using swfc that contains the call "var product = System.Product("connectaddin");"
  2. Use swfmill to turn this SWF into a list of XML opcodes.
  3. Change the appropriate "CallMethod" tag to be a "NewMethod" tag.
  4. Use swfmill to turn this XML back into an SWF.

This was not as laborous as it sounds. A simple bash script did the whole job in a split second. I just used "patch" to patch the XML and ignored the warnings about incorrect offsets. My SWF actionscript, based on SWF the API I had figured out by disassembled using "flare" (SWFScan seemed to barf at some of thse files) was now able to bring up the same "Adobe Connect Pro" dialog that I could bring up by double clicking the EXE but this time I could blank out the contents and right clicking would give a "Movie Load Error" message.

The disappointment

So close! Unfortunately though someone at Adobe had other plans for me. Looking through some more SWF assembly / decompiled code I find that this URL gets loaded:

So I assume my tools will load it. Wrong. Nothing works on this file... Why I wonder... I open it up in a hex editor and notice that compared to meeting.swf it has a strange 68 byte prefix and a suffix containing the string "OpenSSL Certificate File". With that, it all clicks and starts to make sense. This is a signed SWF file and my regular file has no chance in hell of ever running via this plugin unless I get a valid digital signature using the public key encoded in the plugin itself.

My interpretation of the situation

First, even though theres been a lot of investigation up until this point, this is still just speculation on my behalf. Don't take this as gospel by any means..

Basically the custom player used to provide features like screen sharing support and potentially other privacy invassive features is running a forked version of Flash 9. At a guess, it was probably an internal beta version prior to Flash 10. Support was added for screen sharing and AEC enabled. To secure these things properly would require source code security audits, mechanisms to prevent screen sharing without proper flash-security-dialog-based confirmation, etc. To side-step this, the easy way out was chosen and an SSL signature used to wrap up any code deemed safe enough to run this plugin.

This design is probably not through malice or ill-will on behalf of Adobe, but just a result of tunnel vision on behalf of the developers. In terms of getting their product to market securely and painlessly as possible, piggybacking on flash is a great idea and their programmers have done a good job using available resources to best effect.

Unfortunately, its not a fair idea given Adobe monopolises the whole Flash industry to allow this sort of thing to happen. Like Microsoft force-bundling IE and MSN or Apple refusing to allow apps that compete with their own on the iPhone store, a smart business move for a big player can sometimes be a political mine field. In my opinion, this case of clever code reuse clearly represents an unfair political and economical advantage through inability to compete in equally on the Flash platform in the current marketplace.

Notes in regard to AEC...

Support for AEC doesn't really have any of the security concerns that screen sharing introduces and should be able to fit within the confides of the current Flashplayer system panel (perhaps making it a little cramped for space but besides that with no real technical hurdles).

Support is clearly possible and presumably easy to add to Flash 10 given its already working on Mac and PC with few problems on a forked version of the flash player between flash 9 and flash 10.

The API is for this enhanced audio is already fairly clean within the connectaddin plugin. It goes something like this:

if(Microphone.hasEnhancedAudio) { mic.setEnhancedAudio(true); ... }

In summary, I can't see why this is given a "low" priority when clearly so many developers whant it and its clearly being used by Adobe in their Acrobat line of products to provide an unfair competitive advantage over other external products that cannot provide this functionality.