More Mac malware from Google search

macOS permissions and Terminal access

• Several comments discuss macOS Full Disk Access and Terminal.
• Some find it confusing or overly restrictive (e.g. accidentally denying access can break their workflow and feels like “one straw too many”).
• Others argue it’s straightforward and beneficial: strong per‑app permissions are a net security gain, and changing them is simple in Settings.
• Debate on whether giving Terminal full access is “necessary”: some only need limited access (e.g. Homebrew in /opt) while others consider Terminal pointless without full filesystem reach.

Web vs native apps and browser file APIs

• One view: the web should be the safer platform for tools like disk analyzers, but browser policies block useful access (e.g. to ~/Applications), making web-based tools impractical.
• Counterpoint: letting a web app access the home directory is inherently dangerous; limited directories or containers/chroots are safer.

macOS vs Windows security and AV

• Discussion contrasts macOS sandboxing/Mandatory Access Controls and prompts with Windows’ NTFS ACLs and integrity levels.
• macOS: prompts for access to Documents/Desktop etc. even within a single user.
• Windows: can approximate this with things like “controlled folders” and Defender, but they’re off by default.
• Some say third‑party AV on macOS is unnecessary if you’re reasonably careful; others call Apple’s XProtect weak and point to enterprise endpoint tools that inspect exec/fork and block reverse shells, infostealers, etc.
• Disagreement over whether AV would have actually stopped this specific “paste an obfuscated command that downloads a binary” style attack.

curl | bash, Homebrew, and package managers

• Strong criticism of curl | bash installers as “insane,” especially when promoted by big projects.
• Some advocate Homebrew or other package managers as a more “civilized” alternative with checksums and versioning; others argue Homebrew is only slightly safer and has its own issues (security design history, dropping old macOS support, admin assumptions).
• Alternatives raised: MacPorts, Nix/devbox, native .pkg installers, or avoiding external managers entirely.
• Broader theme: trust chains, reproducibility, and the tradeoff between convenience and security.

Google search quality, ads, and responsibility

• Many blame Google’s ad model and “enshittification” for malware surfacing as top sponsored results, often styled to mimic official support pages.
• Some say users must learn security hygiene and not blindly paste commands; others insist that if Google takes money and disguises ads as results, it bears responsibility not to promote obvious malware.

LLMs as defense or new attack surface

• One commenter suggests using LLMs instead of random web pages to vet commands.
• Others push back: LLMs are trained on the same web content, can confidently recommend malware (e.g. downloading random drivers), and are vulnerable to data poisoning.
• Concern that autonomous AI agents with browser/system access could be easily tricked by these attacks.

Social‑engineering patterns and user education

• Multiple examples mirror the article: fake support pages, “captcha” flows that ask users to paste commands (on macOS and Windows), and GitHub repos serving trojans.
• Emphasis that many attacks are social engineering, not pure technical exploits; repeated advice to be suspicious of obfuscated commands, shortened URLs, and unexpected permission prompts.