Archive for July 28, 2022

Thursday, July 28, 2022

Ventura Notifies User of New Login Items

Thomas Clement:

wow so now Apple is going to use my personal name in user notifications to tell users I’m personally installing login items on their machine. I think there’s a difference between the app (that users voluntarily install) doing things and me doing things. That’s… very wrong.

macOS seems to have gotten his name from the code signature on his app. The notification is a potentially useful feature, but it would be better if it reported the name of the app that added the login item. The user doesn’t have a good way of finding the app that corresponds to the reported developer name. Also, showing the developer’s name is especially confusing in the case of an indie developer, where it shows a personal name rather than the name of a company. The notification makes it look like a hacker named “Thomas” broke into your Mac.

Rich Siegel:

This is really terrible UX, and if you see it while testing macOS 13 please report it as a bug.

Update (2022-10-17): Marcin Krzyzanowski:

security by obscurity or what. What’s the point of that 🤔 it literally cannot be more generic information Image

This is going to be so confusing for users.

Update (2023-01-05): Adam Maxwell:

This has all been working fine since 2010, so obviously Apple needed to change something. Aside from the obvious notification bug, TeX Live Utility users have no idea who this “Adam Maxwell” guy is, and shouldn’t have to learn.

Matt Birchler:

OMG, months into Ventura and I still get notifications like this when I reboot. Literally no idea or explanation what this is.


Update (2023-02-03): Christina Warren:

The never-ending “Background Items Added” pop-up for an item I already disabled or already know about is the most annoying part of Ventura after the new System Settings design.

Tim Hardwick:

Numerous Mac users are repeatedly encountering a bug in macOS Ventura that throws up Login Items notifications for various background app processes every time they start up their machine, even when the processes in question have been disabled.


Scouring the complaints across Reddit, Twitter, Apple Support Community discussions, and various other app-specific forums, app processes such as Google Updater, Adobe CC Helper, and Dropbox are repeatedly cited as culprits, but these only appear to be referenced more often because they are popular apps with background processes. Almost any third-party background process can seemingly be referenced in the persistent Login Items notifications.

Update (2023-02-14): Norbert M. Doerner:

The new bug in macOS 13.2 can hopefully be fixed by using Apples and paste and run this command:

sfltool resetbtm

You may need to restart your Mac once to see this in effect.

Unfortunately, the resetbtm option for the sfltool command line tool is not documented by Apple, the man page does not list it.

Update (2023-02-16): macOS 13.3 Beta:

Fixes an issue introduced in macOS Ventura 13.1 that caused the system to post excessive “Background Items Added” notifications after toggling items in System Settings > General > Login Items. Toggling items in macOS Ventura 13.2 doesn’t cause excessive notifications, but that release doesn’t automatically correct the issue inherited from macOS Ventura 13.1.

Studio Display Audio Issues

Seth Willits:

Audio recording from my Apple Studio Display microphone is still fundamentally broken in every app. Latest OS and display firmware versions.

And for what it’s worth, I filed this back in May as FB10017937. No response from Apple yet.

For the last month or so, the speakers on my Studio Display have been broken. Whenever I start playing music (or any other audio), it works for a few seconds and then cuts out.

Internet of Shit:

I have one of the new Apple Studio displays.

Recently, it started being weird: webcam and sound would only work sometimes…

Kirill Zakharov:

Friendly reminder to restart your Studio Display 🤦‍♂️

Indeed, this worked for me. I had restarted and shut down my Mac, but I’d forgotten about restarting the display.

Holger Laufenberg:

YOU HAVE TO RESTART your studio display on occasion, especially if you run into issues with the3 camera, microphone or speakers. The studio display runs its own internal version of IOS that operates the camera, speakers and microphone. Much like ANY other device that runs its own operating system, you can’t run it indefinitely without ever restarting it. You will eventually run into issues and your device does funny stuff. I got my studio display on march 18th and yesterday the camera started acting up, then the microphone etc. After hours with Apple support and trying all kind of things to isolate the issue, it occurred to me that we did EVERYTHING except restart/reboot the display itself. because it has no power button and no software control to restart it, the only way to do it is to unplug it from the power source, wait at least 1 full minute and plug it back in. Of course it immediately solved all the issues.

We spent so long asking for a basic 5K Retina display but never thought to specify that it should have a power button and a decent camera.

Mario Guzman:

I have to restart both my Apple Studio Displays. Otherwise, audio gets choppy and eventually just cuts out completely. Rebooting the Mac doesn’t help. You literally have to power cycle the entire Studio Display(s). Happens about every 5-6 weeks for me it seems.

I rarely use the display’s speakers, so it’s quite possible that my display also had this problem before but that it was temporarily cured by restarting after the firmware update in May.


Update (2022-08-02): See also: 9to5Mac, MacRumors, iMore.

Francisco Tolmasky:

Just make a display. Sometimes it feels like Apple just can’t do stuff without making it weird. Can’t just ship multiple windows on iPadOS without “re-imagining multitasking”. Can’t make a good display without putting shoving old iPhone inside of it.

Update (2022-08-04): Gus Mueller:

My Studio Display’s microphone was fucked up, so of course I had to reboot it to make it work again. Which of course meant I had to unplug it. Has anyone figured out how to remote ssh into this guy so we can just reboot it from the terminal?


PackageKit SIP Bypass

Mickey Jin (tweet):

I found some new attack surfaces in the macOS PackageKit.framework, and successfully disclosed 15+ critical SIP-Bypass vulnerabilities. Apple has addressed 12 of them with CVE assigned so far.


Moreover, an attacker could get arbitrary kernel code execution with the SIP-Bypass primitive. I did find a new way to do this on the macOS Monterey, but I couldn’t share the exploit here right now, because it is related to another unpatched 0-day.


The service provides only one method to shove files from one place to another place[…] However, there is no check for the incoming clients, and any process can fire the XPC request to the service. Therefore, we can abuse the service to bypass the SIP restriction.

And another issue:

In short, the system command /usr/libexec/configd has a special TCC entitlement: kTCCServiceSystemPolicySysAdminFiles, which grants the command permission to change a user’s home directory and forge the user’s database file TCC.db. An attacker could inject a malicious dylib into the process to enjoy the special TCC permission.


Purgeable Mac Apps

Daniel Jalkut (tweet):

For months now, I have been scratching my head over a small but persistent number of “crash reports” affecting a few of my apps. The issue is most prevalent in MarsEdit, where I have a handful of users who run into the issue multiple times per day.


Here we have a message asserting that MarsEdit was terminated, on purpose, and better still, it includes an explanation! As far as explanations go, “CacheDeleteAppContainerCaches” is not much of one, but it did give me something to go on. Searching for the term yielded pertinent results like this post about Apple Mail and Safari “suddenly quitting.” Unfortunately, they all seem to be scratching their heads as much as I am.


With some tinkering, I was able to narrow down the reproduction steps to running the “Free Up Purgeable Space” action. It turns out this is invokes a system API responsible for trying to delete caches, etc., from a Mac. Normally the system only does this when disk space is critically low, but CleanMyMac gives you the option to exercise the behavior at any time.


As you’ve surmised, the exception code 0xbaddd15c (‘bad disc’, which sounds worse than it is) seems to be related to our CacheDelete subsystem.


CacheDelete won’t delete files out from underneath a running app so, if it needs to delete something, it terminates the app. It should only do that when the app is essentially invisible to the user.

macOS really doesn’t like it when the disk is almost full.

Here’s a list of other such exception types.

See also: Howard Oakley.