Reverse Seamless & RES VDX: Separating facts from fiction

Hi Max,

Thanks for the write-up;

In my lab VDX doesn't work with Windows 7 Aero Glass. Are you sure Aero Glass is supported (and works) or do you mean an other functionality?

Ruben

Excellent "clarification" :)

I don't think charging for a value added feature is an issue. $15 RRP which means in quantity can be driven down and that's within my conform zone.

I don't think for one second that if Citrix or anyone else got this concept into production before RES, would make it free for all!

comfort zone!

Updated

@MaxRanzau Quick look at the documentation shows editing an XML file to control behavior. So that means manage distributed XML files I assume? Central management comes from upsell to core RES product I also assume? Still worth $15? Is that secure if an XMl file an be used to override a central policy?

When the protocol vendor releases a client patch, I assume you have to upgrade the VDA or equivalent? If that is the case what happens if you release a patch off cycle from the vendor? Does that mean X client updates for me. How do I know they are tested together or do I just assume they will not break each other?

Is RES is saying they are willing to license the patent and nobody has asked them? If you are saying that, you must be Baghdad Bob en.wikipedia.org/.../Muhammad_Saeed_al-Sahhaf

Come on RES I am sure that is not true. I will asked this question, trust me.

@danielbolton So an SMB will pay $15 to get not a lot and not worry about cost, hmmmm:-) There is no business model here, and why it will be a free feature since it's worth more to the big guys dealing with problem apps that they can't remote.

@appdetective if a SMB NEEDS it they should pay :)

VDX is realy cool, only one thing. Its open's all my application that are also open on my desktop!!!

Thanks Max for the rebuttal, good service.

By any account it’s embarrassing for @appdetective to have just assumed without getting the facts straight (I refer to the virtual channel blunder) and other comments showing a lack of technical insight. I think it’s fair to highlight this.

Nevertheless, I do agree in the points raised on the merits of RES VDX being a standalone, patch-on solution rather than a basic integral part of the mayor Desktop Virtualization solutions.

On the security side of Desktop Virtualization, it’s of much regret that to hereto the issues, by large, are avoided and not discussed properly.

I have a question about the security risk of reverse seamless, namely, can someone explain exactly what the risk is? Because if reverse seamless is really just a window z-order trick.. I mean what's the risk? Anything the user is doing on their client is on the client.. And if you're worried about cutting and pasting sensitive data or a content redirection issue.. that's not a reverse seamless-only thing, you know?

@appdetective i enjoy reading your comments but i am a bit surprised and disapointed with this blog in general as it feels like a concentrated attack on a vendor.

That being said, since you bring up the idea of "what if" your patch cycle does not align with the vendor and the fact that you have to constantly update etc..

Did you know or were you aware that when VMware released vSphere 4 U1, the first thing it broke was PCoIP, which they OEM by the way, Microsoft releases endless upgrades that break Citrix software and they are well aligned.

How could you even use this analogy and i know for a fact you know better.

One other note on the XML thing :) so of all the security risks that can be exploited, someone is going to try and hack a reverse seamless session and land inside a locked down VDI session? :) why explot it in the first place, if they have already hacked the host PC, then they control the host user's priviliges already, why not use that host to jump around, why do they need the reverse seamless.

Come on dude :)

Eli

Brian, it's about introducing client side computing and thus dual management. The assumption is that the end client management either doesn't happen or is done poorly. Further it's assumed that the end client (The PC) in itself becomes a black hole with little or no control over, in effect an attack vector. So you see it’s not directly about the technology, but the implied potential consequences of thereby (again) introducing client computing on the end point.

At least that’s what I meant with “context of the concept”

That said. I do think this is a quite lousy excuse for security problems (and within actual dual managed desktops a non-issue) in the face of the myriads others more real security issues, especially within SBC, but to some degree also within VDI.

I just can't bite my tongue any longer :P

@appdetective: I feel a lot of pent up anger and I'm not sure it's not all aimed at RES Software. Why are you so against paying for the reverse seemless technology? If you don't think it's worth the money then don't buy it. It sounds like you want something for nothing which, let's be honest will never happen. I assume you pay for published applications/desktops from Microsoft and/or Citrix (not that you'll be happy about it). Why don't we get that for free too?

I'm sure that if the vendors such as Citrix, MS and Quest etc were interested in licensing the technology from RES then they would be talking as we speak or at least be thinking about it. If not, it's obviously not that much of an issue for their customer base. End of story. If it is a requirement, you now have a solution for the users that require this functionality (and you only need to license the users that use it). What's the value of that?

As for the off cycle patching and breaking stuff it's a moot point. All vendors are at risk of this just look at the VMware View/PCoIP incident a little while ago.

There. I feel a little better now! Iain

When you need to define policy for different local app interaction per client with the hosted desktop you will need to integrate with the core desktop virtualization security infrastructure. Example cut and paste between local app and hosted application needs to be managed at a per app level, not a generic host setting that determines the behavior for all clients. The Reverse Seamless use case will open up many use cases like this, and therefore it needs to be part of the core protocol, well integrated, secured, attested etc.

@DanielBolton I expect that to be provided as required functionality for remote desktops from the vendors whom are already well paid to provide me with remote desktops.

@Elias I agree with your admin rights point. However it's important to understand that central management of this is overhead and lowers the value of a $15 standalone solution that is nothing more than an upsell to the core RES product suite. It's critical to understand that. Add to that the above use cases, and the security integration and testing becomes a lot more complex and risky, which will mean a lot more risk acceptance from any potential customer. Perhaps your friend Bruce Hoard for virtualNOTreview can write about it......

@kimmo, yes leveraging the VC as a transport is true, but that does not mean it's secure, see above use cases. So understand the use cases.

@Lain, A deeper level of integration is required to meet the use case needs, so it's not the same thing.

Therefore I maintain that RES is using their patent to try to differentiate themselves. That is not their core product or focus, and it's nothing more than a way to upsell that to naive people who don't understand the implications. They have not made a public statement about licensing their patent to the protocol providers  (where they can make money). The protocol providers who are the only ones who can evolve the FREE feature to meet the required use cases. Therefore those of us who want the feature to solve real world use cases are unable to do so, because it will not be possible for RES to do it themselves unless they provide direct evidence that they are jointly developing their standalone roadmap with full cooperation from the protocol vendors. That is not going to happen.

These kind of marketing scams fool simple minds. If you want to fall for that go right ahead and pay RES for a feature that will never evolve to solve many use cases. I instead will continue to insist that is a requirement to deploy desktop virtualization at scale. I have already paid the vendors for that, and therefore I expect them to provide a feature that I need for a successful deployment. If they can't, what value is there in me paying the vendors for software maintenance every year when I can't use it the way I need? Maintenance is not about funding vendors to build features for naive people, it's money I have to defend in budgets to enable my business users, EOM.

When you need to define policy for different local app interaction per client with the hosted desktop you will need to integrate with the core desktop virtualization security infrastructure. Example cut and paste between local app and hosted application needs to be managed at a per app level, not a generic host setting that determines the behavior for all clients. The Reverse Seamless use case will open up many use cases like this, and therefore it needs to be part of the core protocol, well integrated, secured, attested etc.

@DanielBolton I expect that to be provided as required functionality for remote desktops from the vendors whom are already well paid to provide me with remote desktops.

@Elias I agree with your admin rights point. However it's important to understand that central management of this is overhead and lowers the value of a $15 standalone solution that is nothing more than an upsell to the core RES product suite. It's critical to understand that. Add to that the above use cases, and the security integration and testing becomes a lot more complex and risky, which will mean a lot more risk acceptance from any potential customer. Perhaps your friend Bruce Hoard for virtualNOTreview can write about it......

@kimmo, yes leveraging the VC as a transport is true, but that does not mean it's secure, see above use cases. So understand the use cases.

@Lain, A deeper level of integration is required to meet the use case needs, so it's not the same thing.

Therefore I maintain that RES is using their patent to try to differentiate themselves. That is not their core product or focus, and it's nothing more than a way to upsell that to naive people who don't understand the implications. They have not made a public statement about licensing their patent to the protocol providers  (where they can make money). The protocol providers who are the only ones who can evolve the FREE feature to meet the required use cases. Therefore those of us who want the feature to solve real world use cases are unable to do so, because it will not be possible for RES to do it themselves unless they provide direct evidence that they are jointly developing their standalone roadmap with full cooperation from the protocol vendors. That is not going to happen.

These kind of marketing scams fool simple minds. If you want to fall for that go right ahead and pay RES for a feature that will never evolve to solve many use cases. I instead will continue to insist that is a requirement to deploy desktop virtualization at scale. I have already paid the vendors for that, and therefore I expect them to provide a feature that I need for a successful deployment. If they can't, what value is there in me paying the vendors for software maintenance every year when I can't use it the way I need? Maintenance is not about funding vendors to build features for naive people, it's money I have to defend in budgets to enable my business users, EOM.

Anyways, guys. I think that the discussion have been healthy and good.

In the society as general and with great speed in the world of technical geekiness it’s the way of self-chosen numbness in the face of the real or imagined expectations on the surrounding etc.

I think it’s great for people to be freely express and debate – exchange. I also believe that it’s a fundamental to acknowledge that retraction is victory and not a loss, and by all means something that we should reflect in our own.