>>>While I certainly agree protection is needed in some areas for IP of the app, the threat vector of somebody hacking a vfp.exe to infect a network is better avoided by offering secure / hash coded update packages on a protected server accessed by SSL at least. When hacker goes to work on vfp.exe the battle on network entry is already lost.
>
>Working theory in latest healthcare hack/s is malware opened in somebody's email. When that happens, hackers presumably can access apps and anything else the user enjoys. If they get hold of an easily cracked app and can lift database credentials, now they can grab data for blackmail: pay or we upload these sensitive records to the public internet. This was threatened with both recent high-profile hacks.

Yupp, battle on network entry lost in email scenario. Similar if USB port is still available to receive rogue sticks.
Net admin the one to care for that scenario:
for ransom encryption the border between network layers and segments in "same" onion layer will be tested.
for DB credential theft a few vectors can be bottlenecked: user (group) rights, user quota/time and proxies.
for IP included in app: refox, defox, vfp compiler and other stuff

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.

Other vectors like thread-unsafe CPU or WLAN much harder to utilize, but potentially more disastrous.
Paranoid me, previously worried about WLAN and attacking next device in router cascade is setting up more segments, subnets and an air gapped / USB-sneaker-net after FragAttack common knowledge ;-)

Commercial offerings IMO should invest MORE in network security and internal DB security, less in app obfuscation

But i am a codgy, dirty old white male...

regards
thomas