About the security content of macOS Monterey 12.1
support.apple.com
support.apple.com
This vulnerability is basically an information disclosure issue that enables you to get BSSIDs from the Airport Utility without the appropriate location tracking entitlement. Even worse the OS will not even flash the "location being accessed" indicator in the status bar when geolocation is determined this way.
Essentially any app can shell out to the CLI tool and parse its output and then feed the resulting BSSID to one of the many external BSSID -> Geolocation services and determine a device's location.
At Kolide we are huge believers that device geolocation should not be accessible to third party programs without end-user prompting (even ones managed by MDM) so we aggressively seek out gaps the TCC authorization model (or other OS issues that undermine the tenets of https://honest.security) and report them whenever we find them.
I reported this vulnerability on January 17th 2020.
Edit: Btw, I am not really sure why the CVE was withdrawn. To me this is a pretty serious information disclosure style vulnerability and everyone should upgrade to this release as soon as possible.
Thanks though for your background information what is / was going on!
There are lots of macs stuck at macOS High Sierra (the last one that supports GPUs without metal), and none of them are receiving any security update.
No luck with High Sierra though. Its last update was in Nov 2020.
Apple is notable for providing ZERO official guidance on how long various versions receive security updates. Officially they just say you must be on the latest version. At the moment they're still releasing updates back to Catalina on macOS and iOS 12 for all the devices still stuck on that version. But they make no claims on how long that will continue.
Only solution is to use Big Sur installation using Hackintosh patches and to run it on mine computers.
How one knows that BigSur for instance isn't already compromised by one of those wonderful capabilities for code execution as they provide update only now ?
The few viruses that were around were mostly annoyances.
I just had it in "computer class" to play crappy math games that hurt my eyes but they never crashed, and I wasn't a professional. I used Photoshop in 2003 or so, I think it was OSX by then, and never had an issue if you call photoshop and internet usage "professional" work.
And I still miss it.
The problem was that creative users had no concept of "some extensions just aren't compatible with others".
There were plenty of bugs in QuarkXPress, Photoshop and Illustrator to make our Macs bomb, and the fundamental lack of memory protection, process isolation and preemptive multitasking in Mac OS meant that the whole system was wobbly from the bottom up.
Also, my post wasn't meant as a comparision between Win95 and Mac OS. I just responded to a question about what Mac OS was like to work with on a daily basis in the decade of the 90s. Win95 wasn't around for half of it.
Your experience does not match my own.
I had way more issues supporting users on Windows, at least until Windows 98SE landed.
It was a happy day indeed when Windows 2000 finally landed with memory protection, process isolation and preemptive multitasking.
(Until, as you point out, Windows 2000 came around. Then I started working on Mac and PC simultaneously.)
EDIT: Correction, I said 8.5. Sleepy.
>PCs came with dedicated reset buttons for a reason!
They still do! Windows 9x did suck, Windows NT however was amazing, it is like the most Linux like of all the Windows. How could they release Windows ME...
That’s not different from the situation with Windows. An Intel 386DX CPU with 4 MB of system RAM and 50–55 MB of hard disk space won’t see Windows security updates, either, anymore.
What is different is that Apple is less clear in support periods and often more aggressively leave older hardware behind.
I don’t think you can require them to support things forever, but requiring everyone to be clear about it at time of sale, or requiring X years of support would be good ideas, IMO.
Yes. And that is also part of the problem. They also don't patch reported vulnerabilities nor provide a clear path for the community to fix themselves.
> What is different is that Apple is less clear in support periods and often more aggressively leave older hardware behind.
Yes, that amplifies the problem a lot. Many of the abandoned machines are 10-year old but still very suited for daily use. They have 64-bit Core i processors with decent amounts of RAM (such as 8 GB).
Why you can't require them to support things forever ? Why not? It was their choice to lock completely those devices they sell.
I think as long as device is looked and you cannot have root access and install own software of course you can required them to support those things forever until they provide unlock for them at least, no?
Perhaps it's time to question this practice and discuss the issue with potentially making such devices illegal? At least when company doesn't provide software?
Shouldn't then Apple made be legally obligated to provide root access for the devices it no longer supports?
Otherwise it's what? You buy device then it's not functioning anymore just because they decide so. Doesn't it look like some kind of a fraud/scam ? How it's called then?
I mean if one owns computer/iphone and cannot install own software there since those devices are locked and Apple do not provide their software with security updates what an owner of the machine should do?
You knew this getting these devices. You didn’t buy it and except to be able to run android on iPhone did you?
> Perhaps it's time to question this practice and discuss the issue with potentially making such devices illegal? At least when company doesn't provide software?
Why? I don’t see a huge benefit. I don’t love it, but it’s not like you can’t run old versions or it stops working. Do you expect them to give you software updates forever once you buy it? Apple is one of the best at updating mobile.
If it was up to me I’d like to have the paid updates model again, it would stop forcing upgrades, I’m not fond of the security comes with features model, and I think it would force them to have more support for other versions, they expect everyone to always update.
Then again if you don’t like the product, don’t buy it. Many Android phones lets you do all of that, and once I set up an iMessage server to route it I’ll switch completely.
>I mean if one owns computer/iphone and cannot install own software there since those devices are locked and Apple do not provide their software with security updates what an owner of the machine should do?
What security problem are you worried about? I never update iOS from the version it came from and had never been hacked ever, I’d love to hear of anyone with that experience, I have never heard of it happening once, same with my android devices although I root. Maybe my Adblocks, blacklist, or the VPN on mobile prevents it anyway, on my home network I rely on my router to protect my devices.
Do you have a realistic fear, which exploit? Why is it scary? Best practice is to stop assuming you have any safety, updates or not, lots of unpublished backdoors, lots of ways to hack you if they really wanted to.
All of the Macs stuck at High Sierra can also run Windows or Linux.
What about current M1 model after few years?
Btw what about IPhones/ IPads? Can they run linux?
Macs can run another OS by design.
I do not think I did. See above ... "I mean if one owns computer/iphone ... "
>Macs can run another OS by design.
If you are talking about previous models, to the certain degree yes except GPUs if I am not mistaken.
But current M1 Mac as far as I understand it doesn't boot anything else unless it boots first from the internal storage and only then "external OS loader" which should be authorized too at least once by Apple.
You can say that "Macs can run another OS by design." but design in which they authorize anything while do not provide full specs of HW interfaces for "another OS" I can't call so.
When did Intel release the full specs for the hidden OS that runs on the Management Engine in x86 chips?
>[Intel] processors are running a closed-source variation of the open-source MINIX 3. We don't know exactly what version or how it's been modified since we don't have the source code. We do know that with it there Neither Linux nor any other operating system have final control of the x86 platform.
It can reimage your computer's firmware even if it's powered off. Let me repeat that. If your computer is "off" but still plugged in, MINIX can still potentially change your computer's fundamental settings.
https://www.zdnet.com/article/minix-intels-hidden-in-chip-op...
"Strictly speaking, the things can boot off of DFU (USB device mode) too, but to make that useful for regular boot you need to ask Apple, as currently you cannot boot a normal OS like that as far as I know, only their signed restore bundles (which is how you fix an M1 Mac if you wipe the SSD)." (https://news.ycombinator.com/item?id=26116017)
The drivers to do so exist now.
"macOS on ARM is very clearly a descendant of the way iOS works. It's just macOS userspace on top of an ARM XNU kernel, which was already a thing. The way the boot process works, etc. is clearly iOS plus their new fancy Boot Policy stuff for supporting multiple OSes and custom kernels." https://news.ycombinator.com/item?id=28181976
I think after M1 it will be more and more confusing to see them too much separately.
Well, that range covers three different CPU architectures(!) and at least one complete file system rewrite.
But your point is fair - to the layperson there hasn't been much change.
The exercise proves that hardware is irrelevant to an operating system
> and at least one complete file system rewrite.
Which filesystem was completely rewritten, and why? Unless you're referring to AFS... which wasn't rewritten, but developed.
> But your point is fair - to the layperson there hasn't been much change.
Pretty sure not a whole lot has changed for the experienced expert, either. What has incrementally changed (but not so much it's unrecognizable) is the graphical user interface. A GUI is not an operating system.
You know what I meant and the distinction is irrelevant in this case, so don't be that guy. The point is, a lot of impressive engineering resources have gone in to the OS over the years. In particular the seamless transition (due to Rosetta x 2) from Motorola -> Intel -> Apple Silicon (among other things) so the statement that MacOS 10 -> 12 has little fundamental difference is a bit hyperbolic.
Anyways, I'm not sure why you're trying to start an argument but I'm not interested. You sound way more uhhh... passionate about this topic than I care to be.
NeXTSTEP was compiled to run on 68k, x86, RS6000, and Spark, it didn't change the version number. Tiger and Leopard ran on PowerPC and Intel. Snow Leopard ran both 32-bit and 64-bit with distinct kernels. Big Sur and Monterey run on Intel and ARM. In each instance, these are the same OS at the same version running on different platforms. But in each instance, it is still the same operating system, regardless of any differences in the code on any particular platform. The hardware is irrelevant.
There are technologies introduced and some simultaneously deprecated at each increase of a macOS version number. Most of this has to do with the user interface, but there are some changes to the OS having little to do with the user interface. These changes, however, are incremental point increases, at best, not version whole number advances, which Apple has inexplicably ticked forward every year since 2012. What are the differences between Monterey and Mountain Lion that warrants their distinction? Ignoring platform, shown irrelevant above, they merely appear very different, along with a few inconsequential new or removed features, but they are more alike than they are different. So I think Apple has employed version numbering as marketing rather than marking milestones of significant advancement. Microsoft has done this too, in spades. Sure, Vista and Windows 8 are unrecognizable, but they are both still fundamentally NT, and not distinct operating systems.
No, but tone does. As does uncharitably interpreting comments.
And I never said hardware itself mattered, I said the level of software engineering in seamlessly transitioning MacOS across different architectures was impressive and resource consuming. Rosetta (executed flawlessly twice) in particular is an incredible feat. As were Time Machine (effortless backups), full disk encryption (seamless and transparent) at the time they were released. Not world changing, sure - but what OS feature in the past 20 years is?
>Apple has inexplicably ticked forward every year since 2012. What are the differences between Monterey and Mountain Lion that warrants their distinction?
You've moved the goal posts. The comment I replied to was:
>Fundamentally there is very little difference between Mac OS X 10.0 Cheetah and macOS 12 Monterey.
Anyways, I'm no Mac fanboy so it feels weird trying to hype MacOS up. My only point was that the above statement comes across as more than a little hyperbolic.
I'm not entirely sure how to counter your argument since you've provided no criteria for how much the OS should have changed over the years. You've only said it hasn't changed enough. That's a bit vague. What OS meets your criteria? What obvious feature is MacOS lacking? What's your gold-standard benchmark for what an OS should be?
To be clear, I agree with you that many (most) MacOS changes are marketing-driven fluff. But I also fail to see any significant advancements in other OS's that MacOS sorely needs.
In fact, you did list migrating platforms to support macOS versioning, which can be interpreted as saying the hardware matters enough to advance versioning.
Goal posts weren't moved (farther apart, they were moved closer together). This is not the same thing as the meaning of the idiom "moving goal posts," especially because no goal was met.
> since you've provided no criteria for how much the OS should have changed over the years.
This is actually a good example of moving goal posts, because it is beyond the scope of supporting the argument. It is perfectly ordinary that something be proved as less than ideal without providing what a perfect or better ideal is.
> But I also fail to see any significant advancements in other OS's that MacOS sorely needs.
This is a straw man and skew to the argument, which is simply that calling annual upgrades a new operating system due to new GUI features doesn't make one OS distinct from it's previous incarnation, but they are instead, at best, incremental point increases of the same operating system (which is actually what Apple does, 10.5, 10.6, etc.). I'm not sure where you got the notion that I was arguing anything beyond that, arguing anything beyond decrying the Adobe-style marketing strategy of labelling the same software as though it were new and innovative. With Mac OS X, OS X and macOS, the kernel hardly changes and the user land barely changes if at all, and even the window manager barely changes. What mostly changes is a few GUI features deprecate while adding a list of new GUI features; what changes between macOS versions is superficial and incremental.
And it is merely my opinion, not a claim of some fundamental truth. So let me tell you what you're going to do, you're going to have better days and not sweat it so much.
Well, I didn't ignore the argument, nor did I attack you personally (your tone is not your personality, is it?). So you're misusing "ad hominem".
Second, on a human level, I pointed out that your argument came across as curt and unnecessarily argumentative. You can choose to do with that feedback what you will. As in "hey, sorry, I didn't intend it like that" or "NAH-Nah you committed a technical foul therefore I win the argument!". It's your choice, but when people make observations about how you're coming across - it might be wise to assume they mean that genuinely.
>Goal posts weren't moved (farther apart, they were moved closer together). This is not the same thing as the meaning of the idiom "moving goal posts,"
You're plainly wrong. Further apart or narrower doesn't matter - what matters is you changed the scope of your argument to make it easier to support. Your original comment covered 2001-2021, you then casually changed it to 2012-2021 without explicitly acknowledging you were changing the argument.
That is textbook goal post moving. Textbook.
The rest of the argument is simple - you're saying MacOS hasn't changed enough. I'm saying - relative to its peers it has changed about the same amount. If you can tell me some great advancements that other OS's have had during the same time frame that MacOS lacks that would go a long way to supporting your argument. I'm actually curious on this (since for example - I don't follow Windows too closely).
Similarly, I can say Samsung (or whatever) TV's haven't advanced that much in the past 20 years. But if I can't point out a single feature or advancement they are lacking compared with their peers then it's not really a strong argument. It just sounds like I'm angry with Samsung for some reason.
>This is a straw man and skew to the argument, which is simply that calling annual upgrades a new operating system due to new GUI features
You're incredible. Actually screaming "straw man" in the same sentence you're saying Apple (or literally anybody) calls its point releases "a new operating system". Amazing.
You're now 0 for 2 in use of the term "fallacy".
>So let me tell you what you're going to do, you're going to have better days and not sweat it so much.
I'm fine. As previously mentioned, you're the one who sounds angry.
That said, I’ve upgraded the video cards and applied an EFI “fix”, so it runs later releases with full FV2 boot support (hence the EFI “fix”).
High Sierra runs well on this device.
That said, Apple did provide some support for iOS 12.x recently, which was unusual.
Yes, it also applies to MS and possibly many other companies.
One could claim that they do, always, in the newer versions of the OS, which are almost universally incremental improvements based on the older versions.
Not supporting old hardware is something that all companies [1] eventually must do, since resources are limited.
I don't think Apple or Windows would be a good choice, if openness is a feature you're looking for.
I get it, but macOS does not need to do anything hardware-specific to fix security vulnerabilities, they'd only need to patch the old version (which already supports that hardware) and release an update, and only if someone reports a vulnerability. If they planned to group hardware deprecations only every X versions (let's say they'll remove hardware every 5 years), they would have very little work to do to keep those old versions safe.
> I don't think Apple or Windows would be a good choice, if openness is a feature you're looking for.
I agree, but that doesn't mean we shouldn't also push for them to be better. Personally I love linux but I also need mac for iOS development.
Are these things in Objective-C or Swift? Does Swift memory management make buffer overflows and use-after-free mistakes harder to make?
https://github.com/apple/darwin-xnu
C 82.5%
C++ 8.7%
Python 2.3%
Roff 2.3%
Assembly 1.4%
HTML 1.1%
Other 1.7%
The first generation Mac Pros (2006/2007, with 32-bit EFI) are like this too and need to be basically hackintoshed to boot Mac OS X 10.8 and later: https://forums.macrumors.com/threads/2006-2007-mac-pro-1-1-2...
Here you can find some examples: https://reddit.com/r/macbookpro/
I’ll not go into my personal relationships with Monterey, only global statistics matter, but I can say that right now I’m trying to not reboot my system accidentally because one of the issues accidentally disappeared and I don't know what caused it.
Apple used to be so smug about not being vulnerable in those 2000s commercials. Now that they have reached critical mass, their OS is equivalent to Windows.
Yeah, they're basically identical, except macOS doesn't even have Defender.
This was a big deal a few years ago when (IIRC) a bug caused it not to cache the list long enough and it started causing problems when it couldn’t phone home. Aside from that it’s always been a perfectly seamless process.
That's the XProtect blocklist, it's been around pretty long and hasn't caused any issues that I'm aware of.
> bug caused it not to cache the list long enough and it started causing problems when it couldn’t phone home
What changed is that since Catalina macOS additionally makes a synchronous check the first time you open an app. For certain things that are not code signed (eg. shell scripts), it checks every time. This can cause multi-second delays when launching apps or executing commands in the shell. (see https://sigpipe.macromates.com/2020/macos-catalina-slow-by-d...)
To my knowledge, this issue has not been fixed and is still a problem in Monterey (first time app launches on my M1 Max sometimes take several seconds).
It's possible to deactivate the check for Terminal (by marking it as a "Developer Tool" using a checkbox that sometimes shows up in System preferences, and sometimes doesn't). I'm not aware of a way to avoid this slowdown in Finder without disconnecting from the internet.
I wonder how long the same story will repeat before the balance shifts in favor of just rewriting in more modern languages. It's expensive work with a long ROI, but sounds like a lot of these are in foundational libraries that you want to be robust in the long run.
This is especially applicable for various parsers that are typically self-contained code that is not performance critical but very prone to bugs with nasty consequences like the article demonstrated again.
[1] - https://hacks.mozilla.org/2021/12/webassembly-and-back-again...
Haskell's Software-Transactional-Memory (and general focus on immutability-by-default) are another interesting approach towards the same goal.
Software Transactional Memory (STM) is perhaps much easier to get started with than Rust's model. (Though the same can not be said for the rest of Haskell.) The failure model with STM is that your stuff runs slow, if you don't know what you are doing.
For OS and browsers though, I agree completely if infrastructure as long as its not always connected to the open internet, it doesn't seem to be much of a threat, and even though I don't care about memory safety, the performance of rust tools impresses me! I wish people talked about performance of rust more than its memory safety, I don't care as much about that, but everything being faster? Who wouldn't want that? I made this thread a few days ago. https://news.ycombinator.com/item?id=29456115
See eg https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon...
The threat of most security issues is vastly overblown, spectre and meltdown don't exist in the wild, but they crippled all CPUs just in case. Security at what cost? I disabled it, I have no need to make my computer slower for a virus that will never affect me, I "wear" an updated browser. ;)
More pithy: Hanlon's razor says 'never attribute to malice that which is adequately explained by stupidity.', but the reverse is also true: enough stupidity or just randomness can look like malice.
Nothing new should be written in these unsafe languages.
If Spartans were alive they would be using C or C++.
Iterators require at least two mutable references or mixing mutable and non-mutable references. Move-only types require a lot of boiler plate and accidental usage of moved thing is not detected by the compiler. Using std::variant feels like a trolling from the language designers who refused to provide proper type-safe unions into the language.
And, alas, deliberate trolling would be preferable to reality.
Deliberate trolling would indicate a conscious design. C++ accumulated cruft over the years in what looks like brownian motion in retrospect, and almost never shed any.
I do think Apple is honestly committed to Swift over the long term, but it takes loads of time and care to replace the foundations of a building that's in daily use.
They might be committed to it, but I'm doubtful that it's at all possible to write e.g. parts of the kernel in it. And maybe, just maybe, they should direct all their efforts toward rewriting the OS in a safer language instead of making their UIs uglier with nonsensical paddings and messy-looking icons that pretend that there's no pixel grid.
But it would be more interesting to see the parts that deal with untrusted data (file format parsers, protocol handlers) rewritten in Swift.
(There were absolutely spaces where robustness and safety were the priority, but those weren't consumer, and their cost reflected it.)
Even today, I'm not sure we have the engineering margin spend on such efforts (time-to-market is still the priority), though I think the pressure is slowly increasing to do it (again, in consumer spaces, which macOS definitely is).
I guess what really made it a niche language was the cost of compilers. DoD vendors in eighties already learned how to milk their customer.
No one would enjoy paying for a fridge that leaks water, why should they do the same for software.
Bad programming shops taught them that way, that is why.
Most of these programming languages when they were created did not have online connectivity or hackers as a threat. It would be ridiculous to expect them to protect against a threat that didn't exist like calling Japanese idiots for not making nuclear defenses and their bad teachers are the reason. In embedded hardware I still don't see the benefit for memory safety.
If anything, safety considerations in embedded devices are even more important than elsewhere, if only for the fact that those devices typically don't get patched. It has to work right the first time. F*cking this up can have dire consequences, depending on what the device is doing.
In fact it was one of the sales pitch for Burroughs (1961), still being sold by Unisys, which not surprisingly keeps using its safety over classical POSIX as sales pitch.
By the forces of the market, POSIX won because it had more useful features. Personal computers where you were expected to load software yourself and were not connected to any threats? I do not see any reason for me to care about that even today, and its not because programmers had bad habits, they made reasonable tradeoffs, making worst performing software for nonexistent threats of that time is not teaching them bad programming, over engineering for nonexistent threats is bad programming. In non networked devices, I still see no benefit.
It is like 1 euro shops, quality is not what customers are looking for.
Had UNIX been sold like every other OS from the same decade, and it would have been a footnote on the history of OS.
When one is thirsty any liquid goes down regardless of the taste.
There's no law against licensing bad fridges with the explicit warning that they might leak, is there?
Many people choose to go with fridges that are higher quality than the absolute minimum. Some people also choose to pay for extended warranties.
Many other people choose less reliable options, because they have other preferences.
This choice on offer is a good thing.
Why do you want to ban this choice?
Would open-source be effectively outlawed in your favourite world?
Whatever one does to themselves on their own place is their own thing, if they happen to land at the hospital due to food poisoning caused by bad refrigeration.
In any case, the fridge was only one example among thousands.
See, you are suggesting here that customers don't want bad fridge, so they don't buy bad fridges. The problem solves itself.
Why not give customers of software the same responsibility and maturity?
> No one would enjoy paying for a fridge that leaks water,..
For fridge people pay serious money. For software people dig deep in their pocket and then come back with "Fuck it , I am gonna use open source stuff"
People by-and-large _choose_ to license software where the license contract denies liability.
You are free to offer 'proper' liability, and try to charge enough extra for it to make up for your extra costs.
(Or do you want to forbid certain kinds of contracts, so that your preferred kind of contract 'wins' because the competition is banned?)
Do keep in mind that some software does come with liability, and things that are a bit like liability. The latter category is eg when you sell both software and a support contract, and your support people have to work harder when stuff goes wrong.
In fact, in many jurisdictions there are laws against (or, more to the point, denying any effect to) the waivers of liability much software comes with.
It's too early to tell -it dropped last friday - but it will probably be marked as one of the most egregious vulnerability to date due to the sheer omnipresence of Log4j in production java's code and the simplicity of its exploitation. We are talking Heartbleed/EternalBlue/Struts2 vulnerability level here.
The difference of ROI of memory-unsafe/memory-managed is not so evident. Usually memory-managed languages have fewer bugs, but those tend to be massively impactful
The log4j bug fits in the "other" category.
Also, it's a fallacy to believe that memory-safe languages aren't that much better because their bugs are worse. All languages can have the worse bugs, it's just that memory-safe languages solved the easier type of bugs, so there isn't as much of them to bring the average down.
It's like thinking that flying is riskier than driving, because plane crashes are so devastating. Driving kills more people overall, but they're spread across more, smaller events, so we're not as aware of them.
A rewrite will likely introduce plenty of CVEs that weren't present in the original code -- possibly more than are fixed, for many years to come.
I see a Big Sur update dated December 13, so it's definitely still being supported. While I haven't done an exhaustive check, it looks like it patches many of the same security holes.
The only way to be safe on Apple's computers (and phones) is to update to the latest version the day it comes out.
>The only way to be safe on Apple's computers (and phones) is to update to the latest version the day it comes out.
That has not been the case with 14 and 15, its a heuristic but unknown backdoors are a constant threat. Realistically we should state that they are never, ever safe.
CVE-2021-30869 was patched in Big Sur on September 23, 2021
https://support.apple.com/en-us/HT212147
and was patched in Catalina on...September 23, 2021
https://support.apple.com/en-us/HT212825
The article says that the Chinese team said it was on Big Sur, and that the Google team then discovered it was also on Catalina. It doesn't say that Apple didn't patch it on Catalina, or that they patched it "months later".
I would recommend against using vice.com as any kind of authoritative source. On anything.
https://support.apple.com/en-us/HT201222
Big Sur and Catalina got corresponding updates today too.
The sandbox keeps being tightened each release.
That’s just not an option for a regular phone or laptop, which is most of Apple’s market.
Don’t forget about the RAM pressure too.
Lots of Macs have more than one video card. I disagree, I mentioned it since they make their own silicon, and can do virtual GPU, memory management for the browser would be an issue, but Apple doesn't care, they just use swap on the SSD and it would still be cool to have that as an option for single tabs. All web browsing is just a huge amount of javascript virtual machines, and they have custom hardware to run it faster, they might do it via hardware, all their sandboxing is just OS based, TouchID ran its own OS and took years to crack, and needs hardware tools to do so.
[1]: https://web.archive.org/web/20100501010616/http://www.apple....
And back in 2010 or so, when Flash plugin was still available in beta on iOS and Android, but was declared "too slow" or too heavy on the battery, I wrote an extremely fast-for-the-time <canvas> based screen graph to do some side by side comparisons of manipulating sprites, animating vectors, masking touch areas, blitting some basic particles, etc. Javascript performance was not even close to Flash performance in an iPhone. It really has never gotten close, even with much faster processors and with v8, to replicating on canvas what Flash was doing. Only via WebGL has it become possible to get mobile graphics performance in the browser now resembling what Flash could do in 2010. So the performance complaint was, as far as I'm aware, a lie.
The security complaints were, indeed, legitimate; and it's true that Adobe sucked at patching them, and Flash was a dangerous point of failure for corporate networks. That being said, it would have been a lot better if Adobe and Apple could have come to an arrangement to base a standard off of it. Instead what we have is a million workarounds to achieve the same effect, and we still have a huge amount of terrible, web-choking code all over the place. It's just in untyped JS, which is worse. Bad code is always bad code. At least with Flash you could kill the process without killing the page.
It was very easy to make stuff on it it was developer and artist friendly (still has lots of cool stuff that doesn't exist), it was a standard, but performance wise it sucked, and I would find it interesting for you to tell me what "web wellbeing" is. I would say that any analytics, advertising, and (my most controversial opinion) javascript is bad for web wellbeing. Every issue you leveraged against flash is the same with javascript.
Also, it was really Flash's own limitations that killed it on mobile (which, it turn killed it on desktops). Don't forget it was on Android for a while and aggressively marketed as an advantage over iOS. But it was also a poor UX (slow, power-hungry, designed for mouse & keyboard not touch) and a propriety third-party black box.
Apple didn't so much kill Flash as just be the first to see it coming and act on it.
Native. That's what Apple wanted (and still wants) you to be doing.
To address your point more generally, though: that HTML 5 -- or some other technology -- was as bad as Flash in some ways is not a sufficient reason to support it. Flash was worse than the alternatives is some ways (and critically so in some cases, e.g., wrt power) and didn't offer any unique killer capabilities.
You're spot on that Apple always wanted native code, and still do, but what small studio has time to write everything three times? The idea of deploying and maintaining totally separate code for a casual game on Android and iOS and the web is a deal-breaker for a 5-person team, and putting all your energy into one walled garden is not what's best for the developer.