Why delay the announcement? And why remove the original "APPLE-SA-2017-09-19-1 iOS 11" with "Date: Tue, 19 Sep 2017 -0700" from the apple-security email archive?
Also, are Macbooks vulnerable to the same bug until next monday when macOS 10.13 drops?
Highly unlikely, I don't think Apple has ever released multiple branches of updates for any device. The closest is perhaps iOS 6.1.6, a fix for the fatal "gotofail" SSL vulnerability, which was pushed out to devices stuck on iOS 6.x, but if your device was eligible for iOS7 then iOS7(.0.6) was what you would get.
That's also the only time I can remember security updates being pushed after a device model being end-of-life'd.
Nope, so this is going to be interesting to watch. Personally I was hoping that they would offer an optional download of 32bit support libraries to let iOS11 users run important existing legacy apps and access their documents, but they seem to push hard on making developers get in line and update their apps. Which is unhelpful for the cases where the developers no longer have any interest in their apps or even exist (bankrupt, disbanded, in some cases deceased)
>Which is unhelpful for the cases where the developers no longer have any interest in their apps or even exist (bankrupt, disbanded, in some cases deceased)
If they are "bankrupt, disbanded, in some cases deceased" then maybe insisting on using those apps are not the best course for the user either...
It's not just a matter of the space on disk to hold 32-bit libraries. They must also be loaded into memory if there are 32-bit processes running. This degrades performance system-wide, not just for the abandonware apps.
What good is RAM for if not running the applications a user needs to run? If the user is not currently running a 32bit app, drop the libraries from RAM. That is such a non-argument. The amount of space and time needed to load and unload 32bit support libraries is probably 1% of the space and time used every time a user loads a game, or the facebook app, for example.
>What good is RAM for if not running the applications a user needs to run?
What good is degraded performance because some BS game/app who on top of it is abandoned from its developer for years, and it will stop working anyway sooner or later, needs 32-bit mode? Especially when you can find 200 replacement that work fine in 64-bit and are upgraded regularly.
If a customers pays Apple $1000 for a device and uses that device to create valuable data which cannot be migrated to another app, they may expect their device to continue providing the functionality for which it was purchased. It still contains their data + app. Customers want access to their DATA, not apps, not devices - those are mediating tools which change over time.
If Apple wants to force apps to do something, they can force developers to create interoperable data that can be migrated without the developer's consent or continued existence. Until then, Apple has more resources than Microsoft and Linux, which both provide backward compatibility for old apps on new platforms. This is a solved problem.
Why penalize iOS platform customers who were the earliest adopters and had the highest chance of creating data which is now orphaned in abandoned-but-functional offline apps? Let's not get into the Apple's mis-steps on the App Store, which is what caused many iOS developers to go out of business or stop supporting apps.
If your car can only be unlocked by your phone you made a mistake when buying it. Just like if it features proprietary chargers. These things just don't last.
You can still buy new cables that fit the first iPhone today but you can’t buy a new iPhone that fits the 30pin charging dock in old cars.
The main difference though is that you’d expect a device like an iPhone or iPad to last a maximum of about 3 to 5 years while you’d expect a car to last 10 to 25 years. Accordingly it would be wise to use future proof parts, not proprietary parts that go out of style every few years.
That's the point here, if (offline) apps randomly break then your platform is crap. Anything cloud-reliant (in that case) would have broken a long time ago anyway and isn't really relevant.
What legacy apps worth keeping “documents” for - I’m assuming non game apps — would be worth supporting? The chances are even if they did provide support for 32 bit abandoned apps, they would break sooner or later with a future OS upgrade.
Besides are you planning on keeping the same IOS device forever? The newest processors are 64 bit only. I doubt that Apple will ever release a new device that will support 32 bit devices - except for maybe a new iPod Touch or iPhone SE.
> If the developer does not have any interest in updating their own app, do I as a user care about their apps?
A developer's primary interest in their app is to earn an income. A user's interest is in using the app for whatever functionality it provided. There's no symmetry here.
If the developer doesn’t want to update their apps to fully support my device, then I would look for an alternative.
There are almost 0 cases where I would withhold an OS update in order to keep using an specific app, let alone change my device, and I’m completely on Apple’s side for finally killing 32-bit.
What was the point of that be? The apps aren’t going to be updated if they haven’t in the last four years. Keeping all that stuff around is also support burden for Apple.
If they only supported it on the 7 and below then it might be confusing to users why some people get to use older apps and others don’t. On the other hand if they wanted to support it on the 8 and X then they would have to have an entire processor emulator that would only exist to support apps that hadn’t been updated in years.
Don’t forget that Apple keeps tons of usage statistics from people who are willing to give them. Chances are they know pretty exactly what percent of people use 32 bit apps with any regularity and how much total time to use them for. If they were willing to make these decisions my guess is those numbers are very low.
People here on HN are concerned about it and there have been some articles on websites about it but I’m willing to bet that this whole thing is almost a non-issue.
They did, and they’ve been doing that on iOS. The first 64-bit devices came out for years ago.
I was actually thinking of when they left 68K and PowerPC though. I had PowerPC apps that worked through Rosetta for a while and then that was removed when Apple decided it was “time“.
They’ve done it before - released an update for an older OS after the newer one was introduced - but never for a device that was capable of running the newer OS.
Maybe not this time, but they have a history of fatal firmware bugs that could compromise the host system - such as http://boosterok.com/blog/broadpwn2/
Does that mean that all embedded WiFi (and probably also baseband) controllers are deeply rotten, and we only blame Broadcom so far because of their popularity with device manufacturers?
This is a bug that was already fixed. It means nothing in the grand scheme.
In the current grand scheme, Apple and Qualcomm are also currently suing each other and I'm pretty sure part of that is Apple withholding billions in payments.
This is a Hacker News post about an interesting security vulnerability. It is, by both moderator and owner intentions, specifically meaningful in the 'grand scheme' of Hacker News, a site set up to permit people to discuss links.
Yes, at a different level of business, Apple has an open lawsuit against Qualcomm, but that's not the scope that we're here to discuss. Mentioning it is fine, linking to a recent HN post about it would be stellar!, but "It means nothing in the grand scheme" is dismissive and wrong.
Your concerns are clearly expressed, but insulting others for choosing to discuss a topic not relevant to your concerns is no excuse to shut them down verbally. That approach is not welcome here.
Whoa. Attacking another user will get you banned here regardless of how bad some other comment was. Please read https://news.ycombinator.com/newsguidelines.html and don't ever post like this again.
I think these latest sets of wifi flaws are interesting if it turns out they are exploitable by merely being in radio range of an attacker even without joining a malicious network or requiring user interaction. That could quickly become a fast and wormable attack. You could probably flood across an entire city jumping from chip to chip in no time.
Especially now that iOS 11's wifi-off button in the control center no longer actually disables the radio, but merely disassociates from the current access point.
> Especially now that iOS 11's wifi-off button in the control center no longer actually disables the radio
I still can’t belive this decision. I keep my Bluetooth and Wi-Fi off as much as possible and it’s now difficult to to as a result of this change is ios11. Really bothers me.
I really don’t understand why people keep those two off. If you’re not using them they use very little battery at this point; it’s not like it was 10 years ago.
Since Apple keeps detailed usage statistics (from the people who opt in) my guess is they know how common such a behavior is and it’s obviously low enough they don’t think this change is a problem.
I agree with some of the other comments I’ve seen that this probably accomplishes what the user is trying to do (ignoring a Wi-Fi network that’s temporarily behaving poorly) and possibly protecting them (forgetting to turn it back on it running up a huge cell bill). I know I’ve heard complaints from people who accidentally did that a number of times.
I can.. it makes those buttons much more useful for the common case. e.g. this wifi network isn't working, disconnect.. and not forget to reconnect later. I did that often.
And also being hassled about location services not working, etc.
You can still actually disable both through the settings up, just not with the quick access.
This is a bad take. If your threat model has you concerned about people who follow you around and exploit your Wi-Fi firmware, you probably shouldn't ever have Wi-Fi on -- or maybe you shouldn't be using a smartphone.
For everyone else, the new behavior allows users to disconnect from bad Wi-Fi in Control Center while improving their battery life in case they forget to turn Wi-Fi back on.
Am I missing something? Force touch doesn't do anything except show a bigger control with all the radio settings. There is no option to disable wifi, you still have to go to the settings.
Does not having to join a network make a big difference for a worm considering the amount of wifi networks we share with large numbers of other people?
I'd say so. Imagine a worm which could spread itself to any phone within WiFi signal range. I'd guess at a worm like that covering a whole city at a really rapid pace. If you're stuck with infecting networks then the main transmission vectors would be offices, homes and cafes/restaurants etc. I think it would be much slower and much less far reaching.
But instead published after the fact as an additional update: https://lists.apple.com/archives/security-announce/2017/Sep/... and https://support.apple.com/en-us/HT208112
Why delay the announcement? And why remove the original "APPLE-SA-2017-09-19-1 iOS 11" with "Date: Tue, 19 Sep 2017 -0700" from the apple-security email archive?
Also, are Macbooks vulnerable to the same bug until next monday when macOS 10.13 drops?
Also, there are about 6 other similar issues recently posted to Google Project Zero: https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...