That's a cynical and paranoid mindset. Bloat is a lazy tendency not a malicious evil and developers tend to optimise for the latest and greatest if left unchecked and forced to consider backwards compatibility.

> Better have a bricked phone but secured phone?

lets just say don't do any financial transactions on the device or appreciate the general openness of your phone to malicious actors who might use it for nefarious purposes.

As a user, do I care whether my phone is unusable because the developers wanted specifically to render older hardware unusable or whether it was just through their negligence in failing to consider older devices? Stupidity or malice, the result is the same.

lets just say don't do any financial transactions on the device or appreciate the general openness of your phone to malicious actors who might use it for nefarious purposes.

I keep hearing this, but what's the actual presence of malware on Android? If you're not installing shady apps from the Play Store, what's your actual level of risk? Android, even old versions of Android, are far harder to reliably exploit than say, unpatched Windows. As long as you're not installing free-to-play flashlight apps that require every permission under the sun, I'd say your exposure to malware on Android is far less than it is on PC. For the average user, they're still probably better off conducting financial transactions on their phone than conducting those same transactions on their malware ridden laptops.

Yes but whether we attribute the intent to stupidity or malice is important as per the general health of our thought process. Its likely laziness combined with malice when its noted. I imagine a dev getting up in arms about package size and then when the issue is raised its not given high priority because someone twigs the convenient side effect. That's the worst case. Either way the mindset of paranoia is warped and self centred. Its not because they're thinking of forcing you to upgrade its more because they're _not_ thinking of you and instead the wide-eyed new sales opportunities that ship with greater disc space.

> I keep hearing this, but what's the actual presence of malware on Android?

oh wow, you're gonna play this game? I could tell you that its perfectly safe to trace the outline of a cliff with your feet and in many, many cases its going to be absolutely fine until the one case where the earth gives way and its not.

Let me put it this way; when I see the tagline:

> there are over a billion outdated Android devices

my first thought is:

> what's the most effective exploit to tap into that market?

the existence of security flaws encourages action and the hubris of not updating is the clarion call to those that exercise the exploits.

> I'd say your exposure to malware on Android is far less than it is on PC

This. What is this? This is complete conjecture. Get out of here.

> > what's the most effective exploit to tap into that market?

So??? What is it? Do let us know.

I'd venture to say that the fragmentation of that market makes it reasonably secure. Just like how the average router is incredibly insecure, and yet you don't advise people to avoid e-banking and just deal with their money in paper form and through face-to-face contacts.

Yes, you are technically right. But @quanticle is right, in practice: unless those users do some very stupid shit, they're pretty safe doing ebanking on their phones. (and those who do the "very stupid shit" are likely to do it on their computers, too)

I'm not claiming that Android is safe. Nothing is safe. But it does security professionals no good to be alarmists. If we cry wolf about literally every technology that ordinary people use, the result is not people giving up technology. The result is people ignoring security professionals.

If an ordinary user came to you and asked, "Where should I do my banking? On my phone or on my PC?" what would your answer be?

I wish I could quantify that. It's a hard task. But the store is not the only possible vector. On an old Android you're running a very outdated version of Chrome when looking at any pages / ads. That would be the most exposed/insecure element in the system.

The same is valid for the system WebView, but "only" since Android 4.4. It is updated via Play Store, independently from the base system.

> As someone who goes as long as possible without performing updates

I take that to mean without updating the apps either, not just the os. I've seen people reject any kind of upgrades.

You should rather hope for GNU/Linux phones. Linux devices (without the GNU part) is most of the time, just another locked device (see your Android phone, router, TV, etc).

The presence of GNU software pieces (or any software licensed under GNU [LA]GPL v3+) ensures the device is free of locks (or with user breakable locks).

That's not true, as the Linux kernel is still GPLv2. So while you could swap out the userspace GNU utils, the device manufacturer can still lock the bootloader which is perfectly fine with the GPLv2.

Even if the bootloader is unlockable (e.g. LG allows this btw), you will most likely be stuck to a specific kernel version due to proprietary binary blobs which nearly every phone uses.

So instead of a GNU/Linux phone, you should rather hope for a phone with complete open source drivers (or a GPLv3 kernel).

Yeah, probably. But the presence of packages like GNU libc can make it harder for the manufacturer to lock the device.

> ... kernel version due to proprietary binary blobs which nearly every phone uses.

Sadly, binary blobs are always an issue. In the case of Linux, this happened because many Linux developers don't care about binary blobs. If they did, you won't see any binary blobs (as it is a violation of GNU GPL).

> ... with complete open source drivers

My main point was to quote that 'open source' doesn't solve these issues. We should take software freedom more seriously.

> ... (or a GPLv3 kernel).

I wish we will not have to wait until the human civilization end in fire to see this.

It is mostly users, not developers, who don't care about binary blobs. The users then take the "pragmatic" approach of using binary blobs, but hey, stuff works for them.

See also the Nvidia binary driver. Who is the advocate for that? Users (hey, never had a problem and it runs my apps very well) or developers (whoa, we cannot develop Wayland/etc with this)?

Partly yes, but mostly No.

You are right that most people don't care about binary blobs. But the people who can enforce this are the developers. If all developers agree and enforce this, no on can include binary blobs in Linux kernel.

Also it would be wrong for a mere user to try to enforce it by law, because it might piss off the developers, which is really bad. Also, it might not withstand in court because the developers don't care.

> The users then take the "pragmatic" approach of using binary blobs, but hey, stuff works for them.

"pragmatic"? Most of us are concerned about our immediate problems, and thus we end up with temporary solutions (most of the time), sometimes because we don't have choice, sometimes because that's easier.

I recently got an ASUS eeepc which doesn't have graphics support, because when it was first released, the only support was a binary blob, which is now abandoned.

We will eventually face issues with these binary blobs, for sure. As we know, each day, new vulnerabilities are being surfaced.

But yeah, most of us won't care, until and unless something happen. But by then, it will be too late. Just like how many of us consider the importance of time only when we know we don't have enough.

So I don't think it is "pragmatic" in long term.

And yet, it is the users who have the ultimate power over developers of such hw/sw. No, not courts, that's the entirely wrong solution.

Their wallets.

Such solutions are being developed only because there's money in it. It is only up to the users, whether this factor is true or not. If they care about sources, they would not purchase hardware that requires blobs. If they don't care, and reward the developers with their money for the blobs, whose fault it is?

glibc is LGPL, so I don't see how that should change anything?

> (as it is a violation of GNU GPL).

IIRC it's a gray area.

glibc requires libgcc[0], which is GPLv3 (with runtime exception). The same for libstdc++[1].

[0] https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html [1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html

The kernel really is the problem here and where there's no GPLv3 code used at all.

I think what you're arguing is that Android isn't GNU/Linux or that Android isn't libre like what we've come to expect from desktop distributions of Linux.

Librem 5, the phone that focuses on security by design and privacy protection by default. Running Free/Libre and Open Source software and a GNU+Linux Operating System designed to create an open development utopia, rather than the walled gardens from all other phone providers.