I find it odd to think a web browser displaying a page from $some_remote_url would happily try to load an image from the local machine. Never mind the NTFS bug, this is one of those cases where the browser is out of bounds IMHO. The only time it should have access to the local file system is if the user is explicitly doing something like selecting a file to upload somewhere, or saving a downloaded file. I suppose if you're reading a locally stored .html file it should be able to grab other things like images. The ability to exploit this seems like lazyness on the part of browsers. They needed local file access for legitimate reasons and just opened it up.
The whole cross-origin model in browsers, like it or not, allows something like this. It's hard to fix. Chrome already aggressively restricted permissions for file:// in a way that broke existing apps because they wanted to limit the risk of attacks against the local filesystem.
IIRC there have been file://-related vulnerabilities in webapps like pdf.js, too.
I don't know if you were around when the web started, but I was. The web was purely a viewing experience, and it gave me pause the first time I was asked to select a local file to "upload". I thought hmmm, when did they poke this hole? Of course for all I know it was a feature from the start but hadn't been used until then, but the concern is still valid. Had the original browser not allowed cross-site resource loading, perhaps other solutions would have been found to common problems (mostly related to advertising).
How do you define local precisely? Is it 127.0.0.1, 127.0.0.2, localhost, 192.168.0.2 or an IPv6 address in ::1/128? Browsers allow a Web page to load images and code from other domains for obvious reasons. Making exceptions to that rule for the local machine would break some legitimate software and be difficult to implement correctly.
