Live data from Hacker News

Your phone is about to stop being yours

keepandroidopen.org

781–790 of 927 posts

Re: Your phone is about to stop being yours

#782
post #741
post #732

Respectfully, I think this is the wrong fight. And I fear it may be counter-productive, because all the effort put into asking Google to make it a little less painful to install an unverified app is not put into the real fight. IMHO, it should be fine for Google or Apple to do whatever they want with their OS. What should be forbidden is to prevent people from installing an alternative OS on their hardware. But this…

ARM doesn't have any initialization/boot standard enforced on phone manufacturers so everyone is doing their own and never upstreams anything. It's a general ARM problem. PC with some lucky coincidence avoided that fate and we got used to it. RISC-V is in even worse shape than ARM as the fragmentation is even at the CPU instruction level. Both ARM and RISC-V have some discussions/proposed standards but nothing enforc…

Nevertheless, postmarketOS manages to run Linux without Android on quite a few phones.

Re: Your phone is about to stop being yours

#783

Earlier quoted context omitted.

Quite frankly, the whole Librem ecosystem is significantly less "open" than GrapheneOS or any desktop Linux variant to anyone who look at things objectively instead of using weird FSF semantics. Instead of loading firmware in sensible manner like GrapheneOS or desktop Linux distros with the linux-firmware package, they keep PureOS "free of blobs" by having the bootloader inject all of the blobs into memory in an extr…

> Quite frankly, the whole Librem ecosystem is significantly less "open" than GrapheneOS or any desktop Linux variant to anyone who look at things objectively instead of using weird FSF semantics. You will have a point when your Google phone runs Replicant. Now this is just empty words, i.e., FUD. Which blobs are running on the Librem 5 CPU? Which blobs are running on GrapheneOS CPU?

Which blobs are running on the Librem 5 CPU? Which blobs are running on GrapheneOS CPU?

Both the Pixel and Librem 5 have firmware baked into the SoC that is executed.

On GrapheneOS, the firmware is signed and updated along with the OS.

On the Librem 5, the firmware for Wifi/Bluetooth is stored on a NOR chip, which is read from and mounted into the OS by the initramfs into /lib/firmware.

Not-withstanding the above, Librem 5 components such as the USB controller, touch screen controller, radios, battery, etc simply have closed-source firmware baked in (stored on some flash chip on these components), but it doesn't mean that they are not there or in use.

In both cases, components either do not get proper firmware updates from the OS, or they are too old/low quality to get any firmware updates from the vendors to begin with. Storing firmware on the component is also a less secure approach than having signed firmware loaded by the OS, as it now means that these components have persistent storage which can be attacked.

Aside from all of the above, they also use a dedicated CPU core to run firmware blobs for things like memory training.

In essence, what the Librem 5 has achieved is shuffling proprietary firmware storage around instead of eliminating their existence or execution. It is not any more "free" or "open" than anyone else while also being less secure.

Re: Your phone is about to stop being yours

#784
post #16

Let me play out a scenario, imagine to use a Desktop Hardware like a complete built rig, you would need a specific OS like Windows 11 and you could not run Linux on it, just because it's a vendor lock-in. Why is this acceptable for phones but would not for the case above? I know a lot of people don't care, and that's ok, but we should root for an open choice for the users.

It’s the same situation as game consoles. Custom built hardware that is only meant to run the one specific vendor OS. There have been many other computing devices like that in the past as well. The general purpose desktop computer that allows a choice of operating systems is actually less common than the other way. Historically, people didn’t expect to run alternate operating systems on a mainframe, 80s and 90s compu…

Steam Deck exists and works quite well. No lock-in necessary.

Re: Your phone is about to stop being yours

#785

Earlier quoted context omitted.

Not OP, but > This is false. Please stop writing false statements without any links. NXP promises to produce the i.MX 8M Quad until Jan. 2033. The support will be even longer. I think they meant that the processor itself is old. It supports ARMv8 and is lacking the enhanced memory protection and execution features of the ARMv9-A processors on newer phones. > This is false again. It doesn't matter how much my device m…

The kill switches will work independently on a compromise. Why are they moot? Also, it's possible to completely reflash the device in case of doubt. "quite easily" strongly depends on what exactly you are doing. For example, if I use Firefox with NoScript, then it is not very easy.

> The kill switches will work independently on a compromise. Why are they moot?

Kill switches only work as a security feature when you activate them before you know you're compromised. But that's impossible.

It's a reactive "security" feature not a proactive one.

> For example, if I use Firefox with NoScript, then it is not very easy.

Security vulnerabilities aren't only JS related.

https://www.mozilla.org/en-US/security/advisories/mfsa2026-3...

https://www.mozilla.org/en-US/security/advisories/mfsa2026-3...

Adding an extension that can access all your browsing data doesn't seem very secure either.

Required permissions:

- Access browser tabs

- Access browser activity during navigation

- Access your data for all websites

Re: Your phone is about to stop being yours

#786
post #617

You know, I'm fine with this (just as long as the opt-in is one-time, not for every install). A device maker needs to balance the interests of many different groups, including nontechnical users subject to scams, and it's pretty self-centered to get self-righteously outraged when things get a little harder for power users, when those changes may save the butt of a lot of other people. The only thing that gives me pau…

I find it quite interesting that peoples talking on a website called "hacker news" find it fine that a company selling you an OS make it harder for you to install app not approved by them, notably so when there is enough scare screens as of now to discourage any too gullible peoples to do so. What would we think if Microsoft decided all of a sudden to do something similar with Windows? How there is no outrage about t…

> I find it quite interesting that peoples talking on a website called "hacker news" find it fine that a company selling you an OS make it harder for you to install app not approved by them

I'm trying to get outside the myopic software engineer/geek mindset.

> notably so when there is enough scare screens as of now to discourage any too gullible peoples to do so.

Apparently the existing screens are not sufficient, and I buy that. I think the cooling down period is a good idea, because otherwise many people will just do as they're told because they don't understand what they're doing and are too trusting.

> What would we think if Microsoft decided all of a sudden to do something similar with Windows? How there is no outrage about this in that community?

Where is the outrage about nontechnical people getting misled and scammed?

Re: Your phone is about to stop being yours

#787

Earlier quoted context omitted.

I use GrapheneOS too. Most of the time it works great, with some weird bugs around group messages and needing to restart every now and then to get to a fully functional state between the browser and keyboard properly working with each other and the network connectivity going away. I do enjoy full control on network connectivity and notifications. But beyond whether the OS is good or not, "fuck you, I've got mine" is…

> But beyond whether the OS is good or not, "fuck you, I've got mine"... What about, "I got mine and you can have it to." Nobody is preventing access to graphene.

>>> I don't care, I run Graphene, and my phone is definitely mine.

I really don't see an implied "and you can too".

Re: Your phone is about to stop being yours

#788
post #732

Respectfully, I think this is the wrong fight. And I fear it may be counter-productive, because all the effort put into asking Google to make it a little less painful to install an unverified app is not put into the real fight. IMHO, it should be fine for Google or Apple to do whatever they want with their OS. What should be forbidden is to prevent people from installing an alternative OS on their hardware. But this…

I agree with you, but even with the ability to install your own OS properly, you can't necessarily use some of the hardware.

As I recall from Ubuntu Touch, they had to build a system that was a thin wrapper around Android so that they had access to firmware blobs.

I guess that would still be ok as long as the hardware component manufacturers don't start to require authentication from the OS. That would be along the same lines as the fight you're describing.

Re: Your phone is about to stop being yours

#789

Earlier quoted context omitted.

> Which blobs are running on the Librem 5 CPU? https://source.puri.sm/Librem5/fw https://source.puri.sm/Librem5/fw/firmware-librem5-nonfree https://source.puri.sm/Librem5/librem5-fw-jail/-/tree/pureos... > Which blobs are running on GrapheneOS CPU? Depends on the phone. Arguably though, GrapheneOS has the legacy of years of thousands of security researchers working to secure Android from third-party network and GNSS…

In this case I do not understand why you are ignoring the words of a Librem 5 developer saying that no blobs are running on the main CPU: https://news.ycombinator.com/item?id=47943487

I'll take his word that no blobs are running on the main CPU. But the process itself is error prone. It's mounting flash storage with blobs into the filesystem of the OS. The OS can load modules directly from the storage.

> There is not a single non-free blob in the OS that runs there once the bootloader is up (unless you put some there by yourself, which you're of course free to do).

"unless you put some there by yourself, which you're of course free to do" also means unless someone else puts one there.

---

I think the "firmware jail" loader also uses Smart Direct Memory Access (SDMA)?

---

You can run blobs on the main CPU with strong isolation with TEE and other hardware security features.

Re: Your phone is about to stop being yours

#790
post #732

Respectfully, I think this is the wrong fight. And I fear it may be counter-productive, because all the effort put into asking Google to make it a little less painful to install an unverified app is not put into the real fight. IMHO, it should be fine for Google or Apple to do whatever they want with their OS. What should be forbidden is to prevent people from installing an alternative OS on their hardware. But this…

I agree with you, but even with the ability to install your own OS properly, you can't necessarily use some of the hardware. As I recall from Ubuntu Touch, they had to build a system that was a thin wrapper around Android so that they had access to firmware blobs. I guess that would still be ok as long as the hardware component manufacturers don't start to require authentication from the OS. That would be along the s…

I think that for the first step, we need to make sure that AOSP forks can work. And those can just copy the binary blobs.

Don't get me wrong: I like all alternatives. But the most realistic alternative to Stock Android is based on AOSP. In good approximation, today nobody would want anything else.

If we get there, then the next step is to get open source firmwares. But I don't know much about that and it feels like it is a much harder fight. Hardware manufacturers probably strongly believe that they will lose their competitive advantage if they open source their firmwares, and I don't know how true that is.

Post reply on HN