Only data is stored in the secure enclave from what I understand. The secure enclave isn't an environment as it is storage area
It's a bit more complicated than that. The secure enclave offers services to the OS, for example you can give it a digital signature and ask if that signature was signed with a trusted key, or you can give it some data and ask it to decrypt or encrypt it with one of the stored keys. It needs to do these things so that the storage can be write-only: if you are able to pull the keys out of the secure element then you may as well do the whole thing in software. A number of Android phones do something similar using TrustZone (though recent TrustZone attacks give me less confidence in that than I'd have had a year ago), but the Apple implementation is a separate ARM core running its own OS and communicating with the main OS.
Your scenario relies on the connection between the camera and OS being open to attack and not secured.
Well, one of two attacks: the OS is fully compromised (in which case you can't get into the secure element, but you can see anything that the OS can see) or the OS exposes more information to userland than you might want it to.
We'll need more details but the current fingerprint scanner is secured from tampering from what I know.
The difference with the fingerprint scanner is that the only useful thing that you can do with the fingerprint scanner is scan fingerprints, so the OS can expose a simple interface that is simply 'is this a valid fingerprint'. This is actually a slightly too narrow interface for a lot of uses. For example, I might want several people to be able to unlock my iPad with their fingerprints, but no one other than me to be able to unlock my Internet banking app, and iOS currently doesn't provide this functionality, just a 'does this finger belong to an authorised person' query. In contrast, the distance-sensing camera is probably very useful for augmented reality things, where you actually do need to expose the depth information to userspace. This makes it much harder to prevent a malicious app from simply doing a face scan and uploading it to the NSA / FSB / Google / Flat Earth Society.
That there will be widely-distributed NSA malware that sneaks it's way onto iPhones and compromises the secure enclave and FaceID hardware?
As I understand it, the distance data from the camera isn't routed directly to the secure enclave, it's available for AR applications. This means that it doesn't really matter to a malware author if they can't get into the secure enclave: they can just lift the data directly from the camera the next time that you look at the screen.
That evil spell checker is scanning all the documents I type, and it's even scanning things outside my word processor!
My spell checker doesn't have network connectivity and scans only things on my local system. It is entirely under my control and none of the terms that it learns are transmitted externally. Something like Cortana would be very useful if it worked the same way: learning things about my workflow on my own device, not in someone else's computer.
Speak for yourself on that one; the only people I've met that at actually like the metro interface on phones are all big fans of Microsoft. People who are indifferent towards Microsoft have never liked it in my experience.
To add another counter-annecdote:
I use macOS and FreeBSD almost exclusively on real computer, have an iPad and an Android phone (I did have an Asus TransformerPad, but it had crappy vendor support and went into an unrecoverable boot loop - never buying Asus again). My partner's Nokia 1020 (Windows Phone 8.1) was the only mobile device whose UI has not irritated me. It hasn't had security updates for a while and the third-party app support is dire, so she recently replaced it with an Android phone (running LineageOS). She much preferred the Windows Phone UI. A couple of years ago, she got a new Dell laptop that came with Windows 8.1 and an option to install Windows 7. She lasted two weeks with 8.1 before the Metro UI pissed her off there before having me wipe it and install Windows 7. The Dell died recently, so she's now using my old MacBook Pro.
I don't think either of us would be classified as 'big fans of Microsoft'. I should probably add a disclaimer that I do some work with Microsoft Research (and a tiny bit with a couple of product groups), relating to security and toolchains. I found it amusing when I visited Redmond a little while ago that my Mac laptop was the first machine that the group I was visiting had seen that worked with the projector in the meeting room we were in...
It's worth noting that the next version of Android is trying to fix some of these issues, by providing stable kernel interfaces for device drivers, allowing the kernel to be updated independently of the device vendor. That doesn't help when there's a security vulnerability in a device driver that the vendor won't fix, but it does help when there's an issue elsewhere in the kernel. I suspect that part of the motivation for this is to allow Google to use Android device drivers with Magenta.
The big problem with Android has been that Google has developed its own software engineering practices that work well internally, but don't work in any other setting. The Google model is to have a trunk branch that is deployed into production as soon as it passes CI tests. They have large-scale refactoring tools that can run over the millions of lines of code in their internal codebase very quickly. This means that they don't need to design good APIs from the start, they just throw something together and refactor it later. Unfortunately, this makes it impossible to support multiple versions. When there's a security bug fixed in Chromium, it's often impossible to figure out when the bug was introduced or to back-port the fix. Their only solution is to update everyone to the latest Chromium, which is a problem if it doesn't support an older version of Android. Much of the Android development works like this, which makes updates hard.
FreeBSD itself is -- as far as I know -- "managed" by the FreeBSD Foundation, and, in turn, that Foundation is managed by the FreeBSD developers.
Not quite. The FreeBSD Foundation is entirely separate from the FreeBSD Project. The FreeBSD Project is managed by the core team, which is a set of 9 people that are elected by 'active' contributors, defined as people who have committed something in the last year (I think - I'd have to double check the project bylaws for the exact time). The Foundation board is self-selected (i.e. board members are appointed by existing board members). There is usually at least one person who is both on the board of the Foundation and the Core team, though not always. The Foundation employs a few full time people and a lot of contractors to contribute to bits of the project that no one personally wants to work on, no single company wants to contribute, but which everyone thinks are important. This is typically guided by the Core Team. This structure protects the project's independence from the Foundation's financial weight (the Foundation's turnover is $1-2M/year). The Core Team decides who is allowed commit rights (usually in terms of granting this right, in very rare examples by taking it away), so the most the Foundation can do is pay someone to write code, they can't force the project to accept it.
The Foundation also handles a lot of vendor relations. Often, multiple vendors want the same thing, but no one wants to pay for all of it. The Foundation helps in these situations by getting different companies to pay for part of something. For example, ARM and Cavium jointly funded to the ARMv8 bring-up (ARM likes having a BSD-licensed reference implementation, because companies like Apple and Microsoft won't touch GPL'd code, Cavium wants to sell chips to companies like Juniper that use FreeBSD), but the Foundation organised the people to do the work (and others to do code review). They also do a lot of outreach. For the last few years, they've employed the release engineer, which is an incredibly annoying and high-stress job that it's hard to find volunteers for (and hard for companies to want to do, because the big downstream consumers typically use their own internal release process).
Disclaimer: I was on the Core Team for two terms, but this post contains personal opinions that may not reflect the opinions of the FreeBSD Project or the FreeBSD Foundation.
Saliva causes cancer, but only if swallowed in small amounts over a long period of time. -- George Carlin