Good: much less disruptive than a regular macos update.
Bad: still requires a reboot, and is still irrelevant noise for non-users of safari.
Bad: still requires a reboot, and is still irrelevant noise for non-users of safari.
Safari vends an in-app view controller used by lots of third party apps to display web content.
I guess it depends on what the bug is.
If I'm not mistaken, it is the renderer for many arbitrary pages like PDFs and Preview documents. Could be wrong though.
Plenty do display arbitrary _content_ thought. Mail clients, RSS readers, various messaging (twitter, mastodon, ...) clients, etc use it. Obviously these days many apps instead just ship a 400mb out of date copy of chrome instead of using the builtin frameworks, so it's less of an addressable problem, but so it goes.
An RSS reader would be one of those few apps that might have the full risk.
Messaging platforms have to worry about unicode bugs and image bugs, but almost all html or javascript exploits don't matter to them. If there is a safari-specific problem, it's very likely they don't care about it.
But it doesn't matter what proportion of the app ecosystem is or is not using the system webkit framework, we both know that if Apple does update only Safari say, and then people are compromised through their RSS reader, the HN comments will be asking why Apple didn't update the system framework.
Don't get me wrong - I do get annoyed at having to reboot, but I'm not sure what the better solution is given the constraints of macOS and iOS (at least iOS apps are better designed in terms of saving and restoring state).
I mean that whitelist-style, which isn't a losing strategy.
But that's a side issue. I'm trying to argue that the vast majority of programs that use webkit aren't affected by the vast majority of webkit-specific bugs.
> But it doesn't matter what proportion of the app ecosystem is or is not using the system webkit framework, we both know that if Apple does update only Safari say, and then people are compromised through their RSS reader, the HN comments will be asking why Apple didn't update the system framework.
I'm not suggesting not to update. But yes it does matter how many programs are vulnerable.
What are you trying to filter with your "whitelist"? Anything you'd want to filter can be controlled directly via browser embedding APIs, without any vagaries or guesswork.
> I'm trying to argue that the vast majority of programs that use webkit aren't affected by the vast majority of webkit-specific bugs.
I'm not sure what you mean here. The whole point of a security bug is that an entity is trying to compromise the system. We aren't talking a "webkit specific rendering bug", we're talking about the goal being code execution. So "affected by" is "displays untrusted content".
RSS apps, Mail apps, Messaging, and Social media apps are all subject to that. Messaging isn't arbitrarily constrained - any properly encrypted messaging system requires the client to assume that any received message is completely attacker controlled. Even in these hypothetically constrained messaging and social media apps, if nothing else, often allow you to just view web content from within the app. The goal of an attacker is to get some specific content to hit a web view. They do not necessarily care what application is driving that web view - arguably they'd prefer non-safari as 3rd party apps generally aren't sandboxed, so gaining code execution in the host is yet more powerful.
> I'm not suggesting not to update. But yes it does matter how many programs are vulnerable.
What matters is how many users would be exposed, which is a function of the number of apps, the number of users of all of those apps, and the degree to which those apps are exposed to arbitrary content. WebKit on macOS is widely used, and it is often (if not typically) used for untrusted content.
Then they'll already be immune to many exploits, great. You're not really arguing against my point here.
> I'm not sure what you mean here
Sorry. What I meant by webkit-specific was basically a bug that is in webkit but not a more general text or image rendering bug that affects the entire system.
> any properly encrypted messaging system requires the client to assume that any received message is completely attacker controlled
I disagree. Many messaging systems don't send html. If they do send raw html, for most of those apps it's not unreasonable to trust the server, because if the server is compromised they could just send a malicious update. So you only care about things that can make it through the system, which is a tiny percent of html, and renders 90% or whatever of web engine bugs unreachable.
> Even in these hypothetically constrained messaging and social media apps, if nothing else, often allow you to just view web content from within the app.
Now that is an app that is vulnerable! But only some do that, especially on desktop.
> What matters is how many users would be exposed, which is a function of the number of apps, the number of users of all of those apps, and the degree to which those apps are exposed to arbitrary content.
I agree. I just don't want to overstate the degree.
I guess the software updater wasn't built to make those steps easy, so an OS reboot might've been the easiest way to ship this.
I... what?
https://support.apple.com/guide/security/signed-system-volum...
Which is to say, / under Catalina and above (so, since 2019), the root partition is really the mount of an APFS snapshot. There's security as a reason, but also from a system perspective, it makes it more robust to upgrade/downgrade OS versions under such a scheme because you always have a known-good system image to revert back to.
Safari though is a special case, and so /Applications/Safari.app is a symlink to ../System/Cryptexes/App/System/Applications/Safari.app
https://superuser.com/questions/1495124/read-only-file-syste...
EDIT: I feel obligated to say this: pitchforks down, please. I'm not trying to disparage the macOS kernel. As a designer of software systems interested in how OSes are built, I found the choices taken interesting.
Can you explain this more? Despite being a longtime Apple user, I've never heard of RSR before. If it's just an update for Safari, why does it require the computer to be rebooted? Does it not affect me if I use other browsers for 99% of my web usage?
Also, isn't one of the arguments for Apple's stronghold on all the software running on their machines that they know 100% what everything is doing? Should be trivial to look up which processes are using specific parts and restart those.
What stronghold? You can run whatever apps you want on a Mac.
As for identifying libraries in use. you can do that on any platform: Pause all processes, scan the address space of all processes to find anything the looks like a pointer to an impacted library, then hope/assume that there's no pointer tagging or munging going on, and voila that's your list. Hopefully you didn't miss anything.
The problem is that that's just a heuristic and you'd want to be _really_ sure you were right, or weird crashes will happen.
On macOS specifically there are other hurdles, the biggest being that the system partition is readonly, and so system libraries can't be replaced outside of early on in the boot process.
Or worse, you leave running applications vulnerable to a critical security vulnerability while telling the user that they've applied all security patches.
>Rapid Security Responses that involve the operating system require the device to restart. On macOS, the updated operating system content may be made available to Safari and its associated processes with just a relaunch of those processes, though a restart is required to make this content broadly available to the rest of the operating system.
>They deliver important security improvements between software updates — for example, improvements to the Safari web browser, the WebKit framework stack, or other critical system libraries. They may also be used to mitigate some security issues more quickly, such as issues that might have been exploited or reported to exist "in the wild."
I believe they are vague on purpose (and because they're Apple) but it does not strike me as something strictly limited to affecting just Safari, especially given the libraries may be used elsewhere.
ETA: To further quote from https://support.apple.com/guide/deployment/manage-rapid-secu...:
>Rapid Security Responses that involve the operating system require the device to restart. On macOS, the updated operating system content may be made available to Safari and its associated processes with just a relaunch of those processes, though a restart is required to make this content broadly available to the rest of the operating system.
However updating the system requires updating the system partition, which is readonly, so requires rebooting.
This one does, but I don’t think they all will. The language around it seems clear that’s a possibility.