3 ms·
Protecting the safety, security and privacy of users isn't "user-hostile". Leaving your users exposed to hackers, viruses, malware, malicious adware, ransomware
by dkopi 10y ago
Protecting the safety, security and privacy of users isn't "user-hostile".
Leaving your users exposed to hackers, viruses, malware, malicious adware, ransomware, government espionage and bot networks is.
I find it completely baffling than in 2016, people can still refer to writing secure code as "fearmongering".
Being able to dynamically inject code into your process and run it is indeed very powerful.
But i'll cliche quote spiderman about great power, and insist that if you're going to execute "mprotect" or "VirtualProtect", make sure the code you're about to execute is signed and verified.
Not doing so, would be user-hostile.
- junke 10y agoSure, this is a valid concern, but in the context of a learning experiment like the one discussed here, this is not really important. "Hey kid, nice treehouse, but what about burglars?"
- dkopi 10y agoFrom the scasm readme.md: "Do not ask for the final goal of this: this is more a learning vehicle to abord several interesting topics." Isn't security one of those interesting topics?
- sbuttgereit 10y agoIt can be... but it also can be a drag if that's not your immediate area of study. Security is incredibly important, but it is an overhead: including a cognitive overhead. If I'm futzing around with a toy project to learn about how, say, distributed agents can make use evolutionary selection to create efficient protocols amongst themselves (yes, a completely bullshit set of terms strung together) and I fully expect this to never leave a group of VMs on a home server.... yeah, security is NOT something I'm going to sweat. Doing so would be a distraction and counter-productive to my goals. To be fair to your point, however, by not constantly practicing secure coding techniques, regardless of context, I could get out of the habit of secure coding as a default. I may simply not think about it at a time when I should be. By always considering, even in my bullshit toy project, I stick to my good practices and more consistently apply them when it counts. But the argument that security coding can be interesting and fun is not a good enough argument to care about it all the time.
- dkopi 10y agoI'd argue that all code should be fairly defensive. Security flaws in the end are just bugs. And defensive programming helps reduce bugs. As for toy projects - you never know when your futzing around becomes a full blown product. Obviously, security is always a tradeoff. I'm not suggesting you implement 2 factor authentication for your wedding invite website. But it does always help to consider: 1. How can this code break, if someone accidentally misuses it? 2. How can this code break, if someones intentionally misuses it? Very often, thinking about #2 can help resolve a lot of things overlooked in #1.
- mtanski 10y ago"Hey kid, nice treehouse, but what about burglars?" Also building code, fire code, ADA accessibility requirements and permits and sign off.