CLBrown: DEP is a bad idea overall, or at least a very bad implementation. Despite claims of it being "for security," the main upshot of DEP is that it disables a lot of older software...
advowson: I disagree. DEP is a security feature, and a useful one. Any programs broken by it were always wrong, but due to OS limitations and hardware limitations, were historically permitted to run despite being wrong. Most software should never encounter a failure caused by DEP, because most software should have all its executable content in a properly marked text section. The programs most likely to be affected by it are programs whose authors thought they would be clever and generate code at runtime (allocate a read-write page, write code into it, then call that code), but who were not quite clever enough to read the documentation and note that they were supposed to mark the memory as executable before calling into it (and, if at all possible, mark it read-only at the same time, so that it goes from read-write to read-execute, but is never read-write-execute). Most programs have no business generating code like this, and will never notice the presence of DEP.
CLBrown: Unless you're on a public machine, with people running software on the same computer you are... or unless you randomly stick disks and USB sticks into your machine without knowing where they came from... this really isn't much of a risk.
advowson: This is an incorrect explanation of the threat model. The threat model for DEP is that you run a program which, due to a bug, allows malicious input to redirect execution to attacker-supplied data. Without DEP, that data is executed, allowing the attacker to run code with the permissions of the exploited program. With DEP, the application receives an access violation and crashes, depriving the attacker of the ability to abuse the program's permissions. Malicious input can be delivered over the network, or be left in a local file to be triggered when a vulnerable program opens it. If you run without DEP, and run a program which can be exploited by malicious data, you are at risk if the program has any way to receive malicious data, be that interactively from another player in game, interactively from the chat server, by e-mail, or by malicious USB stick. If you run only programs with no such exploits, then you do not need DEP. Most of the major exploits DEP was intended to block were delivered over the network, usually to vulnerable Windows system services. Such users received no protection from refusing to share their computer with hostile parties.
Well, I suppose if you regularly expose yourself to potential exploits... and I guess if you go to "lan parties" or the like, or perpetually play peer-to-peer network games with strangers... this might be a serious issue.
But I have a system here which nobody but me uses. I don't use unsecured connections, don't download unidentified software without giving it a thorough vetting first, don't just pop thumbs or disks into my system without prior vetting, etc. And... perhaps most significantly in this case... I don't use insecure "chat servers," click on unknown links in emails, or allow anyone access to my local network without my direct oversight.
But, for, say, a college kid with a bunch of wireless connections, in a dorm where you KNOW people are running exploits and all sorts of sleazy stuff... yeah, I'd recommend leaving DEP on.
For me, literally 1/2 of my owned software fails if DEP is allowed to run on it. I have a LOT of software, including quite a bit of older stuff. It's not ALL "hackily written." The reality is, the sort of "protection" which DEP provides was never even DREAMT of until a few years back. Now, if you could go back and rewrite the full code base of all software developed before the introduction of the concepts upon which DEP is based... sure, it would be a "win-win" all around. But it's not just "badly written" software which it interferes with. It's anything older than DEP, effectively.
I'd think this would be a no-brainer for people buying stuff from "Good Old Games." Unless GoG fixes the issues, the vast majority of (non-DOS, non-ScummVM) games out there would not be able to be sold in workable fashion with DEP in place.
This, in fact, is really what GoG's techs seem to do best... fix the basic incompatibilities. Sometimes simply through creating a compatibility-database-entry set for a given program. Sometimes by altering the core elements of the code in some small (but signifiicant) way. And that's why I tend to buy stuff from these guys.
