This post is in response to the recent battle of words ignited by a post from Mike Chambers called CommandProxy : .NET / AIR Integration Proof of Concept. Soon after Scott Barnes posted a response to Mike’s post called Adobe AIR + .NET Proxy – Concerns arise and a subsequent post RE: Adobe AIR + .NET Command Proxy Security concerns.

[ Update : Mike added this post that I was unaware of when I wrote mine.. also helpful to clarify what's going on ]

Disclosure

• I am a Flex Developer
• I use Adobe products daily
• I work for an Adobe partner: Universal Mind
• I am a fan of the Adobe platform
• I worked on the eBay Desktop project
• I was co-creator of the Artemis Project (similar to Mike’s CommandProxy)
• I’ve also worked as a java and Microsoft developer in the past.

Add all this up and I think my background gives a bit of relevance to the conversation.

I’d like do discuss some of the real issues here and do it in an attack-free manner. But first, since the previous conversations escalated to attacking some of the people I know and projects I’ve been close to, I’d like to give some shout outs:

Mike

I’ve heard Mike speak several times, had a couple conversations with him, and read his blog pretty regularly. My impression of Mike has always been that he’s an extremely capable technologist who cares a lot about his product (AIR). I’ve had extremely brief discussions with him about competing technologies. There was never a time in the course of any of these discussions where he has bashed another product or an employe of a competing company.

Alan / eBay Desktop

I had the pleasure of working on the eBay Desktop application before the Alpha release in 2006 and for a time after that. Alan is a great guy to work with. Again, like Mike he also cares a lot about his product. As Alan stated, the eBay Desktop application is in beta (as is AIR). It’s hardly fair or relevant to criticize the user acceptance of an application that is in beta. For me, eBay Desktop isn’t about offline it’s about a better experience, but more on that would be off topic.

Adobe’s Developer Relations

I’ve had quite a bit of interaction with the Adobe evangelists, probably the most with Ryan Stewart, but also; Ted Patrick, Mike Chambers, Mike Downey and Kevin Hoyt. Ryan went out of his way to help me out with Artemis and other Flex related stuff even before he was an Adobe employe. All of the other guys I have listed have been more than reasonable in answering all of my questions or concerns. Quite frankly, it’s their job and they’re good at it.

Another place Adobe shines in developer relations is through their engineering team. I’ve had e-mails answered by engineers and product managers from the Flex team that have saved me a lot of time, and I know that I’m far from the exception in this case. In my opinion, this is stuff that they really don’t have to do and it’s very much appreciated.

None of this is meant to be an attack on Microsoft. It’s been over 3 years since I did any Microsoft development, so I really don’t know what they’re developer relations are like. It’s also not to try and get Adobe to buy me a house (although I wouldn’t turn it down). It’s just a chance to highlight the good things going on at Adobe in light of the criticisms raised. Now on to the real issues…

Scott brought up two points that were interesting to me. One was regarding security and the other was on the relevance (ie “what is being solved here?”).

On Security

As I understand it, there are two concerns regarding security. The first is data protection. In Mike’s proof of concept, as well as in the Artemis framework, the data that is exchanged between AIR and .NET/java is sent through a socket that is not encrypted. It is possible for another process to monitor this data and intercept it in the same way a sniffer process that inspects packets on an internet connection can retrieve sensitive data that is sent across the internet. This is a concern for someone building an application that might send sensitive data between AIR and .NET/java.

The second security risk is that another process might hijack the proxy process. It would be possible to build a malware AIR application that could connect to the proxy process and cause it to do very nasty things to the underlying system (like search the hard disk for credit card numbers, or just reformat it). To me, this is the bigger risk. An important question here is: Why is this different from a .NET application that might to the same nasty things? It is different because AIR is a platform that has a security model associated with it. This type of bridging gives a false impression of security to the user. The result is an AIR application to .NET or java that has taken on all of the security risks of the bridged platform as well as the risk of data protection in the transport.

So, Scott is correct, these are big risks and should not be taken lightly, however, where I disagree is that is that Mike as an Adobe employe has no right to explore these ideas publicly. The fact that he (and others at Adobe) work on projects like this make me even more interested in their platform as a developer. That’s not a claim that any of their products are better than the competition, which is arguably subjective claim from either side. What I appreciate is the philosophy at Adobe that allows for and perceives the value of this work. It’s work like this that showed us Quake running in the Flash Player at MAX.

If these kinds of methods were something that Adobe was interested in supporting, rest assured the security issues would be addressed.

On Relevance (What is solved here?)

When I presented Artemis at 360 Flex in August David Coletta asked a question on Artemis that went something like: “Pphilosophically is this a way to improve AIR or extend the capabilities of java?” This is really a similar question. So, why? My answer for that is one that companies selling platforms might not like, and that is: Ubiquity. As a developer I want ubiquity between APIs, frameworks, languages, OSes, and definitely platforms.

The idea for Artemis came from the desire to make the benefits of java (countless open source projects and many great language features) available to a Flex developer creating AIR applications. At the same time, providing the powerful UI capabilities of Flex to java developers. I’d rather stop thinking in terms of the dichotomy that either Flex / AIR or Silverlight / WPFE is better as a platform or for a particular project, and be able to use the great features of both technologies ubiquitously. Unfortunately, I think the days of building a Silverlight module and loading it into a Flex app (or vice versa) are far away.

To sum up…

This work is definitely not the kind of stuff you validate a platform on. It’s not a solution for most (if any) enterprise or consumer applications, but it’s fun, cool stuff. That’s what I love about this technology. It’s fun to create solutions with it and I love the challenge of pushing what it’s designed to do.

Mike, thanks for working on CommandProxy. It’s a great idea to get .NET devs excited about Flex and push what AIR can do. Scott, thanks for bringing your concerns, the real issues underneath all of the unnecessary comments from both sides are relevant and important.