I think this might be the fastest patch of a security issue affecting Apple's operating systems, ever. Aside from *.0.1 releases that fixed critical bugs with core features in new OSes, has anything been patched this fast?
I have a pretty clear memory of the JailbreakMe 2/3 bugs (which, for anyone else reading, were bugs that could be used from the web browser, and so were of the form "you click a link or have some evil iframe and are pwned") being fixed in six days (which I mentally cataloged as the minimum turnaround time Apple could muster).
That's a bit before I was using iOS, so I'll take your word on that one ;) AFAIK some system call filtering went into WebKit at some point to make this specific exploit unreachable from the web process, so I guess you could call it "less severe" than JailbreakMe was. That being said, I guess "zero day affecting all current devices" is probably good enough to get priority. (FWIW, heavily publicized non-security bugs often get quicker updates, sometimes within one or two days, which I assume pushes close to how quickly they can get a fix merged and through B&I.)
This may also illustrate their priority to reintroduce the same bug and re-fix it at faster speeds to wow their fanbase. Or you know the priority may also be keeping the walled garden - walled? Also it might just be security response 101 - like every other major OS vendor out there depending on the bug. But yeah privacy and security for users that's a much nicer marketing pitch.
Jailbreaking is not a threat to the walled garden. The majority of users want the walls there to protect them from malware and crappy software breaking their device. The obvious market preference for managed devices that "just work" is lost on the HN crowd because most of us belong to a different market with different preferences.
My reading is that this bug could potentially allow apps to install rootkits. The speed of the fix tells me maybe it's being exploited that way right now in the wild.
BTW MacOS got the fix in record time too in spite of it being far less strictly walled than iOS. That supports my suspicion that this bug is being used in nasty ways.
If it is true the bug was present in iOS 11 and fixed in iOS 12 before being reintroduced in iOS 13, that might align with macOS 10.14 (≈ iOS 12) being unaffected.
It might seem strange, but they are using a change/build/deploy mechanism designed to deliver updates to any and all parts of an OS across a range of hardware devices.
I'm pretty sure the mechanism, from end-to-end, is complex, and providing an optimized path for small changes would require resources, introduce more risk, and come at the expense of something else.
Sucks, though, for everyone who doesn't have a reasonably fast or reliable internet connection.
That’s not an axiomatic truth. Binary diff algorithms exist (ask me, I’ve written several) that can identify and isolate changes across versions even when content is changed at non-block boundaries, non-contiguously, etc and while they are computationally expensive patches to create, they are trivial to unpack/apply.
But generally the software industry has moved to a model where diffs are shunned and “recreate from scratch” is embraced for reasons that range from reproducibility to speed of development to architectural purity and everything in between.
That's not universally true. Android makes significant use of binary diffs for patching to reduce OTA upgrade sizes, for example. However they're not appropriate for all situations, and there's a bunch of legitimate reasons Apple may have chosen not to pursue this for kernel updates.
Yes, and smaller updates is arguable better security for users because they'll actually update. A 3gig download and a 15 to 45 minute down time is a huge incentive to NOT update.
I work on a ship part of the year. Satellite internet shared between 50 people. These Apple updates would saturate the network and grind it to a halt before we started blocking them on the firewall. iMessage got caught in the crossfire and now sometimes works and sometimes doesn't.
you can verify if Content Cache is working in a couple ways... first, while installing the update, you should see a CPU usage spike in Activity Monitor for the process "AssetCache".
secondly, you can run this command on the machine you want to upgrade, to verify that it can see your Content Caching Server (it should report the local IP address of the machine you set up Content Caching on) "AssetCacheLocatorUtil"
Looks like if the machine is asleep it won't use it for a content cache, even if "wake for network access" is turned on. So a pretty useless feature if you have a machine that's allowed to sleep.
If you've just turned on Content Caching, or the machine running it has rebooted, client devices will not discover the server immediately. You need to wait a while, or reboot the client devices, which will force them to discover it.
On iOS? iPhones don't update automatically (if you tell them not to), but I'm not aware of a way to stop them from downloading updates, other than weird workarounds like installing a tvOS beta profile.
I forget that perhaps Apple's intent is to do what people complain about: download the update anyway, regardless of the setting. My anecdotal experience (I have yet to have an iOS device actually download the update when I have automatic updates turned off) allows me to forget.
Actually, my iphone won't update unless it's being connected via WLAN rather than WWLAN. Makes me kindof of a persona non grata at friends where I have a WLAN password, and the first thing happening if I'm on a visit is that my iphone updates itself. Though it's not as bad as people with Windows notebooks exhausting my mobile plan when they're at my place.
that's a flippant guess. the underlying reasons or the reasoning for others' decisions may not be apparent to you (i.e., under-explained).
beyond that, if decisions others make often seem not reasonable, it's probable that you disagree with the values on which those decisions are based, rather than those business decisions being without reason. you may be entirely justified in your disagreement, but that's a different animal from unreasonableness.
also, most business decisions are made under uncertainty and with imperfect information (under-informed), and many can seem less reasonable in hindsight as a result.
in any case, it's really unlikely that decision makers are chaos monkeys even if it seems that way from your vantage point.
A private company can deliver two human beings alive to a point in space with millimeter precision. Meanwhile another can't deliver Operating Systems without gross bugs or smaller updates with binary diff patching.
I want to point out that software and space are quite different problems. Much of the engineering for space appears to be mathematically differentiable and continuous -- a small change in inputs usually results in a predictable change in outputs. It's hard work, but relatively intuitive.
Software is more chaotic though. A small change in inputs can change behavior drastically, like stepping a tiny bit to the right on a branch of the Mandelbrot set. It's sometimes easier work, but often relatively counterintuitive.
There's no amount of handwaving that will excuse Apple for messing up their signin authentication, mobile throttling, faulty keyboards being delivered for years despite customer outcry or allowing anyone to login as root with blank password on macos. Those things should get caught in basic QA. It's not rocket science.
I currently don't have one, so…no? I do usually try to keep Hacker News clean of low-quality comments, though, which is fairly distinct from "negative apple feedback".
And it's a much more interesting topic than trying to figure out if I'm an Apple astroturfer, which in itself is strange because the top comment in this very thread is me pointing out that Apple unpatched this bug in iOS 13…plus it's against the site guidelines, which is why I assume that the comments have been flagged.
But back on topic: there are some devices that do include a specific partition for updates, but I don't think it's usually for user storage, but for "seamless updates": you install the OS to the other partition, reboot, and the partitions swap and you have a new OS up and running immediately. I actually doubt that any manufacturer would forgo not counting that as part of their user storage, unfortunately…
As someone who has been corrected by you when quoting from inaccurate sources on iOS and jailbreak related info, thanks for what you do and how you go about it. You're curt and courteous, which can come off as being short, but you're always accurate in my experience. I don't think you should worry too much about people thinking you're an astroturfer, because those who know the technical side know that you know your stuff.
Yeah people like you did a lot of work to hide apple’s planned obsolence in the past, wouldnt be entirely shocked if this was the case. Now you can apply for a job at apple showing what a good sheeple you are.
We've banned this account for repeatedly breaking HN's guidelines and using multiple accounts to abuse the site. If you'd please stop doing that, we'd appreciate it.
Except storage is soldered on. Storage juggling should be automated with an additional volume IMHO, because installing a new OS or point release shouldn't be a massive, manual hassle. On iOS, a USB2Go device should be usable... but ideally, it would have enough reserved space for all possible updates.
Strawman. An almost full 256 GB SSD MBP would obviously need the next one up, but it's moot if it's soldered on unless you're a Louis Rossmann fan with the microsoldering and microscope play-at-home pack.
You didn't communicate that. There is no "download" to delete on iOS (and derivatives) and it's managed by the system on macOS. It's not a small delta when it should be tiny (100 MiB), that eats up data plan and storage.
I jailbroke for the first time in nearly a decade when unc0ver came out. It's actually pretty useful. I really love having the ability to use Flex on any app on my device.
(I'm also obligated to post that the bug that this fixes is not new; it was discovered back in iOS 11, fixed, and Apple reopened it in an iOS 13 update: https://www.synacktiv.com/posts/exploit/return-of-the-ios-sa...)