How do Sonoma’s Web Apps work?

Safari’s new Web Apps in macOS Sonoma are a convenient way of gaining ready access to your most-used websites in the Dock. They’re deceptively simple to make, and apparently work without all the fuss and overhead of Safari itself.

Use and behaviour

If you haven’t tried them out yet, open your most commonly used page in Safari. In the Share tool at the upper right of the window, select Add to Dock.

Safari then asks you for the title of this Web App, and to confirm its starting URL. Click on the Add button and the icon will be added to the Dock and Launchpad immediately, ready for you to use.

This Web App behaves differently from Safari, as it’s sandboxed within its original domain. Click on links that would take you outside that and they’re opened in Safari, and all downloads, including files such as PDFs that would normally be viewed inline, are handled by Safari too. It has its own Settings, giving you access to its name and Home URL, together with linked privacy controls for camera, microphone, screen sharing and location access, and the ability to clear the Web App’s site data.

Look carefully at that Web App, and there’s clearly more going on behind the scenes. What’s in the Dock and Launchpad is an app bundle initially stored in ~/Applications, which should also run happily from other Applications folders and locations (including external volumes) on that Mac, but won’t survive copying to another Mac, where it’s reported as being damaged or incomplete, and can’t be opened.

The bundle is a mere 18 KB in size, and contains no executable code at all. Inside its Contents folder are two folders and an Info.plist file: its _CodeSignature folder contains three additional files as well as the standard CodeResources file, and the Resources folder contains just its ApplicationIcon, taken from the website.

Two key pieces of information are contained in its Info.plist: the scope allowed for the Web App, in terms of its domain URL, and the start_url, as its Home URL. In case you feel you could tamper with those, they’re included in the cdhashes protected by the Web App’s ad hoc signature. Changing the Web App’s name or Home URL in its Settings alters their entries in the app’s Info.plist, and presumably requires the calculation of replacement cdhashes in the course of re-signing. To see those take effect on the app, though, you’ll need to open a new window within it.

Creation

Much of the work involved in the creation of a Web App is performed by LaunchServices, in making what it terms a TemplateApp, something not documented as far as I can discover. For a Web App, it’s assigned an ID of com.apple.Safari.WebApp.[UUID], saved as the app’s CFBundleIdentifier, and referred to extensively in log entries. It’s also LaunchServices that computes its cdhashes and gives it an ad hoc signature through lsd.

There are references in the log to looking for stored hashes in ~/Library/Application Support/com.apple.LaunchServicesTemplateApp.dv, although that folder may remain empty.

The finished Web App is then stored as ~/Applications/[webappname].app and added to the Dock and Launchpad, ready for use.

Running

As the Web App doesn’t contain any executable code, when it’s launched it’s actually run by the hidden Web App.app stored in a Cryptex, in the path /System/Volumes/Preboot/Cryptexes/App/System/Library/CoreServices/Web App.app

The Web App appears able to access data stored in ~/Library/Containers/com.apple.Safari.WebApp/Data if that has been created for it.

Currently, Apple’s developer documentation doesn’t appear to contain any mention of Web Apps, nor whether they’re accessible to developers.

Crafted Web Apps

Creating the Web App itself, or copying one to a Mac, is simple, given that it only requires an ad hoc signature. However, unless its UUID is recognised by LaunchServices and accepted as a registered Web App, all attempts to launch it will be denied. Sandbox restrictions placed on link URLs and downloads severely limit the potential for a malicious Web App, as does the fact that its executable code is contained in a Cryptex. Crafted Web Apps don’t appear likely to have much chance of success without the aid of vulnerabilities in LaunchServices.