Apple has just released the first Rapid Security Response for Ventura(eclecticlight.co)
eclecticlight.co
Apple has just released the first Rapid Security Response for Ventura
https://eclecticlight.co/2023/05/01/apple-has-just-released-the-first-rapid-security-response-for-ventura/
108 comments
Warning: if you install this it doesn't give you the option to delay a reboot to apply the update. I got a notification my computer would be restarting in 60 seconds as soon as the install completed.
Ah, the good'ol Windows method of forcing updates. Rely on users saying no within X seconds, otherwise go for it regardless if they want to or not. Awesome when you didn't notice that an update happened because you were grabbing a coffee, or that the computer want to check a 2TB disk for errors upon reboot. Usually happens when you have much more important things to do at the moment.
Forced reboot after an update is not the same as forced updates. It's not like Windows can update without reboot either.
So far I haven't seen Mac OS force any update on me, not only that but when I accidentally activated automatic updates it showed a notification that stays on screen until you confirm/cancel the setting change.
So far I haven't seen Mac OS force any update on me, not only that but when I accidentally activated automatic updates it showed a notification that stays on screen until you confirm/cancel the setting change.
>It's not like Windows can update without reboot either.
And neither can Linux, contrary to popular belief. Anything that involves system services or god forbid the kernel requires a reboot.
Yes, if the kernel wasn't updated you could meticulously reboot each individual system service that was updated instead, but why bother when you can just reboot and be done with it?
And neither can Linux, contrary to popular belief. Anything that involves system services or god forbid the kernel requires a reboot.
Yes, if the kernel wasn't updated you could meticulously reboot each individual system service that was updated instead, but why bother when you can just reboot and be done with it?
> Anything that involves system services
This is not true. NixOS, as one example, is able to figure out which services (including system) need to be restarted.
> god forbid the kernel
This is not true either. Live kernel updates are possible (but are usually a paid addition, e.g. https://ubuntu.com/security/livepatch).
This is not true. NixOS, as one example, is able to figure out which services (including system) need to be restarted.
> god forbid the kernel
This is not true either. Live kernel updates are possible (but are usually a paid addition, e.g. https://ubuntu.com/security/livepatch).
In the case of an update involving a shared library you would still have to close and restart every single program that links against it though, right? Which if we’re talking about something like glibc you might as well just reboot.
If you wanted the change to take effect then, yes, you would need to restart those apps. Because of the way that NixOS deals with dependencies, the old versions would still be around for running apps to use and carry on.
It might actually be a useful tool for NixOS: finding out which processes have a specific version of a module loaded, so that the user can be warned to restart those processes.
If the user wants to restart processes they can, if they want to just reboot they can also. Simply because it's "simpler" to do one, doesn't mean it's the correct universal choice in all circumstances. My wife, for example, leaves way to much crap open and leaves her laptop suspended - a restart is a serious issue for her.
It might actually be a useful tool for NixOS: finding out which processes have a specific version of a module loaded, so that the user can be warned to restart those processes.
If the user wants to restart processes they can, if they want to just reboot they can also. Simply because it's "simpler" to do one, doesn't mean it's the correct universal choice in all circumstances. My wife, for example, leaves way to much crap open and leaves her laptop suspended - a restart is a serious issue for her.
I've never had to reboot Linux after a glibc update if I didn't care whether the new version was being used. In general, glibc updates are not important enough to interrupt what I'm doing to reboot my device and I'll just shut down or reboot my device the next time I normally do.
> And neither can Linux, contrary to popular belief. Anything that involves system services or god forbid the kernel requires a reboot.
That is not true at all, and anyone can confirm this by upgrading the kernel and system services (e.g. desktop environment, display manager, systemd) on Arch Linux and verifying that just about everything continues to work normally. In my experience, the only things that require a reboot are a few particular kernel modules (such as the VirtualBox host modules) and only if you are going to use those modules. Even in that case, it is still your choice whether you want to reboot.
That is not true at all, and anyone can confirm this by upgrading the kernel and system services (e.g. desktop environment, display manager, systemd) on Arch Linux and verifying that just about everything continues to work normally. In my experience, the only things that require a reboot are a few particular kernel modules (such as the VirtualBox host modules) and only if you are going to use those modules. Even in that case, it is still your choice whether you want to reboot.
Gnome, KDE and also Firefox and Chrome don't seem to be particularly fond of updates being applied under their ass, probably because they are heavy on dynamic code loading and spawning workers with unstable APIs, respectively. Firefox even added some code to detect this and show a blank page with "You gotta restart Firefox before you can open new tabs" instead of crashing.
Edit: Another classic is upgrading the kernel on Arch, not rebooting, then trying to use a thumb drive for the first time since the last boot. Since Arch uses one package for all kernel versions, only one set of loadable modules is installed per kernel package - so upgrading the package removes the loadable modules of the currently running kernel.
Edit: Another classic is upgrading the kernel on Arch, not rebooting, then trying to use a thumb drive for the first time since the last boot. Since Arch uses one package for all kernel versions, only one set of loadable modules is installed per kernel package - so upgrading the package removes the loadable modules of the currently running kernel.
I do restart browsers after upgrading them, but that's different from restarting Linux. For desktop environments, I usually don't bother rebooting Linux for anything other than major releases (like GNOME 43/44 and Plasma 5.26/5.27) since most of the minor releases don't make enough of a difference in day to day use to interrupt what I'm doing.
Systemd maintains a graph of relationships between running services. It can mark all the nodes which depend on a node, properly shutdown them then start again.
I got a notification my computer would be restarting in 60 seconds as soon as the install completed.
This is not new. I got the same notice earlier today updating a MacBook running Big Sur, which is two versions before Ventura.
This is not new. I got the same notice earlier today updating a MacBook running Big Sur, which is two versions before Ventura.
This notification is different. The ONLY option I see in the notification is to restart. And it's counting down to 0 menacingly.
Again, same notification I got with Big Sur. Complete with "menacing" countdown.
Not new
you can delay it by simply closing the "restarting in ..." dialog.
you can resume in software update by clicking "Restart Now".
you can resume in software update by clicking "Restart Now".
Can confirm, annoying... reminds me of the "Windows Update hell".
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.
> 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.
Safari vends an in-app view controller used by lots of third party apps to display web content.
Not many of those show arbitrary web pages.
I guess it depends on what the bug is.
I guess it depends on what the bug is.
> Not many of those show arbitrary web pages.
If I'm not mistaken, it is the renderer for many arbitrary pages like PDFs and Preview documents. Could be wrong though.
If I'm not mistaken, it is the renderer for many arbitrary pages like PDFs and Preview documents. Could be wrong though.
> Not many of those show arbitrary web pages.
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.
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.
A mail client is partway there, but is probably significantly filtering the html it allows.
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.
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.
Mail clients do not filter html, that's a losing strategy, they use APIs on the rendering engine they use to prevent the engine from doing anything "bad" e.g. you don't try and filter JS, you tell the engine to not enable JS, you don't try to filter urls or resources by regex on the source, you use the engine APIs to manage resource loading yourself. Then it doesn't matter what absurd syntax or encoding is being used, if the engine thinks it should do a load, or run some scripts, it asks the host app.
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).
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).
> Mail clients do not filter html, that's a losing strategy
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.
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.
> I mean that whitelist-style, which isn't a losing strategy.
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.
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.
> Anything you'd want to filter can be controlled directly via browser embedding APIs, without any vagaries or guesswork.
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.
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.
That still only requires a logout and login, not a full restart. In fact, it doesn't even require a logout, only restarting affected processes.
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 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.
IIUC, safari and other essential OS components are mounted on a read-only volume. The installer has to perform special shenanigans to update it.
Good defense in depth. Frustrating this requires an OS update & reboot, but I prefer that to weakening the defense model.
Yup, see page 51: https://help.apple.com/pdf/security/en_US/apple-platform-sec...
A read-only mount doesn't require the backing store to be immutable, nor does it need open fds on the mount to be closed for the backing store to be updated. I've shipped embedded devices that had read-only rootfs mounts and the updater didn't need to reboot before (or after) applying updates. Of course, this was on the Linux kernel, which does support replacing open files.
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.
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.
> IIUC, safari and other essential OS components are mounted on a read-only volume
I... what?
I... what?
That's right. Safari is an application and so lives under /Applications, which is one a few special directories where the user can make changes, which actually live under /System/Volumes/Data in a scheme similar to unionfs under Linux.
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...
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...
More importantly, it's updating the system WebKit framework, which is a core framework so even if Safari.app was separate, the system framework update forces the reboot. The Safari Technical Previews include their own complete copy of the WebKit framework and link to that (and Safari.app can be made to load WebKit.framework from elsewhere which is how webkit nightlies and from-source builds of webkit can be used)
As a basic security measure the macOS system partition is readonly and cryptographically signed.
https://support.apple.com/guide/security/signed-system-volum...
https://support.apple.com/guide/security/signed-system-volum...
Many other systems, including ostree and Android, have solved this problem years ago. For example, the update can be installed on a read-only cryptographically signed overlay.
[deleted]
If I Understand Correctly
> is still irrelevant noise for non-users of safari.
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?
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?
From the info page on apple (linked elsewhere here but https://support.apple.com/en-us/HT201224 and (no discussion: https://news.ycombinator.com/item?id=35776738))
>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.
>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.
RSR is a new feature. https://support.apple.com/guide/deployment/manage-rapid-secu...
Indeed, here's the crucial quote:
>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.
>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.
The Safari libraries are used by tons of apps running on OSX. It's probably just easier to reboot than to ensure that all affected apps are reloaded.
Are there apps using the Safari libraries running in the background? Sounds like something only user-facing applications would be using.
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.
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.
> 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?
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.
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.
> 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.
Or worse, you leave running applications vulnerable to a critical security vulnerability while telling the user that they've applied all security patches.
Or worse, you leave running applications vulnerable to a critical security vulnerability while telling the user that they've applied all security patches.
I feel like Android is much more modular in that regard, even the apps for the playstore is an app that can be killed/wiped essily from an all apps menu
It almost certainly includes some kernel modification that was required. or it could be that the WebKit component that Safari and other applications use as an API layer needed to be patched and a reboot ensures all components running get the patch. There is also some sandboxing technology that is used for other things besides Safari and that is implemented in the Kernel.
If the bug is used in WebKit, then that's a system framework used by many apps on the system (and has been for well over a decade), not just Safari.
However updating the system requires updating the system partition, which is readonly, so requires rebooting.
However updating the system requires updating the system partition, which is readonly, so requires rebooting.
Kernel patch requires a reboot. This will include important kernel fixes
> Bad: still requires a reboot
This one does, but I don’t think they all will. The language around it seems clear that’s a possibility.
This one does, but I don’t think they all will. The language around it seems clear that’s a possibility.
How is it less disruptive than a regular macOS update?
This macOS update took < 30 seconds - opposed to most regular macOS updates which at the fastest are still 5+ minute operations
For those not familiar with the Apple platforms:
> By default, your device allows Rapid Security Responses to be applied automatically and, if necessary, will prompt you to restart your device.
https://support.apple.com/en-us/HT201224
Unfortunately, the article does not say whether the update is applied automatically even if the device is locked.
> By default, your device allows Rapid Security Responses to be applied automatically and, if necessary, will prompt you to restart your device.
https://support.apple.com/en-us/HT201224
Unfortunately, the article does not say whether the update is applied automatically even if the device is locked.
Interesting, apparently this can be removed post install: https://i.imgur.com/gvbbU8F.jpg
why would that be?
why would that be?
Maybe rapid security updates don’t get much testing, so they allow you to remove it in case it causes problems? Just a guess.
To allow people to jailbreak? /s
Probably to ensure someone can go back if this fix breaks functionality (which it shouldn't do).
Probably to ensure someone can go back if this fix breaks functionality (which it shouldn't do).
The thing I don’t understand is why they blocked RSR behind a password prompt. You can’t even use Face ID / Touch ID and in my experience that plus a reboot means a lot of people will put it off as long as they can.
iOS also really needs to trigger the automatic Photos + Apps storage reclamation process since statistically everyone I know who delays updates does it because their phone is full of pictures & videos. The iCloud offload works beautifully so I don’t know why they haven’t added a trigger multiple years into that feature existing.
iOS also really needs to trigger the automatic Photos + Apps storage reclamation process since statistically everyone I know who delays updates does it because their phone is full of pictures & videos. The iCloud offload works beautifully so I don’t know why they haven’t added a trigger multiple years into that feature existing.
> The thing I don’t understand is why they blocked RSR behind a password prompt.
As I recall there’s something they can’t decrypt without your password that they need to decrypt during updates. You could say “that’s their choice” but maybe they worry if their signing keys leaked that at least you’d also need to type your password in to kick off an update.
> The iCloud offload works beautifully so I don’t know why they haven’t added a trigger multiple years into that feature existing.
Guessing this comes down more to bandwidth as to why it’s opt in. If there’s enough speed to upload your photos but not download them when the update completes, you’re going to be upset. Or if you get on a plane and your iPad is doing an update and it completes after takeoff but all your movies/games were offloaded, you’d be upset.
(That’s probably fixable by doing some math to figure out if it’s workable, or by asking the user on the update screen if they’d like to offload and reload. But it wouldn’t be 100% automated, which is what I think you were asking?)
As I recall there’s something they can’t decrypt without your password that they need to decrypt during updates. You could say “that’s their choice” but maybe they worry if their signing keys leaked that at least you’d also need to type your password in to kick off an update.
> The iCloud offload works beautifully so I don’t know why they haven’t added a trigger multiple years into that feature existing.
Guessing this comes down more to bandwidth as to why it’s opt in. If there’s enough speed to upload your photos but not download them when the update completes, you’re going to be upset. Or if you get on a plane and your iPad is doing an update and it completes after takeoff but all your movies/games were offloaded, you’d be upset.
(That’s probably fixable by doing some math to figure out if it’s workable, or by asking the user on the update screen if they’d like to offload and reload. But it wouldn’t be 100% automated, which is what I think you were asking?)
Yeah, I’m sure there’s a good reason for it. I’m just surprised it’s lingered for years since it’s such an effective deterrent.
> Or if you get on a plane and your iPad is doing an update and it completes after takeoff but all your movies/games were offloaded, you’d be upset.
I could see something like that (although you could do things like install at night when you’re at home) but it’s completely opaque: you’ll just stop getting updates, nothing will ever prompt you, and it forces you to do cleanup manually. At the very least I’d expect a prompt and a “clear up space” button.
> Or if you get on a plane and your iPad is doing an update and it completes after takeoff but all your movies/games were offloaded, you’d be upset.
I could see something like that (although you could do things like install at night when you’re at home) but it’s completely opaque: you’ll just stop getting updates, nothing will ever prompt you, and it forces you to do cleanup manually. At the very least I’d expect a prompt and a “clear up space” button.
> since statistically everyone I know who delays updates does it because their phone is full of pictures & videos
As someone who doesn't use iCloud to store pictures or videos, can you explain what this has anything to do with updates? Is it because their device is so full that they don't have disk space to download the update? And Apple doesn't temporarily grant them additional iCloud storage?
As someone who doesn't use iCloud to store pictures or videos, can you explain what this has anything to do with updates? Is it because their device is so full that they don't have disk space to download the update? And Apple doesn't temporarily grant them additional iCloud storage?
Updates won’t install without a few GB free. Currently, that just disables them with no prompting to fix the problem. It seems like it should do things like tell you and, if you have iCloud Photos, messages off-loading, Drive, etc. enabled it could use those services to release the local cache for things which are already backed up.
If it requires reboot, I don't get why it's better than the regular update. And macOS updates now require downtime like in the worst Windows days. Something went into a wrong direction.
"Unable to check for updates Could't communicate with a helper application." That is the error I am getting when trying to update from on macOS 13.3.1 on a M1 2020 MacBook Air.
Updates are also available for iOS it seems.
Doesn’t seem to be installable for me on Xr.
My iPhone can't verify the update.
Happened to me quite few times, try rebooting
Same. Says it can’t because I’m no longer connected to the internet, but I’m here!
Same. iPhone 8, EU West.
edit: MacOS reports iPhone being up to date.
edit 2: Selecting 'use mobile data' when downloading and installing does work. Go to Settings > General > iPhone Storage and delete the update package. Restart the download & install process and let it use mobile data this time.
I get the feeling checking the hash does work over LTE as opposed to Wi-Fi, based on absolutely wild speculation.
edit: MacOS reports iPhone being up to date.
edit 2: Selecting 'use mobile data' when downloading and installing does work. Go to Settings > General > iPhone Storage and delete the update package. Restart the download & install process and let it use mobile data this time.
I get the feeling checking the hash does work over LTE as opposed to Wi-Fi, based on absolutely wild speculation.
> let it use mobile data this time.
This is the most Canadian-hostile update in the history of computing!
This is the most Canadian-hostile update in the history of computing!
Ditto. Keeps complaining that my phone does not have Internet access.
Please click _here_ to go to our website and troubleshoot why you don't have internet access.
I was great to see until the update didn't work lol. works now but... confusing for the first use.
Hopefully the learnings from this rollout will make future updates smoother.
If anyone thinks any non-Apple platform is more secure than modern iPhone/Macbooks running iOS/macOS, you are dead wrong. Apple's security is far ahead of other platforms.
Security is a complex topic. While I don't disagree with your statement, I also don't agree with it. It's more realistic to say that "in recent years, Apple has clearly invested more in macOS security compared to the late 2010s."
I'm pretty sure that Qubes OS [0] is far more secure than any other desktop operating system: its security relies on hardware virtualization, which was broken last time in 2006 by the Qubes founder [1].
[0] https://qubes-os.org
[1] https://en.wikipedia.org/wiki/Blue_Pill_(software)
[0] https://qubes-os.org
[1] https://en.wikipedia.org/wiki/Blue_Pill_(software)
Like many others, I am unable to verify this right now.
I'm biased because I work on ChromeOS, but Chromebooks seem extremely secure.
One of the cool advantages I was pondering is its greatly reduced attack surface. Linux and Android apps can still come in, but they're always really sandboxed and insulated from the main OS, which is little more than browser+UI. So as secure as you can make the browser, that's your OS security. The most a user can do is install PWAs on it; they're not going to have a bunch of userspace native apps causing trouble.
Thank you Steve.
NSO would lose customers if iOS and Android were secure.
NSO would lose customers if iOS and android were insecure because there would be a million competitors capable of doing the same job.
NSO prefers devices to be 99% secure.
NSO prefers devices to be 99% secure.
Yes. The whole existence of NSO shows that the iPhone is preeminent in platform security. No one pays hundreds of thousands of dollars to access an easily exploitable system.
FWIW, Zerodium still values Android zero-days higher[0] than iOS ones. Suffice to say that both parties pay hundreds of thousands to access their respective systems, to the point that companies like Greyshift sell standard-issue exploit hardware[1] for these devices now. Hacking your phone is a commercial field in the year of 202X.
Both platforms are extremely vulnerable and actively exploited. Make of that what you will.
[0] https://zerodium.com/program.html
[1] https://www.grayshift.com/graykey/
Both platforms are extremely vulnerable and actively exploited. Make of that what you will.
[0] https://zerodium.com/program.html
[1] https://www.grayshift.com/graykey/
> Zerodium still values Android zero-days higher[0] than iOS ones.
Partly due to more android devices out there than iPhones ex-US
Partly due to more android devices out there than iPhones ex-US
OpenBSD is pretty damn secure.
I think I've even seen an insane person with a marginally operational openbsd phone.
I think I've even seen an insane person with a marginally operational openbsd phone.
Security is a lot more than just the OS. Modern iPhones have security chips that ensure the integrity of the main OS during boot and while running. A large part of Apple's security excellence comes from their hardware security integrated with their software/firmware.
And they make the entire mobile industry more secure by showing what can be done, allowing others to follow suit.
What makes you think there is excellence in security? Nearly every case involving Pegasus was on the iPhone.
I believe this affected ~1000 VIPs and caused the death of at least 1 person.
Either 0 VIPs use Android, or it is much harder to break into. (From my research, there wasnt any 0 click exploits, you always had to manually download something and approve it outside the play store)
I believe this affected ~1000 VIPs and caused the death of at least 1 person.
Either 0 VIPs use Android, or it is much harder to break into. (From my research, there wasnt any 0 click exploits, you always had to manually download something and approve it outside the play store)
I sort of agree with the sentiment behind what OP is saying here, but perhaps not the way he is saying it. I'm not sure if I'd call it "security" as much as "system integrity." The model that Apple has moved to with the signed and sealed system volume is pretty interesting. I didn't even realize how much had changed with macOS until I was hunting around to change the startup wallpaper on Monterey and realized that macOS today is totally different from the macOS I remembered administering many years ago.
UAC on a Mac has always been good, but now there is this new layer that even protects the system from the admin. I think the real risk with Apple's model is that there are these choke points now that, if compromised, can cause truly catastrophic failure—especially because of the false sense of security that's out there. If an Apple update server or signing certificate were compromised it would be a potential company ending event. Other ecosystems are much more fragmented, and there is some resilience baked into that. I remember a few years back when an OCSP server went down and internet connected Macs around the world ground to a halt. You couldn't open any application because it took 10 minutes for the server that verifies its certificate to time out.
UAC on a Mac has always been good, but now there is this new layer that even protects the system from the admin. I think the real risk with Apple's model is that there are these choke points now that, if compromised, can cause truly catastrophic failure—especially because of the false sense of security that's out there. If an Apple update server or signing certificate were compromised it would be a potential company ending event. Other ecosystems are much more fragmented, and there is some resilience baked into that. I remember a few years back when an OCSP server went down and internet connected Macs around the world ground to a halt. You couldn't open any application because it took 10 minutes for the server that verifies its certificate to time out.
4 0days were just patched recently on Samsungs which targeted the baseband modem among a batch of 22. https://nakedsecurity.sophos.com/2023/03/17/dangerous-androi...
Every single case involving Pegasus was a targeted attack by a state actor. This is a very different scenario to defend against than what corporations or private persons normally worry about.
How would anyone even know? OpenBSD pretty obscure and unused. Payoff of attacking OpenBSD much lower.
OpenBSD is used, but often in less visible ways, as are many of it's subprojects.
OpenSSH, for example, is an OpenBSD project and damn near everybody uses it.
OpenSSH, for example, is an OpenBSD project and damn near everybody uses it.
Their phone probably had at least 3 other RTOSes on it. Hardware security is more important than the main processor's OS when you have that many radios.
EDIT: Seems to be working as of 15min ago.
https://reddit.com/r/apple/comments/134u12e/apple_releases_r...