Fuchsia has separated the drivers from the kernel[1], enabling proprietary drivers that are never updated to become acceptable. This can result in Blueborne[2], GPU vulnerabilities[3], and any other proprietary driver remaining permanently vulnerable as the hardware manufacturer has no incentive to update the driver.

In Fuchsia's model, you can run the latest OS with these vulnerable, non-updated drivers, or your device ODM could even release nothing and you don't have the GPLv2 to fall back on to get the Board Support Package for your hardware to build your own updates with.

1 - https://www.theverge.com/2020/12/8/22163225/google-fuchsia-o...

2 - https://en.wikipedia.org/wiki/BlueBorne_(security_vulnerabil...

3 - https://redd.it/s48lz

Those types of driver vulnerabilities are exactly why Fuchsia's sandboxed driver model is needed.

I see that as a sort of capitulation. What is actually needed is manufacturers who remain responsible and responsive when it comes to the quality of their drivers. They need to support them much longer than they currently do, and they need to release security fixes promptly.

I think having a sandboxed driver model is a great idea in general, but this will only encourage hardware manufacturers to care even less about supporting their drivers beyond the initial more-or-less-working release.

> What is actually needed is manufacturers who remain responsible and responsive when it comes to the quality of their drivers. They need to support them much longer than they currently do, and they need to release security fixes promptly.

That requires a level of investment in engineering competence that they aren’t doing because there is little incentive.

How would you suggest changing that?

When the support ends, drivers must be open-sourced.

That’s just a wish.

How do you create the incentive for it?

I think that just must be a law. I see no other possibility.

How would the law define ‘support ends’?

Also seizing source code at gunpoint seems antithetical to the notion of free software.

This is the question of security, see https://news.ycombinator.com/item?id=27387169.

> How would the law define ‘support ends’?

Whenever the company refuses to fix security bugs.

What if they don’t refuse - but are just slow or inefficient or produce bad fixes?

There exist more or less standard times for fixing security bugs. Let's say 90 days. If a company cannot provide security for their customers in a reasonable time, they must be held accountable.

Sure - typically the remedy for negligence would be compensation for the impact.

Seizing property at gunpoint doesn’t seem related to this.

Fuchsia has a lot of good features technically, there is no doubt about that - it was time to revisit how an OS should be designed given the usage patterns of devices it powers. I hope the capability model will put to rest the insanity that is SELinux (just look at the amount and complexity of SELinux rules in AOSP). The license choice for the kernel is more controversial, but no one expected Google to ship under the GPL.

It also happens to solve some of the pain points with Android: in a way it is "Project Treble on steroids" aiming to resolve the issue with fragmentation and lack of long term support from Android chipsets and OEMs.

Except there still won't be long-term support from OEMs, you've instead just pushed the security responsibility onto Fuschia and hoping that the kernel maintaining a strong sandbox will be sufficient to mitigate all driver security vulnerabilities (hint: it won't be).

Most (all?) the drivers will be closed source since the license allows it.

Worse yet, the OS itself is non-GPL, an OEM can modify Fuchsia outside just the drivers to support their device (eg: create a board support package) and never release their modifications to their customers, meaning the community can't compile their own updates to the software running on the device (worse than our current Android situation).

At least they won’t break with every minor update.

Unless the OEMs customize the whole stack to only allow the kernel to talk to their drivers. That is only enforceable by legal constraints from Google akin to the CTS [0].

[0] https://source.android.com/compatibility/cts