Apple had a bad week. On 29 July 2024, the company released updates to all its operating systems with a few minor changes in macOS 14.6 Sonoma and nothing but bug and security fixes for everything else (see “macOS 14.6 Enables Double Display Support for 14-inch M3 MacBook Pro,” 30 July 2024). We noticed no problems after installing, so we gave our usual recommendation for minor updates that don’t address zero-day security vulnerabilities—wait to install until it’s convenient. Usually, showstopper problems will be reported within a few days, and Apple will pull or replace the release quickly. This time, it took over a week.

On 7 August 2024, Apple pushed out macOS 14.6.1 Sonoma, iOS 17.6.1, and iPadOS 17.6.1 with release notes saying, “This update includes important bug fixes and addresses an issue that prevents enabling or disabling Advanced Data Protection.” Apple also released macOS 13.6.9 Ventura with slightly more concise release notes that say, “This update addresses an issue that prevents enabling or disabling Advanced Data Protection.” (For more information about what’s involved here, see “Apple’s Advanced Data Protection Gives You More Keys to iCloud Data,” 8 December 2022.)

Indeed, when I went to System Settings > Your Name > iCloud > Advanced Data Protection and clicked the Turn On button, I was prompted for my Apple ID password, but the password dialog disappeared after I typed a single character, the System Settings screen flashed, and I was presented with the error below. On subsequent tries, the setup got farther, but I wasn’t willing to remove my old devices from my account to complete the setup process.

Apple’s security updates page says the updates don’t address any vulnerabilities with CVE entries, and Howard Oakley reports that the only changes are to the Security framework and some keychain-related files. The question, then, is what might be included in those “important bug fixes.”

There have been a small number of complaints about macOS 14.6. In TidBITS Talk, Ronald Lynch reported that, after updating to macOS 14.6, he lost access to Pages templates he had stored in the Template Chooser and couldn’t create new ones. Installing macOS 14.6.1 didn’t bring back his previously stored templates but allowed him to create new ones. In other forums, multiple people have reported extreme slowdowns and problems with Bluetooth pointing devices, plus individual complaints about mounted NAS volumes disappearing from the desktop and enterprise authentication issues. As yet, it’s unclear if these were general bugs or issues specific to particular setups. Nor have follow-up posts said whether or not they were fixed by macOS 14.6.1.

iOS 17.6 has triggered complaints about dropped network connections and notifications not working, along with the perennial problems with battery life that usually resolve within a few days once iOS rebuilds indexes and caches. Again, I haven’t seen any subsequent reports about iOS 17.6.1 either way.

There is one new complaint about macOS 14.6.1 related to headless Macs (those without displays). A TidBITS reader reported that he wasn’t able to connect to a headless Mac mini after updating. He had to turn Remote Management off and back on to regain the ability to connect remotely. If you are updating a headless Mac, connect it to a keyboard, mouse, and display before updating, and toggle the Remote Management setting in System Settings > Sharing > Remote Management before removing them.

My revised advice about updating to this set of updates is as follows:

• If you’re still running macOS 14.5, macOS 13.6.8, iOS 17.5, and iPadOS 17.5 with no problems, stick with them for a bit longer. None of the identified security vulnerabilities in those releases are actively being exploited in the wild, so there’s no big win in updating right away. Revisit the question in a few weeks.
• If you updated to macOS 14.6, macOS 13.6.8, iOS 17.6, and iPadOS 17.6 but aren’t having any problems and don’t intend to turn Advanced Data Protection on or off, stick with them for another week or two to make sure Apple didn’t introduce any more bugs in the latest updates.
• If you updated to macOS 14.6, macOS 13.6.8, iOS 17.6, and iPadOS 17.6 and are having issues of any sort or want to turn Advanced Data Protection on or off, update right away to take advantage of Apple’s fixes.

There’s no question that Apple dropped the ball here. Advanced Data Protection may be a relatively new feature used by only a tiny percentage of the Apple audience, but automated testing should have caught the error I showed above. Perhaps Apple has redirected most of its testing resources to the forthcoming macOS 15 and iOS 18, but that’s no excuse for causing trouble for the current user base with a weakly tested update.

Network Utility was a fixture of macOS from its early days through macOS 11 Big Sur, when Apple dropped it, instead directing users to use command line tools. Apple’s argument seemed to be that the only people who needed the tools Network Utility provided—things like netstat, ping, lookup, whois, traceroute, and finger—were advanced users already familiar with using those tools on the command line.

Perhaps that’s true for network-involved sysadmins, but I suspect many of us occasionally want to use some of these tools and would prefer a graphical interface to a bunch of text scrolling by in a Terminal window. And I do mean occasionally—it was probably a year before I internalized that Network Utility was gone, and I’ve missed it only a few times since.

But I did miss it, so I was delighted to learn that the fine folks at DEVONtechnologies—Eric Böhnisch-Volkmann and Christian Grunenberg—just released Neo Network Utility, a near-clone of the app we remember fondly. It’s free from the DEVONtechnologies Download page. It requires macOS 13 Ventura, so Macs running macOS 11 Big Sur and macOS 12 Monterey will have to continue relying on Terminal, although developer Jeff Johnson told me you could use an old version of Apple’s Network Utility if you ad hoc code-sign it. That is left as an exercise for the reader.

Although I can’t easily compare against the original, Neo Network Utility appears to provide all the same capabilities and more. For instance, I don’t believe the Lookup screen previously offered a choice of information providers (nslookup, dnscacheutil, and dig).

The Speed screen is completely new, leveraging the networkQuality tool Apple introduced with Monterey (see “Use Apple’s networkQuality Tool to Test Internet Responsiveness,” 22 April 2022). 

Ultimately, if you dabble in network testing and miss Apple’s Network Utility like me, I encourage you to download DEVONtechnologies’ Neo Network Utility. Stash it in your Utilities folder for the next time you’re curious about what’s happening with your network or Internet servers.

I have a project for someone out there! As I have admitted numerous times over the years, my development skills are weak at best, but I’ve come up with an idea for a tool that would benefit many Apple admins and consultants and, by extension, the rest of us.

Apple maintains an extensive knowledge base of thousands of pages of support articles that document many technical aspects of the company’s operating systems, apps, and devices. At TidBITS, we regularly link to these articles, and, thanks to a suggestion from reader Jolin Warren, my cleanup macro now trims the URLs so they should load in the default Apple Support site for your country.

Some time ago, I realized that Apple Support URLs follow numeric patterns. For instance, here are the URLs for Apple’s most recent security update release notes:

• iOS 16.7.9 and iPadOS 16.7.9: https://support.apple.com/en-us/HT214116
• iOS 17.6 and iPadOS 17.6: https://support.apple.com/en-us/HT214117
• macOS 12.7.6: https://support.apple.com/en-us/HT214118
• macOS 14.6: https://support.apple.com/en-us/HT214119
• macOS 13.6.8: https://support.apple.com/en-us/HT214120
• Safari 17.6: https://support.apple.com/en-us/HT214121
• tvOS 17.6: https://support.apple.com/en-us/HT214122
• visionOS 1.3: https://support.apple.com/en-us/HT214123
• watchOS 10.6: https://support.apple.com/en-us/HT214124

As you can see, the six-digit ID number after “HT” increments by one for each release, but the ID is assigned randomly to the releases. By creating more of these URLs by hand and guessing at some numbers, I determined that Apple has used other six-digit ranges over time. Many recent URLs start with 213 and 214, but I’ve also found URLs starting with 100–119 and 201–212. I haven’t discovered any pattern behind the ranges, and Apple skips some IDs for unknown reasons.

Leveraging This Realization

When I first figured out what Apple was doing, I considered using Dejal’s Web monitoring app Simon to tell me if any of these pages had changed. I didn’t get very far down that path because I couldn’t see any way to feed Simon thousands of URLs in a programmatic fashion, and it seemed like it might overload my Mac to check regularly. Other Web monitoring tools had the same problem—they’re designed to watch a handful of pages, not thousands.

Next, I created a Google Sheet that had a column for the six-digit ID, a column that appended each ID to the URL root, and a column that used the formula =Hyperlink($A2, IMPORTXML($A2,"//title")) to look up and bring in a hyperlinked title of the resulting page. Not all IDs map to active pages, so some cells were filled with #N/A.

Success? The problem is that when I fill the rows down, Google Sheets gives up at some point because there are too many outgoing calls to Apple’s support site. Then all I see is “Loading…” even though clicking one of the URLs shows the traditional preview.

Shortly after this, I got a press release from a company called Neptyne, which was releasing an add-on for Google Sheets that would enable a programmer to interact with data in Google Sheets using Python. I don’t know Python, but when I explained my goal to the Neptyne founder, Douwe Osinga, he took a swing at what I wanted. Because it was in Python, he could loop in such a way as to avoid causing Google Sheets to freak out. Plus, Douwe was able to extract the date and version from Apple’s pages, which allowed me to sort by date so I could see which pages had changed most recently. (I never figured out Apple’s version numbering scheme.)

As much as this solution worked better initially, it was brittle. Adding more rows caused the whole thing to stop working, and I don’t know Python well enough to troubleshoot it, even with the aid of an AI chatbot. 

But it suggested that what I wanted was possible. Imagine a world where you could learn about Apple’s technical changes as soon as they’re published, rather than having to stumble on them through a search later. 

Apple Support Article Tracker

Being able to iterate through the universe of Apple support article URLs, retrieve the content, and sort the list by date was a good proof of concept. I don’t think Google Sheets is the right platform for this, and my research suggests that neither Excel nor Numbers are contenders either. Instead, I suspect we need a database with a Web-based front end for anyone to use. In my ideal world, the Web scraping would operate roughly like this:

• Traverse all possible Apple support URLs regularly, perhaps once per day or week. (Because it would act like a spider, it would need to honor robots.txt exclusions, throttle itself, and behave nicely.)
• On the first pass, load each page into a database, populating fields for title, date, version, and full text.
• On subsequent passes, save the content locally if it has changed from the previous save.

With the database storing the metadata, full text, and versions, the public website would need to:

• Display a list of all Apple support article titles, sorted by date, with access to previous versions. 
• For any selected article and version, display a pane showing the rendered HTML.
• Provide a view that shows the differences between any two versions of an article.
• Offer alerts for new and changed articles, perhaps via RSS or email.
• Allow full-text searching. (Apple’s search engine is notably weak—see “Apple Launches Documentation Site for Manuals, Specs, and Downloads,” 25 March 2024.)
• For extra credit, provide a per-article discussion topic for annotations.
• For double extra credit, create an AI chatbot to allow conversations with the knowledge base, with answers referencing source pages.

I’d like to believe this wouldn’t be too difficult for someone with decent Web development chops, but it’s well outside my skill set. (Though he wasn’t volunteering to create it, Glenn Fleishman suggested that a Wiki site might be an easy way to store, diff, and present the data, plus provide options for community annotation.) I’m sharing the idea in the hope that someone finds it a compelling challenge and actually builds it. I’m happy to collaborate on the process and help with hosting if necessary. Are you game? Are there other features you’d like to see in such a tool?

I rarely write about Apple’s betas because something significant may change between when I publish an article and when Apple updates the beta or releases the production version. I don’t want to waste your time or mine.

But it’s a different story when things should change, as is the case with what feels like one of Apple’s biggest potential missteps currently in the macOS beta—one from which it could still pull back. macOS 15 Sequoia constantly asks for permission to reauthorize apps that rely on screen recording, which is true of many utilities beyond screenshot apps. It’s bad for usability, increases user frustration, and decreases security awareness.

Continue to Allow

A few days after installing the developer beta of macOS 15.1 Sequoia on my M1 MacBook Air, I realized something was very wrong. I rely on CleanShot X for the many screenshots I take while writing TidBITS and TCN articles, and I wasn’t surprised on my first use after upgrading to be asked if I wanted to continue granting CleanShot X permission to capture my screen. After a complete operating system upgrade, I can see Apple’s desire to have us verify previously granted permissions we hadn’t thought about in a while. (For some people, that’s when they discover they’re still running a utility or other app they haven’t used in years.)

However, I was taken aback to receive the same prompt again a short time later. And increasingly irritated when I was asked again after another day or two. And again. And again. Eventually, with my usability hat aflame, I decided to write something about it and tried to capture a screenshot of the dialog. That proved tricky because until I clicked Continue To Allow (and yes, the Apple Style Guide’s rules on capitalization clearly state that it should be “Continue to Allow”), CleanShot X didn’t have permission to capture a screenshot. Triggering a screenshot stacked a second dialog on top of the first, and macOS stopped responding for a few minutes. Eventually, I was able to click Continue To Allow in both dialogs and continue working. The problem was that CleanShot X was capturing all mouse clicks as I tried to select the dialog for the screenshot, so I couldn’t properly click Continue To Allow. The correct way to capture these screenshots was to press Escape to cancel CleanShot X’s screenshot-capturing mode and use Apple’s built-in screenshot tools, which, unsurprisingly, require no permissions. Weirdly, it turns out that clicking Open System Settings has the same effect as Continue To Allow, and System Settings provides no additional information explaining the request.

Before I finished writing this piece, Chance Miller at 9to5Mac published “macOS Sequoia adds weekly permission prompt for screenshot and screen recording apps.” He does a good job covering the situation, noting that this prompt repetition is intentional on Apple’s part, not a bug. The prompts recur weekly, whenever you reboot, or, as I discovered, when you log out and log back in. Although an update to Miller’s article quotes well-known developer Craig Hockenberry as noting that there may be an entitlement developers can request from Apple to sidestep these prompts, the company has shared no information about that. Michael Tsai has also captured the outrage from the Mac development community, and Jason Snell, John Gruber, and Nick Heer have weighed in.

While I mostly encountered these dialogs using a screenshot app, many apps request the Screen & System Audio Recording permission in macOS to identify and position onscreen interface elements or perform other tasks. A few of these include Adobe Photoshop, Adobe Premiere, Bartender, Default Folder X, Display Link, Google Chrome, Ice, Keyboard Maestro, Slack, Splashtop, TextSniper, and Zoom. If Apple continues down this path with Sequoia, there will be a lot of approvals to acknowledge every week or more frequently.

Security Through Endless Warning Dialogs

Many have decried the increase in permissions prompts over the past few years. In “Mojave’s New Security and Privacy Protections Face Usability Challenges” (10 September 2018), security expert Rich Mogull presciently wrote:

Balancing security notifications and authorization requests is notoriously tricky. Prompt users too often and they will both become annoyed and reflexively click OK. A security feature has failed when the noise of so many alerts leads users to stop reading them—and that eventually leads to malware asking for and receiving authorization. It’s a modern-day version of “The Boy Who Cried Wolf.”

We’ve already passed the point of security alert overload. The first time or two that the Sequoia beta prompted me to reauthorize, I admit that I didn’t read the text of the alert beyond determining that I should click Continue To Allow to capture the screenshot I needed for whatever I was writing. The dialog came in direct response to the keyboard shortcut I had just pressed, and I have used and trusted CleanShot X for years. It wasn’t until the dialog popped up a few more times that I read it closely to see if I was missing something. I wasn’t.

Apple seems to assume that all third-party apps that monitor the screen (or audio) could be malicious. That may not be a problematic foundation on which to develop a security framework, but it’s patently not the case in the real world. I’d guess that over 99% of apps on all Macs are legitimate for the simple reason that no one intends to install a malicious app or run it regularly.

There have been isolated examples of updates to legitimate apps being compromised (Transmission and Handbrake), but those were in 2016 and 2017—it’s just not an everyday concern for users. We also recently saw the kerfuffle with Bartender, which had long required screen recording permissions, being sold to a new owner without notifying users (see “Bartender Developer Explains and Apologizes for Quiet Acquisition,” 5 June 2024). In none of these cases would extra prompts have made any difference because users had no way of knowing that anything had changed.

By prompting for continued permission, Apple is asking if we still trust previously trusted apps. What would change in any short period of time that would have us reconsider this action? We would need new information to make a different choice. I could see an argument for double-checking permissions a few days after the first launch to ensure the user knows the app is still active, but repeated checks? After every restart?

It made sense when Apple added location permission alerts in iOS that appear occasionally after weeks or months of background location access. The alert shows how many times you’ve been tracked, shows a map with locations your device has provided, and lets you take a sensible action. The dialog lets you switch location permissions to “only while using.” Perhaps you had forgotten you gave an app permission during a trip and didn’t realize it continued tracking you at home. Maybe you don’t remember installing and giving that app permission at all. Whatever the case, the process makes sense—and it pops up only rarely.

Adding protections against virtually non-existent threats and providing warnings without a sensible action that can be taken actively harms the Mac experience. More than one writer has brought up the specter of Windows Vista, which became known for excessive security dialogs and prompted mockery from Apple. Like most Mac users, I never used Windows Vista when it shipped in 2007, so these second-hand comparisons felt fuzzy until I dug up this 2006 piece from Stack Overflow and Discourse co-founder Jeff Atwood. He warned that “security through endless warning dialogs” doesn’t work for exactly the reason that has proved to be true:

All those earnest warning dialogs eventually blend together into a giant “click here to get work done” button that nobody bothers to read anymore. The operating system cries wolf so much that when a real wolf—in the form of a virus or malware—rolls around, you’ll mindlessly allow it access to whatever it wants, just out of habit.

It’s depressing to see Apple recapitulating Microsoft’s mistakes from over 15 years ago.

Apple’s Actual Motivation?

I’m left wondering why Apple is adding these additional permissions prompts. The cheap answer is that Apple’s security team believes that apps regularly go over to the dark side within a week and we will figure that out by getting a prompt to remind us that we have already granted it screen-recording permissions. But that’s patently stupid. If the user trusts an app on Monday and nothing changes with that app by the following Monday, there’s no reason to doubt the previous trust level. If there were, Apple should use its anti-malware systems to block the app from running at all, right? More likely, Apple believes people intentionally install an app that is actually malware, give permissions when prompted, and would only reconsider if prompted repeatedly. That still feels excessive.

Perhaps the change was prompted by the success of how Apple quietly ratcheted up the passcode requirements for Touch ID and Face ID a while back. In addition to other cases in which you had to enter a passcode for an iPhone or iPad (or a password for a Mac), such as after restarting, Apple added a 6.5-day countdown clock that starts every time you enter your passcode. After that period elapses, a second 4-hour timer starts: if you don’t unlock your device with Touch ID or Face ID within that period, you are prompted to enter your passcode the next time you use it. Although it’s a slight annoyance for users to enter their passcodes at least once per week, it’s an overall security win because the routine reinforcement helps ensure that people don’t forget their passcodes.

However, with permissions prompts, routine reinforcement is unnecessary and excessive, and it desensitizes us to essential security warnings. Plus, computers should save us from repetitive work, not give us more unnecessary buttons to press.

We can hope that the public outcry will cause Apple to rethink this problematic path, but additional direct user complaints will also help. If you’re using the public beta of Sequoia, use Feedback Assistant to file a bug against these dialogs. Those who aren’t testing the beta can try using Apple’s Feedback page, perhaps for the Mac you plan to upgrade.