Hacker News Reader

Comment by yreg | Hacker News Reader

Safari always unzips any downloaded archive, wraps it in a folder and puts it into ~/Downloads.

I prefer this functionality as most of the time I do want to unarchive it. I can rearchive it later (or remember to use another browser) when I need to.

View on HN

If you download a Wordpress plugin, you need to re-up it zipped -- not a major use-case but I could see other similar situations (downloading tarballs). It's an interesting choice.

MS Windows' transparent zip treated as folders works well (it's the same on Kubuntu), one could just do that and pre-cache an uncompressed version; then you get to use the file or open the folder with minimal friction?

It's not always, there's an option to turn this off in the Safari Preferences

And if someone does not want this there is a checkbox in Preferences under "General": "Open 'safe' files after downloading". Unchecking it will prevent Safari form auto-extracting.

Have had this set for many years, I recall some early macOS malware would be present in malformed PDF files that could be downloaded in the background of an infected page & the would open/execute automatically for users who had 'Open safe files' set.

How can you for instance verify the checksum of the file when it's deleted?

Wouldn't the decompression fail in that case?

The idea is to publish the checksum of the archive separately. After downloading the archive you can calculate its checksum and compare with the published checksum. If they differ you known something is up (possibly bad).

When a browser helpfully decompresses the archive you can no longer perform this check.

If it fails to decompress because the file is corrupt, the browser would more then likely keep the archive?

But if someone replaces the archive with a malicious file that decompress normally, he will also probably change the listed checksum on the download page....

The actual download might be hosted by 3rd party mirrors.

You can compare the checksum to the one on the author's site to ensure the mirror provider didn't alter the file.

There are signature schemes that can fix that issue, and cases where it's useful anyway, like:

Many linux distro isos are available from several different mirrors. Having a secure hash on the original site with the links to mirrors means I don't have to trust the mirror(s).

Another case where the archive hash is useful is when there's some public key crypto involved. I can have a public key from a publisher (gotten either out-of-band or in the past) and the hash can be signed so I can verify it. These schemes would mean that an attacker would at the least need to have compromised a site for an extended period of time (if I have history with the site, the first visit it doesn't do anything extra), or in the case of out-of-band key sharing, multiple communication methods might need to be compromised for an attack to succeed.

But yes, in the common case a hash next to a file link hosted on the same domain really doesn't do anything.

You don't. Though to Apple's credit, users who are concerned with verifying checksums probably overlap with those that take cursory steps to harden their browser by, among various steps, disallowing Safari to open "safe" documents (that's what they're called in Safari's option).

Would it be prejudice to think that the checksum verifying users are not using safari?

Yes. Chrome is surveillance-ware now. I’d rather use Safari or Firefox than Chrome.

Might be, I've no idea. Anecdotally I use Safari - faster, I prefer the UI, and I don't trust Chrome.

The only reason I've Chrome around is for the growing number of sites that only work with Chrome. Apps made by Google, in particular, increasingly don't support macOS/Safari. Which I find infuriating, but that's another topic.

Chrome is the new IE.

Convenience over security

It should be noted, when Safari deletes an extracted archive, it isn’t deleting it; it’s putting the archive in the Trash. You can just turn around and fish it back out. That’s one of the Trash’s roles in macOS: to serve as a place for the OS to put things that you probably don’t want, “but if you do, here’s an opportunity to grab them before they’re gone.” (I’m honestly surprised that every time you Cmd+C, the previous contents of the clipboard don’t end up as a file in the Trash. It’d be perfectly in line with the metaphor they’re going for.)

——

Also, fun bonus fact re: checksumming:

Apple uses the https://en.m.wikipedia.org/wiki/Xar_(archiver) file format for their own software downloads (e.g. App Store downloads; and developer-tools packages from the Apple developer website; and downloading Safari extensions, before those were rolled into the App Store; etc.). Despite Apple being seemingly the sole user of .xar, it’s not an Apple-specific format; rather, it’s developed by OpenDarwin. So you can use it too (for, at least, your macOS-targeted downloads), if you like.

A .xar file contains embedded checksums (both for the archival representations of each file, and for their extracted representations); when Safari auto-unpacks a .xar, the .xar unpacker (Archive Utility?) verifies those checksums as it does so. IIRC, if the verification fails, the extraction stops, what has been extracted so far is deleted, and the user is told the archive is broken and asked whether they want to keep it or move it to the Trash.

A neat thing about .xar extraction, is that it seemingly tags the extracted files with an xattr declaring that they’ve already been checksummed. Apple ships applications like “Install macOS Whatever.app” as a .xar containing an .app bundle containing several mountable .dmg files; normally those .dmg files would do their own checksumming when they mount, but since they came out of a .xar, they know they’ve already been checksummed recently, so they just skip the internal checksumming step. (I think this is one of the main reasons Apple chose to move to .xar; they wanted to be able to make the macOS Installer run faster, by having it not have to do any checksums of its support .dmg files during install.)

So that’s the deeper answer to your question: ultimately, Apple expects people who want archives with checksums, to use .xar or a format like .xar, that does checksumming during extraction.

> I’m honestly surprised that every time you Cmd+C, the previous contents of the clipboard don’t end up as a file in the Trash.

Purely my hypothesis: it’s too high a risk that someone accidentally leaves a password or private info in their clipboard. People don’t expect a clipboard to persist, so you’d need to re-educate everyone to avoid this “bug”, just like browser history and incognito mode.

Apple is notorious for assimilating popular third party extensions. Screencapture, night shift, colour picker , why no stack based clipboard? It’s too useful to have been overlooked. Must have been a conscious decision.

Reply on news.ycombinator.com