[Ruq]

It sounds like a really bad idea to have all software "components" be resolved, downloaded, and executed from over the internet. Seems like a supply chain/waterhole attack just waiting to happen.

Not to mention it would seem to sign away the devices ability to act autonomously or offline. Of course, with my views of Google, it seems very like them to design everything to constantly rely on them to even function.

Correct me if I'm wrong on any of this.

[fartcannon]

They're claiming its about trusting the code you run. Google, you're the source of the code I don't trust.

[londons_explore]

I like the idea of it being possible. Just because it's a feature doesn't mean you have to use it.

For one thing, I assume such a system would have the ability to pin certain versions/hashes. If I (the user) can pin a set of hashes that are allowed to run, then I don't care where the actual resources are downloaded from.

Alternatively, if I can give a certificate I trust of someone else to give a 'realtime' list, that would also satisfy my needs.

[wittrock]

Hi there, I work on Fuchsia, specifically on our Software Delivery system [1].

You hit on exactly the right point: it's _possible_ to download and run software on demand, but it's also possible (and recommended) for products to turn off that capability if it's not useful or valuable for their use case. We pin packages for the base system itself, as well as lots of configurations of products.

The ability to run code on demand is really valuable for our development flows and quick prototyping: built a new test or experiment? No need to update your device, just try to run it, and it runs!

[1]: https://fuchsia.dev/fuchsia-src/get-started/learn/intro/pack...

[erickt]

I also work on Fuchsia’s Software delivery team.

For some more detail on how we secure downloading components, we implement a concept called verified execution [1]. We establish a chain of trust from:

* a hardware key (on hardware that supports it), which checks the signature of

* the bootloader, which has a key baked into it and verifies that each boot slot has a properly signed vbmeta structure. This vbmeta then contains a hash of the zircon kernel, and the merkle root for the user space system image blob.

* we boot up zircon, which eventually starts up blobfs, our content addressed file system. It then reads the system image from blobfs, and launches Component Manager and Package Cache (which implements a package filesystem on top of blobs).

* package cache gets launched with the system image merkle from vbmeta, which allows us to know which packages are part of the base package set.

* base packages are then launched upon demand.

This establishes a direct line of trust from the hardware key to the base packages.

For over the air updates and ephemerally resolved packages, we use The Update Framework [2] and Omaha [3] for our package repositories. Each entry contains the merkle root for the package metadata, which in turn bakes in the merkle roots for each blob in the packages. We bake in the public keys for TUF and Omaha into our system image. This allows us to indirectly verify from hardware up that we are fetching the correct software.

[1]: https://fuchsia.dev/fuchsia-src/concepts/security/verified_e...

[2]: https://theupdateframework.io/

[3]: https://chromium.googlesource.com/chromium/src.git/+/master/...

[a1369209993]

(At this point it's less "assume good faith" and more "halfheartedly check for the unlikely event that any good faith is present", but...)

How do you insure that the end user is able to replace the hardware key and bootloader with one of their own devising (and generally to tamper with arbitrary parts of system) without a remote vendor/employer/DRM firm being able to prevent or detect it?

[katbyte]

I would tend to agree, unless pinning is enforced/the default.

[turminal]

I think the idea is "ensuring software is always up to date", so no pinning by default.

[metadat]

Until they drop support for your hardware... Then what happens?

[ketralnis]

You have to chuck it in the bin and buy a new one, obviously. That's the state of the startphone world today, if you want to keep up on security updates

[myko]

This is lamentable and I'd love to see longer periods of support for older devices, but I'm not sure what the ideal state is - beyond being able to install your own OS on your device, which will still require some level of support from someone.

What's reasonable - 5 years of support? 10?

[dhodell]

These things work in tandem: the base system is pinned, but can also be easily updated with an OTA. Packages existing outside that set are resolved on-demand, and are thus updated when components in a package are run after a new version is published to the package repository.

[katbyte]

until randomly without warning the latest version is broken, removes something, deprecates something, or is incompatible with something else. "always up to date" is something that sounds great but in practice has many many pitfalls.

[cptskippy]

This sounds like exactly the kind of enterprise OS running on Servers that Google wants for itself. Not something for consumer devices.

[guyzero]

You'll be surprised of the first commercial deployment of Fuchsia then: https://www.theverge.com/2021/8/18/22630245/google-fuchsia-o...

[cptskippy]

I guess that makes sense. Those screens are black boxes as far as the user is concerned and highly dependent on the cloud to even function.

I guess I was thinking more Laptops and Phones.