nmgycombinator

> The primary outcome appears to be increased profit margins rather than societal advancement. While previous technological revolutions created new industries and democratized access, AI seems focused on optimizing existing processes without providing comparable societal benefits.

This is the thing that worries me the most about AI.

The author's ramblings dovetails with this a bit in their "but the craft" section. They vaguely attack the idea of code-golfing and focusing on coding for the craft as essentially incompatible with the corporate model of programming work. And perhaps they're right. If they are, though, this AI wave/hype being mostly about process-streamlining and such seems to be a distillation of that fact.

Edit made: Ventura and Sonoma will remain vulnerable. Apple made the decision to only patch this in Sequoia.

I mean, I don't know how there would be? Unless they were scanning the text of every pop-up for words convincing the user to enter their computer password. There would be no way to determine intention without some sort of language analysis.

I agree with you. However, in this case, I was abusing a legitimate OS prompt (not just making my own), so I don't know if a security image would be a barrier there. It would definitely be one for instances where malicious apps make their own pop-ups.

That's a fair point. But did Mac have the same issue as Windows where file extensions were not shown by default? That feels like it would have been the core issue.

I mean, as others have mentioned, actually true capabilities would be nice. But as long as we're going to have a database, it would have to end up in user space or in the kernel. And I'm not sure how much I like either option.

Ooh! Thanks for the links!

I think Apple uses an L4 variant for their SEP co-processor, though I'm not sure if it's that specific one. Sounds like another OS I'll probably have to do a deep dive into at some point.

Damn, that really puts things into perspective. Granted, attached modals presuppose there's a window to attach to. But I think that would probably be true 9 times out of 10.

I do agree that uninstallation can be hard on macOS. I think Apple just envisions a future where every app is self-contained and putting the app in the trash really does remove everything because it was all in there.

Maybe that's not realistic, though.

I still think there's something to be said about an installation/uninstallation process that relies purely on moving files around, no custom script execution.

I will definitely admit, it can be a bit of a pain point that Apple sometimes takes a lot of time to determine a bounty. I'm just waiting patiently now to see what they say. I appreciate your kind words and encouragement.

I think their "Hall of Fame" (or at least whatever people colloquially refer to as that) is their credits for people who found bugs in their web servers, so I don't think that counts here. I did get credited, so I'm happy about that. Now I just have to wait and see if they determine it's worth a reward (and, if so, how much).

Correction (longer explanation elsewhere): only 15.5. Apple didn't patch it in the other two releases.

Yeah, to be perfectly honest, I understand. I think TCC is meant to be the primary consent system, but there are others (such as the Authorization system, and the Service Management framework).

As someone who dove deep into keychain items for a previous write-up, I believe you are misunderstanding this situation. As far as I understand it, many keychain items can be stored in your iCloud keychain. However, your local machine can have its own keychain that's different than the iCloud keychain, with items that are not sent to iCloud.

And besides all that, to my knowledge your local machine password (the password you use to login) isn't stored in a keychain item, so there's no way it could make itself into the iCloud keychain, or your local keychain.

You may be mistaking some explanations. Your computer password is used to unlock your local keychain, but it itself is not stored in your keychain. Your local keychain is also not your iCloud keychain, it's not stored in iCloud.

Again, I'm not an Apple developer, so there may be stuff I don't know, but I am a developer in general and I have researched this. The above is my current understanding.

That's honestly a pretty smart move.

Hijacking this current top comment to let everyone know there is an important update to this article: https://news.ycombinator.com/item?id=43969087

Oh nice! I'll take a look at these.

An important correction, so hopefully this bubbles to the top (this will be appearing on the post as well):

A previous version of this article mentioned below that this CVE was patched in macOS Sequoia 15.5 et al., but I was a bit mistaken in that. Despite being released today as well, it appears that macOS Ventura 13.7.6 and macOS Sonoma 14.7.6 are not patched against this vulnerability.

I wrote that sentence assuming that Apple would have included a patch in all of the releases. It was only later, when I checked the security release notes, that I saw I was not credited under the other two releases. I reached out to Apple to clarify if these releases were patched. As of writing, I have not heard back.

I chose to do my own testing and spun up a virtual machine. After some difficulties I got it updated to macOS Sonoma 14.7.6 and was able to compile and run my proof of concept. It still worked. I would assume the same is true for macOS Ventura 13.7.6. I'm not sure why Apple didn't include the patch in these two releases.

I will update the post when I have more information and/or context.

Thank you for your kind words. To respond: 1. I'm not a "he", I would prefer "they". 2. As I mentioned in another comment, I have not received word back yet on any reward.

As someone who's looked into the internals of macOS for a bit now, this is all incredibly fascinating. However, I am curious: do you think capabilities could be implemented like this at a really low level? Part of me thinks we have the security models we do in POSIX is because they're simple enough to represent in C code.

The capability systems you're mentioning sound cool, but they sound a lot more complex. And if that's true, and they aren't built with irreducible complexity, then it would be possible to work around it by just pulling out bits and pieces from the system and abusing them.

Lol, I know that curiosity feeling.

Damn, that sucks.

I'll definitely start considering it.

How often do you face that? I would think the OS would save your response in a way it could refer back to.

There's a small section in System Settings that they don't really tell you about that pops up when the OS blocks a file from opening. You can then override the block there. Yes, it's extremely annoying.

Quick clarification on terminology. From a developer perspective, entitlements a static dictionary (or a collection of key-value pairs) attached to the app at code-signing time. The entitlements you mentioned don't "entitle" the app to access resources, as user consent is still required.

An app with [the com.apple.security.device.usb entitlement](https://developer.apple.com/documentation/bundleresources/en...) is technically always going to have that entitlement attached to the app regardless of user consent.

> The idea being that I could then migrate more easily by copying the whole home directory, and thus all my apps that didn't require "installation" would come over.

Unrelated, but this is what I find so interesting and cool about the drag-and-drop to install method prevalent on macOS. People complain, but what I guess they don't realize is that all they're doing is moving a folder into their `Applications` folder and that the "wizard" way they're used to is far messier.

Granted, since I think it's up to the developers, they often seem to make the user drag and drop into the root `Applications` folder.

Fascinating! Personally, I need an admin account in my daily work, so I wouldn't do this, but for those it could help it definitely looks interesting.

That's an interesting idea. I do think it would be nice to have some way of knowing "is this prompt coming from the operating system or some third-party app?". However, I don't think it would have helped in the case of my vulnerability, because it abused a legitimate OS prompt.