Here is an easy fix for MongoDB's inability to do transactions or safely store data.
Take the thing you want to store. JSON serialize it. Put that in a SQL table (called JSONtable) stored under a GUID index.
When you want it back, select the object you want by its GUID and then deserialize it.
Voila and congratulations. Now you have all of the benefit of a schema-less database, plus the transactionality, able-to-deal-with-lots-of-data-ness and likely-to-not-get-corrupted-ness of SQL.
It was RCE because with a web.config you get the machine key of the ASP.NET application. With the machine key of the ASP.NET application you can sign any data as part of the ViewState, which means that you can fabricate malicious viewstate which is then deserialized. And although it wasn't widely known at the time, the deserializer was vulnerable to RCE (CVE-2013-3171).
So tl;dr is that the web.config oracle was RCE at the time if your web.config contained a machine key and used viewstates anywhere in your application.
Even now it's more than an information disclosure; with the machine key you can still get an arbitrary file delete from the ASP.NET machine account (which isn't many files, but it isn't zero files either), and this bug has been around since at least 2012.
I have a meeting tomorrow at 9am, but John can't make it.
<The meeting ... tomorrow ... at nine A..M.. no longer contains anyone in your line management chain and the schedule does not contain any projects you are involved in. Would you like me to delete the invite so you can have a lie in tomorrow?>
Thanks Cortana. That sounds great.
<Deleting the invite and setting alarm for nine ... thirty A..M>
On what planet does whether a product is open/closed have any meaningful impact on that product's performance?
They will need to keep the restriction on store apps (or at least mark store apps that do this with a big banner shouting "warning!" to users), because understanding how to secure these IPC channels is depressingly hard for ordinary developers (there were several hundred bugs filed by WinSec against this type of channel before Win8 shipped) - and that's even before you realize that a malicious app-store doing this gets medium integrity impersonation of the user on the desktop for free doing this.
Or in other words, this breaks the entire AppContainer security model by turning a download of one of these apps into effectively double-clicking an EXE you found on the Internet and hoping it doesn't pwn your system.
Generally, a better solution for store apps would be for Windows to be a bit more proactive at inventing and shipping new WinRTs.
For example, even on this forum some developers have asked for COM1 read/write from inside a Windows Store app. Now the correct approach to this is not for Microsoft to give developers medium integrity DLL execution. That's like your four year old daughter asking for a wendyhouse and you handing her a powerdrill and telling her she can build her own.
The correct response is to write a bespoke COM1-over-IPC channel - Microsoft is able to build and secure these because that's what WinRTs are. Microsoft should be proactively seeking out new ideas for WinRT that developers are really asking for, and implementing them and releasing them out-of-band with the rest of the release cycle of Windows.
Why should a developer have to wait until 2016 (or later, who knows?) before getting a feature that's make-or-break for their app? Like being able to 3D-print, or use a custom barcode scanner? Or maybe a banking app that interacts with a custom card reader or something?
It's nice that Microsoft is allowing developers to be flexible here - but developers need to be careful. That powertool is not only heavy and complicated; it's dangerous too.
Fed-Ex will refuse to carry anything with a declared value in today's money of $50,000 or above, so it's more than that, but it might not be as huge as you think.
Regarding royalties, my guess is that Microsoft will have wanted ownership of whatever became the Windows XP background image considerably more than they wanted his photo to be that image. If he'd have held out for royalties, the Windows XP background would be something entirely different and he'd have not got anything.
That would make no difference in this case; the bug here isn't that it's returning uninitialized memory, but that it's reading data beyond the allocation. Even zeroing mallocs would return passwords, SSL keys and SSNs if they had this bug.