Google abandons work to move Assistant smart speakers to Fuchsia(9to5google.com)
9to5google.com
Google abandons work to move Assistant smart speakers to Fuchsia
https://9to5google.com/2023/07/25/google-abandons-assistant-speakers-fuchsia/
209 comments
Why wouldn't they catch this before they started work on porting this device to Fuchsia? Why isn't this a problem with the existing OS (Android? ChromeOS?)?
Perhaps they didn’t think the impact was going to be as bad as it was and it turned out it just wasn’t possible to meet their standards as they had hoped w/o requiring crypto hardware.
Or, perhaps, they simply changed their minimum security standards and had to raise requirements as a result.
Or, perhaps, they simply changed their minimum security standards and had to raise requirements as a result.
Security people very often underestimate the performance impact of encryption (especially on embedded devices), so the former would not be surprising to me. Without acceleration, AES hurts and is incredibly hard to implement without opening up side-channel attacks. SHA is also very slow without acceleration. Both have simple, more modern alternatives that are a lot faster on embedded (ChaCha and Blake2 respectively).
Of course, they are also often unwilling to compromise on their chosen security practices to adapt to the situation, even if that just means switching to lightweight/embedded-friendly cryptography algorithms with similar security levels.
Of course, they are also often unwilling to compromise on their chosen security practices to adapt to the situation, even if that just means switching to lightweight/embedded-friendly cryptography algorithms with similar security levels.
Fyi, blake3 was released in 2019 and should probably be used over blake2 unless you have some strong reason not to. It's basically a reimplementation of blake2 with performance tweaks.
https://github.com/BLAKE3-team/BLAKE3
If you need a non cryptographic hash, the xxhash family is crazy fast.
https://github.com/Cyan4973/xxHash
https://github.com/BLAKE3-team/BLAKE3
If you need a non cryptographic hash, the xxhash family is crazy fast.
https://github.com/Cyan4973/xxHash
That reason could well be that the hardware doesn't support it, or that it is too slow.
With that said, if the hardware cannot what is required, and SoM chips are required, then... Maybe better hardware should be used.
With that said, if the hardware cannot what is required, and SoM chips are required, then... Maybe better hardware should be used.
Cannot upvote enough.
This decision reeks of DJB-hating. A lot of NIST types really hate the fact that there are now first-class hashes and symmetric ciphers that perform well without crypto-specific accelerators. This makes bugdooring a lot harder. And then the same guy went and published a curve (Ed25519) whose implementation is nearly impossible to fuck up in ways that leak your secrets.
Lesson to be learned: don't piss off supergenius mathematicians.
This decision reeks of DJB-hating. A lot of NIST types really hate the fact that there are now first-class hashes and symmetric ciphers that perform well without crypto-specific accelerators. This makes bugdooring a lot harder. And then the same guy went and published a curve (Ed25519) whose implementation is nearly impossible to fuck up in ways that leak your secrets.
Lesson to be learned: don't piss off supergenius mathematicians.
Blake vs. Nist is irrelevant to the performance debate, because no matter what you do, they're both going to go approximately the same speed. The debate is why hardcore 256+ bit crypto is needed at all by the operating system primitives on a simple device living in my home, when doing that goes literally 30x slower than using something like crc32 or xxhash. Not to mention that if you're pushing for hard crypto merkle tree stuff, you'd be a fool to do it without things like ecc ram too. Since cosmic rays will blow up your data structures. So you're not just making embedded go slow. You're making it less reliable too. Just to wield ironclad remote control of people's personal possessions.
> The debate is why hardcore 256+ bit crypto is needed at all by the operating system primitives on a simple device living in my home
A device with a microphone and network connection? You don't think people would be excited to hack that?
A device with a microphone and network connection? You don't think people would be excited to hack that?
Is the extra 100 bits of security on your cryptography standard what's actually going to stop them?
In reality, most hacks are stopped by stupid stuff, like closing down ports and proper key management hygiene, not by using completely-brute-force-proof encryption standards. I'll make you a deal: do everything else on that compute-limited embedded device to a practically-uncrackable standard, then you can upgrade to 256 bit crypto. Some devices get there, but no consumer electronics.
Encrypting the filesystem on that specific device is also completely irrelevant to my security as a user - it has more to do with Google protecting itself from copies and users being able to add features.
In reality, most hacks are stopped by stupid stuff, like closing down ports and proper key management hygiene, not by using completely-brute-force-proof encryption standards. I'll make you a deal: do everything else on that compute-limited embedded device to a practically-uncrackable standard, then you can upgrade to 256 bit crypto. Some devices get there, but no consumer electronics.
Encrypting the filesystem on that specific device is also completely irrelevant to my security as a user - it has more to do with Google protecting itself from copies and users being able to add features.
Third parties who want to exploit the relationship between Google and its users are certainly not users. I don't think it's productive to question their intentions. The better question to be asking here is how or why we allowed our homes to become yet another front in the war between Google and its adversaries. Their business model doesn't jive with third amendment culture. I reject any world in which guests within my home have a legitimate need for their own military grade encryption. That is not the future I'm rooting for.
I would be just as concerned - if not more - about Google having access to such a device as I am about some random hacker.
Someone who feels comfortable letting a tech company control a microphone in their home (and by proxy all the agencies that company is obligated by law to serve) probably isn't too concerned about the local neighborhood prankster getting in on the action too. I think the great fear they have is that someone will come along and install a daemon on that speaker which charges them rent.
> Not to mention that if you're pushing for hard crypto merkle tree stuff, you'd be a fool to do it without things like ecc ram too. Since cosmic rays will blow up your data structures. So you're not just making embedded go slow. You're making it less reliable too. Just to wield ironclad remote control of people's personal possessions.
Can you give me an example of how a bit-flip would blow up a cryptographic merkle tree, but not blow up a non-cryptographic file system?
Can you give me an example of how a bit-flip would blow up a cryptographic merkle tree, but not blow up a non-cryptographic file system?
> Can you give me an example of how a bit-flip would blow up a cryptographic merkle tree, but not blow up a non-cryptographic file system?
Any bit changes anywhere in the merkle tree immediately destroy its ability to self-verify because the integrity is ruined. Basically the entire tree is dead because you can't add new nodes.
Non-cryptographic file systems? A bit-flip changes 1-bit in an isolated place. That one place is ruined but can be easily recovered with checksums or strategies like RAID parity. Detection is harder, though.
Either can be recovered at the block level, though.
I use merkel trees as a solution for a project at work and it has brittleness issues related to data integrity and we have to solution specifically around it.
Any bit changes anywhere in the merkle tree immediately destroy its ability to self-verify because the integrity is ruined. Basically the entire tree is dead because you can't add new nodes.
Non-cryptographic file systems? A bit-flip changes 1-bit in an isolated place. That one place is ruined but can be easily recovered with checksums or strategies like RAID parity. Detection is harder, though.
Either can be recovered at the block level, though.
I use merkel trees as a solution for a project at work and it has brittleness issues related to data integrity and we have to solution specifically around it.
Turns out most bit flips in non-crypto systems simply have no effect.
A bitflip in an error handling path of a binary, where that error never happens - no user impact.
A bitflip in a bitmap image buffer - user doesn't notice one miscoloured pixel for 1 frame in an animation.
A bitflip in a config datastructure changing 0x00000001 to 0x00400001 - no impact because the whole number is treated as boolean anyway.
A bitflip in an error handling path of a binary, where that error never happens - no user impact.
A bitflip in a bitmap image buffer - user doesn't notice one miscoloured pixel for 1 frame in an animation.
A bitflip in a config datastructure changing 0x00000001 to 0x00400001 - no impact because the whole number is treated as boolean anyway.
[deleted]
Even Raspberry Pi (all of them!) doesn't have AES accelerated instructions.
That’s not a big deal on a multi-core 1ghz processor. Much bigger deal on a single core 200mhz microcontroller that doesn’t have branch prediction or any of those fun optimizations.
I know you're pointing at the general class of hardware performance enhancements including branch prediction, hardware prefetching, superscaler execution, pipelining, etc. But out of all of them, if you get a speedup for any advanced branch prediction beyond just always assuming branches are taken then I'd be very worried your cryptographic algorithm is broken.
> Why wouldn't they catch this before they started work on porting this device to Fuchsia?
Perhaps because the CPU was erroneously marked as supporting those instructions?
> Why isn't this a problem with the existing OS (Android? ChromeOS?)?
I'm not very informed here, but I think the existing OS doesn't do (1) or (2)?
Perhaps because the CPU was erroneously marked as supporting those instructions?
> Why isn't this a problem with the existing OS (Android? ChromeOS?)?
I'm not very informed here, but I think the existing OS doesn't do (1) or (2)?
Where did amlogic advertise that their smart speaker SoC had the crypto extensions?
This is just speculation that they didn't catch this before.
Maybe they weren't yet decided on lowering their security stance for these specific devices to one similar to the existing OS or skipping these devices. Maybe management was pushing for them to find a solution either way. We can speculate in a lot of different ways.
Maybe they weren't yet decided on lowering their security stance for these specific devices to one similar to the existing OS or skipping these devices. Maybe management was pushing for them to find a solution either way. We can speculate in a lot of different ways.
> For protecting mutable storage, both reads and writes go through AES-XTS, either in zxcrypt or fxfs-crypt.
Fuschia uses block-based disk encryption? I think iOS had more secure file-based encryption in 2010.
(It looks like fxfs-crypt has better options than AES-XTS block encryption though.)
Fuschia uses block-based disk encryption? I think iOS had more secure file-based encryption in 2010.
(It looks like fxfs-crypt has better options than AES-XTS block encryption though.)
>the Fuchsia team’s approximately 400 members
...what? There were FOUR HUNDRED people working on this thing at G? Quite literally the opposite of the anecdote from the "Androids" book where the Sony (?) execs were confused when the Danger, Inc guys told them Brian Swetland wrote all the code for the T-mobile Sidekick by himself (whereas Sony (?) had teams and teams of people for the same stuff in their offerings).
...what? There were FOUR HUNDRED people working on this thing at G? Quite literally the opposite of the anecdote from the "Androids" book where the Sony (?) execs were confused when the Danger, Inc guys told them Brian Swetland wrote all the code for the T-mobile Sidekick by himself (whereas Sony (?) had teams and teams of people for the same stuff in their offerings).
The project seemed super bloated. I remember thay had at least one person who seemed to be working full time on a clone of vim which iirc was considered part of the OS.
You’re referring to Raph Levien’s work on Xi [0]. Not really just a vim clone. In Fuchsia, iirc, it would have been the basis of all text editing services. If nothing else, it seems to have popularized rope data structures [1] for newer text editors.
[0]: https://github.com/xi-editor/xi-editor
[1]: https://xi-editor.io/docs/rope_science_00.html
[0]: https://github.com/xi-editor/xi-editor
[1]: https://xi-editor.io/docs/rope_science_00.html
No doubt the project generated some interesting research and was pushing the boundaries, but its an explanation as to how a smart speaker OS could take 400 developers.
Fuchsia was not meant for just embedded devices. I recall there being a sentence in an old description (which I can no longer find mention of) which explicitly called out PCs and smartphones as targets. That’s likely still the ambition.
Those who think fucsia is just a smart speaker OS does not understand the full picture. It's research on a future OS which can run anywhere
The full picture is apparently that after years of full time work by 400-person team Fuchsia is more like "nothing OS" instead of "a smart speaker OS"...
It can run on few devices like
- Acer Switch Alpha 12 - Intel NUC - Google Pixelbook
Its build by Google so im not sure it will get mainstream or just killed. But calling it "nothing OS" is big understatement, When was the last time a new OS from scratch was created? or if we comparing it to linux/Windows/Mac Im sure a lot people work on these
https://fuchsia.googlesource.com/docs/+/refs/changes/56/1013....
- Acer Switch Alpha 12 - Intel NUC - Google Pixelbook
Its build by Google so im not sure it will get mainstream or just killed. But calling it "nothing OS" is big understatement, When was the last time a new OS from scratch was created? or if we comparing it to linux/Windows/Mac Im sure a lot people work on these
https://fuchsia.googlesource.com/docs/+/refs/changes/56/1013....
There are college classes where you write an OS from scratch in a semester. The basics of a modern OS are not difficult. The vast majority of the effort in any OS is all the different hardware you need to support.
If we're talking about commercial operating systems then Windows NT comes to mind. Here's what they say:
"In 1988, when the project first began, the team comprised about 20 engineers. By the time the first version of Windows NT shipped five years later, the team had expanded to about 150 engineers as it battled constraints and tradeoffs."
https://news.microsoft.com/features/the-engineers-engineer-c...
But I think comparing these team sizes is not very meaningful without at least a cursory look at what is part of the project and what isn't. Is it just the kernel? Does it include an entire graphics pipeline, a UI toolkit, a network stack, device drivers?
"In 1988, when the project first began, the team comprised about 20 engineers. By the time the first version of Windows NT shipped five years later, the team had expanded to about 150 engineers as it battled constraints and tradeoffs."
https://news.microsoft.com/features/the-engineers-engineer-c...
But I think comparing these team sizes is not very meaningful without at least a cursory look at what is part of the project and what isn't. Is it just the kernel? Does it include an entire graphics pipeline, a UI toolkit, a network stack, device drivers?
Serenity OS : by 1 person
https://serenityos.org/
> When was the last time a new OS from scratch was created?
On top of all the sibling comments, Redox (https://www.redox-os.org/) & TempleOS (https://en.wikipedia.org/wiki/TempleOS)
On top of all the sibling comments, Redox (https://www.redox-os.org/) & TempleOS (https://en.wikipedia.org/wiki/TempleOS)
He probably meant "usable OS fit for mass market adoption". Of course one person can develop a bare bones OS, but this will be missing so many things compared to established systems, while providing too few advantages, that any wide adoption is impossible. Even Microsoft, with well over a thousand (IIRC) Windows developers, had to scale back their Longhorn plans substantially.
This story’s carrying a beautiful irony about tech giants that seems to be lost on FAANG‘s entirely.
Was it supposed to be "a smart speaker OS"?
Does not this "nothing OS" already run on Nest Hub?
Why do you post such vague claims that are not even correct?
Why do you post such vague claims that are not even correct?
Except a ca. 2020 smart speaker, apparently.
Perhaps an early sign that the speakers aren't going to be around in the future
That name's DoA for political reasons. Remember the time we tried to name a covid flavor that?
That is a very googley, very stupid thing to do.
This anecdote is a little mangled; Danger was a small startup but the Sidekick wasn't written by one person.
It is an entire OS. Canonical has 500 so the number isn't surprising for a fully original, in development OS.
Does it feel like they have 400 people working on it given the PR? Nope. I'm a little surprised it's still in development.
Does it feel like they have 400 people working on it given the PR? Nope. I'm a little surprised it's still in development.
My guess is that around 75% of Canonical's staffing is sales, sales engineering, customer support, marketing, and misc business functions.
I mean, it probably helps that a large % of the software they ship as part of Ubuntu is upstream, Kernel, Window Manager, Utils etc. etc.
The better metric would be how many people does Apple have working on Darwin/iOS/MacOS/WatchOS/iPadOS/VisionOS in total.
The better metric would be how many people does Apple have working on Darwin/iOS/MacOS/WatchOS/iPadOS/VisionOS in total.
For an OS which is only used on smart speakers is a lot of developers. In the meantime Android receives updates up to 2 years.
My knowledge can and probably is very out of date given how many of Google's projects are publicly realized. But my impression was that Fuschia is a general purpose OS and was planned (like, very long term planned) to eventually become the OS of choice for some Android and Chromebook devices. A project that lofty makes sense to have 400 engineers on.
Canonical with all that people is making a very mediocre desktop experience.
So doesn't seem surprising making something actually good would take a lot more.
Desktop experience is generally not the same people as the OS. Desktop experience is a lot more complex than an OS (both are complex in different ways though)
Somewhat of an ironic anecdote since Brian Swetlands' LinkedIn says he spent 3 years on the Fuchsia team.
Most of that was when the team was pretty tiny. It was fun starting from when the kernel was just beginning to run userspace code. I'm still very happy with how the syscalls turned out. If I did it again, I'd stick with a (small) monolithic kernel though -- makes a lot of things simpler.
it's my impression that fuschia syscalls work like linux's vDSO.
why don't linux use vDSO for more things?
why don't linux use vDSO for more things?
vDSO doesn't provide a security boundary. vDSO basically provides a pure-userspace fastpath for syscalls, only making the real syscall if necessary. It's great for low-overhead read-only calls that cache well and that you're always allowed to do, like clock_gettime(2) -- but not much more. You can't implement all syscalls as vDSO; if it's a vDSO the goal is to not make an actual syscall at all.
Fuchsia might use vDSO-style things more as a way to replace the glibc-style syscall stubs, abstracting away the actual syscall ABI? That doesn't remove the actual syscall.
> why don't linux use vDSO for more things?
vDSO is much more complex to manage than traditional syscalls, can't be used for anything except pure read always allowed things, etc.
As for optimizing syscalls, it seems things are moving more toward io_uring and ringbuffers of messages going in/out of the kernel, with very few syscalls made after setup.
Fuchsia might use vDSO-style things more as a way to replace the glibc-style syscall stubs, abstracting away the actual syscall ABI? That doesn't remove the actual syscall.
> why don't linux use vDSO for more things?
vDSO is much more complex to manage than traditional syscalls, can't be used for anything except pure read always allowed things, etc.
As for optimizing syscalls, it seems things are moving more toward io_uring and ringbuffers of messages going in/out of the kernel, with very few syscalls made after setup.
The intent behind the vDSO style interface for syscalls in Fuchsia was primarily to avoid baking specific syscall mechanisms into the ABI, hopefully to allow future changes to the mechanism without breaking binary compatibility -- which was defined as ELF linkage against libzircon.so.
[deleted]
Or, over double the number of engineers on WinNT when it launched...
Wait until you hear how many people work on Android today.
But Fuscia might have tens of thousands of users whereas Android has billions, right?
What does number of users have to do with the amount of components/code and related support an OS needs?
"Need" is a binary concept, that's not how project planning and prioritization work in the real world. There are a lot of things that are not "needed" that are beneficial, and a lot of things that are beneficial that you end up not having resources to implement. So then it is all about tradeoffs.
Software projects can derive massive economies of scale from a large install base, since there is no marginal cost. A larger install base lets you amortize the fixed cost over more users. The more users you have, the more useful but not strictly need optimisations and features you can justify implementing.
Software projects can derive massive economies of scale from a large install base, since there is no marginal cost. A larger install base lets you amortize the fixed cost over more users. The more users you have, the more useful but not strictly need optimisations and features you can justify implementing.
> There were FOUR HUNDRED people working on this thing at G?
It's a people retention project to stop ex-important hires from getting poached.
It's a people retention project to stop ex-important hires from getting poached.
That's what I've heard too: some high-up engineer is bored but Google wants to keep their talent on staff, so they hand them a shiny, exciting computer science playground with grand aspirations.
And that 400# is after a round of layoffs which apparently hit Fuchsia fairly hard.
When I was in the home/hardware PA, they seemed to have unlimited headcount. But still couldn't seem to actually ship anything.
9 women can't make a baby in 1 month, and all that.
When I was in the home/hardware PA, they seemed to have unlimited headcount. But still couldn't seem to actually ship anything.
9 women can't make a baby in 1 month, and all that.
These numbers often get inflated because the people in change count every part-time worker as a full team member (bigger headcount = bigger promotion!). But it's still a crazy number. At every level everyone is incentivized to bloat the headcount as much as possible.
I don't think part time work in SWE is common at all. Especially at Google.
The 400 number is likely including product owners, business analyst, designers, etc into those numbers not strictly being SWEs (happy to be proven wrong).
The 400 number is likely including product owners, business analyst, designers, etc into those numbers not strictly being SWEs (happy to be proven wrong).
For a comparison, initial Windows NT 3.1 had 340 devs/testers, NT 3.5 had 530 devs/testers. No idea why product/program managers aren't listed. There must have been some.
See https://danluu.com/microsoft-culture/
See https://danluu.com/microsoft-culture/
Does anybody know how MS does Windows development these days? Just curious…
I hope someone at Microsoft does, though their attention seems to be elsewhere.
I'm guessing around 800: 3 devs for the OS core, the rest for the adware and spyware.
(/s)
(/s)
That's good to know, honestly surprised to read that NT had that many. I'd figured early versions wouldn't require that many people. Now knowing the Fuchsia numbers, I don't know if that's a signal to how productive the team is or if they dwindling resources.
And also for comparison, Windows NT 3.1 had to run and interact with a much broader zoo of devices.
That's not what I mean. At Google you can be 50% on one project and 50% on another.
You can but it’s not common either (across orgs).
It’s basically “I caught a fish this big” story where each telling increases the size
Off topic but... What's the future of Fuchsia?
Years ago it seemed like it would replace Android and ChromeOS but time passes and we haven't seen any results other than the Nest hub running it.
Years ago it seemed like it would replace Android and ChromeOS but time passes and we haven't seen any results other than the Nest hub running it.
I've been assuming for several years now that they will never end up killing either Android or ChromeOS in favor of Fuchsia. The reasons aren't technical but business related.
The business reason for this is that this would alienate the OEM ecosystem. The likes of Samsung want less Google influence, not more and they're really invested in Android. Without Samsung on board, Google's choice is letting them take over Android or keep control on their side. It's that simple. There are also various Chinese manufacturers that already cut loose from Google for legal reasons that are running Android forks. Amazon has its own fork. So, Google has their work cut out forcing that ecosystem in the direction of Fuchsia.
With ChromeOS, they have a similar issue. Lots of OEMs and it's actually a relatively successful platform. IMHO they should push to merge the ChromeOS and Android ecosystems more. Fuchsia does not solve a problem any OEM has.
It's Google's big not invented here syndrome. They started doing an OS because they had some technical concerns with Linux. Instead of working with the Linux community to address those concerns, they've been building their own OS for years now. They'll ultimately probably do the easy and obvious thing which is to write off the whole effort. At best a lot of the components (minus the kernel) might find their way into Android/ChromeOS and their UI frameworks (jetpack compose and flutter).
The business reason for this is that this would alienate the OEM ecosystem. The likes of Samsung want less Google influence, not more and they're really invested in Android. Without Samsung on board, Google's choice is letting them take over Android or keep control on their side. It's that simple. There are also various Chinese manufacturers that already cut loose from Google for legal reasons that are running Android forks. Amazon has its own fork. So, Google has their work cut out forcing that ecosystem in the direction of Fuchsia.
With ChromeOS, they have a similar issue. Lots of OEMs and it's actually a relatively successful platform. IMHO they should push to merge the ChromeOS and Android ecosystems more. Fuchsia does not solve a problem any OEM has.
It's Google's big not invented here syndrome. They started doing an OS because they had some technical concerns with Linux. Instead of working with the Linux community to address those concerns, they've been building their own OS for years now. They'll ultimately probably do the easy and obvious thing which is to write off the whole effort. At best a lot of the components (minus the kernel) might find their way into Android/ChromeOS and their UI frameworks (jetpack compose and flutter).
Thanks that makes sense. But why keep investing into Fuchsia? By all accounts it's quite an expensive hobby.
Why indeed. Big companies being rational and efficient are not that common. My guess is that there are some ongoing internal differences of opinion on this that are causing Google to slowly strangle but not quite kill this effort. Clearly the camp that was going to steam roll Fuchsia through as the Android replacement seems to be no longer in charge. At least, I see no signs of that happening any time soon.
It's a weird dynamic that big companies have where different camps are powerful enough to frustrate each other's roadmaps but not powerful enough to outright kill each other. Stronger leadership would be more decisive and act a lot sooner too. Google has no strong leadership is the only conclusion and there are probably more out of control teams like this.
I've seen the same dynamic in Nokia fifteen years ago where different parts of the org tree were fighting over who got to deliver X where X was some important feature. The most extreme version of this that I saw was when our group in Nokia Research was working on a feature related to coupons and vouchers and started talking to different business units to see if there was any interest in this. We started making an inventory of different teams working on similar things. We stopped counting at seven. Most of these teams did not know of each other or if they did were working on it because those other teams were in the wrong part of the org tree and it was just easier for them to work around each other.
I bet there's a lot of that happening in Google right now. At least they look similarly big and bloated to me.
It's a weird dynamic that big companies have where different camps are powerful enough to frustrate each other's roadmaps but not powerful enough to outright kill each other. Stronger leadership would be more decisive and act a lot sooner too. Google has no strong leadership is the only conclusion and there are probably more out of control teams like this.
I've seen the same dynamic in Nokia fifteen years ago where different parts of the org tree were fighting over who got to deliver X where X was some important feature. The most extreme version of this that I saw was when our group in Nokia Research was working on a feature related to coupons and vouchers and started talking to different business units to see if there was any interest in this. We started making an inventory of different teams working on similar things. We stopped counting at seven. Most of these teams did not know of each other or if they did were working on it because those other teams were in the wrong part of the org tree and it was just easier for them to work around each other.
I bet there's a lot of that happening in Google right now. At least they look similarly big and bloated to me.
I don't think it was ever meant to replace Android/ChromeOS, but rather the layer below (linux).
IIRC it does have a GUI and application layers. There was a video a couple of years ago of a user logging in and launching Chrome.
These are technically different projects. The kernel is named Zircon and the operating system is Fushia. The user interface and applications are written in Flutter which uses Dart.
> Off topic but... What's the future of Fuchsia?
To keep engineers that would otherwise leave Google for competitors engaged.
To keep engineers that would otherwise leave Google for competitors engaged.
This was because the code was being worked on by multiple teams who ended up working on code stored in the following directories:
fuscia
fucsia
fucshia
fuschia
fushia
fuchia
Trying to unravel and integrate all the code has proved to be too daunting a task.
EDIT:
Spellings taken from https://blog.xkcd.com/2010/05/03/color-survey-results/
fuscia
fucsia
fucshia
fuschia
fushia
fuchia
Trying to unravel and integrate all the code has proved to be too daunting a task.
EDIT:
Spellings taken from https://blog.xkcd.com/2010/05/03/color-survey-results/
The sad thing is I'm not even sure this is a joke
Reminds me of everybody saying "mastadon". Let's just agree, Americans can't spell :P
I've never been able to make sense of why people are having such a hard time spelling Fuchsia correctly[0] but this still made chuckle. :)
[0]: Just think of a popular four-letter word starting with "fuc". Replace the last letter with an "h". (The "ch" in German "Fuchsia" is pronounced exactly how that four-letter word ends.) Then append "-sia".
[0]: Just think of a popular four-letter word starting with "fuc". Replace the last letter with an "h". (The "ch" in German "Fuchsia" is pronounced exactly how that four-letter word ends.) Then append "-sia".
Needing a paragraph to describe a mnemonic for remembering how to spell the word is why.
In the context of Google projects, I propose fucks-ya. As in, will screw you over.
I can never remember how to spell or pronounce this word.
It clicked for me when I learned that the plant the colour is named after was itself named after a Dr. Fuchs. So now I remember the name, and tack "-ia" on the end. In German, Fuchs sounds something like "fooks", so it's "fooks-ee-ah".
That is general problem with English's language vowel shift.
Another project designed to get L7-9s promoted at Google. Ambition and the ability to wave hands are all you need. I like cool stuff, like capabilities, as much as the next person, but nobody needs a new OS. Linux will evolve sufficiently anyway. A new OS isn’t compelling for users.
> At that time, Fuchsia was never originally about building a new kernel. It was actually about an observation I made: that the Android team had their own Linux kernel team, and the Chrome OS team had their own Linux kernel team, and there was a desktop version of Linux at Google [Goobuntu and later gLinux], and there was a Linux kernel team in the data centers. They were all separate, and that seems crazy and inefficient.
> The architectures were all different, which meant that outside developers couldn’t actually do work and attack all the platforms Google was offering. You had to do bespoke work.
https://9to5google.com/2022/08/30/fuchsia-director-interview...
> The architectures were all different, which meant that outside developers couldn’t actually do work and attack all the platforms Google was offering. You had to do bespoke work.
https://9to5google.com/2022/08/30/fuchsia-director-interview...
> They were all separate, and that seems crazy and inefficient.
From an organizational-design perspective: That's the whole point.
Decentralization means they can all move more quickly — each team can cater to the needs of its local customers. In moving quickly and solving local problems, they end up repeating some work. That's the price of velocity. Good local leaders should counter-balance this by creating informal forums for idea exchange and cross-pollination.
Sadly, overly-ambitious office-politicians see this happening, flag it as "inefficient," and roll the headcount up into a centralized team. Centralization puts an end to all the local ideas and excitement, instead routing it through a centralized committee that "plans" and "decides" which customers are worthy of how much innovation.
In a way, this is the pendulum of life at a big company. But in another way... this pursuit of "efficiency" sure seems like it explains a lot of why Google moves so slowly.
From an organizational-design perspective: That's the whole point.
Decentralization means they can all move more quickly — each team can cater to the needs of its local customers. In moving quickly and solving local problems, they end up repeating some work. That's the price of velocity. Good local leaders should counter-balance this by creating informal forums for idea exchange and cross-pollination.
Sadly, overly-ambitious office-politicians see this happening, flag it as "inefficient," and roll the headcount up into a centralized team. Centralization puts an end to all the local ideas and excitement, instead routing it through a centralized committee that "plans" and "decides" which customers are worthy of how much innovation.
In a way, this is the pendulum of life at a big company. But in another way... this pursuit of "efficiency" sure seems like it explains a lot of why Google moves so slowly.
>From an organizational-design perspective: That's the whole point.
There's more to it than that. Unlike most other projects, these kernel teams were working on the Linux kernel, which is an open-source project not under the control of any one corporation. These teams were simply maintaining their own kernel forks (which are undoubtedly optimized for their use-cases) and developing features/patches which they might try to submit upstream. And a lot of the work was undoubtedly device drivers for the particular hardware they used. Since they were working on very different projects (datacenters, Android, ChromeOS), with very different hardware, there was probably almost no overlap going on here.
There's more to it than that. Unlike most other projects, these kernel teams were working on the Linux kernel, which is an open-source project not under the control of any one corporation. These teams were simply maintaining their own kernel forks (which are undoubtedly optimized for their use-cases) and developing features/patches which they might try to submit upstream. And a lot of the work was undoubtedly device drivers for the particular hardware they used. Since they were working on very different projects (datacenters, Android, ChromeOS), with very different hardware, there was probably almost no overlap going on here.
The centralized organization you're describing is called a "functional organization" and is how Apple works, which is not typically described as slow.
Apple is absolutely incredibly slow by any standard.
Not impressed by shipping an OS every year?
The cadence of cutting a OTA from a repo isn't really correlate with speed of delivery and innovation.
Apple is legendary for not being first to adopt or invent technologies (outside some exceptions).
Apple is legendary for not being first to adopt or invent technologies (outside some exceptions).
That's all well and good... when the teams aren't all beholden to the velocity of the linux kernel.
> The architectures were all different, which meant that outside developers couldn’t actually do work and attack all the platforms Google was offering. You had to do bespoke work.
So they decided to build a bespoke OS that would take a decade to build and would require bespoke work from those devs anyway?
So they decided to build a bespoke OS that would take a decade to build and would require bespoke work from those devs anyway?
>A new OS isn’t compelling for users.
Yes it is. Not directly, of course, nobody cares about the OS. But in case of Android distributions, if they could exchange the Linux layer to Fuchsia, while keeping most of the Android userland in terms of UX, and deliver gains such as increased battery life, then suddenly people would be interested. It would be similar to Apple's development and adoption of ARM architecture.
Yes it is. Not directly, of course, nobody cares about the OS. But in case of Android distributions, if they could exchange the Linux layer to Fuchsia, while keeping most of the Android userland in terms of UX, and deliver gains such as increased battery life, then suddenly people would be interested. It would be similar to Apple's development and adoption of ARM architecture.
In this case they could not.
Agree on the first point, L7+'s are often looking for technical ways to transform the business.
Fuchsia and Dart are still big technologies though touching many other projects, so back-tracking on speakers doesn't quite mean fuchsia is a failure/not necessary.
Fuchsia and Dart are still big technologies though touching many other projects, so back-tracking on speakers doesn't quite mean fuchsia is a failure/not necessary.
Data point:L7 annual salary and bonus are $718k and $603k if the data from this article is accurate.
See https://nypost.com/2023/07/21/leaked-google-pay-data-reveals...
L8+ would be more obviously.
See https://nypost.com/2023/07/21/leaked-google-pay-data-reveals...
L8+ would be more obviously.
Based on the large discrepancy with levels.fyi, I'm betting that person either put down their total comp as salary, or they are a very specialized researcher in an extremely hot area (probably AI).
Agree with this. 700k base does not make sense.
Look at the TC numbers on levels: https://www.levels.fyi/companies/google/salaries/software-en...
The total is actually somewhat comparable to what's reported, but the breakdown from the article seems completely wrong.
Look at the TC numbers on levels: https://www.levels.fyi/companies/google/salaries/software-en...
The total is actually somewhat comparable to what's reported, but the breakdown from the article seems completely wrong.
>A new OS isn’t compelling for users.
I'm a user (and in particular a Linux user) and a new OS which has Chromium ported to it is compelling to me because I expect that Linux will never evolve to be secure enough.
I'm a user (and in particular a Linux user) and a new OS which has Chromium ported to it is compelling to me because I expect that Linux will never evolve to be secure enough.
Linux security (another desktop user here) is... fine? You can get pretty great security on it, if you want, by running Wayland instead of X11 and running all your apps via Flatpak or Snap (assuming you only choose apps that aren't intentionally allowed to break out of their sandbox).
And none of these things require Linux (the kernel) to change all that much. Hell, Android has decent security by running all apps with different user IDs and restricting the parts of the filesystem it can access.
Obviously your default Linux desktop install doesn't work like this, but some motivated individuals could do it, if they wanted. Writing an entire new OS is hardly necessary. Google just wanted something it could control, when it comes to Fuchsia. And they're the last company that I would trust to build an OS that doesn't end up being user-hostile.
And none of these things require Linux (the kernel) to change all that much. Hell, Android has decent security by running all apps with different user IDs and restricting the parts of the filesystem it can access.
Obviously your default Linux desktop install doesn't work like this, but some motivated individuals could do it, if they wanted. Writing an entire new OS is hardly necessary. Google just wanted something it could control, when it comes to Fuchsia. And they're the last company that I would trust to build an OS that doesn't end up being user-hostile.
Flatpak and Snap are an inherently bad model; they break stuff and fail to secure other stuff, and their design means this will always be a game of whack-a-mole. And even if you were to Flatpak/Snap-ify all your apps (really? Would you run e.g. Bash that way?), you'd still be left having to run a bloated kernel to support a bunch of cruft that you weren't using. Starting from scratch with a clean interface seems like a better approach.
(Qubes, OTOH, is interesting; I see it as one possible path to the future)
(Qubes, OTOH, is interesting; I see it as one possible path to the future)
> you'd still be left having to run a bloated kernel to support a bunch of cruft that you weren't using
Would you? Linux is, in fact, quite modular, and perfectly happy to not load things until asked to (often as a result of hardware being discovered or plugged in).
Would you? Linux is, in fact, quite modular, and perfectly happy to not load things until asked to (often as a result of hardware being discovered or plugged in).
Why are they a bad model?
Sandboxing is a much better approach to security than the Unix permissions model, which is nearly obsolete.
Sandboxing is a much better approach to security than the Unix permissions model, which is nearly obsolete.
> Sandboxing is a much better approach to security than the Unix permissions model, which is nearly obsolete.
That's an incredibly low bar. They're a bad model because the Unix API surface is huge and underspecified; there are a zillion different ways apps could potentially interact with each other. Some of them are giant security holes. Some of them are vital to some obscure corner of app functionality. Most of them are both.
That's an incredibly low bar. They're a bad model because the Unix API surface is huge and underspecified; there are a zillion different ways apps could potentially interact with each other. Some of them are giant security holes. Some of them are vital to some obscure corner of app functionality. Most of them are both.
I'm not talking about syscalls, but that in modern times everything of value is in your account, and computers are rarely shared.
So when you download a game your threat model isn't that it might want to mess with the kernel, but that it's going to steal all your data from your browser cache. Dealing with that requires some sort of sandboxing.
So when you download a game your threat model isn't that it might want to mess with the kernel, but that it's going to steal all your data from your browser cache. Dealing with that requires some sort of sandboxing.
> I'm not talking about syscalls, but that in modern times everything of value is in your account, and computers are rarely shared.
Huh? No-one is advocating using user accounts for security.
> So when you download a game your threat model isn't that it might want to mess with the kernel, but that it's going to steal all your data from your browser cache.
Why do you think this contradicts anything I said? And what mechanism do you think it's going to use to do that? Maybe not syscalls in the narrow sense, but certainly via one of the "zillion different ways apps could potentially interact with each other".
> Dealing with that requires some sort of sandboxing.
Is this the "something must be done" fallacy? "We need some kind of sandbox, snap/flatpak are some kind of sandbox, therefore we need snap/flatpak".
Huh? No-one is advocating using user accounts for security.
> So when you download a game your threat model isn't that it might want to mess with the kernel, but that it's going to steal all your data from your browser cache.
Why do you think this contradicts anything I said? And what mechanism do you think it's going to use to do that? Maybe not syscalls in the narrow sense, but certainly via one of the "zillion different ways apps could potentially interact with each other".
> Dealing with that requires some sort of sandboxing.
Is this the "something must be done" fallacy? "We need some kind of sandbox, snap/flatpak are some kind of sandbox, therefore we need snap/flatpak".
There is more to them than sandboxes though. They also package everything, if there is a security problem in a common library you are vulnerable in each sandbox until it is updated so updates become a much larger hole.
Sure the problem cannot escape the sandbox, but in the end i'm more concerned with my data in the sandbox.
Sure the problem cannot escape the sandbox, but in the end i'm more concerned with my data in the sandbox.
It’s not necessary to include every library inside the package. Flatpak packages use runtime packages like Gnome, Freedesktop and KDE. Those runtime packages already include libraries like OpenSSL,libpng, libjpeg, gtk, qt and are updated very frequently to fix the bugs in those libraries.
Yeah, but that's because Linux doesn't have a stable ABI, and really everyone does that these days.
Both Mac and Windows just dump a whole bunch of libraries into the install directory.
I think on Flatpak you can update the base platform package and have the applications use that automatically, so there's that.
Both Mac and Windows just dump a whole bunch of libraries into the install directory.
I think on Flatpak you can update the base platform package and have the applications use that automatically, so there's that.
Linux has a stable ABI for user land programs. For drivers the ABI is not stable, but drivers are not sandboxed in linux.
I didn't mean just the kernel, but the userspace libraries as well. So GNU/Linux or whatever you want to call that.
So it's either AppImage/Flatpak/etc or it's building a package per distro.
So it's either AppImage/Flatpak/etc or it's building a package per distro.
I think the world is destined to move to a microkernel OS eventually. I am just mad that there is not national level funding of sel4, which is audited and available today.
You can have secure monolith and insecure microkernel. It’s not a silver bullet, and security nowadays is really complicated.
> You can have secure monolith and insecure microkernel.
Superficially, that claim sounds reasonable, but I'd have a hard time substantiating it. There is exactly one secure microkernel ready for production use today, and zero secure monolithic kernels. There's not even a "here's how one could secure a monolithic kernel in principle" whitepaper.
Superficially, that claim sounds reasonable, but I'd have a hard time substantiating it. There is exactly one secure microkernel ready for production use today, and zero secure monolithic kernels. There's not even a "here's how one could secure a monolithic kernel in principle" whitepaper.
> There is exactly one secure microkernel ready for production use today, and zero secure monolithic kernels.
I'd be interested to hear your definition of "secure", and why OpenBSD doesn't qualify.
I'd be interested to hear your definition of "secure", and why OpenBSD doesn't qualify.
OpenBSD mostly operates on a hobbyist's idea of security, where they just make up attacks to defend against rather than being systematic or actually keeping up with the outside world. (https://isopenbsdsecu.re)
Although professional security people are also rather bad at this and like to eg stack multiple cool-looking mitigations even if they break each other. (https://siguza.github.io/PAN/)
Although professional security people are also rather bad at this and like to eg stack multiple cool-looking mitigations even if they break each other. (https://siguza.github.io/PAN/)
Okay, so what threat model successfully attacks an OpenBSD box and fails on... I assume the one "secure" microkernel is seL4? Since OpenBSD only defends against made up attacks, this should of course be very easy to demonstrate.
It's not "an OpenBSD box" but "an OpenBSD box running a typical amount of third party services".
There are some technologies that are so good they can fix everything, almost as if by magic.
Functional programming, micro kernels, RISC (or, depending on the decade, CISC), cryptocurrency, etc.
Functional programming, micro kernels, RISC (or, depending on the decade, CISC), cryptocurrency, etc.
Microkernels work great for virtualization guests, yet they aren't taking off in this kind of low friction environment. I don't think there's a killer app for them that justifies leaving behind Linux.
Android (well, the Pixel anyway) does a great job of isolating processes by using SELinux and seccomp. You can have processes running as root that are still completely isolated away from most of the system.
Secure for who, you or Google? What are the privacy implications of Google owning the entire stack?
Secure for whoever has the keys to the device.
Even if what you say makes sense, there are maybe around three people in the world who are interested in a new OS because of this reason, which is not really the "users" that people talk about.
Ha ? You think an OS which exfiltrates all your data is "secure" ?
If people followed this logic there would be no Linux to “evolve sufficiently”
Huh? Linux solved a real problem, at the time there really wasn't an alternative (386BSD was under a lawsuit cloud, GNU didn't run, Minix didn't perform well enough for daily driver use and was opposed to the kind of changes that would be needed to fix that).
Someone must have written somewhere about the concept of the corporate concentration span.
Surely some companies have ADHD.
Surely some companies have ADHD.
Off topic, but I hate the name Assistant. It is the most uninspired name imaginable. There's no personality to it and no fun.
When did Google get so boring?
When did Google get so boring?
Hasn't Google always been pretty boring? GMail, Reader, Docs, Sheets, Drive, etc. aren't exactly inspired names either.
I’ve mentioned this before, but this is actually a godsend feature in their named product offerings in GCP. Amazon’s product names make no sense and it’s impossible to keep track of everything if you aren’t working with it all the time. Conversely, GCP’s product name is literally just what the product is. Nothing more. Google Cloud DNS vs Route 53. Amazon RDS vs Google CloudSQL. Cloud Pub/Sub vs SNS/SQS. Etc etc
♪ Rekognition, Fraud Detector's cool,
Wavelength, Blockchain, Well-Architected Tool.
Though half of 'em start with "Amazon", for reasons we can't guess..
These are the major services of AWS. ♫
This is great. This one in particular got me:
> Device Farm - Should have been called Amazon Drawer of Old Android Devices
And another one
> Mobile Analytics - Should have been called Spot on Name, Amazon Product Managers take note
> Device Farm - Should have been called Amazon Drawer of Old Android Devices
And another one
> Mobile Analytics - Should have been called Spot on Name, Amazon Product Managers take note
Route 53 is arguably one of the more obviously named AWS offerings.
> Route 53 is arguably one of the more obviously named AWS offerings.
Er, then please humor my ignorance: What is it named for? Because the name means nothing to me, and even some light searching just turns up an actual highway and I still don't see what it would have to do with DNS.
Edit: Okay, I do feel a bit foolish for forgetting that DNS is traditionally port 53, so now half of the name makes sense to me. The other half still seems like a more or less random choice to me.
Er, then please humor my ignorance: What is it named for? Because the name means nothing to me, and even some light searching just turns up an actual highway and I still don't see what it would have to do with DNS.
Edit: Okay, I do feel a bit foolish for forgetting that DNS is traditionally port 53, so now half of the name makes sense to me. The other half still seems like a more or less random choice to me.
It's a play on "Route 66":
https://en.wikipedia.org/wiki/U.S._Route_66
https://en.wikipedia.org/wiki/U.S._Route_66
[deleted]
Route 53 sounds like a service to forward DNS requests to the right DNS server (misapplying L2 naming of "route" for what sounds like proxying). Routing DNS does not sound like an authoritative DNS server.
What next, a HTTP server named Route 80 (or Route 443)?
What next, a HTTP server named Route 80 (or Route 443)?
Good point, it’s just really noticeable here because the competition is Alexa, Siri, and Bixby. (RIP Cortana)
Much to the chagrin of people named Alexa, Siri and the handful of people named Bixby.
Maybe they should have picked historical names that no one uses any more, like Hieronymus.
Hey, it's a family name.
Funny enough you can't even extend Google Assistant (except for smart devices) on Google Home devices anymore.
https://www.androidpolice.com/google-shutting-down-assistant...
https://www.androidpolice.com/google-shutting-down-assistant...
It's part of the Google informational branding, which is why you say, "Hey Google" instead of "Hey Alexa" or "Hey Siri".
For HN it seems boring, but for normies it's simply descriptive.
For HN it seems boring, but for normies it's simply descriptive.
In that case can I please have my 1st gen Nest Hub back on the pre-Fuchsia OS please? Ever since the "upgrade" it's been more laggy and requires semi-regular power cycles, as if there's a memory leak somewhere.
When it launched, we shipped it with an HTML/TypeScript based UI. It sold well, and got excellent reviews
So of course a few moments later it was insisted that the whole thing had to be rewritten in Flutter/Dart. Because reasons.
But of course Flutter didn't exist for the platform. So that had to get written too.
Which also meant somehow writing things like screen reader, and other accessibility features, which are services provided normally by the OS for other platforms (Android, iOS) that Flutter ran on. And which we had just finished porting to Cast OS from Chrome OS.
And of course they insisted that because, I dunno, Flutter was native or something it would just be faster than that dodgy HTML stuff. Nevermind that thousands and thousands of engineering hours have gone into the Chromium graphics stack, and my coworkers had made it perform very well on the little old outdated cheap SoC in the thing...
And while this was all happening, simultaneously people were working off in Fuchsia land with seemingly unlimited headcount, hoisting the whole thing into Fuchsia. And claiming they'd be done any minute now. But then, of course, late for multiple years.
All along the Cast OS team was deprived of product roadmap or headcount, to maintain the existing thing... which we had shipped into customers homes successfully and gotten excellent reviews.
Anyways, I wasn't central to this or anything, most ephemeral. But ephemerally flabbergated and frustrated.
Happy to hear you enjoyed the earlier experience :-)
So of course a few moments later it was insisted that the whole thing had to be rewritten in Flutter/Dart. Because reasons.
But of course Flutter didn't exist for the platform. So that had to get written too.
Which also meant somehow writing things like screen reader, and other accessibility features, which are services provided normally by the OS for other platforms (Android, iOS) that Flutter ran on. And which we had just finished porting to Cast OS from Chrome OS.
And of course they insisted that because, I dunno, Flutter was native or something it would just be faster than that dodgy HTML stuff. Nevermind that thousands and thousands of engineering hours have gone into the Chromium graphics stack, and my coworkers had made it perform very well on the little old outdated cheap SoC in the thing...
And while this was all happening, simultaneously people were working off in Fuchsia land with seemingly unlimited headcount, hoisting the whole thing into Fuchsia. And claiming they'd be done any minute now. But then, of course, late for multiple years.
All along the Cast OS team was deprived of product roadmap or headcount, to maintain the existing thing... which we had shipped into customers homes successfully and gotten excellent reviews.
Anyways, I wasn't central to this or anything, most ephemeral. But ephemerally flabbergated and frustrated.
Happy to hear you enjoyed the earlier experience :-)
> Importantly, the Nest Hub series of smart displays are entirely unaffected by this change. Those devices will continue to run Fuchsia under the hood and will continue to receive updates as normal.
[deleted]
Is it just me or Fuchsia sounds more and more like vaporware the more I read about it? Did Google never consider that Fuchsia might become to Android what Plan 9 is to Unix?
Here's the story behind Fuchsia told to me by a Google employee:
One day a bunch of senior engineers wanted to quit. Google asked them why and they answered "we're bored." So google asked them "what would you rather work on?" and they replied "write an OS" and so google said "here's more money. do whatever you want."
Fuschia isn't a serious project. It was busy work to keep top employees from leaving for competition. I was also told that no one inside google seems to know or care about Fuchsia. It only ever was used in the smart speaker. And reading through the API and syscall interface its clear no one is serious about writing an real OS.
One day a bunch of senior engineers wanted to quit. Google asked them why and they answered "we're bored." So google asked them "what would you rather work on?" and they replied "write an OS" and so google said "here's more money. do whatever you want."
Fuschia isn't a serious project. It was busy work to keep top employees from leaving for competition. I was also told that no one inside google seems to know or care about Fuchsia. It only ever was used in the smart speaker. And reading through the API and syscall interface its clear no one is serious about writing an real OS.
If those engineers that Google wants to keep are so good, then why they cant deliver anything?
Or do they just game google and will spend years doing nothing
Or do they just game google and will spend years doing nothing
Well just because they were good at one thing doesn't mean they are good at another. I'm sure google was initially confident in their assertion but the current state shows that it is a dead end.
Surprise surprise (not really).
Fuchsia had great potential but Google being Google.
Fuchsia had great potential but Google being Google.
Utter lack of Product Leadership who actually is allowed and able to lead.
So, do we need to add this to https://killedbygoogle.com/ ?
Under Fuchsia, the system wears a headset to operate you!
Is flutter next to be axed?
does this matter at all to customers? i assumed fucscia is just some IP/vendor lock in play but I might just be cynical since i dont know the details
For more context: we have historically required the crypto instructions because
1. We make heavy use of sha256 in blobfs, where such content-hashing is on the critical path of loading all binaries, and we believe that in the absence of hardware acceleration, product owners will likely find that their performance requirements are difficult to attain and may seek to resolve those issues by compromising core security invariants, which we do not wish to encourage
2. For protecting mutable storage, both reads and writes go through AES-XTS, either in zxcrypt or fxfs-crypt. For similar reasons, we want AES instructions to be accelerated, so that protection of user data is not something that we are motivated to compromise for performance reasons.
3. In any product, we expect to do TLS for a variety of purposes (software updates, time sync, communications with servers, etc.), and don't want poor TLS performance to be a reason that people are later motivated to avoid TLS/use weak ciphersuites/etc.
Since we do not want product owners to be motivated to disable fairly fundamental security features of the system, we have endeavored to ensure that the hardware baseline is likely to adequately support performance requirements, including through the requirement of the ARM crypto instructions on such boards.
-- https://fuchsia-review.googlesource.com/c/fuchsia/+/808670?t... marking the relevant CPU as not supporting crypto instructions.