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

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

phoronix.com

Post reply on HN
Print view View original

31–40 of 116 posts

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

#31

Post by the8472 »

pjmlp wrote: post #29
the8472 wrote: post #20

Earlier quoted context omitted.

> I really wish people would stop griping about losing security features when you flip the one switch that ensures the security of the system. Unlocking the bootloader means it is now possible to modify system files. Of course Safetynet is going to fail. The point of Safetynet is to ensure the system hasn't been tampered with. That's pretty much drinking the DRM koolaid. You can have both, verified boot and freedom.…

It is no longer a security theater when the user gets a malicious app installed, that takes over their bank management app.

Changing the root of trust doesn't mean applications can suddenly take over other applications. It also requires granting the malicious app sufficiently elevated permissions for that takeover. The user made several choices along the way. If your argument is that there's the possibility that they could make the wrong choice then this is in my opinion security theater because it posits that a thing can only be secured by taking away choice and no other way.

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

#32

Post by 5e92cb50239222b »

izacus wrote: post #22
c0l0 wrote: 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

This isn't always possible or realistic. The cheapest Pixel phone is worth 2+ median monthly salaries in my location.

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

#33

Post by pjmlp »

the8472 wrote: post #31
pjmlp wrote: post #29

Earlier quoted context omitted.

It is no longer a security theater when the user gets a malicious app installed, that takes over their bank management app.

Changing the root of trust doesn't mean applications can suddenly take over other applications. It also requires granting the malicious app sufficiently elevated permissions for that takeover. The user made several choices along the way. If your argument is that there's the possibility that they could make the wrong choice then this is in my opinion security theater because it posits that a thing can only be secured…

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.

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

#34

Post by techrat »

pjmlp wrote: post #30
techrat wrote: post #18

Earlier quoted context omitted.

> With Google's eventual transition to Fuschia OS I still have yet to see even the most remotely reliable source that indicates Fuschia is actually going to replace Android. Reminds me of when people were so absolutely sure that Android and ChromeOS were going to be merged. Never happened. I really wish people would stop repeating hare brained tech blog gossip and speculation as confirmed roadmaps.

Maybe some Gerrit commits will help, https://android-review.googlesource.com/q/fuchsia Also in case you missed, Android apps now run on ChromeOS.

Code gets shared between projects all the time. Nothing in there specifically says that Fuchsia will replace Android.

In case you had problems comprehending it the first time, ChromeOS and Android were not *merged.*

The rumor has been around since 2015.

https://www.theverge.com/2015/10/29/9639950/google-combining...

Running ones' apps on another OS is not merging the two.

The ChromeOS/Android merger claims are still unsubstantiated. Pretty sure you'd find a fair number of AOSP/Android commits in the ChromeOS repos.

Still not convinced there's any actual evidence of Fuchsia replacing Android here.

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

#35

Post by rvz »

techrat wrote: post #18
noptd wrote: 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.

> With Google's eventual transition to Fuschia OS I still have yet to see even the most remotely reliable source that indicates Fuschia is actually going to replace Android. Reminds me of when people were so absolutely sure that Android and ChromeOS were going to be merged. Never happened. I really wish people would stop repeating hare brained tech blog gossip and speculation as confirmed roadmaps.

> I still have yet to see even the most remotely reliable source that indicates Fuschia is actually going to replace Android.

Let’s come back in at least 8 years or a decade and we will see if ‘Fuchsia’ actually replaces Android and even ChromeOS then.

I won’t be surprised if they do, given that is where they are heading.

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

#36

Post by the8472 »

pjmlp wrote: post #33
the8472 wrote: post #31

Earlier quoted context omitted.

Changing the root of trust doesn't mean applications can suddenly take over other applications. It also requires granting the malicious app sufficiently elevated permissions for that takeover. The user made several choices along the way. If your argument is that there's the possibility that they could make the wrong choice then this is in my opinion security theater because it posits that a thing can only be secured…

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 bank could still check if it's really their app that's running (as confirmed by the boot trust chain). I'm not sure how fingerprint scanners are tied into secure boot, maybe they could be used to verify user intent too.

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

#37

Post by dmm »

SXX wrote: post #27
izacus wrote: post #22

Earlier quoted context omitted.

> 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…

> Googles own devices not only allow you to unlock the bootloader, but to relock it with your own signing keys. And does it let you pass SafetyNet and run most of the apps. AFAIK it's not so re-lockable bootloader is useless.

I use a pixel phone with my own signing keys and I find it very useful. I can live without SafetyNet, whatever that is.

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

#38

Post by ghuin »

5e92cb50239222b wrote: post #32
izacus wrote: post #22

Earlier quoted context omitted.

> 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 This isn't always possible or realistic. The cheapest Pixel phone is worth 2+ median monthly salaries in my location.

Premium features, premium price point.

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

#39

Post by tgb »

vadfa wrote: post #17
noptd wrote: 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.

Why is it that nobody seems to be able to spell the word "fuchsia"?

Even Google misspells it: https://blog.xkcd.com/2010/05/03/color-survey-results/

I checked the other day and it's still true.

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

#40

Post by jacob019 »

ignoramous wrote: post #15
c0l0 wrote: 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…

Replacing OEM Android is only one part of the equation. There are many components that run with full privileges (EL2/EL3?) outside of Android and never subject to Android's sandbox. Well, at least until Google can force OEMs to stricter standards with their effort to KVMize those privileged executables [0]. If you do not trust the OEM, replacing its ROM with GrapheneOS / CalyxOS / LineageOS isn't going to help much a…

I'm happy with my degoogled phone. There are so many great open source apps on f-droid. Still, it's 2021 and I need a few closed source apps on my main driver, so Aurora Store, MicroG, AdAway. Ok so I'm still using google servers for push notifications of the closed apps--compromises. I still have way more control and battery life. I love the idea of a linux phone, and maybe I could sacrafice the last few closed apps, but what I hear from users is that the hardware sucks. I want a nice phone.
Post reply on HN