If we are talking about ransomware running in a user context, it'd have the permissions of the user to encrypt anything the user has access to.

If we are talking about extreme sandboxing, you make it hard for programs to work together without permission fatigue, or the user having no idea what they are allowing or getting used to allowing all permissions.

I have old paperwork for significant shareholdings in 3 extinct companies I worked at that tried to outsource all development. Out of 6 or 7 major outsourced projects I was involved in or responsible for, only one could be classified as "successful", a couple more ended up with somewhat usable code/systems that met requirements (mainly due to them being poorly written) but which were unmaintainable and replaced within 12-18 month timeframes. The rest were all complete throwaways and represent low 7 figures worth of money completely wasted (with, perhaps, the exception that I and others learned new ways that outsourcing can go wrong and a bunch of useful war stories.)

As I see it, when (most) companies have an in house dev team, what they _actually_ have but do not understand (at senior management levels) is a Solution Architecture and System Design team, a software development team, and a QA and Test team - all of which are likely to be the same people who do not have those roles listed on any org chart or job description.

Realistically, the best you can possibly hope for is to outsource the non team lead parts of the software development, and _maybe_ some of the testing work (if your in house QA is on top of things).

The "50% cheaper" off shore dev team is, in my experience, at best capable of doing something under half of what a typical in house dev team does. Given that the management and oversight of the off shored development and testing work needs to be done in house, and cannot possibly be done in the company's best interest by the offshore devs or an outsourcing company, you are going to need to retain in house staff to do those roles - and they're going to need to be the more experienced and more senior people from your existing in house team.

Anybody who thinks "half the hourly rate" translates to "half the cost for the entire project" has clearly never done it before. At best, you are going to be able to outsource 50% of the work. So at best you can save perhaps 25% of the development costs, and that requires you to have some very good inhouse technical skill who are experienced in system design and architecture, writing unambiguous requirement docs and User Acceptance Tests, and who have seen the sort of "tricks" outsourced developers do to pass tests instead of actually writing secure stable and maintainable systems.

Php users tried with addslashes(), realized there are cases it can't handle, made a sql variant in mysql_escape_string, realized it's open for abuse since you can mess with the character set. Then made mysql_real_escape_string and later mysqli_real_escape_string, which even them have some flaws depending on the db charset.

So if you find the concept easy, I'd wager it's because you don't handle some exploit path.

Several years ago, I showed a colleague that in the simple file-storage web app he'd written, just changing part of the URL from e.g. "/folder/23/" to "/folder/23 OR 1=1" would show every file ever uploaded by any user, ever. (He hadn't even added a clause to limit it to the logged-in user, but that's another matter.)

He was taking that folder number from the URL, passing it through mysql_real_escape_string() because he'd simply learned by rote that that's how you make any user input safe, then concatenating the SQL, without putting quotes around the variable in the query because it's meant to be an integer: "...WHERE folder_id = $folder_id".

It didn't matter how I tried to explain things, he just didn't get it. He still works there (I left, I'd had enough) - his job title is "senior developer".

That's a common problem. A lot of people don't realise that if you accept user input, you can get every single byte and sequence of bytes possible. Validating that a parameter is an integer ([0-9]+) is even easier than escaping.

his job title is "senior developer".

Likely that's purely because of how long he's worked there, not how much he actually knows.