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

November 19, 2009 7:00 PM

Download a certain program with Firefox and a key feature is broken. Download it with Safari, and it runs fine. Howzzat?

My school requires students to use Exam4, a sort of hobbleware text editor, for exams. It has different modes, which control just how hobbled your computer is. In all but one mode, the internet connection is disabled to prevent cheating. On Macs, starting an exam in these modes brings up a login box to authorize Exam4 to disable the computer's ethernet adapters at some low level.

For the longest time, when I would enter my credentials to do this, it would fail to disable my connection. (It would also fail to bring up the actual text editor, so I was never able to enhance my GPA with my 1337 h4X -- instead, I just managed to avoid any exam that forbade Internet access).

This time, tech support diagnosed my problem right off -- they told me to download the file again, but this time to use Safari. Sure enough, it worked straight away. My question is, how could the browser possibly affect a downloaded executable such that it would install and open just fine, but have one feature broken?

For what it's worth, the file is downloaded as a zipped archive with a single executable inside. The only possible thing I can come up with is deliberate interference -- the site could deliberately sniff out Firefox users and serve us a defective file. But that doesn't make any sense, and besides the files from each browser look identical (both are 1,002,699 bytes).

posted by electric_counterpoint to Computers & Internet (13 answers total)

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.
posted by AndrewStephens at 7:16 PM on November 19, 2009

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.
posted by aaronbeekay at 7:18 PM on November 19, 2009

Could it have something to do with the "quarantine" function that was added in 10.5 (Leopard)? Try downloading the file with each browser, and then examine the .zip files in the terminal using "xattr -l filename.zip" (you may have to cd into whatever folder you downloaded them into).

Also try "cmp file1.zip file2.zip" to verify that they are in fact byte-for-byte identical (aside from the attributes that xattr will show you) — if they're the same, cmp will print nothing; otherwise it'll print a terse description of where they differ.
posted by hattifattener at 7:20 PM on November 19, 2009

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?
posted by porn in the woods at 7:24 PM on November 19, 2009

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
posted by electric_counterpoint at 7:25 PM on November 19, 2009

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.
posted by mikeh at 7:33 PM on November 19, 2009

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.
posted by electric_counterpoint at 7:33 PM on November 19, 2009

@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.)
posted by electric_counterpoint at 7:36 PM on November 19, 2009

Actually making a technical change instead of having a lame support policy? You might be asking too much.
posted by mikeh at 9:02 PM on November 19, 2009

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).
posted by jaffacakerhubarb at 9:30 PM on November 19, 2009

You could chmod the modification time back and see if it works.
posted by Obscure Reference at 3:40 AM on November 20, 2009

Can you actually run the md5 and cmp tests recommended above?
posted by turkeyphant at 5:47 AM on November 20, 2009

Theory: The file is being served as a .zip but the mime type is wrong. Safari and Firefox then do different things based on the mime type. If that mime type happens to be ascii, then Firefox may be converting line feeds which will break the binary. IE was notorious for disregarding the mime type, back in the day, so this kind of crazy was common.
posted by chairface at 5:18 PM on November 20, 2009