Download it with Firefox and it's borked. Download it with Safari, and it's fine. Huh?

If the files truly are identical then it must be something at runtime. My guess is that disabling the ethernet at "some low level" is not actually that low level at all. It could just be disabling the standard libraries that most browsers use to perform requests over HTTP. Firefox does not use these libraries and would not be disabled. The software may just be detecting that Firefox is running and refusing to start because of that. This should be easy enough to test.

Does either browser automatically unzip the zip archive when it downloads, or do they both toss it in your Downloads folder? Try comparing the downloaded zip files' MD5 checksums: in the Terminal, run 'md5sum path/to/zipfile.zip', then 'md5sum path/to/zipfile2.zip'. Are the strings the same? If so, so are the files.

I notice the same issue when I'm downloading clip art from MS Office Online (don't laugh! there's some great royalty-free stuff there; it's not (entirely) the crap WMF files you might associate with MS). The site creates a bundled download package that can only be opened with Microsoft Clip Gallery. Safari gets along just fine - the downloaded bundle opens in MCG without issue, whereas FF's download is unusable and chokes MCG. Has always stumped me. Your situation with Exam4 is even more baffling -- a zip is a zip is a zip, right?

That makes sense, but I don't it's the answer. I just ran a quick test — not only did the "Safari version" run correctly without complaint when Firefox, Safari, and Chrome were open, but this is what my network.prefpane looked like: http://grab.by/GFB

I would imagine their server is serving the zip file with the wrong mime type header, and Firefox is respecting the header in how it saves the file. Similar to old FTP issues that would occur when you accidentally transferred a file in ascii mode rather than binary mode.

Here's one thing I just happened to notice — Safari seems to preserve downloaded files' original modification date, while Firefox updates it to the moment the file was downloaded. Exam4 is built on a site licensing scheme and "expires" after certain time (hence all the re-downloading on my part). I wonder if each version checks its executable file for a specific modification date as part of this process? I doubt this is it, since I believe I've seen old versions actually throw a "this version has expired" message, and since what I suggest sounds like an ass-backwards way of implementing a shelf life. For now I'll consider it an unsatisfactory but potential solution.

@mikeh: That makes sense, but wouldn't you think they'd reconfigure the server once in the last two years instead of fielding the same question from stressed out grad students hundreds of time over the same period? (I hadn't noticed before, but I now see that the download page itself warns you to use Safari — although it doesn't contraindicate Firefox specifically, fwiw.)

Actually making a technical change instead of having a lame support policy? You might be asking too much.

This is totally guesswork on my part, but rather than the download being corrupted in a way that directly affects the way the app works, I'd guess that this is actually a permissions-related issue. In order to disable network interfaces, I'm pretty sure you need administrative privileges. If the permissions on the app are in some way futzed, then it won't be able to even ask you to do that, and the text editor not appearing is possibly a byproduct of this (the app expects the network interface to be switched off, so it sits around waiting until that happens).