If history is of any guide Android and ChromiumOS likely still have many critical bugs the public does not know about yet.

Sadly the only choice is to burn extra ram to give every security context a dedicated kernel and virtual machine. Hypervisors are the best sandbox that exists anchored down to a hardware IOMMU.

QubesOS being VM based is thus the best effort secure workstation OS that exists atm. SpectrumOS looks promising as a potential next gen too.

I define the network access for each VM in a spreasheet (local services and Internet horizon), which then gets translated into firewall rules. I can simultaneously display multiple web browsers, each with a different network nym (casual browsing, commercial VPN'd, TOR, etc).

The downsides include needing an ethernet cable on my laptop (latency), and that this setup isn't great at going mobile. Eventually I'll get around to setting up a medium-trust laptop that runs a web browser and whatnot directly (while not having access to any keys to the kingdom), one of these days real soon now.

Which brings me to the real downside is the work required to administer it - you already have to be in the self-hosting game. This is where an out-of-the-box solution could excel. Having recently become a NixOS convert, SpectrumOS looks very interesting!

Running something like it on a laptop directly makes sense, but I worry about bringing some workloads back to my laptop that I really prefer to keep off it. In terms of raw performance my laptop isn't even close, especially with heavy graphic workloads. And then there's heat, etc.

My Ryzen 5700G ("router") idles around 20-25W, which seems like a small price to pay to not be at the mercy of the cloud. That's around 60 miles of driving per month (gas or electric), which seems quite easy to waste other ways.

My Libreboot KGPE ("desktop/server") burns about 160W. This is much higher than a contemporary computer should be, but that's the price of freedom. I could replace it with a Talos II (~65W from quick research), but the payback for electricity saved would take several decades.

To cut back on the environmental impact, I do plan to install solar panels with battery storage, which will also replace the need for UPSes. I've got another KGPE board for which it's interesting to think about setting up as a parallel build host, only running during sunny days rather than contributing to electricity storage requirements.

[0] https://www.kasmweb.com

We really need a way to run untrusted code and give it just the files we want, at run-time.

You never get nagged to take $5 out of your wallet to hand to an untrusted person, why should you get nagged to drop a file into an application you don't trust.

I suppose, you never have been to a significantly poorer country? (outside of the protected tourist areas).

Or well, spend time with kids, who really want something.

Begging can get very intense.

And about file permissions, well - are you aware, what kind of permissions the standard free app on the google play store will ask of people? And yes, I won't use them. But I use WhatsApp. Did not wanted to give permission to read contacts, or wide file access. But denying it, means it is allmost unusable, so I also eventually gave in ..

The clerk at the store doesn't ask for permission to take your payment.

  onSave() =>
    fh1 = GetFileWritePerm($documents + "/project.foo");
    fh2 = GetFileReadWritePerm($myFolder + "/cache.db");
    while(!fh3) {
      fh3 = GetFileReadWritePerm("/etc/passwd");
    }

You'd think that would be really rude of the app. That may have mattered 20-30 years ago. Today, most consumer-facing tech companies - big corporation and small startups alike - adopted "being a rude, obnoxious asshole" as a business model.

Note that this includes all the major commercial OS vendors too - i.e. Apple, Google and Microsoft. This creates a new challenge: how do we design secure systems when neither the apps nor the OS itself are trusted parties? How do we develop this security framework, when untrusted parties are the ones gatekeeping adoption, and also most likely to be developing it?

In other words: how do we maintain security for hens, when the foxes are guarding the hen house?

Just for interest sake, is Linux better or worse than MacOS, iOS and Windows at this?

OpenBSD by contrast has dual auditing and a stellar security reputation, but development is much slower and compatibility is very low.

seL4 as an extreme is a micro-kernel with mathematically provable security by design, but no workstation software runs on it yet.

MacOS, iOS, and Windows are proprietary so they are dramatically worse off than Linux in security out of the gate. No one should use these that desires to maximize freedom, security and privacy.

If you define security as a "lack of exploitable bugs", then security can never be proven, because it's impossible to prove a negative. Also many formally verified systems have had critical bugs discovered, like the KRACK attacks in WPA. The formal verification wasn't wrong, just incomplete, because modeling complex systems is inherently an intractable problem.

The fact that seL4 doesn't even offer bug bounties should be a huge red flag that this is still very much an academic exercise, and should not be used in places where security actually matters.

https://github.com/seL4/seL4/blob/master/SECURITY.md

In fact, in a seL4 system, most of the vulnerabilities we find on Linux wouldn't even be on the kernel, and their verification logic can't test something that isn't there.

That said, the seL4 model does probably lead to much better security than the Linux one. It's just not as good as the OP's one-liner implies.

I’m not involved in this kind of research or low level auditing, but I have some mathematical training and fascination with the idea of formal verification.

I ran across this thing called “K-Framework” that seems to have invested a lot in making formal semantics approachable (to the extent that’s possible). It’s striving to bridge that gap between academia and practicality, and the creator seems to really “get” both the academic and practical challenges of something like that.

Here’s a brief overview of one of the features that seems most impressive/useful: https://youtu.be/x_xm69gd3fE

The clarity of Grigore’s explanations and the quality of what I’ve found here: https://kframework.org/ makes me think K has a lot of potential, but again, this is not my direct area of expertise, and I haven’t been able to justify a deep dive to judge beyond impressions.

You’re correct in pointing out that complex systems are inevitably difficult to verify, but I think stuff like K could help provably minimize surface area a lot.

It sure makes auditing that code conforms to an expected design a lot easier, which is most security bugs. This is a fantastic design choice for a security focused kernel.

I will grant that proving something was implemented as designed does not rule out design flaws so, fair enough.

If you install something like grsecurity or use SELinux policies, I could buy the argument. I have yet to see these used in production though.

Also seL4 is not mathematically proven to be secure, it is formally verified which means it does what it says it does. Part of that spec may include exploitable code

As for Linux, piles of companies pay for Linux kernel security, though many bugs are found by academics and unpaid independent security researchers. Linux is one of the best examples of many-eyes security. None of those brilliant and motivated researchers are allowed to look at the inner workings of MacOS or Windows though Darwin is at least partly open source so I put it way ahead of Windows here.

Also re-implementations of most features from grsecurity have been in the mainline kernel for years. https://gist.github.com/madaidan/2031b844d760683af19e85bda18...

On system-call firewalling tactics like SELinux it is true very few use these in practice as most devs have no idea what a system call is, let alone how to restrict it. That said Kernel namespacing features have come into very wide mainstream use thanks to Docker and similar containerization frameworks which cover much of the scope of things like SELinux while being much easier to use.

As for most Linux /distributions/, I sadly must agree they favor compatibility and ease of use over security basically always. I will grant that Windows/MacOS enable basic sandboxing features that, while proprietary, are likely superior to nothing at all like most Linux distros. Other choices exist though.

QubesOS is the Linux distro for those that want high security. It is what I run on all my workstations and I would trust it out of the box over anything else that exists today as hardware access and application workflows are isolated by virtual machines and the base OS is offline.

QubesOS is a Xen distro that happens to use Fedora by default as dom0 vm.

I think we can have the best of both worlds here: OS distributions that are being maintained by paid teams of security experts, and that can be audited by anybody.

What are the major ones? Android, Chromium OS, RedHat (Fedora, CentOS), and SUSE.

I think the reasons are indeed quite good, the security community or industry has a lot of black sheep.

Problem with MS and Apple is that they force intimacy by design. That itself is a security threat to me.

Not sure how fair this is, even though I agree with you with regards to Linux being auditable and the others not.

Windows and macOS these days have vendor-provided code signing authorities that can be leveraged (and are by default), which provides at least some protection against malware at the macro level (in that the certificates can be revoked if something nefarious is identified). This doesn't exist at all in Linux, although third party products are in the early stages.

Windows 11 and macOS have hardware-backed root-of-trust. In Windows the root of trust is the TPM, on macOS it's the T2 (Intel) or the chip package (ARM).

Any of these features could be compromised without your knowing, but at least where you have control authorities for these systems you can draw some comfort in knowing that once new malware has been identified spreading on pretty much any machine, it can be stopped quite rapidly on all machines by revocation until the bug can be patched.

The code-signing is relatively trivial to workaround, you just have to get users to run xattr(1) to remove quarantine status.

With Genode, POSIX compatibility is at the point where you can run a webkit2-derived browser natively. There is also 3d acceleration.

macOS has SIP.

GNU/Linux is still not there doing this out of the box.

Would you say macOS, iOS, Windows are more trustable than FOSS OSes like Fuschia or ChromeOS, Android, or even QubeOS and Tails?

If not, where else ChromiumOS / Android lack (keeping in mind the embedded nature of the latter)?

How long do you think before viable open firmware / open hardware computing devices show up?

Thanks.

Because even for FOSS stuff, unless you are an expert on all levels of the stack you will not be able to assert there are some hidden exploits disguides as perfectly safe code.

And if you have to rely on third parties to assert that for you, then you will have to trush their honesty and technical skills to be able to assert such statements.

So there is only hope that all players are experts, don't do any mistakes, keep being honest, and exercise their certification for every new release for all products that make up a standard installation.

Until pretty recently (~3-4 years) Linux the kernel was actually pretty far behind in most respects versus competitors, including Windows and mac/iOS. I say this as someone who used to write a bunch of exploits as a hobby (mainly for Windows based systems and windows apps). But there's been a big increase in the amount of mitigations going into the kernel these days though. Most of the state of the art stuff was pioneered elsewhere from upstream but Linux does adopt more and more stuff these days.

The userspace story is more of a mixed bag. Like, in reality, mobile platforms are far ahead here because they tend to enforce rigorous sandboxing far beyond the typical access control model in Unix or Windows. This is really important when you're running code under the same user. For example just because you run a browser and SSH as $USER doesn't mean your browser should access your SSH keys! But the unix model isn't very flexible for use cases like this unless you segregate every application into its own user namespace, which can come with other awkward consequences. In something like iOS for example, when an application needs a file and asks the user to pick one, the operating system will actually open a privileged file picker with elevated permissions, which can see all files, then only delegate those files the user selects to the app. Otherwise they simply can't see them. So there is a permission model here, and a delegation of permissions, that requires a significant amount of userspace plumbing. Things like FlatPak are improving the situation here (e.g XDG Portal APIs for file pickers, etc.) Userspace on general desktop platforms is moving very, very slowly here.

If you want my honest opinion as someone who did security work and wrote exploits a lot: pretty much all of the modern systems are fundamentally flawed at the design level. They are composed of millions of lines of unsafe code that is incredibly difficult to audit and fix. Linux, the kernel, might actually be the worst offender in this case because while systems like iOS continue to move things out of the kernel (e.g. the iOS WiFi stack is now in userspace as of iOS 16 and the modem is behind an IOMMU) Linux doesn't really seem to be moving in this direction, and it increases in scope and features rapidly, so you need to be careful what you expose. It might actually be that the Linux kernel is possibly the weakest part of Android security these days for those reasons (just my speculation.) I mean you can basically just throw shit at the system call interface and find crashes, this is not a joke. Windows seems to be middle of the pack in this regard, but they do invest a lot in exploit mitigation and security, in no small part due to the notoriety of Windows insecurity in the XP days. Userspace is improving on all systems, in my experience, but it's a shitload of work to introduce new secure APIs and migrate things to use them, etc.

Mobile platforms, both Android and iOS, are in general significantly further ahead here in terms of "What kind of blast radius can some application have if it is compromised", largely because the userspace was co-designed along with the security model. ChromeOS also qualifies IMO. So just pick your poison, and it's probably a step up over the average today. But they still are comprised using the same fundamental building blocks built on lots of unsafe code and dated APIs and assumptions. So there's an upper limit here on what you can do, I think. But we can still do a lot better even today.

If you want something more open in the mobile sector, then probably the only one I would actually trust is probably GrapheneOS since its author (Daniel Micay) actually knows what he's doing when it comes to security mitigation and secure design. The FOSS world has a big problem IMO where people just think "security" means enabling some compiler flags and here's a dump of the source code, when that's barely the starting point -- and outside of some of the most scrutinized projects in the entire world, I would say FOSS security is often very very bad, and in my experience there's no indication FOSS actually generally improves security outside of those exceptional cases, but people hate hearing it. I suspect Daniel would agree with my assessment most of the fundamentals today are fatally flawed (including Linux) but, it is what it is.

One issue is that software has vulnerabilities and bugs. I’m not talking about the software that users run in sandboxes environments. I’m talking about the sandboxes environments. I’m talking about cryptography implementations. I’m talking about the firmware running in the “trusted” hardware.

The other major issue is as you alluded to: the need to trust vendors and hardware. Without protection and monitoring at the physical level, the user has no way to verify the operation of the giant stack of technology designed to “protect them”. Without the ability to verify operations, how is the user to trust anything? Why do companies tell users to “trust them” without any proof they are trustworthy?

This may seem like a minor point, but this is really the crux of the issue. Building this giant house of cards on top of a (potentially) untrustworthy hardware root of trust does not buy anyone anything. Certainly it does not buy “security”.

Large companies and nation states are the most likely adversaries one wants to be wary of these days (e.g. journalists, whistleblowers, etc.). What good does the technology do them if the supply chain is compromised or vendors are coerced to insert backdoors? These are the threats that actually face people concerned about security, not whether or not their executables are run in a sandboxed VM or not. Great, you’ve stopped the adversary from inserting malicious code into your device after purchase. Good thing for them, they did it prior to or during manufacture.

The technology you alluded to above is mainly useful for protecting company IP from end users, IMO. That’s how I’ve mainly seen it used, and the marketing of “security for the user” is a gimmick to justify the process.

EDIT: I forgot to mention this entire class of security issue since I am used to working on air gapped systems. I don’t care if you are operating in a sandboxed VM with a randomized MAC over a VPN over Tor. If you’re communicating with any other device over the Internet, you have to trust every single other machine along the way. And you shouldn’t.

You know the answer here, they are not to be trusted.

Samsung phones, for example, have a gpsd, which phones home at random times. This runs as root, ignores vpn settings (so no netguard for you!), and if it is just getting updated agps info, it sure seems to send a lot of data for that.

So no, they don't want a legitly auditable device. Too many questions, you see.

At the end of the day you need to trust Qualcomm or MediaTek. The Oracle of the hardware world, with more lawyers than engineers, or... MediaTek.

That's a NOPE for me.

If I were the NSA, that’s where I’d be focussing at least some of the attention of the “exploit people’s phones” department. If you want cellular connectivity, the cellular provider needs a real time way to identify your device and it’s location (at least down to neatest few cell towers accuracy).

(And once I had some capability there, the people running the “most secure basebands/devices would be the ones I kept the closest eye on. I’ve heard my local intelligence service are very interested in phone switch on/off events, because they are a signal that someone might be attempting to evade surveillance, and the rarity of “normal people” switching their phone off (or disconnecting from the cellular network) makes it worthwhile collecting all that “metadata” so they can search it for the “interesting” cases.

WiFi is in a similar position, but at least the diversity is a bit better causing integration tests to fail better when too many bad implementations try to talk to each other.

That leaves all the other chips, which I think are best trusted in a divide and conquer setup where they all have to independently verify their blobs, and not be allowed to mess with each others memory/internal state. It can make them more expensive, but it also compartmentalises them in a way that side-channel attacks within CPU cores are completely mitigated.

Only a very very very small amount of companies in the world will have the capital, expertise and manpower to make devices where enough of the stack can be trusted, and out of all of those, only some actually seem to try:

  - Google (mostly for UX, but also to make fat stacks of cash via ads) 
  - Apple (mostly for UX, but also to make fat stacks of cash via ecosystem)
  - Microsoft (console, ARM windows, mostly for DRM, but also UX)
  - Sony (console, mostly for DRM, but also UX)
  - Nintendo (console, mostly for DRM)

The more a company does _not_ want to get burned on their security/privacy positions and keeps iterating making better designs, the more you _could_ trust them. The only realistic alternative is going back to 80's computing, and nobody has time for that.

If I’m not a terrorist/sex-trafficker/investigative-journalist, can I reasonably ignore those threats even if I, say, occasionally buy personal use quantities of illegal drugs or down/upload copyright material? (With, I guess, the caveat that I’d need to assume the dealer/torrent site at the other end of those connections isn’t under active surveillance…)

Nation states, especially the US, should be suspected of having compromised everything. Look at all the things Edward Snowden released. Look at the way the NSA has corrupted cryptographic standards in the past (e.g. Dual EC DRBG). There are countless instances of similar situations.

With iOS at least I know that apps really are sandboxed and cannot access anything unless I grant permission. No app can ever attempt to access my photos unless I explicitly pick a photo or grant partial/total access. Even then it's read-only or "write with confirmation, every time"

And you can deny the file access permission like any normal permission, most modern apps request music or videos and photos, rarley an app requests full file access.

> A 7-9 year old iOS device is crippled today, with non-user-replaceable parts (both software and hardware).

A 7-9 year old iPhone has user replacable parts (hardware), as does the equivelant Pixel. It also runs perfectly well.

> A 3-year-old Pixel is newer than the one I use, running sshd and accepting connections only from the bearer of my private key.

That's a lovely thought. The baseband manufacturers with their own blobs disagree though.

> The market for old iPhones drops sharply, and is just for folks with an iCloud account. The market for old Pixels allows a Pixel 6 to be sold for >$1000 less than half a year ago (with a more trustworthy third party OS installed), ready for the user to choose whether this trust model of a pre-installed OS is even sufficient.

This is simply untrue. The Pixel 6 is available for $900 AUD new and about $500-600 used. The iPhone 13 (same year) starts at $1200 AUD new and about $800-900 used. The value held is extremely similar, and in fact drops less for older Apple phones than Android ones likely - as the GP mentioned - due to more than double the years of OS support from the vendor.

It's fine for you to decide that the fruit company is less trustworthy than the advertising company, but don't spread nonsense to try and sell your point.

Not that a Desktop with Windows would be any better. But I don't trust the OS itself, no matter how many layers of virtualization you put between code I choose to execute. The weak link is already provided by design. This isn't a technical criticism of Android, but the whole platform as being intransparent and paternalistic.

Not a fan of trusted computing because I doubt it will ever be used in the interest of users. It will be a requirement for some services, which I don't want to further support in their endeavours.

I talked to a security researcher specializing on Android at a conference and he didn't sound like he'd agree.

While I personally think ChromiumOS does a good job, I think a huge problem is that the issue is in how liberally complexity is added. And complexity is typically where security issues lurk. This has been seen again and again.

It's also why I think projects such as OpenBSD do such a great job. Their main focus seems to be reducing complexity (which they are sometimes are criticized for). A lot of the security seems to come from the reduced attack surface you get. And then the security mechanisms build, which typically are more easily implemented, because of said simplicity are the next layer.

And I think OpenBSD has reached a sweet spot there, where it's not some obscure research OS, but an OS that you can install on your server or desktop, run actual work loads, heck, even play Stardew Valley, or a shooter on, but have all the benefits in terms of security or simplicity that you can from research OSs, Plan 9, etc.

So maybe not mainstream, but mainstream enough to actually work with it. There's sadly many projects that completely ignore reality around them, also because their goal is to simply be research projects and nothing more. Then we have those papers that rarely everyone ever looks at on how in a perfect world all those big security topics could be solved. Unless some big company comes along and puts it into some milestone.

ChromiumOS seems like the limitations you get are similar, probably even more severe than what you get compared to OpenBSD's flexibility. That's something many de-google projects struggle with as well. At the same time the complexity remains a whole lot bigger. Of course goals and target groups are hugely different.

I think both Android and ChromiumOS used to put more emphasis on simplicity, but gave it up at some point. I am not sure why, but would assume that many decisions are simply company decisions. After all the eventual goal is economic growth.

That locking down on mobile devices is not just to increase security, but has the beneficial side effect of controlling the platform. This might not even be directly intended by the security focused developers, but it is a side effect.

So "most trustable" in that scenario comes with "most gate-keeping", "least ownership", etc., which we are kind of used to on smartphones, tablets and Chromebooks. So I think comparing it with other kinds of mainstream OSs isn't really leading to much.

But the nice parts of ChromeOS, as far as security properties go are the way it can be "power washed" between usages. Along with a desktop Linux system that has less binaries installed at it's base than most. And things that are built in are typically built atop chrome's sandbox.

I used to joke with my friends who ran TAILS Linux that my grandma with her Chromebook had the same threat model.

OpenBSD's track record is impressive but is it a significant target compared to Windows, MacOS, and Linux?

It is easy to say "only two bullets have ever penetrated my armor" when hardly anyone is shooting at you. I do not know if this is the case because I have never used OpenBSD and I do not know how widely it is used (headless servers, embedded devices, etc.).

You can read more about OBSD's security by going to https://openbsd.org then clicking the "Security" link near the top left.

ps: FreeBSD seems to have more users than OpenBSD, and NetBSD seems to have fewer users than OpenBSD.

Also I separate things by user account, so I don't do my general browsing as the same user that does my programming, which is again separate from bank access, which is separate from .... So the kernel is providing a lot of protections.

(And I usually browse without images and javascript, which is not OS-specific but a suggestion. Many things I use don't require it, and I can flip it on or configure it specifically for those that do.)

Who gives a shit about it enough to attack it a la (say) Windows?

Do jails not fulfill this?

ps: see also: https://man.openbsd.org/?query=chroot&apropos=1&sec=0&arch=d...

Noob here, I recall often hearing that iOS has superior security to Android. Has this situation reversed in the last few years, or was it never true?

I suspect remarkably few people are qualified to objectively say which is more secure. If you're an expert on one, you're unlikely to be an expert on the other.

Security is multidimensional. It's unlikely there will be a platform that's more secure from every possible angle. What's secure for you might not be secure for a less technical person, or a world traveler.

In terms of privacy, Android is "compromised" by default, i.e. Google collects and stores a ton of private information about you. I believe Apple used to be much better, and still is, but getting worse.

Apple also does the same. Also, this only applies if you're running an Android device "out-of-the-box". Fortunately, there exist AOSP forks that mitigate this type of intrusion (e.g. GrapheneOS).

However, this is a speculation, so please take it as a grain of salt.

The pKVM hypervisor is new to Android 13 and requires Pixel 7 hardware, both of which are a few months old.

I would also assume the fact that their vertical integration all the way down to silicon is an advantage here as well.

With the exception of the blobs, everything on Android is auditable.

Meanwhile very little of MacOS or iOS is auditable.

Personally I do not use or trust any of the above, but if forced to choose Android is worlds ahead of iOS in terms of publicly auditable privacy and security.

You cannot form reasonable confidence something is secure unless it can be readily audited by yourself or capable unbiased third parties of your choosing. This means source code availability is a hard requirement for any security claims. Even if you had teams de-compile everything you could never keep up with updates.

Not all open source code is secure, but all secure code is open source.

The bug bounty is pretty hard to actually get access to, there’s still no source outside of the kernel, and the Security Research Devices are really hard to get access to. You have to be someone they’ve heard of, in a country they approve of, you can’t move the device around, and you have to sign your life away to get it for 12* months.

Either the sandbox is very weak and Apple instead relies on App Store audits, or they disallow users installing apps outside the app store to protect their 30% tax that makes them a LOT of money.

As far as I can tell, there is no meaningful protection in place to prevent OEMs from poisoning the Android well (and the Android brand), even without considering the black box firmware running on wifi/BT/LTE/5G modems.

Cryptographic verification of the boot chain with Hardware root of trust are real. Heavily sandboxed userspace is real. Everything else would seem to be a reimplementation of common best practices (disk encryption), or a mitigation of a self-created problem (there shouldn't be binary driver blobs running on the main CPU to begin with).

And from what I remember, a plain AOSP install seemed to still phone home to Google to check for Internet connectivity and whatnot. It's awfully hard to put my faith in an operating system primarily developed by a surveillance company, as the working assumptions are a drastic departure from individualist computing. And trying to question those assumptions with independent devs is often dismissed (for a particularly striking example, see LineageOS/"Safetynet").

True, but those protections are enabled by default (on Pixels at least). Users don't have to do anything here.

> And from what I remember, a plain AOSP install seemed to still phone home to Google to check for Internet connectivity and whatnot.

You're not wrong, but GrapheneOS and CalyxOS are valid options, if you don't trust the ROM Pixel ships with. Even with a custom ROM you're left trusting the OEM. It'd be nice if we could have an open hardware / open firmware Android, but it hasn't happened, yet.

My fundamental problem with Graphene/Calyx is that I don't trust the devs have enough bandwidth and resources to catch all the vulnerabilities created upstream, especially with the moving target created by rapid version churn. For example, Android is finally getting the ability to grant apps scoped capabilities rather than blanket full access permissions, which is actually coming from upstream - the Libre forks should have had these features a decade ago, but for their limited resources.

Concretely, what discourages me from going Pixel is the Qualcomm integrated baseband/application chipsets. I've heard that Qualcomm has worked on segmenting the two with memory isolation and whatnot, but their history plus the closed design doesn't instill confidence. Yet again it's the difference between the corporate perspective of providing top-down relativist "security" rather than the individualist stance of hardline securing the AP against attacks from the BB.

Pragmatically, I know I should get over that and stop letting the perfect be the enemy of the good (I'm currently using a proprietary trash-Android my carrier sent me. The early 4G shutdown obsoleted my previous Lineage/microG). But every time I look at Pixels it seems there's so damn many "current" models, none stand out as the best but rather it's a continuum of expensive versus older ones (destined to become e-waste even sooner due to the shameless software churn). And so I punt.

Google Pixel hasn't used Qualcomm chipsets since the Pixel 5.

It absolutely is. Default setting matter a lot!

It's great to have extra security features too. But even experienced users won't change defaults if they have too much cost. If things are turned on by default then those costs diminish because other software has to work within them.

My point was that when talking about commercial security offerings, the security models generally end up relying on on "trust the company", which has never worked out well. So corporate offerings finally coming around to having full disk encryption is more catching up with something they lacked, rather than advancing the state of he art. (Contrast with Android's process sandboxing, which seems like a genuine advancement and could be worthwhile to port to desktop Linux)

In the context of talking about individual actions one can take to trust their personal machine, it's reasonable to assume this involves appropriately configuring your software environment. If this was instead a thread about what products would be good to recommend to your parents, then what was commercially available off the shelf would be relevant.

Users install apps and grant them full access all the time. Android phones are wide open no matter how secure the operating system itself is, because the security model for apps is so weak from a user experience point of view.

Aren't those still user-based? So, in the typical case of a single-user computer, a rogue app that I run with my account would be able to access my data.

There's the protected folders thing (not sure about the name) since a few versions ago, which attempts to block random apps from accessing random folders.

But it's opt-in (folders are not protected by default, you have to add them one by one). It's also all or nothing: either a given app is "untrusted" and it can't access any of the protected folders, or it's "trusted" and it can access all of them.

I can't say I trust Photoshop to only touch my pictures folder, but not my .ssh folder.

The Windows kernel does offer an impressive number of options to lock down processes. Look at the Chrome sandbox code some time. The Windows API is huge but you can really lock it down a lot. The macOS sandbox architecture is, however, the best. The Linux approach is sadly in third place.

• Copy an EXE to %TEMP% and run it from there.

• Use a Win32 API flag to start a process (of any path) outside the app container.

There are only a few cases where Helium is an issue and they're all easy to work around. One example is writing a log file to your app private UserData directory and then opening Notepad on it. If you do it the 'naive' way then Notepad won't be able to find it, because you'll pass a redirected path which it can't see. The fix is simply to resolve the redirect before passing the argument to Notepad using a Win32 API call.

I know we talked about Conveyor a few days ago so I'll note here that if you package a JVM app with it then the %LOCALAPPDATA% and %APPDATA% environment variables are rewritten to their target locations automatically, so as long as you use them to decide where to write app private files then their paths will be visible to other apps, avoiding the Notepad issue. This doesn't apply to native or Electron apps though, at least not at this time.

Asking because I base hardware purchases on whether LineageOS is available for the device and wondering whether I should restrict further to GrapheneOS or CalyxOS.

But it is possible to verify what it does, the same way you would for an android phone (I.e. not just look at the source code and hope that it matches what’s running on your device). https://youtu.be/8mQAYeozl5I At 26:42 he talks about lockdown mode. Would be a bit weird if he lied about the impact lockdown mode has.

He doesn’t have to be a liar to be telling you untruths about how it works.

Could you please make concrete a point?

Edit: whether people are wrong about android security is orthogonal and whataboutism

And no, I never asked why we would need to verify the security researcher’s claims (but sure, you should).

1. Dma54rhs says Apple’s (!) claims supposedly can’t be verified and that you need to take Apple’s word for it

2. I ask why not, provide a link to a talk about iOS security by a renown security researcher as both an example of how to verify Apple’s claims (reverse engineer iOS) and to lend some credence to the point that they are likely to be true

3. You talk about the researcher and/or programmers being wrong by replying with an “orthogonal” comment containing “whataboutism”.

Edit: Could we please talk about the actual topic? Do you or someone else know about instances where Apple lied about mitigations like lockdown mode before? Maybe there’s a long history of it and I just don’t know. Or is there some other flaw in my logic?

There is always the argument about hidden bugdoors, backdoored compilers or whatnot. But that’s not practical, by then you might as well stop using technology.

If Apple can’t be trusted then why can you trust google? Or Qualcomm?

You can’t verify that iOS is doing what Apple says that it’s doing, because you can’t read the code. You can’t trust that Apple perfectly understands their product, because it’s extremely complicated, and therefore you can’t just take their word for it. I’ll state that the check here, although it’s painfully obvious, is that exploits happen. Researcher opinions are fine, but facts are better.

None of this is in any way contentious or new, it’s the exact debate about open-vs-closed that we’ve been having since the beginning of software.

Knowing a PUK-code for a SIM card you own (and you can insert/hotswap) is all you need(ed) to unlock practically any Android phone until recently. Granted, this got reported and then fixed, it doesn't matter how good the TCB is if the front door is wide open.

I'd say that actual trust is hard to come by because you cannot trust what you see, since what you see is merely what is 'presented'. If a device says something like "the only Root CA I trust to sign my stage 1 boot loader is X", I still don't know if it is lying or not. I also can't do something like replace a SoC BROM since it's fused RO or simply a ROM (and not EPROM or Flash), or because the sources for that are owned by the SoC manufacturer, which isn't AOSP or Google, and I cannot inspect, build and run them. Hell, we can make this worse: even if I could flash it, who's to say that the memory I flashed is also the memory that is read when the SoC comes out of reset? What if there is a separate area on the die that has a different ROM that nobody told us about.

So trust isn't going to be purely based on "because this is the design we present you", but has to be based on non-technical factors and independent research. The former is mainly based on soft factors, and the latter is hard to come by and often just based on individual devices, not even an entire SKU release.

Architecturally, it seems to me that Apple with their own SoCs, bootrom, RTKit, iBoot etc. has a stronger platform trust case because they actually own the stack all the way with nobody else having a say about it. Especially with the spreading around of individually signed and verified hardware ROMs that don't even run on the same chips in the same device, a compromise would be very limited in scope. The only other hardware/software combination that would come close is the aforementioned Pixel devices since Google has almost all of the stack there as well.

On the x86 side it's a mess that will never be resolved, nearly every technology that was supposed to make it more trustworthy has been used to reduce trust and install persistent access outside the view of the OS. AGESA, IME, TXT, SGX, even the SMM implementations before any of those came along had problems that essentially circumvent any trust that was built up by other means. Even the hardcoded certificate signature hashes in the CPUs are coming in range if easy brute forcing (SHA1 mostly) which means that entire decades of systems can now think they are running trusted software from the reset vector all the way to the OS, just because a signature hash was using a crappy algo that was never intended to be used that way.

Windows is probably only ever going to be boot-trustable (but not OS-trustable) on ARM, just like macOS root-of-trust is pointless on anything before the T2 chip (and M1 later on). For Linux, it's about as trustworthy as you want to make it, but putting in the work is a PITA, so unless a distro or derivative (Qubes, ChromeOS etc.) does it for you, most users leave it as-is (untrusted).

> Architecturally, it seems to me that Apple with their own SoCs, bootrom, RTKit, iBoot etc. has a stronger platform trust case because they actually own the stack all the way with nobody else having a say about it.

That's why I specifically and only mention Pixel in my comment. Google's been doing their own hardware since Pixel 6. (iirc) Daniel Micay, creator of GrapheneOS, once said that Google shares firmware / proprietary code for the Pixel hardware "if you ask nicely enough".

Like you point out, eventually, one is left trusting a BigCo or worse assuming a flawed implementation is secure. Though, it isn't for the want of not trying. Or, to put it another way, "the best among the rest".

Sweet, so we can trust that our personal machine is only compromised by Google et al? XD