Google abandons work to move Assistant smart speakers to Fuchsia
9to5google.com
9to5google.com
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.
Or, perhaps, they simply changed their minimum security standards and had to raise requirements as a result.
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.
https://github.com/BLAKE3-team/BLAKE3
If you need a non cryptographic hash, the xxhash family is crazy fast.
With that said, if the hardware cannot what is required, and SoM chips are required, then... Maybe better hardware should be used.
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.
A device with a microphone and network connection? You don't think people would be excited to hack that?
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.
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.
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.
if (launch) {
do_launch();
}
else {
printf("this is just a test...\n");
}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)?
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.
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.)
...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).
- 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....
"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?
On top of all the sibling comments, Redox (https://www.redox-os.org/) & TempleOS (https://en.wikipedia.org/wiki/TempleOS)
Why do you post such vague claims that are not even correct?
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.
The better metric would be how many people does Apple have working on Darwin/iOS/MacOS/WatchOS/iPadOS/VisionOS in total.
why don't linux use vDSO for more things?
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.
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.
It's a people retention project to stop ex-important hires from getting poached.
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.
The 400 number is likely including product owners, business analyst, designers, etc into those numbers not strictly being SWEs (happy to be proven wrong).
(/s)
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.
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).
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.
To keep engineers that would otherwise leave Google for competitors engaged.
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/
[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".
> 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...
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.
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.
Apple is legendary for not being first to adopt or invent technologies (outside some exceptions).
So they decided to build a bespoke OS that would take a decade to build and would require bespoke work from those devs anyway?
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.
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.
See https://nypost.com/2023/07/21/leaked-google-pay-data-reveals...
L8+ would be more obviously.
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.
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.
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.
(Qubes, OTOH, is interesting; I see it as one possible path to the future)
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).
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.
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.
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".
Sure the problem cannot escape the sandbox, but in the end i'm more concerned with my data in the sandbox.
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.
So it's either AppImage/Flatpak/etc or it's building a package per distro.
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.
I'd be interested to hear your definition of "secure", and why OpenBSD doesn't qualify.
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/)
Functional programming, micro kernels, RISC (or, depending on the decade, CISC), cryptocurrency, etc.
Surely some companies have ADHD.
When did Google get so boring?
♪ 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. ♫
> 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
BigQuery, Bigtable.
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.
What next, a HTTP server named Route 80 (or Route 443)?
https://www.androidpolice.com/google-shutting-down-assistant...
For HN it seems boring, but for normies it's simply descriptive.
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 :-)
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.
Or do they just game google and will spend years doing nothing
Fuchsia had great potential but Google being Google.