Live data from Hacker News

Apple patches CVE-2020-9859 (unc0ver)

support.apple.com

71–79 of 79 posts

Re: Apple patches CVE-2020-9859 (unc0ver)

#71
post #49

Earlier quoted context omitted.

If that doesn't illustrate their true priorities re: user security/ privacy, then I'm not sure what could.

https://twitter.com/s1guza/status/1266433756270866433 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 m…

> Or you know the priority may also be keeping the walled garden - walled?

That's actually what I interpreted prvc's comment to be saying. But I guess I might have misinterpreted it.

Re: Apple patches CVE-2020-9859 (unc0ver)

#72

Earlier quoted context omitted.

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 s…

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.

Chrome does too, I hear.

Re: Apple patches CVE-2020-9859 (unc0ver)

#73

Earlier quoted context omitted.

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.

^ This is why you should always be able to turn off automatic downloading of updates.

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.

Re: Apple patches CVE-2020-9859 (unc0ver)

#74
post #70

Earlier quoted context omitted.

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…

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 repeat: it's incompetence.

I rather would point out management. This is what changed in this timeframe.

Re: Apple patches CVE-2020-9859 (unc0ver)

#75

Earlier quoted context omitted.

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.

Chrome does too, I hear.

https://blog.chromium.org/2009/07/smaller-is-faster-and-safe...

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.

Re: Apple patches CVE-2020-9859 (unc0ver)

#76
post #49

Earlier quoted context omitted.

If that doesn't illustrate their true priorities re: user security/ privacy, then I'm not sure what could.

https://twitter.com/s1guza/status/1266433756270866433 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 m…

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.

Re: Apple patches CVE-2020-9859 (unc0ver)

#78

Earlier quoted context omitted.

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".

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.

https://news.ycombinator.com/newsguidelines.html

Post reply on HN