This sounds like an interesting mitigation, but comes with it's own drawbacks: - you now start worrying about if it's possible to get a malicious download from

This sounds like an interesting mitigation, but comes with it's own drawbacks: - you now start worrying about if it's possible to get a malicious download from your domain that dll-hijacks non-malicious downloads (better than the current state of the world, but not a lot) - less user friendly: who wants to remember what domain they downloaded something from when they go looking for an old download? also there's the question of should you associate the file with the domain that served it (probably?) or the domain that was in the browser bar when the download was triggered? I think it's unclear because the user's will expect the latter but the former makes more sense as security. Anyhow I think the right answer is that this is on the OS to provide better defense mechanisms. Maybe just something like the ability for the browser to tag the file with the domain it's from, instead of just "the internet". And then the OS could say "exe from www.foo.com is trying to load dll from www.bar.com, this looks fishy do you want to allow?" or maybe just flat out fail it; this way you get your cross-domain restrictions but less usability problems. Or better yet, the OSes could solve this problem entirely by having a much stronger whitelist of what DLLs are included from where. why don't we just require programs to specify the full path to any DLL they try to load, instead of doing a search for the file? Or maybe some sort of code signing technique could apply, and programs could specify they want to load X dll, but only if signed by Microsoft or whoever the expected party is, with some optional power-user way to override this? Or maybe we should just have some sort of warnings when you download a DLL from the internet, and put DLLs in their own download folder or something? That might be the easiest mitigation for a browser to implement.