Hacker News Reader

Comment by palata | Hacker News Reader

Let's make a thought experiment: let's think about designing a new Linux distro from scratch. Obviously starting with Linux-the-kernel, and then thinking about what we need to be a modern smartphone OS.

- We'll probably want the security model, with the nice sandboxing and I would argue the verified boot.

- We'll want the battery optimisation.

- We'll want access to the firmwares of the components running in the phone.

- ...

From the very first step "start from Linux-the-kernel", every single question I ask myself goes towards the Android design and away from the classical Linux distro design.

In other words, the open source Linux distribution that is the closest to a modern mobile system is... Android :-).

View on HN

The best battery life I ever got on a smartphone was on a HTC One X back in 2013 or so. It had a custom ROM (Paranoid Android IIRC) where I stripped out all the google services, blocked all wakelocks and so on. It had an nvidia Tegra3 CPU, which had 4 normal ARM cores and a 5th tiny core that ran at 100Mhz or so max (with powersave governor). On that setup, when I was not using it, it drained like 2% battery a day (50 day runtime). Since then we went from 40nm to 3nm, 2000mAh to 5000mAh, I'm doing the same things on my phone and yet, due to bloat and spyware the battery life is worse and worse. I went through HTC One m8, HTC 10, OnePlus 7Pro, and a Samsung Fold7 and each had worse efficiency than that 2011 CPU on the OneX (And a Nexus7-2012 until it died due to low quality NAND)

"I had a phone where I disabled most of its smartphone features and broke them" is not really how you get a useable OS.

Reminds me of those dudes who think a terminal console with broken bluetooth is sufficient to make a macOS Linux distro competitor.

I mean, it was still connected to a cell network, so it was fully usable except maybe notifications. (Obviously the battery drained faster during active use)

Ah, except ONLY notifications? Wow, really not important for a smartphone. Not to mention other background operations that most people want to rely on.

See back to my point about terminal dudes with broken laptops thinking that's good enough.

Even more so, it is the closest to Inferno's design, which was the evolution the UNIX founders went through.

Like they created UNIX, they declared it done, created Plan 9, followed by Inferno, most as a reaction to JavaOS, but still, the creators of UNIX moved on.

Whereas the FOSS community seems to be stuck in recreating Bell Labs in the 1970's.

Most of the FOSS community is hostile to even creating basic sandboxing. The Flatpak project gets panned all the time. Not for having a weak sandbox (which would be a fair criticism), but for having a sandbox at all and not using 90s-style package management.

A lot of people from the FOSS community seem to believe that (at least from recurring discussions) that Linux is secure because the software is open source and you can trust the maintainers. The idea that even trusted software can have vulnerabilities and that the 80s/90s security model of the standard Linux desktop means that you are only one Mastodon/e-mail/RSS/whatever client vulnerability away from exfiltration of your whole home directory does not even occur to them. All the while all these applications use (XML/image/...) parsers from the 90/00s written in C.

The only reason we don't see mass-exfiltration of data is because the Linux desktop marketshare is effectively meaningless. Though we see some results of the desktop security disaster (also to some extend of macOS) through leaked credentials obtained by compromised NPM, PyPI, etc. packages.

> Most of the FOSS community is hostile to even creating basic sandboxing.

> 90s-style package management

> 80s/90s security model

> parsers from the 90/00s

Perhaps the crux of the issue, and the reason these new systems get pushback, is because people, myself included, don't like being told that they have to stop using the tools that served them well for arbitrary reasons (usually age). Similarly, you can't expect everyone to trade user control, convenience, usability, and more for security, or sometimes perceived security.

We can debate about the 90s style package management, but old C-based file parsers and DAC access control were certainly not designed for modern attack vectors. Defending a device now requires layered security using a combination of among other things:

- Memory-safe languages where possible.

- Sandboxing of applications, parsers, etc., along with a strong permission model.

- Mitigation like secure app spawning, zeroing out pages, etc.

- Modern mitigation hardware-assisted mitigation like MTE and PAC.

- Storing secrets in a separate secure enclave (not ~/.config or ~/.ssh).

- Read-only and fully verified system partitions (anti-persistence).

This graph:

https://security.apple.com/assets/image/generated/xlarge_adv...

from Apple's MIE docs [1] shows where modern systems like iOS and Android are. An attacker often needs a long exploit chain to compromise a device and it becomes increasingly difficult with various mitigation techniques. On the standard Linux desktop it's often as easy as exploiting an image parser in a client. Old parsers in C have a history of bad vulnerabilities, exploiting one often gives you privileges of the process calling the function, since Linux applications mostly don't separate/sandbox parsers and from there you have direct access to all data of the user, since Linux applications are typically not sandboxed.

[1] https://security.apple.com/blog/memory-integrity-enforcement...

Lets not forget that the motivations for Alef, and Limbo, from the C authors themselves, were also to improve language safety.

In Inferno, only the kernel, DisVM (+ JIT), and a few drivers are still C, everything else in userspace is Limbo.

> Limbo is the application programming language for the Inferno operating system. Although Limbo looks syntactically like C, it has a number of features that make it easier to use, safer, and more suited to the heterogeneous, networked Inferno environment: a rich set of basic types, strong typing, garbage collection, concurrency, communications, and modules. Limbo may be interpreted or compiled ‘just in time’ for efficient, portable execution.

https://doc.cat-v.org/inferno/4th_edition/inferno_OS

And even if the design isn't the best in the world, it was then followed by Go, it was not what Google is doing in C++ should be redone in C.

https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

Another angle on this is general reliability and what that does to the experience. I'm reminded of Linus having a moan about poor availability of ECC in consumer RAM and how many errors that get blamed on software are actually down to something happening to hardware but it isn't specifically identified. Plus when you're talking billions of devices even small proportions are significant. Firefox built a memory tester into their bug reporter tool as that 'noise' became a large enough problem for them.

Yeah, pretty much so.

Which is of course after having met those requirements IOS is basically android with a different name and closed source and we only need one player that isn't even properly foss. Or why ChomeOS invalidates the need to keep working on kde/gnome/etc

Or that isn't the case and this is all just a silly comparison.

Sorry I don't understand. Would you mind rephrasing that?

He’s saying the examples given were so generic that every OS that cares about battery life and security would just be Android. Battery life optimizations and sandboxing don’t make Android inevitable or the only option.

WebOS was a 3rd option until HP sold it off. Microsoft also had a go at it. They were both very different than Android, but would have those features (if not then, they’d have them by now if the projects were still going).

Well then he is missing my point. Which may mean I was unclear, or course.

My point was that "Linux on Mobile" seems to be mentioned a lot when talking about an alternative to evil BigTech. The thing is, if you want to fork something and make it a modern mobile OS, you may as well just fork Android and go from there. Because Android is open source and already has billions of apps.

Microsoft didn't make an open source system, I think? I had never heard of WebOS, so I'd be open to it, but the fact is that the "Linux on Mobile" crowd is more into Alpine or Debian running on a mobile. Which is far from a modern mobile OS.

I totally respect the Linux on Mobile projects, they do a lot of cool stuff. But I don't see that being a serious alternative to modern mobile OSes anytime soon.

I didn't go into that in this article, but given the number of comments here and on Reddit, I think I should write a second article that explains my thoughts on why I think Linux phones are better strategically than AOSP phones. I'm not opposed to AOSP phones--I use my two AOSP phones more than my two Linux phones. Most people aren't going to use the current Linux phones. Even I as someone who has using Linux since 1999 find that the functionality of the current Linux phones doesn't match AOSP phones. However, I think using AOSP helps lock us into the Android ecosystem, whereas using Linux helps build an alternative ecosystem which is what we need for long-term independence and freedom.

> which is what we need for long-term independence and freedom

Sources are required here. I think that Android being open source is great, and I actually run a fork of Android (GrapheneOS) which is great.

Again I am not against the Linux on Mobile initiatives. I have been trying them, and following since 2020. I stopped following a bit in the last couple years, but really, what I see is many Linux on Mobile projects that seem to focus on "having a nice UI" and supporting waydroid and being able to use the phone like a normal phone (that is, being able to call someone). And a ton of work mainlining mobile hardware, which I do respect a lot. However, I haven't seen much (or anything at all, really) around the security model.

In other words, the Linux on Mobile philosophy is really "bring a traditional Linux distro to the mobile phone". And the traditional Linux distro doesn't have a security model that works for a modern mobile phone, period.

I would argue that if you rethink the traditional Linux distro to have a modern security model for mobile phones, then it stops counting as a traditional Linux distro and it becomes a new mobile system. Which would be very hard (again, resources against Android), but seems out of topic because this is not what Linux on Mobile is.

It’s just a question of funding. Ubuntu made a push for mobile years ago. They put up a phone on Indiegogo, but it didn’t hit its funding goal.

https://en.wikipedia.org/wiki/Ubuntu_Edge

This is what their Unity Desktop was for as well. A desktop environment that had a consistent design language from desktop to mobile.

The remnants of all of this are still kicking around, I think the community still maintains the phone OS, but without the weight of Canonical really pushing it, and a phone shipping with the OS pre-installed, it won’t get as far.

And did UbuntuOS have an actual security model?

I never looked into it, but I would assume it handles security the same way Ubuntu does.

Which makes it less secure than a modern mobile OS, right? That was my point above.

Android's security model isn't the only inevitable option. It was an absolute mess when it launched, to the point where I didn't feel comfortable using any apps from the Play Store and gave up even trying the use the platform. They've since copied a lot of the security controls from Apple, from what I understand, but last I looked, I still like how Apple handles things better.

So even in the world we live, there are 2 platforms that handle security in 2 different ways. Those ways have evolved over time. Ubuntu Touch was made 13 years ago. What did security look like on Android 13 years ago? It's a bit unfair to judge it by today's standards. We can only assume an actively developed OS, being used by normal people (not just hobbyists), would evolve and grow to meet the needs of the platform in the market.

I also assume one of the reasons people want a Linux phone is to have more control, having root without needing to jump through hoops, side loading apps, building from source, etc. They don't want to be locked in a sandbox. I think there is also an assumption that people will play better in a classic Linux environment where there aren't so many financial incentives, and anyone who tries to implement the kind of data collection we see on most modern platforms would be booted from the ecosystem until they can play nice. It would be nice if the current duopoly would do some of this, but most people don't care, and pulling apps from the app stores for breaking the rules is incredibly unpopular.

> Android's security model isn't the only inevitable option

I never said it was. I said "we need a modern security model in a modern mobile OS, and Linux on Mobile doesn't remotely have that".

> Ubuntu Touch was made 13 years ago. What did security look like on Android 13 years ago?

That's a bit my point. If Linux on Mobile is 13 years late, against modern mobile systems that get the resources they get (that is, orders of magnitude more than Linux on Mobile), you're not really catching up. And if you had enough resources to maintain such a project, maybe it would be interesting to fork AOSP instead of spending a decade catching up?

> We can only assume [...] would evolve and grow to meet the needs of the platform in the market.

Is that the only assumption we are allowed to make? When countless alternatives from Microsoft, Samsung and others failed?

> I also assume one of the reasons people want a Linux phone is to have more control, having root without needing to jump through hoops, side loading apps, building from source, etc.

Totally, this is what many of them say. Though side loading, building from sources and the "etc" I can imagine totally work with AOSP. I can easily have root on AOSP, I don't know what "jumping through hoops" means here (other than "I want it enabled by default on official builds").

> I think there is also an assumption that people will play better in a classic Linux environment

I believe that GrapheneOS plays nice and makes a nice system. As for the apps, I barely use tens of apps (realistically I mostly use what... ten of them?), so it's not completely crazy to ask me to select 10 good apps from the billions available. And those that are proprietary (e.g. for public transport) I wouldn't have a choice on Linux (probably they wouldn't exist there).

> but most people don't care

I do care. I run GrapheneOS. Because I disagree with you does not mean I do not care.

Reply on news.ycombinator.com