Live data from Hacker News

Google shifting to “upstream first” Linux kernel approach for Android features

phoronix.com

61–70 of 116 posts

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#61

Earlier quoted context omitted.

So privacy is a premium feature now, that should only be available to developed societies? Okay.

that's not how it should be, that's how it is. The only way cheaper devices are so cheap is by cutting all the corners they can, and turns out one of the corners people don't care to be cut is their privacy and security

Is locking the bootloader cutting corners though? Sounds like an extra step to me.

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#62
post #6

I am afraid it does not matter any more, at least not for practical software freedom. Most Android devices these days have bootloaders that cannot be unlocked, preventing device owners from installing custom kernel images onto their devices. And even if you have a phone where that isn't true, Google's SafetyNet will prevent you from using many crucial applications, like your bank's Android app, on that handset. It's…

I wish I could upvote you more.

There's nothing about "freedom" in this post, it's all about developer's convenience. It's easier to keep local changes and push them later if the upstream is not changing much. If your upstream is a moving target, doing anything but upstream-first is only making it worse for yourself in the long run.

Nothing to add regarding bootloader locking and safetynet on top. I don't want multiple phones (I actually don't want one), but I was forced to to install my banking app 2nd factor app. I cannot root it, I cannot remove GA, safetynet prevents me to reflash it with something else, even though I theoretically can.

The best part is that at some point you can choose between:

- old/vulnerable/unpatchable android with safetynet => banking apps will be happy to work with it

or

- new fixed android which is safer, but won't pass safetynet

Yeah.. "safety".

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#63
post #22
post #6

I am afraid it does not matter any more, at least not for practical software freedom. Most Android devices these days have bootloaders that cannot be unlocked, preventing device owners from installing custom kernel images onto their devices. And even if you have a phone where that isn't true, Google's SafetyNet will prevent you from using many crucial applications, like your bank's Android app, on that handset. It's…

> Most Android devices these days have bootloaders that cannot be unlocked, preventing device owners from installing custom kernel images onto their devices. And even if you have a phone where that isn't true, Google's SafetyNet will prevent you from using many crucial applications, like your bank's Android app, on that handset. Googles own devices not only allow you to unlock the bootloader, but to relock it with yo…

> vote with your wallet and don't complain how "most devices" don't give you feature you're not ready to pay for.

I believe that the ability of a device owner to exercise the same level of control over it as the company that manufactured it is a matter of consumer rights, not features.

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#64
post #2

With Google's eventual transition to Fuschia OS, the skeptic in me sees this as little more than an easy PR win before they begin to wind down new Android development.

But finally this happened. The issue has been around for years. I think (hope) this will dramatically improve the update situation on Android. I wonder though how close Fuchsia is for day-to-day use on current phones

I would imagine it'd be a win for phone SoC-based SBC makers.

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#65

Earlier quoted context omitted.

I'm afraid vendor BSPs will be a shit situation for until the end of time, since they are still allowed to ship custom kernel modules - which means when Google updates the kernel, the modules will also have to be reworked (since they live outside of the kernel, they don't benefit from upstream rework effort), and most vendors will take their sorry sweet time to do so or do nothing at all. Really, I don't get why Goog…

Whilst I completely agree with you (alas) and frankly I am not sure I want to see Fuscia succeed (entirely for ideological reasons -- I believe in the value of the GPL) -- this part of you statement has a very clear answer: > this would have prevented so much e-waste... E-waste is effectively profit for the device manufacturer. Discarded phones mean that the whole portable computer that is still more powerful than wh…

On the other hand I'm much more comfortable buying a 500$+ phone from OnePlus that gets updated for 5 years. Maybe it can turn out to be good for both sides with manufacturers selling more high-end devices. (Rather than designing and selling cheaper but many low-end throwaway devices)

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#66
post #6

I am afraid it does not matter any more, at least not for practical software freedom. Most Android devices these days have bootloaders that cannot be unlocked, preventing device owners from installing custom kernel images onto their devices. And even if you have a phone where that isn't true, Google's SafetyNet will prevent you from using many crucial applications, like your bank's Android app, on that handset. It's…

> I don't think there's a way out any more.

Whenever you estimate something bad to be inevitable like this, please consider the many terrible inevitable things in the past. Those in the past thought they were inevitable, but they weren't.

- everyday violence on a much higher level than today

- inability to correct mistakes of government in the long run (voting, free speech)

- lack of power of women

- vulnerability to many diseases

- protection of law

I think any one of these is composed of many traditions that when I think about them seem almost impossible to come about, in the same way that an evolved animal seems remarkable: how did that ever happen? They do happen! People worked hard and incrementally to make them happen.

Estimating them to be inevitable I think can be a discouragement to that hard work.

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#67
post #60

Earlier quoted context omitted.

Xiaomi phones are the gold standard of price/performance where I live and their bootloader can be unlocked.

Obligatory reminder of the state surveillance and censorship baked into Xiaomi products: https://news.ycombinator.com/item?id=28616683

If you can swap the device OS with something more trustworthy, does any of that matter or is there evidence that the hardware itself is untrustworthy?

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#68
post #36
post #33

Earlier quoted context omitted.

On this kind of devices the security chain of trust needs to take into consideration the same kind of users that fill their Internet Explorer with random toolbars from website popups. Not the user with a CS degree that knows what they are doing.

Those kinds of users are unlikely to replace the root of trust, simply due to the process being onerous. And even if everyone were to install malware. There are other ways to secure banking. E.g. by providing an external token with a display. This is how hardware crypto wallets and some PIN generators for in-browser banking work. Or they could ask the owner to upload the attestation pubkey to their website, then the…

Okay, so the app's running.

Except the app is remote-controlled by a malicious “display driver” that waits for the user to do all this authentication set-up, transfers the money away, “are you sure”s it, then prevents the user from seeing any of the on-phone scam warnings until it's too late to reverse the transaction.

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#69
post #36

Earlier quoted context omitted.

Those kinds of users are unlikely to replace the root of trust, simply due to the process being onerous. And even if everyone were to install malware. There are other ways to secure banking. E.g. by providing an external token with a display. This is how hardware crypto wallets and some PIN generators for in-browser banking work. Or they could ask the owner to upload the attestation pubkey to their website, then the…

Okay, so the app's running. Except the app is remote-controlled by a malicious “display driver” that waits for the user to do all this authentication set-up, transfers the money away, “are you sure”s it, then prevents the user from seeing any of the on-phone scam warnings until it's too late to reverse the transaction.

Display driver is part of the kernel, which is part of the trust chain.

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#70
post #22
post #6

I am afraid it does not matter any more, at least not for practical software freedom. Most Android devices these days have bootloaders that cannot be unlocked, preventing device owners from installing custom kernel images onto their devices. And even if you have a phone where that isn't true, Google's SafetyNet will prevent you from using many crucial applications, like your bank's Android app, on that handset. It's…

> Most Android devices these days have bootloaders that cannot be unlocked, preventing device owners from installing custom kernel images onto their devices. And even if you have a phone where that isn't true, Google's SafetyNet will prevent you from using many crucial applications, like your bank's Android app, on that handset. Googles own devices not only allow you to unlock the bootloader, but to relock it with yo…

OP said "Most Android devices". You then singled out a specific subset of phones that are only a small portion of the market to claim that OP's comment is "weird".

OP's comment is accurate because Pixels are not "most Android phones". You also don't know whether or not OP already owns a Pixel, so I'd say it's "weird" to tell them not to complain without knowing whether or not they have already voted with their wallet.

Post reply on HN