Adobe AIR + .NET Proxy - Concerns arise.
I read the post of both Ryan Stewart and Mike "Mesh" Chambers on a bold plan to connect Adobe AIR with a .NET Proxy (Proof of concept anyway). At first It was a great story and I for one was thinking to myself "hey this could be a sweet approach"..
However, the more I thought about it, the more I wanted to validate some concerns I had. I approached some of our .NET folks with it and this was their response:
"...I’d be afraid of encouraging developers to do this, and what the platform would be like if many applications on it did something like this..."
There were other parts to this, but suffice to say the underlying point is that one could do this via web proxy (whilst slow) and remain in a more safe position.
I don't know why AIR isn't looking to open its borders to native OS and it kind of illustrates the elephant in the room, in that when you go X-Platform with one bundle of code, something has to be left on the table. Native access to the operating system is one of these, and if any desktop platform is likely to succeed beyond a "Look ma, I just turned Flash into a desktop experience" then it's got to be more serious, focus on security (critically important) and ensure real world solutions can be built. In that, eBay AIR application has had no apparent success beyond its launch and furthermore not really sure what unique value AIR offers in this case either other then offline… but who uses eBay offline?
I'd like to think we know a thing or two about .NET and its implications in the wrong hands. I think what Mike is doing is great in terms of approach and concept, but lacks execution (from what I've read). I only state this as we have a habit of being labeled the bad guys when something goes wrong .NET related, and wanted to clear the air (no pun intended).
As people move to full trust on the desktop they open an entirely new set of complex security challenges. It’s something not to take lightly but has to be respected.
I think AIR needs to focus more energy in the space of allowing folks the ability to talk back and forth on the native operating system it’s deployed, as this will ensure a much more secure transaction (if done correctly, this is rocket science in many ways) vs. Proxies (probably also why Adobe won’t support this proxy).
Just my 2c.
Note: Red Stickers were provided by design-police.org .
Comments
Anonymous
January 20, 2008
The comment has been removedAnonymous
January 20, 2008
sigh I do declare your response Matt@Adobe as being: "Ad_hominem" "An ad hominem argument, also known as argumentum ad hominem (Latin: "argument to the man", "argument against the man") consists of replying to an argument or factual claim by attacking or appealing to a characteristic or belief of the person making the argument or claim, rather than by addressing the substance of the argument or producing evidence against the claim. The process of proving or disproving the claim is thereby subverted, and the argumentum ad hominem works to change the subject." With that i'll leave the response alone.Anonymous
January 20, 2008
As was pointed out in my original post. This is a proof of concept and nothing more. That is why there are no binaries provided, and no samples / examples available for download.... mike chambers mesh@adobe.comAnonymous
January 20, 2008
Hi Mike: Correct, I did state in the first paragraph that it was a Proof of Concept. Scott / Microsoft.Anonymous
January 21, 2008
An "ad hominem" argument would actually be something like "Don't listen to Scott, because he can't speak English." Here Matt actually addressed suppositions and statements in your essay, so his argument was "ad rem", even though it contained some personal comments. Matter of fact, your own rejoinder was more to-the-person than to-the-facts. (btw, your bio could be read as stating that you were employed by Allaire et alia, instead of being an independent developer who used Adobe technologies.) jd/adobeAnonymous
January 21, 2008
I don't really see where you've given a reason why this is a bad approach. You've got a quote from people saying they wouldn't encourage developers to do this but you don't spend any time explaining that. You just talk about what AIR doesn't do right now and then offer vague references to security. I don't know much about .NET security, so I'm asking out of curiosity, what makes this a bad solution? =Ryan rstewart@adobe.comAnonymous
January 21, 2008
I was going to ask the same question Ryan did. Can you go into details on why this is a bad solution? What are the security implications? With response to Matt Voerman's post, I can only conclude that he mis-read the words he quoted To quote this paragraph from him: [Start Quote] You mention "I don't know why AIR isn't looking to open its borders to native OS" - Mikes opening sentence answers that in stating that its one of the "Two of the most requested features" [End quote] I suspect that he read the quoted statement as "I don't know why AIR IS looking to open its borders..." In which case his response (because people request it) makes sense. And if you never worked for Allaire / Macromedia / or Adobe; as John Dowell suggested; you should change the wording on your bio. Instead of an "Adobe/Macromedia/Allaire" developer, you might say "I've been a developer of "Adobe/Macromedia/Allaire" Technologies. Or you might say use "customer" instead of developer.Anonymous
January 21, 2008
decided to "AIR" this conversation in a more focused thread as i think a couple of you folks have raised some good concerns and I should clarify it more. http://blogs.msdn.com/msmossyblog/archive/2008/01/22/re-adobe-air-net-command-proxy-security-concerns.aspxAnonymous
January 21, 2008
The comment has been removedAnonymous
January 31, 2008
"when you go X-Platform with one bundle of code, something has to be left on the table. Native access to the operating system is one of these" Whuh ? There is no 'has' about it. The 'X-Platform' ColdFusion server, for instance, is Java based, runs on Macs, Linux and Windows, and has a 'cfexecute' feature that allowes running native commands.Anonymous
January 31, 2008
Tom, Correct. Yet AIR isn't a server-side solution, it's a client-side solution. Different contexts apply. Security is the goal, provide a runtime experience similiar to native client(s) but within a sandboxed security, thus something's got to give... It's essentially putting lipstick on the pig imho.