Inspect extended attributes

Extended attributes store metadata outside normal file contents: named key-value pairs attached to a file. macOS uses them heavily. Downloaded items may carry quarantine information used by macOS security checks, Finder stores tags and comments in them, and apps stash their own bookkeeping there.

Inspect names and values

xattr file.zip
xattr -l file.zip

The first form lists attribute names only. The second prints values too. On a fresh download you typically see:

com.apple.quarantine: 0083;68b2c41a;Safari;9F2A1C44-73D2-4E8B-9E01-2B7C55D10E42
com.apple.metadata:kMDItemWhereFroms: ...

The quarantine value is semicolon-separated: flags, a hex timestamp, the application that downloaded the file, and an identifier. kMDItemWhereFroms records the download URL. Together they answer a genuinely useful question during troubleshooting: where did this file come from, and has Gatekeeper evaluated it yet?

When you first open a quarantined app, macOS runs its security checks. If the app is blocked, the quarantine attribute is part of why, and that is your cue to check the publisher, not to strip metadata.

Treat attributes as evidence

Treat the attribute as evidence about origin and handling. Verify the publisher and download source. If a legitimately obtained file from a verified developer still trips a check, removing quarantine from that one file is a deliberate, informed decision:

xattr -d com.apple.quarantine Example.app

That is one attribute, one path, after verification.

The mistake to avoid

Do not normalize xattr -cr as an installation step because it removes metadata recursively without solving trust. It strips every attribute from every file in the tree — quarantine, tags, resource metadata, all of it. Any tutorial whose install instructions start with xattr -cr is asking you to blind the security system instead of understanding why it objected. Read the attributes first. They usually tell you exactly what happened.