11 ms·

ex-AOSP dev here Android and ChromiumOS are likely the most trustable computing platforms out there; doubly so for Android running on Pixels. If you don't pref

ex-AOSP dev here Android and ChromiumOS are likely the most trustable computing platforms out there; doubly so for Android running on Pixels. If you don't prefer the ROM Google ships with, you can flash GrapheneOS or CalyxOS and relock the bootloader. Pixels have several protections in place: - Hardware root of trust: This is the anchor on which the entire TCB (trusted computing base) is built. - Cryptographic verification (verified boot) of all the bootloaders (IPL, SPL), the kernels (Linux and LittleKernel), and the device tree. - Integrity verification (dm-verity) of the contents of the ROM (/system partition which contains privileged OEM software). - File-based Encryption (fscrypt) of user data (/data partition where installed apps and data go) and adopted external storage (/sdcard); decrypted only with user credentials. - Running blobs traditionally run in higher exception levels (like ARM EL2) in a restricted, mutually untrusted VM. - Continued modularization of core ROM components so that they could be updated just like any other Android app, ie without having to update the entire OS. - Heavily sandboxed userspace, where each app has very limited view of the rest of the system, typically gated by Android-enforced permissions, seccomp filters, selinux policies, posix ACLs, and linux capabilities. - Private Compute Core for PII (personally identifiable information) workloads. And Trusty Execution Environment for high-trust workloads. This is not to say Android is without exploits, but it seems it is most further ahead of the mainstream OSes. This is not a particularly high bar because of closed-source firmware and baseband, but this ties in generally with the need to trust the hardware vendors themselves (see point #1).

BLKNSLVR 4y ago
Does LineageOS have a place alongside GrapheneOS and CalyxOS? 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.
- ignoramous 4y ago
  There's overlap between CalyxOS and LineageOS. CalyxOS (privacy-focused ROM, currently Fairphone and Pixel-only) has different goals to LineageOS (Android ROMs for as many phones as possible); while GrapheneOS is a security-focused distribution. DivestOS is another credible alternative.
andai 4y ago
> it seems it is most further ahead of the mainstream OSes 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?
- transpute 4y ago
  > Running blobs traditionally run in higher exception levels (like ARM EL2) in a restricted, mutually untrusted VM The pKVM hypervisor is new to Android 13 and requires Pixel 7 hardware, both of which are a few months old.
  - milkey_mouse 4y ago
    pKVM (theoretically) works on Pixel 6, 6 Pro, and 6a as well.
- lrem 4y ago
  Isn’t most of the value here in not allowing sideloading? In iOS your grandma/child cannot be tricked into clicking “allow apps from untrusted sources”, which is how most breaches happen.
  - gkbrk 4y ago
    If the apps sandboxed, how can installing an app cause breaches? As far as I know, iOS apps are sandboxed. 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.
    - Consultant32452 4y ago
      The sandboxes are regularly breached. Basically any time you hear about people "rooting" their phones, that's an intentional sandbox breach.
      - 4y ago
zython 4y ago
What is your opinion on ios Lockdown mode ?
- Dma54rhs 4y ago
  You cant verify but just take Apples word for it, it's not a fair comparison in my opinion.
  - ylk 4y ago
    What do you want to verify exactly? Do you think Apple is lying about what lockdown mode does? Why would they do that? Could you at least say what your opinion is based on? 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 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.
    - Godel_unicode 4y ago
      What if he’s wrong? Computers do things their programmers don’t expect them to literally all the time. Security bugs generally come from a mistaken assumption about how something behaves. He doesn’t have to be a liar to be telling you untruths about how it works.
      - ylk 4y ago
        What if everyone is wrong about the effectiveness of Android’s mitigations? Then iOS would be more secure. Could you please make concrete a point?
        Godel_unicode 4y ago
        You asked why we would need to verify things he said. I explained it quite concretely. What part did you not understand? Edit: whether people are wrong about android security is orthogonal and whataboutism
lrvick 4y ago
IMO we have to step back and be honest that the Linux kernel is simply not equipped to run trusted code and untrusted code in the same memory. New bugs are found every few weeks. 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.
- flanked-evergl 4y ago
  > Linux kernel is simply not equipped to run trusted code and untrusted code in the same memory. Just for interest sake, is Linux better or worse than MacOS, iOS and Windows at this?
  - aseipp 4y ago
    It's... complicated. Linux is just the kernel, but good modern OS security requires the kernel, the userspace, and the kernel/userspace boundary to all be hardened a significant amount. This means defense in depth, exploit mitigation, careful security and API boundaries put in place to separate components, etc. 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.
pontilanda 4y ago
All that looks good on paper, but a lot of apps require full disk access and can easily run in the background, so how "trustable" can that really be in practice? 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"
- jacooper 4y ago
  On GrapheneOS you can choose specifc storage scopes, even if the app is requesting full user storage access. 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.
- Grim-444 4y ago
  Well both of your complaints were already addressed. Android introduced the scoped storage system to remove and fix abuse of "full" disk access, and they also added the foreground notification system which forces a system notification to be displayed if any app is doing work in the background, so that you know about.
  - drozycki 4y ago
    Right, but if the average real-world Android experience lags behind say iOS in terms of security, then the point, even if outdated, still serves to disprove the parent’s premise that AOSP is the most secure.
- derkades 4y ago
  In recent years, I have not seen any app request full file access permissions besides file managers
tete 4y ago
> Android and ChromiumOS are likely the most trustable computing platforms out there 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.
- solarpunk 4y ago
  This page has stuck with me since I read it regarding openbsd. It's a bit mean spirited, but I think openbsd mostly benefits from its own obscurity. https://isopenbsdsecu.re/ https://isopenbsdsecu.re/ 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.
mindslight 4y ago
Most of your bullet points are reinventions of standard technology or incidental complexity. 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").
- ignoramous 4y ago
  > Everything else would seem to be a reimplementation of common best practices... 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.
  - mindslight 4y ago
    Sure, but full disk encryption was also enabled on my Mom's Ubuntu laptop 15 years ago, because I chose the correct options when I set it up. What commercial vendors offer out of the box has never been a good yardstick for talking about security features, and it's only gotten worse with the rise of the surveillance economy. 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.
helloooooooo 4y ago
Windows does all of those, in addition to fine grained access controls. I would go so far as to say that the Chromium sandbox implementation is better than on Android because of the ability to completely de-privilege processes.
- pl4nty 4y ago
  Windows struggles with feature adoption though. Win11 helped with the TPM requirement and features on by default, but MSIX apps are still underrepresented so userspace sandboxing is weaker. Windows virtualization-based security is great though, imo it's a significant advantage over Android
  - mike_hearn 4y ago
    MSIX doesn't implement sandboxing. Apps can opt in to being sandboxed via that tech, but you can also write totally unsandboxed apps. There's also a very light weight app container mode called (internally) Helium which just redirects some filesystem and registry stuff, but the goal is to make uninstalls clean, not security. 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.
    - mwcampbell 4y ago
      Is Helium mandatory for MSIX-packaged apps?
      - mike_hearn 4y ago
        I think they recently added a way to opt out of it entirely. That said, it does very little and because it's not a sandbox it's easy to 'escape': • 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.
goodpoint 4y ago
...assuming you blindly trust google. The same company that sends on average 12 MB of telemetries a day from android devices.
- mysterydip 4y ago
  Do you have a link for that? I'd love to send it to some friends.
  - ignoramous 4y ago
    Not OP; see: https://news.ycombinator.com/item?id=26639261 https://news.ycombinator.com/item?id=26639261
7e 4y ago
And yet law enforcement seems to be able to open up Android phones without issue, but has problems with iPhones. Is this still the case?
- sneak 4y ago
  Law enforcement has never had problems with iPhones. iPhones in the default configuration back up all data to iCloud with Apple keys, allowing Apple and the FBI to read all of the photos and messages on a device at any time, without the device. The "Apple vs FBI" thing was a coordinated PR campaign following the Snowden leaks to salvage Apple's reputation. https://www.reuters.com/article/us-apple-fbi-icloud-exclusive/exclusive-apple-dropped-plan-for-encrypting-backups-after-fbi-complained-sources-idUSKBN1ZK1CT https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
  - iosystem 4y ago
    Unsure why you're ignoring the difference of unlocking an iPhone to access the data on the phone compared to accessing data on iCloud.
- bestbuyer__ 4y ago
  Not really, companies like Cellebrite provide tools to access iPhones just the same.
closeparen 4y ago
What is an example of a workload on a smartphone that doesn’t handle PII?
astrostl 4y ago
> Android and ChromiumOS are likely the most trustable computing platforms out there Sweet, so we can trust that our personal machine is only compromised by Google et al? XD
noyoudumbdolt 4y ago
[flagged]
lumb63 4y ago
I can’t discuss my former role in too much detail, but it has convinced me that all the above is insufficient in a number of very realistic threat models. 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.
- b112 4y ago
  Why do companies tell users to “trust them” without any proof they are trustworthy? 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.
drozycki 4y ago
Hasn’t this all been long true for iOS as well? There are reasons to hate it, but a walled garden is safer in many ways (as long as you trust Apple). You mention baseband - Android hardware comes with max 3 years of baseband support, compared to 7-9 years on iPhone. The story is similar when it comes to stock OS support. So from my pov, iPhones can be a comparable value (security and otherwise) to the best Android has to offer, specifically because of their (usable to me and the next guy to own my phone) 7-9 years of life, compared to 3 years max with a Pixel. What am I missing here?
- omniglottal 4y ago
  Accuracy. You're missing "making accurate statements" here. And context - neither Apple's proprietary practices nor "trust" of them are applicable solutions to the problem domain here. A 7-9 year old iOS device is crippled today, with non-user-replaceable parts (both software and hardware). 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. 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.
  - TheHappyOddish 4y ago
    It seems you're the one lacking accuracy here. > 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.
jmole 4y ago
The problem is that third-party OEMs don’t have to run AOSP, they can easily replace any and all code with malicious call-home backdoors, and still pass CTS tests. 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.
Synaesthesia 4y ago
PRISM revelations showed that the state worked together with large companies like Google and Apple, MS, Facebook etc to gather information. The CIA also had backdoors into popular mobile and desktop OSes. I'm afraid we can't trust any device right now.
replwoacause 4y ago
You’re saying Android is more secure than iOS?
- ignoramous 4y ago
  There's been academic comparison between the two OSes in terms of data security that you might be interested in: https://archive.is/tYzcX https://archive.is/tYzcX / https://www.arxiv-vanity.com/papers/2105.12613/ https://www.arxiv-vanity.com/papers/2105.12613/ (caveat: Security posture on Android has changed quite a bit since that paper came out).
oneplane 4y ago
Considering the security UI layers control device access, I don't think AOSP or Android in general (with its many vendor customisations) is the most trustable. 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).
raxxorraxor 4y ago
My impression is that Android is compromised by design because it so easily leaks data that any defense against it already became futile. Apps might not have permissions to do anything, but the same is true for users. 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.
3327 4y ago
[dead]
deleted 4y ago
[deleted]
Abishek_Muthian 4y ago
I didn't know that pixels allowed custom ROMs to re-lock bootloader with custom keys, Digging into it I found that even OnePlus & FairPhone might have that feature.
zestyping 4y ago
These are all part of the operating system and unrelated to the biggest attack surface: apps. 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.
SkyMarshal 4y ago
How does iOS compare to Android and ChromiumOS these days?

BLKNSLVR 4y ago

Does LineageOS have a place alongside GrapheneOS and CalyxOS? 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.

ignoramous 4y ago
There's overlap between CalyxOS and LineageOS. CalyxOS (privacy-focused ROM, currently Fairphone and Pixel-only) has different goals to LineageOS (Android ROMs for as many phones as possible); while GrapheneOS is a security-focused distribution. DivestOS is another credible alternative.

andai 4y ago

> it seems it is most further ahead of the mainstream OSes 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?

transpute 4y ago
> Running blobs traditionally run in higher exception levels (like ARM EL2) in a restricted, mutually untrusted VM The pKVM hypervisor is new to Android 13 and requires Pixel 7 hardware, both of which are a few months old.
- milkey_mouse 4y ago
  pKVM (theoretically) works on Pixel 6, 6 Pro, and 6a as well.
lrem 4y ago
Isn’t most of the value here in not allowing sideloading? In iOS your grandma/child cannot be tricked into clicking “allow apps from untrusted sources”, which is how most breaches happen.
- gkbrk 4y ago
  If the apps sandboxed, how can installing an app cause breaches? As far as I know, iOS apps are sandboxed. 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.
  - Consultant32452 4y ago
    The sandboxes are regularly breached. Basically any time you hear about people "rooting" their phones, that's an intentional sandbox breach.
    - 4y ago

zython 4y ago

What is your opinion on ios Lockdown mode ?

Dma54rhs 4y ago
You cant verify but just take Apples word for it, it's not a fair comparison in my opinion.
- ylk 4y ago
  What do you want to verify exactly? Do you think Apple is lying about what lockdown mode does? Why would they do that? Could you at least say what your opinion is based on? 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 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.
  - Godel_unicode 4y ago
    What if he’s wrong? Computers do things their programmers don’t expect them to literally all the time. Security bugs generally come from a mistaken assumption about how something behaves. He doesn’t have to be a liar to be telling you untruths about how it works.
    - ylk 4y ago
      What if everyone is wrong about the effectiveness of Android’s mitigations? Then iOS would be more secure. Could you please make concrete a point?
      - Godel_unicode 4y ago
        You asked why we would need to verify things he said. I explained it quite concretely. What part did you not understand? Edit: whether people are wrong about android security is orthogonal and whataboutism

lrvick 4y ago

IMO we have to step back and be honest that the Linux kernel is simply not equipped to run trusted code and untrusted code in the same memory. New bugs are found every few weeks. 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.

flanked-evergl 4y ago
> Linux kernel is simply not equipped to run trusted code and untrusted code in the same memory. Just for interest sake, is Linux better or worse than MacOS, iOS and Windows at this?
- aseipp 4y ago
  It's... complicated. Linux is just the kernel, but good modern OS security requires the kernel, the userspace, and the kernel/userspace boundary to all be hardened a significant amount. This means defense in depth, exploit mitigation, careful security and API boundaries put in place to separate components, etc. 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.

pontilanda 4y ago

All that looks good on paper, but a lot of apps require full disk access and can easily run in the background, so how "trustable" can that really be in practice? 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"

jacooper 4y ago
On GrapheneOS you can choose specifc storage scopes, even if the app is requesting full user storage access. 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.
Grim-444 4y ago
Well both of your complaints were already addressed. Android introduced the scoped storage system to remove and fix abuse of "full" disk access, and they also added the foreground notification system which forces a system notification to be displayed if any app is doing work in the background, so that you know about.
- drozycki 4y ago
  Right, but if the average real-world Android experience lags behind say iOS in terms of security, then the point, even if outdated, still serves to disprove the parent’s premise that AOSP is the most secure.
derkades 4y ago
In recent years, I have not seen any app request full file access permissions besides file managers

tete 4y ago

> Android and ChromiumOS are likely the most trustable computing platforms out there 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.

solarpunk 4y ago
This page has stuck with me since I read it regarding openbsd. It's a bit mean spirited, but I think openbsd mostly benefits from its own obscurity. https://isopenbsdsecu.re/ https://isopenbsdsecu.re/ 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.

mindslight 4y ago

Most of your bullet points are reinventions of standard technology or incidental complexity. 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").

ignoramous 4y ago
> Everything else would seem to be a reimplementation of common best practices... 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.
- mindslight 4y ago
  Sure, but full disk encryption was also enabled on my Mom's Ubuntu laptop 15 years ago, because I chose the correct options when I set it up. What commercial vendors offer out of the box has never been a good yardstick for talking about security features, and it's only gotten worse with the rise of the surveillance economy. 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.

helloooooooo 4y ago

Windows does all of those, in addition to fine grained access controls. I would go so far as to say that the Chromium sandbox implementation is better than on Android because of the ability to completely de-privilege processes.

pl4nty 4y ago
Windows struggles with feature adoption though. Win11 helped with the TPM requirement and features on by default, but MSIX apps are still underrepresented so userspace sandboxing is weaker. Windows virtualization-based security is great though, imo it's a significant advantage over Android
- mike_hearn 4y ago
  MSIX doesn't implement sandboxing. Apps can opt in to being sandboxed via that tech, but you can also write totally unsandboxed apps. There's also a very light weight app container mode called (internally) Helium which just redirects some filesystem and registry stuff, but the goal is to make uninstalls clean, not security. 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.
  - mwcampbell 4y ago
    Is Helium mandatory for MSIX-packaged apps?
    - mike_hearn 4y ago
      I think they recently added a way to opt out of it entirely. That said, it does very little and because it's not a sandbox it's easy to 'escape': • 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.

goodpoint 4y ago

...assuming you blindly trust google. The same company that sends on average 12 MB of telemetries a day from android devices.

mysterydip 4y ago
Do you have a link for that? I'd love to send it to some friends.
- ignoramous 4y ago
  Not OP; see: https://news.ycombinator.com/item?id=26639261 https://news.ycombinator.com/item?id=26639261

7e 4y ago

And yet law enforcement seems to be able to open up Android phones without issue, but has problems with iPhones. Is this still the case?

sneak 4y ago
Law enforcement has never had problems with iPhones. iPhones in the default configuration back up all data to iCloud with Apple keys, allowing Apple and the FBI to read all of the photos and messages on a device at any time, without the device. The "Apple vs FBI" thing was a coordinated PR campaign following the Snowden leaks to salvage Apple's reputation. https://www.reuters.com/article/us-apple-fbi-icloud-exclusive/exclusive-apple-dropped-plan-for-encrypting-backups-after-fbi-complained-sources-idUSKBN1ZK1CT https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
- iosystem 4y ago
  Unsure why you're ignoring the difference of unlocking an iPhone to access the data on the phone compared to accessing data on iCloud.
bestbuyer__ 4y ago
Not really, companies like Cellebrite provide tools to access iPhones just the same.

closeparen 4y ago

What is an example of a workload on a smartphone that doesn’t handle PII?

astrostl 4y ago

> Android and ChromiumOS are likely the most trustable computing platforms out there Sweet, so we can trust that our personal machine is only compromised by Google et al? XD

noyoudumbdolt 4y ago

[flagged]

lumb63 4y ago

I can’t discuss my former role in too much detail, but it has convinced me that all the above is insufficient in a number of very realistic threat models. 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.

b112 4y ago
Why do companies tell users to “trust them” without any proof they are trustworthy? 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.

drozycki 4y ago

Hasn’t this all been long true for iOS as well? There are reasons to hate it, but a walled garden is safer in many ways (as long as you trust Apple). You mention baseband - Android hardware comes with max 3 years of baseband support, compared to 7-9 years on iPhone. The story is similar when it comes to stock OS support. So from my pov, iPhones can be a comparable value (security and otherwise) to the best Android has to offer, specifically because of their (usable to me and the next guy to own my phone) 7-9 years of life, compared to 3 years max with a Pixel. What am I missing here?

omniglottal 4y ago
Accuracy. You're missing "making accurate statements" here. And context - neither Apple's proprietary practices nor "trust" of them are applicable solutions to the problem domain here. A 7-9 year old iOS device is crippled today, with non-user-replaceable parts (both software and hardware). 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. 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.
- TheHappyOddish 4y ago
  It seems you're the one lacking accuracy here. > 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.

jmole 4y ago

The problem is that third-party OEMs don’t have to run AOSP, they can easily replace any and all code with malicious call-home backdoors, and still pass CTS tests. 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.

Synaesthesia 4y ago

PRISM revelations showed that the state worked together with large companies like Google and Apple, MS, Facebook etc to gather information. The CIA also had backdoors into popular mobile and desktop OSes. I'm afraid we can't trust any device right now.

replwoacause 4y ago

You’re saying Android is more secure than iOS?

ignoramous 4y ago
There's been academic comparison between the two OSes in terms of data security that you might be interested in: https://archive.is/tYzcX https://archive.is/tYzcX / https://www.arxiv-vanity.com/papers/2105.12613/ https://www.arxiv-vanity.com/papers/2105.12613/ (caveat: Security posture on Android has changed quite a bit since that paper came out).

oneplane 4y ago

Considering the security UI layers control device access, I don't think AOSP or Android in general (with its many vendor customisations) is the most trustable. 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).

raxxorraxor 4y ago

My impression is that Android is compromised by design because it so easily leaks data that any defense against it already became futile. Apps might not have permissions to do anything, but the same is true for users. 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.

3327 4y ago

[dead]

deleted 4y ago

[deleted]

Abishek_Muthian 4y ago

I didn't know that pixels allowed custom ROMs to re-lock bootloader with custom keys, Digging into it I found that even OnePlus & FairPhone might have that feature.

zestyping 4y ago

These are all part of the operating system and unrelated to the biggest attack surface: apps. 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.

SkyMarshal 4y ago

How does iOS compare to Android and ChromiumOS these days?