This also happened on iOS when they began to prompt users before apps could access the clipboard. I built an app that would handle the inbound redirect automatically if you had a relevant URL in your clipboard - did this for years with many users happy with the feature.
Then it started prompting users before allowing them to paste, and then the claims of privacy violations began to come in.
If instead I were able to specify what was happening in the prompt rather than iOS giving users an ambiguous statement, or even provide a detection pattern, it wouldn't have been nearly as bad.
I feel like this really harms security and privacy awareness by flooding the field with unimportant prompts/warnings to the degree that a real issue is similarly ignored because it is assumed to just be noise.
If they allow apps to provide that message from code, that is very hard to test for, even for Apple.
Shady developers would try very hard to get past such checks, for example by changing that message based on the date, IP address range, nearby WiFi networks, receipt of a payload, etc.
They could introduce an optional string-valued entitlement and check its text. That would be a lot easier but still require them to translate messages.
BlackBerry supported incredibly fine grained permissions way back in the day, and even that wasn't sophisticated enough to support OP's use case.
I don't really even care what OP's good intentions are, because the minute the app is sold, those good intentions are out the window. I use very few apps because I assume they are always going to potentially be adversarial to my interests.
The system warning is correct and should not be subject to the developer promising free candy to gullible users.
I think the visibility of these dialogs serves as a warning to the user--but they should do a better job directing the user's attention to where the threat is. If the user is getting annoyed at all these pop-ups, he should direct this annoyance at the developer who is (in all likelihood) asking for access to more of the user's computer than he needs.
The fact that there are so many popups should mean apps are reaching for access to your system way beyond what they should be. It shouldn't mean Apple needs to get rid of the pop-ups.
I get the pop-up semi-frequently from Chrome. I don't think complaining to Google has ever helped with anything; but then it's not like complaining to Apple has a better track record.
Yes, I don't know why the OS isn't tracking the pop-up by bundle id or anything. It's not like I changed my mind the last dozen times…
From the perspective of the simple dialog, its a problem with the consumer app who calls the api to open the dialogue without context, without informing the user or obtaining user consent prior to doing so. Plenty of apps get this right, eg. Have a screen with buttons in the on-boarding flow that opens the dialogue next to the “maybe later” option, and use that page to explain or “sell” the benefits of enabling the permission.
Maybe the dialogs api should be treated like autoplaying videos with sound on the web, just disable the api if it is called outside of a click event handler, and let the consumer app break. That would be a breaking change for OSs tho. It wouldn’t prevent malicious UI patterns from triggering annoying permission prompts, but it would minimize accidental bad ux eg calling it in the main method on load
Then you have to require these permission controls to tell the app the user denied permission, and not just giving a valid but empty result. Some people on HN feel strongly that when you deny contacts permission to an app, the app should receive a list of dummy contacts. Without it a bad app can lock its UI and not do anything unless the permission is granted.
If you have an Extracare card, in some markets, you can self-unlock the locked display cabinets with the CVS app (because they have your identity via the ExtraCare card which adds inherent trust).
Very interesting. But I'd imagine they aren't doing proper KYC to get an ExtraCare card, I bet it is very soft KYC. Like phone number verification or card payment which you can get anonymously, so it won't necessarily do too much to find the perpetrator. I wonder if it works through throttling and blacklisting so the loss and damage radius are reduced.
At the same time, though, the thought is "a criminal won't give out their business burner's cellphone number" to sign up for a card/unlock a case. There's still an additional level of self-selection required to be honest enough to want to acquire the loyalty card that a "dishonest" person does not want to spend time doing (they want to snatch and run).
Same reason Walmart gated the self-checkout Scan-and-Go-via-phone system behind a paid membership on Walmart+, criminal's not gonna burn fifty bucks to steal a couple times if they have to hand over anything vaguely close to PII, even if it's burner PII.
Ah, are you telling us that while people were outraged about rampant theft and pointing to all the locked-up merchandise as emblematic of the corporate response to rampant theft, even while there wasn't enough staff to unlock the cabinets... but the lockups are also a way to entice customers to install the app, sign up for an account, and enable Bluetooth all the time?
I mean, I didn't go to the worse version. Step right up to the little display, enter your phone number, smile for the camera, and the case unlocks magically!
Have a problem with pesky permissions dialogs from sandboxed apps? This unsandboxed unverified app that requests Accessibility permissions, to the rescue!
Well I don't have the problem it's trying to solve so I don't need to. But among people who install it, how many will? And remember to do it again before every upgrade?
So you're kinda looking for a "I want to allow this software to do whatever it wants - I accept all risks?" button? And with each new update you're re-evaluate?
"I want to allow the software to talk to devices on my local network", not "whatever it wants".
I've never had a case of this where the access was malicious, and devices on my network have security controls. For me this popup is exceptionally low value.
You can allow-list certain IP address ranges to not need the local network permission and I believe that should stop the popup from appearing (but I'm not sure). See https://developer.apple.com/documentation/technotes/tn3179-u... for more information, TL;DR:
I did that yesterday after updating from macOS 14 to 15 on my work laptop; well, added "10.0.0.0/8" too. Spent a few hours trying to understand that that new permission thing simply couldn't work with my Emacs launch agent (service)... fucking Apple treating CLI users like dirt.
I don't know what Apple is looking for. The iPhone ships with a Weather app preinstalled, you allow it to your location so it can warn of severe weather, and several weeks later "OMG WEATHER APP IS USING YOUR LOCATION!!11!".
Same with MDM agents. Ours are installed automatically as part of the Apple Business Manager configuration, we manually grant them precise location in the background, and months later "HEY USER, WANNA BLOCK LOCATION FROM 'MDM SERVICE'?".
Edit: To avoid replying to the two following comments with the same reply, my gripe is not about the notification, that's a good thing; my gripe is with their implementation, which seems very in tune with Apple's way of complying with regulations. There are definitely many user-friendly ways to handle privacy compared to seemingly random notifications.
The first scenario is due to anti-trust complaints forcing Apple to treat their pre-installed apps identically to third-party ones. (Also why you can "delete" system apps.)
Okay, to me it reads like a lazy swipe. You seem to be aware of the power of AI to build you whatever you want, so why ask this question like this? It seems like you're just trying to tell people they should fully trust the software they install.
I'd rather something tell me exactly why this popped up in the first place, as every new OS version seems to introduce more triggers. I have apps that now pop this up when I quit, which doesn't make much sense.
Ideally, every API to call a function that provides the developer "dangerous" access to your system, should give the developer a text string argument to explain/justify to the user why it's needed. Then, instead of a confusing "Do you want this app to use Bluetooth?" pop-up with zero context, you let the developer convince the user.
Amazing. I'd LOVE for you to expand it, to also auto-dismiss "Foo.app would like to access data from other apps."
Adobe programs ask for this every time they start, and Claude Code randomly asks me this daily out of nowhere. It doesn't matter how many times I click "Don't Allow", it never gets remembered. (But of course if I ever mistakenly click "Allow" even once, that gets remembered for eternity and I never get asked again...)
Don't know about Adobe but the issue with Claude Code is when Claude does a recursive find or grep on your home directory. You might be able to fix it just by putting some warning against doing that in your global CLAUDE.md
CLI/developer tools in general often lose or forget permissions because they aren't shipped as proper signed Mac app bundles, so the OS has no stable identity to attach the permission grant to. You might find that even if you click allow, that gets forgotten too sooner or later.
Can’t we not have some OS level thing which suppresses all intrusive dialog and puts them in a nice inbox so I can decide which I want to answer or ignore in bulk…
I'm surprised nobody here is saying "what if your staging server is on the LAN, or you want to test a website from another machine?" Somehow Safari allows it, and Chrome has to go through this system that prompts you. I try never to miss one of these permissions ("yes"), because having Chrome blocked from local websites is just no good.
side note but what is the consensus on figuring out whether small brew packages like this one are malicious?
I'm sure this one probably isn't, but I have no clue how I would know whether it is without reviewing the source code myself (or pointing an agent at it etc)
Even if they're not malicious, there's no guarantee that they won't become malicious in the future. Prefer living off the land, and install only the very essential extras.
It's so funny to read these, as if countless examples didn't prove that llms don't actually distinguish between your instructions and the data they read at your request.
Do you think a malicious repo author won't think of hiding a suitable prompt within?
took me about 30 seconds to find. there's tons of them. of course it's an arms race, the models get better the harnesses get better the attackers get better but again: for the model itself, your prompt and third party data it reads are the same thing (input). as long as it is true, the attack will always be possible.
Basically the question for any executable code (or even just any data) that you let on your machine and which did not go through independent vetting processes. The question you need to ask is if the benefit (getting rid of an annoying popup) is worth the risk of a distribution method that is trivial to compromise.
That's why I like small, open source projects like this one. I don't have to figure out if it's malicious. I just fork it, then ask claude to review the code, then run my own fork.
> Chromium browsers (Chrome, Brave, Edge, Island, Arc) copy their own app bundle into a random temp folder at launch so the code signature survives in-place updates. macOS keys the Local Network decision to that random path, so the next launch looks like a brand-new app.
OH DEAR GOD that explains so much other cursed behavior, including the "do you want to allow google chrome helper to show notifications" always reappearing. or teams. or anything that does autoupdates.
> Nothing on a typical Mac needs this permission except a printer or scanner utility, a media server, or a LAN-discovery tool, and those you answer once and they're done.
This is wrong. Browsers and media players need it because that is how multicast discovery for stuff like Chromecast works. Spotify, same thing. And Steam plus virtually all games with LAN multiplay for the same reason. Did I note already that Steam also has an autoupdater and so does Spotify and... argh.
Apple really needs to fix the very first point, preferably in a way that doesn't force app developers to ship a "helper" binary.
(Side note: it might even be the case that opening the file picker may be enough, if you got network-discoverable paths in your Finder Locations sidebar, but i'm too tired to test that one out...)
That explanation sounds wrong to me. I've written my own implementation of macOS signing logic. TCC doesn't usually tie permission grants to paths, it ties it to the designated requirement of the app bundle, which in turn is usually an indirection through the code signing certificate identity. The whole macOS architecture is designed to let you drag apps around and treat them as files, it's not a UNIX where installation path is meant to matter.
I just dumped my TCC database and the entries are mostly not path tied. The Chrome entry is as expected a bundle ID+designated requirement. Unless the local network permission inexplicably uses a different permissions engine, that statement is a misdiagnosis of what's happening.
$ sudo sqlite3 "/Library/Application Support/com.apple.TCC/TCC.db" "SELECT hex(csreq) FROM access WHERE client = 'com.google.Chrome';" | xxd -r -p | csreq -r /dev/stdin -t
(identifier "com.google.Chrome" or identifier "com.google.Chrome.beta" or identifier "com.google.Chrome.dev" or identifier "com.google.Chrome.canary") and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = EQHXZ8M8AV
In other words, the permission grant applies to any Chrome channel as long as it's signed by Google's team ID.
Even for chromecast and spotify I never want or use these features, and if I am not turning such a feature on I never want to be asked about a permission related to it, as a user. If I am turning a feature on or I am trying to use chromecast, THAT is the time to prompt me about it
The permission keying off of a temp folder feels so broken. I don't know whether Google / Chrome deserves the blame for the weird hack of running an app from a place the user never specified or Apple the OS for making such a hack necessary and not giving the permission system a way to understand the canonical user installed app as the source of the request.
This is the sort of classic MacOS situation that has mandated the use of Hammerspoon scripts and the like for more than a decade by now (this is not a sectarian point btw, Windows requires winutil just the same according to my optics)
Hmm another gripe of mine. Mac OS's vnc brings a popup that steals your focus when someone connects to the machine while you're physically in front of it.
I know it's well intentioned but I have this weird setup where I am almost constantly keeping vnc on from my laptop to my desktop. And the mbpro randomly wakes up to do whatever, even when not used, which reactivates the vnc connection, which pops up a warning on my desktop, which steals my focus.
Anyone knows a way to disable that? Possibly just for connections from a specific other machine.
Edit: as for this app, I think the OS only asks once for a new app? I don't remember being asked a second time even when denying it.
I could also whine a bit about "this app wants to access files on a removable volume" since my desktop has a thunderbolt ssd plugged in for extra space...
Yes. Thank you. This is such a simple thing that should be a part of the operating system, and in the ideal world it would be. This is the perfect problem for the LLM to solve, because the reason it does't exist in the system is a decision by some stupid PM at Apple, and not an actual system constraint.
It’s just a choice of which key to use. I don’t think it was some decision made with this intent, I think it is just the unexpected result of a decision.
Permissions consent prompts are broken. they are far too coarse, and out of context. The customer is forced to consent without knowing the scope or what will break.
A better experience would be an async consent screen, with placeholder content and calls to action until permission is granted.
For example, a network ping scanner could show placeholder host names & status until the user clicks to allow access.
The operating system could easily stub the sensitive APIs with placeholder content and a flag indicating the content is false. So even legacy apps could work.
this is exactly the type of app that makes me excited to see what the future will hold with ai. any regular joe or jane can now realistically solve many of their small annoyances with little effort and no experience.
(not saying this is ai or not, i have no idea, just speaking generally)
Yes! I got annoyed that I had to manually close old finder/preview windows, so I OSSd an app that closes any stale window. There have been commercial apps in this space a decade, but none worked how I wanted (per window not per app, config each app separately). So I just made it with Claude using some spare tokens at the end of the week. You can customize anything to be the way you like it now.
This particular item never been a problem for me because I incessantly close everything after I am done with it but it is super cool that we can ask AI to dig into the weeds for us now and fix our annoyances -- or even search repos online where someone else had and fixed this problem
Sometimes I am shocked by how blind Spotlight is. I will have something in my applications folder with a straightforward name -- say, Steam.app -- and it will keep picking the shortcut generated by CrossOver for the Windows version of Steam, that is nested inside a bunch of subfolders. Wtf? I ended up renaming the CrossOver version to WinSteam so it stops prefix-matching.
The big problem with these permission dialogs, is their lack of technical detail about what the app is actually trying to do which triggers them.
How do I know whether to say "Allow" or "Disallow" when it gives me no idea what either option actually means in concrete?
This also happened on iOS when they began to prompt users before apps could access the clipboard. I built an app that would handle the inbound redirect automatically if you had a relevant URL in your clipboard - did this for years with many users happy with the feature.
Then it started prompting users before allowing them to paste, and then the claims of privacy violations began to come in.
If instead I were able to specify what was happening in the prompt rather than iOS giving users an ambiguous statement, or even provide a detection pattern, it wouldn't have been nearly as bad.
I feel like this really harms security and privacy awareness by flooding the field with unimportant prompts/warnings to the degree that a real issue is similarly ignored because it is assumed to just be noise.
> If instead I were able to specify what was happening in the prompt rather than iOS giving users an ambiguous statement
No. They’re correct, there.
The app developer should not get to provide the message text for a prompt like that.
A secondary note somewhere in less than ten words, maybe, where it explicitly warns that the statement may be false.
> The app developer should not get to provide the message text for a prompt like that.
In App Store apps, where these messages get human review, it could more safely be allowed.
If they allow apps to provide that message from code, that is very hard to test for, even for Apple.
Shady developers would try very hard to get past such checks, for example by changing that message based on the date, IP address range, nearby WiFi networks, receipt of a payload, etc.
They could introduce an optional string-valued entitlement and check its text. That would be a lot easier but still require them to translate messages.
For the iOS permissions I know of (Camera, etc), the message comes from the Info.Plist in the .app bundle, not from code.
App Store reviews are no longer human, they’re LLM
BlackBerry supported incredibly fine grained permissions way back in the day, and even that wasn't sophisticated enough to support OP's use case.
I don't really even care what OP's good intentions are, because the minute the app is sold, those good intentions are out the window. I use very few apps because I assume they are always going to potentially be adversarial to my interests.
The system warning is correct and should not be subject to the developer promising free candy to gullible users.
Exactly
I think the visibility of these dialogs serves as a warning to the user--but they should do a better job directing the user's attention to where the threat is. If the user is getting annoyed at all these pop-ups, he should direct this annoyance at the developer who is (in all likelihood) asking for access to more of the user's computer than he needs.
The fact that there are so many popups should mean apps are reaching for access to your system way beyond what they should be. It shouldn't mean Apple needs to get rid of the pop-ups.
I get the pop-up semi-frequently from Chrome. I don't think complaining to Google has ever helped with anything; but then it's not like complaining to Apple has a better track record.
Yes, I don't know why the OS isn't tracking the pop-up by bundle id or anything. It's not like I changed my mind the last dozen times…
Regardless, apple should definitely not send popups unless an app is being engaged with.
I love the clipboard warning.
before that, facebook was stealing everything on your clipboard and send back to their server.
This dialog is what it take to stop them.
and it have the pattern detect you asked.
as a user with an itchy delete app finger, this is exactly why i like apple.
Counterpoint: do not read my clipboard without any action on my side, dude!
From the perspective of the simple dialog, its a problem with the consumer app who calls the api to open the dialogue without context, without informing the user or obtaining user consent prior to doing so. Plenty of apps get this right, eg. Have a screen with buttons in the on-boarding flow that opens the dialogue next to the “maybe later” option, and use that page to explain or “sell” the benefits of enabling the permission.
Maybe the dialogs api should be treated like autoplaying videos with sound on the web, just disable the api if it is called outside of a click event handler, and let the consumer app break. That would be a breaking change for OSs tho. It wouldn’t prevent malicious UI patterns from triggering annoying permission prompts, but it would minimize accidental bad ux eg calling it in the main method on load
Well, usually the answer is no, and then when something breaks the app will tell me.
Which reminds me. Why does the CVS app need access to Bluetooth?
> when something breaks the app will tell me.
Then you have to require these permission controls to tell the app the user denied permission, and not just giving a valid but empty result. Some people on HN feel strongly that when you deny contacts permission to an app, the app should receive a list of dummy contacts. Without it a bad app can lock its UI and not do anything unless the permission is granted.
Oh! There's actually good reason!
If you have an Extracare card, in some markets, you can self-unlock the locked display cabinets with the CVS app (because they have your identity via the ExtraCare card which adds inherent trust).
It's powered by the Invue smartlock platform. https://invue.com/smart-locks
https://abc7ny.com/post/cvs-testing-new-nyc-shoppers-open-ca...
Very interesting. But I'd imagine they aren't doing proper KYC to get an ExtraCare card, I bet it is very soft KYC. Like phone number verification or card payment which you can get anonymously, so it won't necessarily do too much to find the perpetrator. I wonder if it works through throttling and blacklisting so the loss and damage radius are reduced.
At the same time, though, the thought is "a criminal won't give out their business burner's cellphone number" to sign up for a card/unlock a case. There's still an additional level of self-selection required to be honest enough to want to acquire the loyalty card that a "dishonest" person does not want to spend time doing (they want to snatch and run).
Same reason Walmart gated the self-checkout Scan-and-Go-via-phone system behind a paid membership on Walmart+, criminal's not gonna burn fifty bucks to steal a couple times if they have to hand over anything vaguely close to PII, even if it's burner PII.
Ah, are you telling us that while people were outraged about rampant theft and pointing to all the locked-up merchandise as emblematic of the corporate response to rampant theft, even while there wasn't enough staff to unlock the cabinets... but the lockups are also a way to entice customers to install the app, sign up for an account, and enable Bluetooth all the time?
https://youtu.be/zS9U3Gc832Y?si=BmVOHE6ahKLbw82c
Are you telling us we're being increasingly policed by technology?
Yes! This is part of the Flockification of everything.
I mean, I didn't go to the worse version. Step right up to the little display, enter your phone number, smile for the camera, and the case unlocks magically!
https://indyme.com/solutions/freedom-case
The CV footage just adds that extra comfortable feeling, doesn't it?
https://indyme.com/hubfs/E6A61CF7-E252-4994-91E1-0FC0E88781F...
It's "freedom" for "honest shoppers"!
Even better, they have a model called the "Freedom Cage"!
Have a problem with pesky permissions dialogs from sandboxed apps? This unsandboxed unverified app that requests Accessibility permissions, to the rescue!
It's a couple hundred lines of code. You could just, like, read it.
Well I don't have the problem it's trying to solve so I don't need to. But among people who install it, how many will? And remember to do it again before every upgrade?
Honestly it can drain my crypto wallet or whatever as long MacOS stops doing an imitation of Windows Vista with a billion security pop ups.
Cancel or Allow?
https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt
Non-sandboxed apps have this permission prompt too.
Reddit comment
Can I have the opposite, a tool that automatically clicks on "allow"? I installed the app, it's fine.
So you're kinda looking for a "I want to allow this software to do whatever it wants - I accept all risks?" button? And with each new update you're re-evaluate?
> So you're kinda looking for a "I want to allow this software to do whatever it wants - I accept all risks?" button?
Yes.
> And with each new update you're re-evaluate?
No. Hope that helps.
"I want to allow the software to talk to devices on my local network", not "whatever it wants".
I've never had a case of this where the access was malicious, and devices on my network have security controls. For me this popup is exceptionally low value.
Yeah. That’s how installing an exe has worked for a long time.
Some people like to live dangerously!
You can allow-list certain IP address ranges to not need the local network permission and I believe that should stop the popup from appearing (but I'm not sure). See https://developer.apple.com/documentation/technotes/tn3179-u... for more information, TL;DR:
I did that yesterday after updating from macOS 14 to 15 on my work laptop; well, added "10.0.0.0/8" too. Spent a few hours trying to understand that that new permission thing simply couldn't work with my Emacs launch agent (service)... fucking Apple treating CLI users like dirt.
Thanks for writing and then sharing this document. (Kidding. Thanks though.)
Sometimes you need to use a particular piece of software but don't want all of its functionality. You're allowed to want some but not all.
I don't know what Apple is looking for. The iPhone ships with a Weather app preinstalled, you allow it to your location so it can warn of severe weather, and several weeks later "OMG WEATHER APP IS USING YOUR LOCATION!!11!".
Same with MDM agents. Ours are installed automatically as part of the Apple Business Manager configuration, we manually grant them precise location in the background, and months later "HEY USER, WANNA BLOCK LOCATION FROM 'MDM SERVICE'?".
Edit: To avoid replying to the two following comments with the same reply, my gripe is not about the notification, that's a good thing; my gripe is with their implementation, which seems very in tune with Apple's way of complying with regulations. There are definitely many user-friendly ways to handle privacy compared to seemingly random notifications.
The first scenario is due to anti-trust complaints forcing Apple to treat their pre-installed apps identically to third-party ones. (Also why you can "delete" system apps.)
Doubly annoying as it asks for the widget separately.
So many smart people and yet such a stupid timeline. Usability psychology is well documented.
That was due to antitrust pressure such that they did not self-prefer their own apps.
You'd think that would force them to make the third party app experience as good as the first party app experience. Instead, they did the opposite...
Seems like this is a signal that they in fact take the privacy concerns seriously?
If they took the privacy concerns seriously it wouldn't take anti-trust pressure for this to happen.
I didn't say you weren't. I'm asking for myself, not for you.
Okay, to me it reads like a lazy swipe. You seem to be aware of the power of AI to build you whatever you want, so why ask this question like this? It seems like you're just trying to tell people they should fully trust the software they install.
No, I'm very obviously not, and the only lazy swipe was your response.
I assume that is a quick fork and publish, but seems scary lol
I'd rather something tell me exactly why this popped up in the first place, as every new OS version seems to introduce more triggers. I have apps that now pop this up when I quit, which doesn't make much sense.
Ideally, every API to call a function that provides the developer "dangerous" access to your system, should give the developer a text string argument to explain/justify to the user why it's needed. Then, instead of a confusing "Do you want this app to use Bluetooth?" pop-up with zero context, you let the developer convince the user.
Agree with that, I like the idea of permissions for specific things like this but it’s way to hard to know what’s actually being asked and why.
Amazing. I'd LOVE for you to expand it, to also auto-dismiss "Foo.app would like to access data from other apps."
Adobe programs ask for this every time they start, and Claude Code randomly asks me this daily out of nowhere. It doesn't matter how many times I click "Don't Allow", it never gets remembered. (But of course if I ever mistakenly click "Allow" even once, that gets remembered for eternity and I never get asked again...)
Don't know about Adobe but the issue with Claude Code is when Claude does a recursive find or grep on your home directory. You might be able to fix it just by putting some warning against doing that in your global CLAUDE.md
CLI/developer tools in general often lose or forget permissions because they aren't shipped as proper signed Mac app bundles, so the OS has no stable identity to attach the permission grant to. You might find that even if you click allow, that gets forgotten too sooner or later.
Says a lot about the state of Mac OS.
Linux is no better... Why should I ever allow "xdg-portal-something" access to "wallet" when I start chromium (or some app embeds it)?
Did Apple hire some of the folks who created Windows 11? How else can this trend be explained :)
Yes they are hiring H1Bs at the same level as the rest of F_GMAN
Can’t we not have some OS level thing which suppresses all intrusive dialog and puts them in a nice inbox so I can decide which I want to answer or ignore in bulk…
I'm surprised nobody here is saying "what if your staging server is on the LAN, or you want to test a website from another machine?" Somehow Safari allows it, and Chrome has to go through this system that prompts you. I try never to miss one of these permissions ("yes"), because having Chrome blocked from local websites is just no good.
Chrome may start restricting requests to private networks (2021) https://utcc.utoronto.ca/~cks/space/blog/web/ChromePrivateNe...
side note but what is the consensus on figuring out whether small brew packages like this one are malicious?
I'm sure this one probably isn't, but I have no clue how I would know whether it is without reviewing the source code myself (or pointing an agent at it etc)
Even if they're not malicious, there's no guarantee that they won't become malicious in the future. Prefer living off the land, and install only the very essential extras.
Good question -- I have been pointing claude at repos for security reviews before I install stuff now for exactly this reason.
It's so funny to read these, as if countless examples didn't prove that llms don't actually distinguish between your instructions and the data they read at your request.
Do you think a malicious repo author won't think of hiding a suitable prompt within?
> countless examples
Show me just one where a frontier model got prompt injected when checking if code if malicious.
FWIW I can do this, but I bet you can't.
Here's prompt injection via a harness for example: https://www.promptarmor.com/resources/google-antigravity-exf...
took me about 30 seconds to find. there's tons of them. of course it's an arms race, the models get better the harnesses get better the attackers get better but again: for the model itself, your prompt and third party data it reads are the same thing (input). as long as it is true, the attack will always be possible.
Basically the question for any executable code (or even just any data) that you let on your machine and which did not go through independent vetting processes. The question you need to ask is if the benefit (getting rid of an annoying popup) is worth the risk of a distribution method that is trivial to compromise.
so we are back at choosing where we draw the line and you picked this one to get us going
That's why I like small, open source projects like this one. I don't have to figure out if it's malicious. I just fork it, then ask claude to review the code, then run my own fork.
> Chromium browsers (Chrome, Brave, Edge, Island, Arc) copy their own app bundle into a random temp folder at launch so the code signature survives in-place updates. macOS keys the Local Network decision to that random path, so the next launch looks like a brand-new app.
OH DEAR GOD that explains so much other cursed behavior, including the "do you want to allow google chrome helper to show notifications" always reappearing. or teams. or anything that does autoupdates.
> Nothing on a typical Mac needs this permission except a printer or scanner utility, a media server, or a LAN-discovery tool, and those you answer once and they're done.
This is wrong. Browsers and media players need it because that is how multicast discovery for stuff like Chromecast works. Spotify, same thing. And Steam plus virtually all games with LAN multiplay for the same reason. Did I note already that Steam also has an autoupdater and so does Spotify and... argh.
Apple really needs to fix the very first point, preferably in a way that doesn't force app developers to ship a "helper" binary.
(Side note: it might even be the case that opening the file picker may be enough, if you got network-discoverable paths in your Finder Locations sidebar, but i'm too tired to test that one out...)
That explanation sounds wrong to me. I've written my own implementation of macOS signing logic. TCC doesn't usually tie permission grants to paths, it ties it to the designated requirement of the app bundle, which in turn is usually an indirection through the code signing certificate identity. The whole macOS architecture is designed to let you drag apps around and treat them as files, it's not a UNIX where installation path is meant to matter.
I just dumped my TCC database and the entries are mostly not path tied. The Chrome entry is as expected a bundle ID+designated requirement. Unless the local network permission inexplicably uses a different permissions engine, that statement is a misdiagnosis of what's happening.
In other words, the permission grant applies to any Chrome channel as long as it's signed by Google's team ID.Even for chromecast and spotify I never want or use these features, and if I am not turning such a feature on I never want to be asked about a permission related to it, as a user. If I am turning a feature on or I am trying to use chromecast, THAT is the time to prompt me about it
It's a user experience thing. They don't want to show the cast icon to the user if there is no device present to cast to.
(I think both POVs are valid, but the actual solution should be for a proper OS-level interface to provide mDNS discovery...)
The permission keying off of a temp folder feels so broken. I don't know whether Google / Chrome deserves the blame for the weird hack of running an app from a place the user never specified or Apple the OS for making such a hack necessary and not giving the permission system a way to understand the canonical user installed app as the source of the request.
This is the sort of classic MacOS situation that has mandated the use of Hammerspoon scripts and the like for more than a decade by now (this is not a sectarian point btw, Windows requires winutil just the same according to my optics)
There should be a third option: allow but give fake data
And it should be default.
Thanks. It’s macOS' own cookie banner and dick bar.
It’s weird they haven’t just made this a menu flag…
"One Swift file" except it's two Swift files
One bunch of Swift
Swifties are everywhere
oof, it was originally one, forgot about the refactor lol
Hmm another gripe of mine. Mac OS's vnc brings a popup that steals your focus when someone connects to the machine while you're physically in front of it.
I know it's well intentioned but I have this weird setup where I am almost constantly keeping vnc on from my laptop to my desktop. And the mbpro randomly wakes up to do whatever, even when not used, which reactivates the vnc connection, which pops up a warning on my desktop, which steals my focus.
Anyone knows a way to disable that? Possibly just for connections from a specific other machine.
Edit: as for this app, I think the OS only asks once for a new app? I don't remember being asked a second time even when denying it.
I could also whine a bit about "this app wants to access files on a removable volume" since my desktop has a thunderbolt ssd plugged in for extra space...
https://forums.macrumors.com/threads/repeated-allow-google-c...
You can see other people with tens of instances of the same app in the settings for this
Yes. Thank you. This is such a simple thing that should be a part of the operating system, and in the ideal world it would be. This is the perfect problem for the LLM to solve, because the reason it does't exist in the system is a decision by some stupid PM at Apple, and not an actual system constraint.
It’s just a choice of which key to use. I don’t think it was some decision made with this intent, I think it is just the unexpected result of a decision.
I maintain that Steve Jobs would have taken the engineers to task over this poor UX.
Permissions consent prompts are broken. they are far too coarse, and out of context. The customer is forced to consent without knowing the scope or what will break.
A better experience would be an async consent screen, with placeholder content and calls to action until permission is granted.
For example, a network ping scanner could show placeholder host names & status until the user clicks to allow access.
The operating system could easily stub the sensitive APIs with placeholder content and a flag indicating the content is false. So even legacy apps could work.
this is exactly the type of app that makes me excited to see what the future will hold with ai. any regular joe or jane can now realistically solve many of their small annoyances with little effort and no experience.
(not saying this is ai or not, i have no idea, just speaking generally)
Yes! I got annoyed that I had to manually close old finder/preview windows, so I OSSd an app that closes any stale window. There have been commercial apps in this space a decade, but none worked how I wanted (per window not per app, config each app separately). So I just made it with Claude using some spare tokens at the end of the week. You can customize anything to be the way you like it now.
https://github.com/scosman/Squeegee
This particular item never been a problem for me because I incessantly close everything after I am done with it but it is super cool that we can ask AI to dig into the weeds for us now and fix our annoyances -- or even search repos online where someone else had and fixed this problem
The first app I will do is Spotlight. Its insistence on finding everything across the universe except applications is tiring.
We're getting free from our software!
Sometimes I am shocked by how blind Spotlight is. I will have something in my applications folder with a straightforward name -- say, Steam.app -- and it will keep picking the shortcut generated by CrossOver for the Windows version of Steam, that is nested inside a bunch of subfolders. Wtf? I ended up renaming the CrossOver version to WinSteam so it stops prefix-matching.