4 ms·

The problem is the alternative is giving your bank credentials and other sensitive personal information directly to a third party. At least when the software i

by zrm 7y ago

The problem is the alternative is giving your bank credentials and other sensitive personal information directly to a third party. At least when the software is on your computer it's possible to analyze it to see what it's doing with your information. Once it leaves your computer into the possession of a third party, it's no longer even within your power to observe what they're doing with it.

taneq 7y ago
I'm not sure I agree. On the one hand, once you provide data to a web service, that piece of data is permanently out of your control. On the other hand, once you're running untrusted code on your computer, all of your data is potentially permanently out of your control if you ever reconnect to the internet. As for analyzing software, even for software devs that's impractical. It's not enough to run it under some kind of process spy to see what it's doing because the malicious behaviour might be time limited or otherwise triggered unpredictably, so you really need to decompile and reverse engineer the program to figure out what files it can read and what it does with them. Not gonna happen. A better option is to spin up a fresh VM to run untrusted code on, but even that's cumbersome.
- zrm 7y ago
  Decompiling the program is arduous but it is possible. You only need one person to do it and expose the nefarious activity to destroy their reputation, which acts as a deterrent. Another option is to restrict its network activity. If it can't communicate with the developer then it can't send your information to them. You could also merely log its network activity, maybe using some hooks into any crypto library it links against so you can see the plaintext. That wouldn't prevent it from doing something bad, but it would at least allow you to detect it after the fact and then everyone would know to stop trusting that developer, and you get the deterrent without investing as much time and effort.

by zrm 7y ago

taneq 7y ago

I'm not sure I agree. On the one hand, once you provide data to a web service, that piece of data is permanently out of your control. On the other hand, once you're running untrusted code on your computer, all of your data is potentially permanently out of your control if you ever reconnect to the internet. As for analyzing software, even for software devs that's impractical. It's not enough to run it under some kind of process spy to see what it's doing because the malicious behaviour might be time limited or otherwise triggered unpredictably, so you really need to decompile and reverse engineer the program to figure out what files it can read and what it does with them. Not gonna happen. A better option is to spin up a fresh VM to run untrusted code on, but even that's cumbersome.

zrm 7y ago
Decompiling the program is arduous but it is possible. You only need one person to do it and expose the nefarious activity to destroy their reputation, which acts as a deterrent. Another option is to restrict its network activity. If it can't communicate with the developer then it can't send your information to them. You could also merely log its network activity, maybe using some hooks into any crypto library it links against so you can see the plaintext. That wouldn't prevent it from doing something bad, but it would at least allow you to detect it after the fact and then everyone would know to stop trusting that developer, and you get the deterrent without investing as much time and effort.