Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keep Android Open

f-droid.org

Post reply on HN
Print view View original

531–540 of 764 posts

Re: Keep Android Open

#531

Post by microtonal »

Onawa wrote: post #259
paulryanrogers wrote: post #218

Earlier quoted context omitted.

It's also high risk. I've bricked two phones doing it.

I've been flashing phones for over 2 decades and have never bricked a phone. How did you manage that?

Lots of people brick their phones by relocking the bootloader when the Android SPL before flashing was newer than the newly flashed OS when the phone has downgrade protection (e.g. Fairphone 6). The Fairphone/e Foundation forums are pretty full of people making this mistake. Then the only solution is paying Fairphone to fix it.

Re: Keep Android Open

#533

Post by microtonal »

kllrnohj wrote: post #384
user3939382 wrote: post #263

Earlier quoted context omitted.

Are you seriously implying that flashing phones doesn’t risk bricking them or you’re not aware of that risk are you serious?

"flashing" a phone is largely the same as any OTA update. There's of course always a risk of it going wrong, disk failures are always possible, but it's exceptionally hard to do so accidentally. Especially with custom ROMs where they basically never include a new bootloader, so "flashing" is no different than installing an OS on a desktop system - it's just writing to the boot partition. Which you can always do again…

It is not 'largely the same as OTA' on phones with downgrade protection. Once you lock the device again, it's game over because the bootloader refuses to boot an older version of the OS, and you cannot unlock the phone anymore. Happens all the time in the /e/OS and Fairphone forums.

It really depends on the device. E.g. Pixel is quite hard to brick. Though they do sometimes increment the anti-rollback version:

https://developers.google.com/android/images

In that case you have to be careful to not flash an older version to both slots and lock the bootloader, which is possible, because many non-Google/GrapheneOS images are often behind on security updates.

Re: Keep Android Open

#534

Post by necovek »

cosmic_cheese wrote: post #313
necovek wrote: post #303

Earlier quoted context omitted.

Flatpak and Snaps are built to solve this. They do conflict with some expectations from users to be able to play around with things, though, so they do not have the penetration one might want.

They only cover the user-facing app part of the story. The rest of the system needs isolation and safeguards, too, including things like the desktop environment and whatever random daemon. A solution that's integral to the system and not just loosely taped on is required.

For many services that was solved even earlier: that's why things like Docker, podman and VMs are so popular.

The hard bit is the desktop experience which is not fully there yet, but the technology is.

Re: Keep Android Open

#535

Post by gethly »

foobiekr wrote: post #296
gethly wrote: post #142

Just like Microsoft screwed up Windows, Google will screw up Android and people will move to Linux on PCs and some open version of Android, or Harmony, or whatever new mobile system comes up, on their phones. Nothing lasts for ever. The sooner you make the switch, the better off you will be.

What is the advantage of moving sooner vs. moving later when rough spots have been smoothed over?

You keep hoping things won't get too bad, but they will. You just keep delaying the inevitable. So it's better to switch now to get the initial hurdles of such a big change over with as soon as possible. It's not easy, getting used to completely strange behaviours and new things in general. Abandoning what worked for you for years for something completely foreign. You have to force yourself to withstand the first few days or week(s), but then it becomes the new normal and you'll be fine.

Personally, I am still on W10 and and delaying the move, so i'm not holier than thou. It's tough. But I also am a programmer/power user and am on my PC 24/7, sort of, so this disruption must be timed properly for me to make the move, which is not necessarily the case for most people/average users.

Phone on the other hand, as long as it works and does not limit me, I have no need to use different ROM, it's more of a want. But i do not see me doing anything until the system stops being supported or it breaks or something else. So it depends on how you use it.

Re: Keep Android Open

#536

Post by microtonal »

observationist wrote: post #258
arcanemachiner wrote: post #148

Earlier quoted context omitted.

If this finally pushes adoption of truly open Linux phones, then this will end up being a good thing, and the greatest favor that Google could do for the open source community. Tragically, Linux phones have languished and are in an absolute state these days, but a lot of the building blocks are in place if user adoption occurs en masse. (Shout out to the lunatics who have kept this dream alive during these dark years…

Even if you have linux, there are still third parties that have control over your hardware. Even if you're using graphenos, you can't block the sim or the cellular radio stack, and likely other modules on the SoC, from at-will access to every sensor on the device. You can at least protect your files, unless there's a mitm or other vector that graphenos can't cope with. And at worst, they can simply clone all your enc…

FYI: GrapheneOS only support devices with isolated radios. These radios cannot access other sensors. More background: https://news.ycombinator.com/item?id=46841033

Re: Keep Android Open

#537

Post by yxhuvud »

post-it wrote: post #201
retired wrote: post #193

Earlier quoted context omitted.

Good thing restricting side-loading isn't legal in the European Union! Not a problem here. Apple had to enable side-loading on their EU-based phones and so will Google if they restrict it.

Yes it is, and no they didn't. Apple has to allow (heavily restricted) alternative app stores, and I'm not clear on whether any actually exist right now.

What Apple restricts and is legal are not the same. Apple is doing malicious compliance and the legal system ain't buying it. But it takes some time and iterations to shake out.

Re: Keep Android Open

#538

Post by necovek »

NewJazz wrote: post #315
necovek wrote: post #303

Earlier quoted context omitted.

Flatpak and Snaps are built to solve this. They do conflict with some expectations from users to be able to play around with things, though, so they do not have the penetration one might want.

Flatpak provides very weak sandboxing compared to android. It was more about packaging and distribution than security.

https://docs.flatpak.org/en/latest/sandbox-permissions.html says otherwise.

Most apps not using tight hardening are for different reasons though (files/folders org).

Re: Keep Android Open

#539

Post by madeofpalk »

WarmWash wrote: post #80

The judge told Google that Apple is not anti-competitive because Apple has no competitors on it's platform (this all stemming from the Epic lawsuits). Google listened. Blame the judge for one of the worst legal calls in recent history. Google is a monopoly and Apple is not. Simple fix for Google...

Google lost because they have all the emails colluding to prevent competition.

If Google had not done that, they wouldn't have lost.

Re: Keep Android Open

#540

Post by microtonal »

necovek wrote: post #309
palata wrote: post #232

Earlier quoted context omitted.

> We really need to get past the 90s-minded paradigm of everything having access to everything else all the time I do agree with that, and I strongly believe that the iOS and Android security model is way ahead of Desktop Linux. But what I observe is that nobody seems to care about the security model. A recurrent complaint I see against anything AOSP-based (including Android) is that people "want to be root".

It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks. But both Flatpak and Snap offer this new model from the two biggest desktop players in the Linux world: Red Hat and Canonical. As the sibling comment said though, being an administrator for your own computer (including a phone) does not mean that you…

It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks.

What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside. Most desktop apps probably have a good number of security vulnerabilities that can be exploited when they parse untrusted data. On the Linux desktop, most apps still use decades-old C libraries for parsing XML, images, JSON, etc.

Sandboxing also protects against external attacks.

Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software.

Agreed, though for a lot of technical and social reasons, most apps still need privileges that allow trivial sandbox escapes on Flatpak (I don't know or care about Snap). Strengthening app sandboxing should be a top-priority for the Linux desktop, but only a few people seem to care. The same for fully verified boot, etc. Even things like UKIs only go so far, yet almost no distribution has adopted them.

The general security mindset of the Linux desktop community seems to be stuck in the 90ies, levitating between hahah, they cannot get root (as if that matters on desktop Linux) and secure boot and sandboxing is here to take my rights (on open source desktop Linux, seriously?).

Post reply on HN