Archive for October 27, 2022

Thursday, October 27, 2022

Apple Security Research Blog

Ivan Krstić:

Apple Security Research, our new blog and website at security.apple.com! We launch with an update on Apple Security Bounty, and a deep dive into some fundamental XNU memory safety improvements with kalloc_type.

Why doesn’t Apple like RSS?

Apple Product Security:

At times we received many more [security bounty] submissions than we anticipated, so we’ve grown our team and worked hard to be able to complete an initial evaluation of nearly every report we receive within two weeks, and most within six days.

[…]

Our Apple Security Research site includes a new way to send us research on the web and get real-time status updates.

Previously:

WSJ Tech Live 2022 Apple Interview

Joe Rossignol (video):

Apple’s software engineering chief Craig Federighi and marketing chief Greg Joswiak spoke with tech columnist Joanna Stern at The Wall Street Journal’s Tech Live event in California on Tuesday. A full video of the interview is now available on YouTube.

Some good questions, but not a lot of real answers here. It’s notable that they neither defended Lightning as a technology nor indicated that they were working on anything better. They just like the name and the large installed base—and don’t like governments telling them what to do.

Sami Fathi:

Apple’s vice president of worldwide marketing, Greg Joswiak, today said that Apple will have to move to USB-C on iPhone and its remaining devices that still have a Lightning connector in order to comply with new EU rules.

Chris Hannah:

I wonder if the EU law works somewhat in Apple’s favour here. Apple were clearly already on a journey to USB-C with the rest of their products. Although some would argue, the iPhone was destined to be port-less. However, this allows Apple to redirect any possible negativity towards the switch to USB-C to the EU.

Matt Birchler:

I know ordinary people in my life who don’t use social media or follow tech news at all and they are getting annoyed with the iPhone using “Apple proprietary port” instead of what everything else uses. This is anecdotal, of course, but this wasn’t a thing I heard 5 years ago, and now it comes up all the time when I talk to people about what they like/dislike about their iPhone.

Previously:

Preview Drops Support for PostScript Files

Joe Rossignol (tweet):

Starting with macOS Ventura, released this week, the built-in Preview app on Mac no longer supports PostScript (.ps) and Encapsulated PostScript (.eps) files, according to a new Apple support document. Preview can still be used to open these files on macOS Monterey and earlier. Apple did not provide a reason for the change.

This is sad, since I have tons of these files. Interestingly, the frameworks still seem to support them, as they still display properly in third-party apps such as EagleFiler and Skim.

Update (2023-02-21): Rob Griffiths:

But this now fails because Preview won’t parse the PostScript file. There are two solutions for this, one that relies on an external package (which is the solution I found), and another using only macOS’ built-in tools (which I found just after finishing this writeup).

Ventura’s “Open at Login” vs. “Allow in the Background”

Quinn:

  • Open at Login shows a list of login items, per the legacy kLSSharedFileListSessionLoginItems API. These items are always launched at login, and are intended to be under the control of the user.

  • Allow in the Background has different semantics. This is an allowlist. It doesn’t show what programs will be launched at login, it shows what programs are allowed to be launched at login.

You can see this with the SMLoginItemSetEnabled API:

  1. Enable your Service Management login item by calling SMLoginItemSetEnabled with true.

  2. The item shows up in the Settings list.

  3. Back in your app, disable your login item by calling SMLoginItemSetEnabled with false.

  4. The item still shows up in the list.

Via John Siracusa:

Can this really be true? If an app ever wants to be able to launch on login in Ventura, it must forever appear in the “Allow in the Background” section of the Login Items screen in System Settings?

The new SMAppService.mainApp.register() and unregister() calls will add and remove an app from the “Open at Login” section, but nothing seems to remove an app from the “Allow in the Background” section.

[…]

To be clear, the problem with Ventura listing apps set to launch on login under the “Allow in Background” section is that it implies they can “perform tasks when the app is not running,” as the text says. But launch on login is not that!

John Siracusa:

Ventura’s handling of “launch on login” will make users suspicious of apps that the OS says can do stuff when they’re not running, even if that isn’t true. And when a developer explains, the user won’t believe the truth because the OS says otherwise. It sows distrust and worry.

Guilherme Rambo:

There should definitely be a distinction between simple login items and launch agents / daemons, which are the things that do in fact allow an app to do stuff when it’s not running.

John Siracusa:

Also, this is only a problem for apps that want to work on pre-Ventura versions of macOS. If your app requires Ventura, you can use only the new Ventura-specific API to launch on login and keep your app out of the “runs in background” list.

Stephen Hackett:

I’m not sure this new notification in macOS Ventura could be less helpful if it tried. What items? What is “System Events.app” and why is it in quotes?

Ezekiel Elin:

I've filed a few FBs about this system over the summer, most notably that it tends to just dump a whole bunch of alerts on the user at once

Like, jeesh

Previously:

OmniDiskSweeper 1.14

The Omni Group (tweet):

When OmniDiskSweeper cannot fully read the contents of a file or directory (due to system protections or file permissions), it places a + sign next to its size to indicate that the reported value is an incomplete, minimum value rather than the total size. (For example, a size of “1.8 GB+” indicates that the content OmniDiskSweeper was able to access was 1.8 GB, but there was additional content which OmniDiskSweeper was unable to read.) Incomplete sizes will always be sorted above complete sizes, since there’s no telling how large that content actually is.

There are lots of apps that can calculate the sizes of all your folders, but I still like this one the best.

Previously:

Dropbox on Ventura

Peter Steinberger:

The new Dropbox version for macOS Ventura is absolute garbage. fileproviderd is eating my CPU alive, files are no longer really on disk so QuickLook and some apps fail, etc. How did this ship, even as beta?

Then again, it’s now about as unreliable as the iOS Files extension, which crashes after using it a while and the only recourse is to reboot iOS.

This is not the first time that the official API ends up being less reliable than the original hacky solution.

I’ve mostly switched to iCloud Drive, and when I do need to access Dropbox I do so via Transmit.

Previously: