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

11–20 of 116 posts

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

#11

Post by krageon »

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…

> your bank's Android app

Worst comes to worst you can decompile it and take out the checks, but it is admittedly a huge hassle.

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

#12

Post by looperhacks »

krageon wrote: post #11
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…

> your bank's Android app Worst comes to worst you can decompile it and take out the checks, but it is admittedly a huge hassle.

Not really. Safetynet runs on Google servers and communicate with your banks servers (if they have that enabled). If a modded app removes these checks, the bank will notice because they ask Google whether your device fulfills all requirements.

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

#13

Post by danogentili »

krageon wrote: post #11
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…

> your bank's Android app Worst comes to worst you can decompile it and take out the checks, but it is admittedly a huge hassle.

You can't really do that with safetynet, as it relies on sending an (often signed with a hardware key) payload to the servers of the app, which then connect to Google's server for validation, before allowing access to the APIs the app requires.

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

#14

Post by infologics »

Greetings! Very helpful advice within this article! It is the little changes that produce the largest changes. Many thanks for sharing!

http://infocampus.co.in/ui-development-training-in-bangalore...

https://www.firstenquiry.com/ui-development-training-in-bang...

http://infocampus.co.in/web-designing-training-in-bangalore....

http://infocampus.co.in/web-development-training-in-bangalor...

http://infocampus.co.in/react-js-training-in-bangalore

https://www.firstenquiry.com/reactjs-training-in-bangalore

http://infocampus.co.in/angularjs-training-in-bangalore.html

http://infocampus.co.in/angulartwo-training-in-bangalore.htm...

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

#15

Post by ignoramous »

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 anyway.

One right answer to this is fully open-source (hardware and software) phones like the PINE64 and Librem, among others.

[0] https://lwn.net/Articles/836693/

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

#16

Post by techrat »

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

[citation needed]

I'm finding the majority of devices to be unlockable as long as you don't buy your device from a carrier.

Carrier locked devices are not typically the norm but in the US.

And if you truly cared about software freedom, you wouldn't be buying carrier locked devices in the first place.

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.

However, despite all of your doom and gloom posturing without actual examples, I've yet to actually use a single app (and I use several banking and root detecting apps like remote features for my car) that will prevent me from continuing to use the app if rooted. It just pops up and says "We see you're using a rooted device, this is not recommended." I click "OK" and proceed as normal.

The alternative is to use Apple and whelp, that'll never happen... since I actually do care about software freedom.

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

#17

Post by vadfa »

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"?

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

#18

Post by techrat »

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.

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

#19

Post by krageon »

danogentili wrote: post #13
krageon wrote: post #11

Earlier quoted context omitted.

> your bank's Android app Worst comes to worst you can decompile it and take out the checks, but it is admittedly a huge hassle.

You can't really do that with safetynet, as it relies on sending an (often signed with a hardware key) payload to the servers of the app, which then connect to Google's server for validation, before allowing access to the APIs the app requires.

The checks I've seen when I have explored the possibility of doing this (in an explicitly legal way, I had permission) were easily bypassable client-side. It's not generally a good idea to assume the heaviest option was picked when a simpler one could also have been picked.

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

#20

Post by the8472 »

techrat wrote: post #16
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 [citation needed] I'm finding the majority of devices to be unlockable as long as you don't buy your device from a carrier. Carrier locked devices are not typically the norm but in the US. And if you truly cared about software freedom, you wouldn't be buying carrier locked devices in the first place. I really wish people would stop griping abo…

> 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. All it takes is a mechanism to replace the manufacturer's trust root with an owner-supplied one. The process would wipe anything secured by the trusted components (including keys securing the user data) but that should be fine since you can make a backup.

The only thing that wouldn't work is software that wants to ensure that the user has no control over the system - DRM or "the user is too dumb to be trusted with their own device" security theater.

Post reply on HN