bdash

It is a little more direct than that even. The application's entitlements are passed into the interpretation of the sandbox profile. It is the sandbox profile itself that determines which policies should be applied in the resulting compiled sandbox policy based on entitlements and other factors.

An example from /System/Library/Sandbox/Profiles/application.sb, the profile that is used for App Sandboxed applications, on my system:

  (when (entitlement "com.apple.security.files.downloads.read-only")
        (read-only-and-issue-extensions (home-subpath "/Downloads")))
  (when (entitlement "com.apple.security.files.downloads.read-write")
        (read-write-and-issue-extensions (home-subpath "/Downloads")))
  (when (or (entitlement "com.apple.security.files.downloads.read-only")
            (entitlement "com.apple.security.files.downloads.read-write"))
        (allow process-exec (home-subpath "/Downloads")))

App Sandbox is fundamentally a way for programs to use the underlying sandbox subsystem without having to write SBPL code themselves. When a program has opted into the App Sandbox, the system applies one of these sandbox policies automatically during app initialization. The policy examines the entitlements of the application to determine which additional resources should be permitted. See /System/Library/Sandbox/Profiles/application.sb if you're curious.

By far the biggest advantage of App Sandbox is that the policy ships along with the OS. If a system framework changes what resources it accesses in a software update, Apple can update the policy so the framework functionality still works. If your app uses a custom sandbox policy, you're on your own to both notice that something has changed and to update your policy.

The downside is that the App Sandbox policy is limiting and inflexible.

See https://bdash.net.nz/posts/sandboxing-on-macos/ for more details on how sandboxing works on macOS. It touches on how the SBPL Scheme source code is interpreted in userspace to build a bytcode representation of the policy, and the kernel MAC hooks that the Sandbox kernel extension uses for enforcing sandbox policies.

There are SME / SME2 instructions that use the ZA tiles as vector registers / vector groups. These can take advantage of the higher throughput of the SME processing grid vs SSVE instructions that operate on Z registers. See the `FMLA (SME2)` case under Peak Performance at https://scalable.uni-jena.de/opt/sme/micro.html#peak-perform....

Intel's software optimization guides have similar annotations on many of their guidelines, and have done since long before LLMs were a thing. As a reader it's useful to know how impactful a given recommendation is and how generally applicable it is without having to read the more detailed explanations.

SSVE instructions are executed by the SME engine, which trades latency for throughput. SSVE is really intended to support use of SME, rather than as a replacement for Advanced SIMD on the CPU core itself.

The Apple Silicon CPU Optimization Guide has a lot of great information on SME and SSVE, along with more general information on optimizing for Apple's CPUs

A few quotes from Apple's guide that are particularly relevant to SSVE, from "SSVE Vector Execution Unit Optimization":

> Broadly, this unit is designed to support long vector and matrix operations performed on ZA storage _in the SME Processing Grid_.

> Recommendation: Use SSVE in a supporting role to enable high throughput SME grid computation.

> [Magnitude: High | Applicability: High] SSVE offers wide 64B vectors. While the ISA includes instructions that can operate on multi-vectors, the throughput is often only one 64B vector per cycle. Use SSVE to enable SME, which offers higher parallelism.

> Because of non-speculative execution, communication latencies, and in some cases long memory and computation latencies, SME engine instructions trail execution in the core by dozens to thousands of cycles. Any core compute instructions that consume data produced by the SME engine may have to wait an indeterminate (but long) amount of time for the data to arrive.

Strangely the WindowServer issue is a constant issue on my personal MacBook Pro, but I've never seen it on my identical work MacBook Pro. It seems like there's some other factor that is necessary to trigger the problem.

I'd sorta hope they are testing widely-used applications in the way that typical end users will experience them before releasing a new OS version.

This affects some of the most widely used applications on the platform, including "productivity" applications such as Slack that Apple uses internally. How did no-one at Apple notice this and do something about it prior to macOS 26 being released?

I've had success using https://github.com/nico/ninjatracing along with Clang's `-ftime-trace` to visualize the build performance of a C++ project using CMake. https://github.com/aras-p/ClangBuildAnalyzer helps further break down what the compiler is spending its time on.

It mostly seems to be deprecated to encourage developers to use App Sandbox rather than doing custom sandboxing things. With custom sandboxing baking implementation details of system frameworks into the sandbox policy is almost unavoidable, and Apple would really rather you didn't do that as it limits their ability to make changes in the future.

The underlying sandbox subsystem is what App Sandbox uses. Apple can happily rely on implementation details of system frameworks in their policies because they can update them as the system frameworks change.

The sandbox subsystem is what all of Apple's system software uses for sandboxing, as well as many security-conscious third-party programs such as web browsers. It's not going anywhere anytime soon, despite being marked as deprecated.

What's most amusing is that in the most recent blog post (https://eclecticlight.co/2025/04/30/why-some-apps-sometimes-...), the handful of log statements that serve as the source of the claim in fact confirm that it is syspolicyd performing a malware scan that is responsible for the delay during launch.

11.012004 com.apple.syspolicy.exec Recording cache miss for <private>

20.898736 AppleSystemPolicy Waking up reference: 174

The first of the two messages is from `syspolicyd` and is reporting that it has no cached malware scan result for a file it was asked to scan. The malware scan is triggered by an up-call within the AppleSystemPolicy kernel extension during a MACF hook (`proc_notify_exec_complete`, `file_check_library_validation`, or `file_check_mmap`) if the kext doesn’t have a cached malware scan result for the vnode of the file in question.

The second log message is from the AppleSystemPolicy kernel extension when it receives the result of the malware scan and permits the process to resume execution.

It's a little puzzling that the original analysis is published based on speculation, without any real attempt at verifying that the data supports their hypothesis. Looking at `top` or Activity Monitor during the slow launch would show which process is performing work. A spindump captured during the slow launch would reveal what work it is doing. The system log store captures the process and subsystem that logged any given message. A few minutes in Binary Ninja or Hopper gives you a rough idea of what the code that emits the log is doing.

Doctor Bandit Heeler is an archeologist. https://www.youtube.com/watch?v=Uiv_V7QOy3A

The code snippets are purely declarative because they are reconstructed from the simple bytecode that the macOS sandbox library generates after evaluating the Scheme code. At that point any abstractions present in the source code are long gone and only predicates and actions remain.

If you look at typical SBPL source code you'll see it tends to contain a mix of straightforward, declarative `(allow …)` policies and custom functions/macros used to simplify repeated patterns. See https://github.com/WebKit/WebKit/blob/11b5279aec6113c661dac3..., for example.

It still compiles the rules down to a very basic bytecode: https://bdash.net.nz/posts/sandboxing-on-macos/#sandbox-poli...

Passkeys are a different story than the keychain more generally. Other browsers that work with passkeys via the system APIs had to jump through hoops and get Apple's approval to do so: https://developer.apple.com/documentation/bundleresources/en...

When I first run locally-built software I tend to notice XProtect scanning each binary when it is launched. I know that XProtect matches the executable against a pre-downloaded list of malware signatures rather than sending data to the internet, but I haven't monitored network traffic to be sure it is purely local. You can see the malware signatures it uses at /private/var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara if you're curious.

I suspect they're referring to changes to Gatekeeper in recent macOS versions: https://arstechnica.com/gadgets/2024/08/macos-15-sequoia-mak...

It used to be that you could run any third-party application you downloaded. And then for a while you'd have to right-click and select Open the first time you ran an application you'd downloaded, and then click through a confirmation prompt. And macOS 15, you have to attempt to open the application, be told it is unsafe, and then manually approve it via system settings.

https://security.googleblog.com/2024/07/improving-security-o... talks a little about improvements Chrome has made on Windows to make it harder for malicious software to access the encryption key used to encrypt cookies and passwords on disk.

Each keychain item on macOS has an access control list associated with it that lists the applications that are granted access to the keychain item. If an application not on the ACL attempts to access a keychain item, macOS prompts the user for authorization. The ACL entries identify applications based on properties of their code signature and so are not spoofable.

As someone with a good understanding of the technologies involved I came away rather confused by the article. There are a few things that are obviously incorrect, and others that don't make much sense. Some of them could be perhaps be explained if the author is doing their work on an outdated version of macOS, but I'd expect that to have been mentioned explicitly in the introduction to the article.

Entitlements aren't stored in Info.plist. They're embedded in a binary's code signature.

It demonstrates code injection via Mach APIs starting with `task_for_pid` when `task_for_pid` is only usable by root or by a process signed with specific entitlements.

VeraCrypt does use the hardened runtime and so the `DYLD_INSERT_LIBRARIES` example cannot work with it.

It gives an example of using `emond` for persistence, but that was removed from macOS several releases ago.

To get that game for $500 I think the owners would need to be at a point where they're sick of it and just want it gone.

A couple of thoughts:

1. Games on location are often not owned by the location, but instead owned by a third-party operator that is responsible for maintenance and splits coin drop with the location. 2. Since the game is on location it was probably playable at some point recently. It may be off because of something simple like a rubber ring breaking and the ball keeps getting stuck or an important switch not registering, but the operator hasn't had a chance to fix it. If it was recently and only needs minor work, its value is more likely to be $5,000 than $500. 3. Even if it has been broken and not working for years, its value would heavily depend on the cosmetic condition. A non-working machine with a great cabinet (artwork without fade, no dings) and no wear or damage to the playfield would still probably be worth closer to $2-3,000.

It never hurts to ask, though!

I'm not really making any money doing it. I learn a lot and enjoy the process.

As an example, I picked up a 1978 Bally Strikes and Spares machine from Marketplace. It'd sat in the owners garage unplayed for 10 years and no longer worked. I bought it for $400, put somewhere between 20-30 hours of work into it and around $600 in new parts. If I'm lucky, I'll be able to sell it for around $1800.

I've bought non-working pinball machines from Facebook Marketplace or Craigslist for great prices and brought them back to life. They cover a range of the pinball spectrum from electromechanical games from the 1970s through 1990s games with dot matrix displays. I fix these up, play them until I get bored of them, then sell them to make room for future projects or trade them for something new-to-me.

Separately from that, I've bought, sold, and traded to end up with a set of games that I enjoy playing. There are a couple of modern Stern games in the mix along with some mid-90s Bally/Williams games.

That's how mine started getting out of control. I had one non-working machine that I rescued from a family friend's barn. My wife decided we should get a newer, working one so we would have something to play while I kept working on the first. A year later and I'm at over a dozen…

They’re heavy, awkward to move, and take up a lot of floor space. They’re loud and require ongoing maintenance.

They’re also a lot of fun! I really enjoy both playing and working on mine.

They collect a lot of information, but make very little of it available. What is available isn't exposed in a particularly friendly way. Some of the extra data they gathered makes it into the Year in Review stats they make available at the start of the year. https://social.bdash.net.nz/@mrowe/111779120066480793 shows an example of this.

I'd love to be able to see a moving average of my score on a particular game so I can see how I'm improving (or not) over time. Beyond that, I'm not sure what data would be useful other than as a curiosity.

Folks in the industry bought licenses, tooling, and parts for games from manufacturers that shut down. Others were reverse-engineered after the fact. Between https://www.pbresource.com, https://www.pinballlife.com, https://www.marcospecialties.com, https://www.actionpinball.com, and https://www.planetarypinball.com you can find parts for many machines going all the way back to the 50s.