Quarantined Safari .webloc Files
Opening a
weblocfile, for example by double-clicking in Finder, now triggers a Gatekeeper alert in the latest versions of macOS Golden Gate and Tahoe, 27.2 and 26.7.2 respectively, though oddly not in macOS Sequoia 15.8.2.[…]
I could not find anything relevant in the macOS 27.2 security release notes, but the document is extremely long and each entry terse, in typical Apple fashion.
I’ve seen this occasionally, over the years, with Web archives and downloaded PDF files, but now it seems to happen with every bookmark file. I’m not sure what the point of it is. These are not even downloaded files; they’re created by the user dragging a link, so presumably it’s not a surprise what the file contains. And if it is a surprise, the alert doesn’t help because it doesn’t show you a preview of the URL that would be opened. A malicious URL would probably hide anything suspicious behind a redirect, anyway.
So how is this actionable? What is the story where Apple thinks a user will accidentally end up with a bad .webloc file and be dissuaded from opening it by this alert? It just seems like pointless friction.
All that opening the file does is open the URL in Safari, which is the same thing that would have happened had you clicked the link in the browser window. What’s next—warnings for those clicks, too? They could market it as a reason to Switch to Safari.
Previously:
- macOS 27.2
- macOS 26.7.2 and macOS 15.8.2
- Gatekeeper vs. .terminal and .fileloc Files
- Ventura Adds com.apple.provenance
- Quarantine: Apps and Documents
- Security-Scoped Bookmarks and .webarchive Files
1 Comment RSS · Twitter · Mastodon
My hunch is that this is part of an uncoordinated push to distrust and track anything that happens in userland. Maybe they prepare for verifying browsing sessions initiated by the user as opposed to an automation? Gatekeeper could theoretically record the source of the event used to dismiss its alert.
To be honest, I’m basing this assumption on nothing more than my annoyance when finding out that my workflows didn’t work anymore, because the assumption, that you can grant full disk access to Terminal.app once and never have to worry about it, no longer holds true when the session was created using an AppleScript applet. You now need to grant full disk access to the AppleScript applet, even though it no longer runs by the time you for example try to access the Desktop folder in Terminal.app.
