>>Running apps in server VM, as real (foxInCloud) web app or via browser accessing a webified GUI by one of the other "translators" might be a good vector to hinder all of the above. Screenscraping from the compromised device nearly impossible to block.
...
...

It can cost a fortune if you get drawn into organizational security processes. My documentation commits AES256 encryption of any credentials and license keys, more recently committing non-ECB AES since ECB now gets a security fail and is starting to be disallowed in some jurisdictions. Also obfuscated compiled C++ code for all sensitive parts and other hacker checks with no dangling encrypt declarations that are easily hooked, forcing a dll decompilation with exponential difficulty so that effort quickly outweighs benefit and switch to softer target. What else customers do for security is to be encouraged, but outside vendor brief. If they are so foolish as to allow hackers access to the app and encrypted credentials- we've made it as fearfully difficult as possible to attack from there while acknowledging that anything can be hacked if you allow physical access. That includes browser apps, fwiw: browser vendors continue to find and lock down attack vectors, sometimes in features relied on by app vendors to extend functionality past monolithic single-page apps that dominate the web.