> I think you are somewhat conflating the needs of desktop/laptop/mobile users.
No, we aren't. Desktops need far better privacy and security than they have today. That does not require giving up functionality. Development can be done in contained hardware accelerated virtual machines specific to projects. It doesn't require running an OS where anything goes and software doesn't run in a sandbox on the host. QubesOS could have a far more secure OS as the one people interact with despite running far less secure operating systems in many of the guests. It would not prevent people getting work done. It can also be done with far higher usability than is currently provided.
> Hardware security tied to unlocking modes makes little sense on desktops.
Verified boot and hardware support for disk encryption is very valuable to a desktop and laptop.
> I can lose my phone, or possibly my laptop, but my servers and workstation are at home, guarded by a dog and a shotgun.
Servers and workstations being in a trusted location doesn't mean the security of those against physical attacks doesn't matter. It also doesn't address remote attacks.
> Disk encryption already covers a realistic threat model such as a break-in.
You do not have comparable disk encryption. You have it in a form that only truly works when the device hasn't had the encryption passphrase entered since boot. It's wide open to data extraction via a bunch of debugging interfaces. There's incredibly poor security against physical attacks at both a hardware and OS level.
> I don't expect protection against apps, and don't want to pay the performance tax that comes with "enhanced" memory allocators and memory-safe languages/runtimes.
The performance cost of exploit protections can be determined in a granular way. GrapheneOS has a toggle to use the standard allocator for any apps. Memory safe languages do not imply inherent overhead and can be faster for some uses. Rust is very high performance and even Java can be higher performance for certain uses where there are lots of short lived allocations.
> The irony is that Android is practically designed to run commercial malware. The sandbox you have in mind does very little in practice.
Android's sandbox provides enormous benefits and the permission model gets significantly better ever year. Android has heavily focused on improving a lot of what you're talking about itself upstream and GrapheneOS improves it much more.
Android can force backwards incompatible changes on the whole app ecosystem to improve privacy and security which it does with each new major target SDK version for the major yearly releases. They limit how much they do this in each major release and aren't as focused on privacy and security as us so we wish they did more, but no other mainstream platform has made such substantial improvements to the privacy and security model for apps. Android has improved drastically more than iOS since it had a much worse starting point and had to catch up. It has caught up in most areas and surpassed iOS in some but still needs improvements in others. GrapheneOS is heavily focused on those areas where it's still behind iOS and has done a lot to improve it.
> Users consent to sharing files, contacts, locations, photos, when asked to because they want to use some app, and all of that is sent straight to Facebook, Google, or others.
GrapheneOS has Contact Scopes and Storage Scopes to choose which contacts and files/media are shared with the app seeing it as the permissions it requested being granted. This is an extension of Android's standard approach built on the infrastructure it provides for this. It's already heavily moving in this direction and has increasingly forced apps to use a case-by-case consent approach. Location, Microphone and Camera access in Android can be granted on a one-time basis. It heavily pushes apps to using the system file picker, media picker, contact picker, etc. and store policy is increasingly used as a deterrent against requesting bulk access. GrapheneOS does much better and it's able to do much better because of the infrastructure Android provides.
> Android apps can also communicate in some obscure and unexpected ways to discover each other and share information behind the user's back
Communication better apps is possible within profiles where both apps want to engage in it. Users do have the ability to prevent apps seeing each other and communicating via profiles (Private Spaces, work profiles and secondary users). GrapheneOS will be providing finer-grained nested profiles beyond a single Private Space per user or a single work profile along with it being more convenient.
Apps getting access to user data in the first place is what's most relevant rather than whether they can communicate regardless. They could also send it to a service rather than another app. Android is focused on preventing apps getting access to sensitive data including data from other apps or the user's profile data (files, media, contacts, etc.) which GrapheneOS greatly enhances. We do have things like a Network toggle but it's not intended as a substitute for the main approach of avoiding apps getting access to sensitive data. Android is currently phasing in a standard local network access permission for apps will provide one of the main benefits of our Network toggle.
alt Hacker News
> That's a rather bold claim.
No, it's not a bold claim. It's a strong consensus among people working on privacy and security engineering or research.
> Care to elaborate?
We did in our response to you at https://news.ycombinator.com/item?id=49366321 and posted more elsewhere. Others have posted far more details about it in articles and papers.
> I think you are somewhat conflating the needs of desktop/laptop/mobile users.
No, we aren't. Desktops need far better privacy and security than they have today. That does not require giving up functionality. Development can be done in contained hardware accelerated virtual machines specific to projects. It doesn't require running an OS where anything goes and software doesn't run in a sandbox on the host. QubesOS could have a far more secure OS as the one people interact with despite running far less secure operating systems in many of the guests. It would not prevent people getting work done. It can also be done with far higher usability than is currently provided.
> Hardware security tied to unlocking modes makes little sense on desktops.
Verified boot and hardware support for disk encryption is very valuable to a desktop and laptop.
> I can lose my phone, or possibly my laptop, but my servers and workstation are at home, guarded by a dog and a shotgun.
Servers and workstations being in a trusted location doesn't mean the security of those against physical attacks doesn't matter. It also doesn't address remote attacks.
> Disk encryption already covers a realistic threat model such as a break-in.
You do not have comparable disk encryption. You have it in a form that only truly works when the device hasn't had the encryption passphrase entered since boot. It's wide open to data extraction via a bunch of debugging interfaces. There's incredibly poor security against physical attacks at both a hardware and OS level.
> I don't expect protection against apps, and don't want to pay the performance tax that comes with "enhanced" memory allocators and memory-safe languages/runtimes.
The performance cost of exploit protections can be determined in a granular way. GrapheneOS has a toggle to use the standard allocator for any apps. Memory safe languages do not imply inherent overhead and can be faster for some uses. Rust is very high performance and even Java can be higher performance for certain uses where there are lots of short lived allocations.
> The irony is that Android is practically designed to run commercial malware. The sandbox you have in mind does very little in practice.
Android's sandbox provides enormous benefits and the permission model gets significantly better ever year. Android has heavily focused on improving a lot of what you're talking about itself upstream and GrapheneOS improves it much more.
Android can force backwards incompatible changes on the whole app ecosystem to improve privacy and security which it does with each new major target SDK version for the major yearly releases. They limit how much they do this in each major release and aren't as focused on privacy and security as us so we wish they did more, but no other mainstream platform has made such substantial improvements to the privacy and security model for apps. Android has improved drastically more than iOS since it had a much worse starting point and had to catch up. It has caught up in most areas and surpassed iOS in some but still needs improvements in others. GrapheneOS is heavily focused on those areas where it's still behind iOS and has done a lot to improve it.
> Users consent to sharing files, contacts, locations, photos, when asked to because they want to use some app, and all of that is sent straight to Facebook, Google, or others.
GrapheneOS has Contact Scopes and Storage Scopes to choose which contacts and files/media are shared with the app seeing it as the permissions it requested being granted. This is an extension of Android's standard approach built on the infrastructure it provides for this. It's already heavily moving in this direction and has increasingly forced apps to use a case-by-case consent approach. Location, Microphone and Camera access in Android can be granted on a one-time basis. It heavily pushes apps to using the system file picker, media picker, contact picker, etc. and store policy is increasingly used as a deterrent against requesting bulk access. GrapheneOS does much better and it's able to do much better because of the infrastructure Android provides.
> Android apps can also communicate in some obscure and unexpected ways to discover each other and share information behind the user's back
Communication better apps is possible within profiles where both apps want to engage in it. Users do have the ability to prevent apps seeing each other and communicating via profiles (Private Spaces, work profiles and secondary users). GrapheneOS will be providing finer-grained nested profiles beyond a single Private Space per user or a single work profile along with it being more convenient.
Apps getting access to user data in the first place is what's most relevant rather than whether they can communicate regardless. They could also send it to a service rather than another app. Android is focused on preventing apps getting access to sensitive data including data from other apps or the user's profile data (files, media, contacts, etc.) which GrapheneOS greatly enhances. We do have things like a Network toggle but it's not intended as a substitute for the main approach of avoiding apps getting access to sensitive data. Android is currently phasing in a standard local network access permission for apps will provide one of the main benefits of our Network toggle.