Google blocked patch to disable extraction to APK | Hacker News Reader

Google blocked patch to disable extraction to APK

twitter.com

93 pointsNicoJuicy55 comments

Yea the mentality with phones is super annoying from both Android and Apple.. The user should have access to everything via some special interface / typing in your pin / password or whatever. The idea that the owner of the phone can be prohibited from seeing what is actually running on their device is horrible. Hope one day the norm is that users can get root on the device they own rather than it being explained that “oh that’s too powerful for users to have.. we as the company who made the device have root but you cannot..”

To be clear, Google did the right thing here. Xiaomi proposed an evil user-hostile patch, which Google refused to merge.

> evil user-hostile patch

I do not doubt you, but that is not a fact-based statement. Can we do better?

What would “better” be in this context? The decision to merge a patch is functions correctly is necessarily opinionated.

The patch inhibits the owner of the phone from accessing data stored on the phone.

Funny, I thought this was Hacker News, not Reuters.

What are facts, in this day and age, anyway? I guess 'objective reality' doesn't quite have the same ring to it.

Which means in the end Xiaomi phones will have feature anyway.

The Android ecosystem is full of fragmentation, the same one that Google fanboys argue that Android was designed to fix in regards to J2ME.

Another two common example among Android devleper complaints, is OEM support for cameras, and background services being killed in name of battery resources.

Whatever Google decides is of little value for an ecosystem where the majority of consumers aren't getting Pixel phones.

What matters is that the consumers have choice to use free software if they want. If someone makes an app for a (locked-down) samsung phone, it's going to work on a pixel phone running some AOSP distro. If google took some hardline policy or license that prevented the likes of samsung or xiaomi from tinkering with the OS, then all of these companies would be spinning up their own OSes and you would have even more fragmentation. the end result would be worse for the remaining AOSP/Pixel users.

Even if the consumers had privacy and control by default (which is a good thing, don't get me wrong), they still have to choose to take steps to maintain that privacy and control, because user respecting software is necessary but not sufficient for freedom.

I think the android userbase will come around when they realize that plain AOSP and vanilla android are just way better than all the bloated shit these manufacturers are doing with android.

The OEMs are spinning their own OSes for years, as anyone trying to make their app work across the ecosystem painfully knows, what AOSP allows is that they don't need to start from zero.

Android userbase, the one that actually matters to app developers, just goes to the shopping mall and gets whatever cheap Android devices are on sale with pre-paid cards.

Again, Pixel phones are more symbolic than anything, outside US very few countries have them on sale on those shopping malls.

That's true, but I think the wisdom of tech-inclined people will eventually reach the general public. See the rise (and fall) of OnePlus, which was once praised for making a good stock android phone.

A device that was nowhere be found in Europe.

> The Android ecosystem is full of fragmentation, the same one that Google fanboys argue that Android was designed to fix in regards to J2ME.

I know that there's probably some specific argument that really exists that you're actually referring to, but nobody I know uses Android because of this. Nobody I know was comparing Android to J2ME either. More casual users tend to use it because they dislike iPhone and possibly feel limited by it. More advanced users tend to use it because it's generally more customizable, open source and at least in the past, was much easier to mod and patch.

It is true that unlike Windows devices, every Android phone is a snowflake. That's a real problem. But for many people, they don't really care about that problem, only the derivative consequences, like not being able to upgrade their phone to the latest version, or security issues that result from shoddy OEMs. And frankly, users are right to not care: it is not a given that these derivative problems can't be solved in a different way that is satisfactory.

(And yes, of course, many users today buy Android devices because they're cheap. But they still had to cross a threshold in the market before they could become the mass market success that they are today, and that happened with mostly enthusiasts.)

I was talking about a common argument that used to exist in Android developer circles in its early days of existence.

As for the users, if we go down that path, they don't even care about Linux kernel, AOSP, Project Treble, or whatever.

That happened because of Google, the continuous adoption failure of FOSS phones since OpenMoko proves that enthusiasts aren't enough to sustain a business at scale.

Let’s be honest: the primary problem with any of the FOSS options before and after Android is that they literally suck. A phone has to have good SMS and phone capabilities, decent performance, and some kind of non-anemic app ecosystem to really exist today. Some of the open source options for phones never managed to achieve any of these, and the ones that exist today still struggle at it, and yet may possibly still be sustainable.

Ultimately, I don’t buy the argument that developers opinions about J2ME vs Android had anything to do with it. The T-Mobile G1 is why Android broke through the market. I believe that is in part due to Google’s backing, which instantly made it newsworthy at least in enthusiast circles.

The closest thing we have now is the Pinephone, but it largely doesn’t work (though I still find it in much better shape than many of its FOSS phone peers, probably bested by Librem 5 but I don’t own one to know for sure.) To be sure, it doesn't look close to breaking through to the mainstream any time soon, but it’s also not really ready. It has no app ecosystem and no carriers shipping it, and core functionality is still mostly barely working.

Possibly Google rejects GApps to be installed to the device that the patch applied, or doesn't care.

Given how they have behaved until now, they won't care.

Answer about OEM changes regarding killing background jobs, at this year's Google IO Android Fireside, paraphrasing, "Android is a rich environment that depends on its OEMs, and the inovations that they bring into the picture, so it is always a balance that we need to strive for".

Video is available in case you want to cross check the exact words.

Yes they did -- but as a thought experiment, these types of security measures could be totally reasonable to have if the owner of the phone had root. Sure, lock my phone down until the cows come home.. but I hold the master key (or I can get it easily in a fashion I have control over -- if you fear being forced to under duress then you can set something up to prevent that). Lets be real here (as many people mentioned) the key exists, its just not in your hands as the phone owner. It is in the manufacturers hands. And we want it. The one problem to solve is how to verify that you own the device. Saying that that is too hard to solve is not a good enough reason to deny people from having it. There are 100 solutions to this that cryptography folks could devise -- probably folks here could think of tons (one time keys, requiring physically going to a safe place to retrieve the key, requiring a secondary person, having the ability to provide provable information to the person who wants the key that the person who you are threatening does not have the ability to unlock it, etc) -- but yea, there is theft, hacking, border security snooping phones, etc.. those all exist, so blocking those people from getting root on your device is critical -- now lets think of solutions rather than saying OK Apple and Google get to own my device. If we are one patch away from essentially having no clue whats running on our phones, then we are in way more trouble than we thought we are in... we should have "right to root" on our devices now.

It sounds as if you're confusing "the owner of the phone" with "the momentary user of the phone", as in, the DHS officer who may ask for your phone when you travel into the US.

The protection from "the momentary user of the phone" is supposed to be the encryption/lockscreen PIN. And even if that weren't the case, I'd rather that the DHS officer be able to access my APKs than for me to be unable to access them.

How is it that in these discussions, apologists for removing user sovereignty become suddenly ignorant of every existing security solution (such as, in this case, even plain old passwords), to claim the only way to secure a device is to hand control to the manufacturer?

"How will I keep people from breaking into my cell if the warden doesn't lock it?"

I think that happens as soon as someone writes "Hope one day the norm is that users can get root". The quote is from upthread. I have a phone on my hand, no proof of purchase, no proof of ownership, no traceable path of transactions back to the manufacturer, should I be able to get root?

That is a spectacularly, obtusely uncharitable interpretation of that statement. I didn't need proof of purchase, ownership, or a traceable path of transactions to the manufacturer when I got root on the PC I built. Or on my phone, for that matter. Yet somehow, it's now secure, and anyone else that gets their hands on it, won't be able to get root.

This is the exact kind of amnesia I was talking about. Are you really unfamiliar with default passwords that one changes at boot, such as every consumer router has?

Those passwords don't grant root access, they don't even grant access to execute general programs, far less to execute anything as root.

Would you be happy if Google granted access to run Google-supplied programs as root, but not programs from anyone else? No?

You're using an overly specific definition of the word "root access". "root access" in the context of this conversation just means the paramount ability to decide what runs on the computer (ownership secure boot keys, ability to modify OS, ability to change or remove userspace programs).

In other words, root access does not require being able to run Total Commander as root, or SimpleSSHd? I have a NAS at home, "root access" doesn't mean that I would be able to back up the entire phone to that NAS?

Within this context, "root access" is "root" in the sense that it refers to whatever the highest level of privilege is (the root of the trust chain). It's like a tree where each program/agent can spawn subprograms/subagents with privileges that are a subset of its parents.

With root access, you have the ultimate ability to decide what runs on the computer. Including programs that do not have root access or programs that prevent other programs from running with root access.

If the highest level of privilege is secure boot (the ability to decide what OS runs on the device), then you can run an OS that lets you read everything off the filesystem, sure. But you can also run an OS that doesn't let you read everything off the filesystem.

What matters is that if you have root, you (as a person) are at the top of the trust chain. It doesn't matter if the root permissions trickle down to seated users because you can change that if you're at the top.

Yes

The requirement to get root on it should be that you know the password to it, which thieves won't.

Yes. When you have physical access all bets are off.

Come to think of it, I think this is another instance of the "cause miracles" thing.

No user ever gets root. What gets root is a process. "Grant root access to the owner" while blocking malware means that the OS kernel must distinguish whether a process is acting on behalf of the owner of the device, and has not deceived the owner about what the process will do. If the OS developer (Google in this case) does not do that, clearly the OS developer is evil or horribly incompetent, and anyone who thinks that what the OS currently does is reasonable is an apologist who comes creeping out of the woodwork.

https://astralcodexten.substack.com/p/book-review-the-revolt...

If granting me root access is incompatible with blocking malware, then I don't want my phone to block malware.

Custom Android ROMs exist for you and me.

Someone who lives across the backyard from me was social-engineered out of several months' salary. Almost their complete savings. It was a nasty story, and no, the money hasn't been returned.

If a smartphone vendor wants to give a wide audience access to apps and the net, then the vendor has to cater to people like that neighbour. And that, in turn, means that it must be very, very, very difficult to social-engineer that neighbour into granting another app access to the data in the banking app. To my mind, protecting most people's savings is much more important than catering to people like you and me. You may disagree.

>Someone who lives across the backyard from me was social-engineered out of several months' salary. Almost their complete savings. It was a nasty story, and no, the money hasn't been returned.

Let me guess, bank transfers? Maybe we should think about improving banking security and informing users before we try locking down nearly every piece of consumer electronics on the market. There is no need for these "banking apps" to exist in the first place. What happened to online banking over the web? Where is the accountability of these banks here? Where is the personal accountability from these users?

I really don't buy this argument. If you can't practice basic security and due diligence, you shouldn't have an online banking account, let alone a computer, you should be in a nursing home.

Your guess is wrong. It was a two-step attack that relied on social engineering and misleading. They had scammed about fifty people in Munich by the time it was in the papers, and my guess is that a substantial number of ordinary adults here would fall for it.

Personally, I consider it quite reasonable if our OSes are set up to make it difficult to scam regular people, even at the cost of making my tinkering difficult. It's the sensible default, IMO. Feel free to disagree, or even to downvote me.

(I'm sure some of the fifty-odd people used apps to pay the criminals, but that wasn't relevant to the way the scam worked.)

What changes to the OS would have prevented the kind of scam you're talking about?

"Protecting most people's savings" quickly becomes "90% of the population only has access to officially sanctioned apps and websites". Not good if you want a free society.

But since you haven't offered any details of the social engineering attack, I'm going to assume there's a freedom-respecting way to prevent it that you're ignorant of, just as you were ignorant of how random people may be prevented root access to non-manufacturer-controlled devices by something as common and trivial as default, buyer-changeable passwords.

Did the social engineering involve root access to a phone, or was it more along the lines of just tricking the victim into doing a bank transfer? And should we take away root access from desktop computers too by the same logic?

If the OS developer has authority over the end user, then the OS itself is malware. Simple as that.

Because at customs etc. you can be forced to unlock your phone for example. Or your government might force you to install root certs etc. (Hi Kazakhstan!)

So there is an argument to be made for “should it be possible”. I am saying this even though I would still prefer to be allowed to access everything in the system.

If you have a good enough password, you cannot be made to do unlock anything so long as your keys remain in your head, in contrast to what randall munroe believes https://imgs.xkcd.com/comics/security.png

The alternative is that the manufacturer holds control over your device, and when the government wants to get in, you're none the wiser.

Can you elaborate on “you cannot be made to unlock anything”?

Jail time, denying entry, a gun to your head are all potential ways I can think of.

For manufacturer & government; it depends on which government. If we are talking of the US government; you are right. If we are talking about most smaller authoritarian regimes? Not so much.

>Jail time, denying entry, a gun to your head are all potential ways I can think of.

A gun may motivate someone to unlock their hard drive, but if they are are not sufficiently motivated then a gun cannot do anything. You could imagine a spy or a terrorist who prefers to die vs reveal important information, or a journalist who prefer to spend years in jail vs reveal an in-progress investigation that might get them assassinated.

Really, rubber hose attacks are a question of motivation, not technical ability. If apple invented a feature that wiped your storage when you are detained by border guards in some tyrannical state, then you would probably just be tortured to death. In that case you would prefer the ability to unlock your device because the purpose of torture is not to reveal secrets, but to "persuade" you into revealing your secrets.

It's a completely different mode of attack. If the manufacturer has control over the phone, and the gov. makes the manufacturer unlock it, then you will have no idea that you have been attacked, or how much information the gov has on you. They do not need to confront you at all.

When only you have control over the phone, you will know when the government has access to your information, and what information they will have because they will need to torture it out of you.

That's why this "crypto-nihilism" that munroe entertains is just stupid. It leads people to believe that cryptography doesn't matter when in reality it's a major hurdle for the government and corporations trying to exert tyrannical control over people. In his comic, Munroe doesn't present the case where the laptop is unencrypted which is often what gets journalists/protesters/spies' data leaked unbeknownst to them, and then their collaborators are killed in a car bomb weeks later.

In the smartphone case, this has to do with manufacturers choosing to encourage low-entropy passwords that can be easily cracked (e.g. 4-digit pin), "secure boot" that isn't really secure, and biometrics that are not used for disk encryption. These are all intentional flaws.

>For manufacturer & government; it depends on which government. If we are talking of the US government; you are right. If we are talking about most smaller authoritarian regimes? Not so much.

North Korea? The government can simply ban phones that aren't backdoored. It's not a question of size, it's a question of technical competence. China, a much larger country than North Korea, is apparently only using user-space malware; you can still buy phones with unlocked bootloaders and run AOSP.

And this assumes that you purchase your device from a manufacturer whose supply chain lies only within the jurisdiction of governments friendly to your interests, and also from a manufacturer that is friendly to your interests. I don't think I can name a single manufacturer I trust that much to control my hardware over the wire with no oversight, merely because all organizations can eventually succumb to corruption.

You have to explicitly enable adb support for the mechanism this patch prevents.

If a DHS officer can unlock your phone to enable adb support, or if you left debugging support on and did not poweroff your phone, then you have much larger problems.

This patch only targets people who are already able to unlock the device and setup adb debugging.

Even if you left ADB enabled, the phone needs to be unlocked to approve connections from untrusted devices.

Eh? Android permits this user access and blocked a mechanism to remove this user access. This comment is a complete non-sequitur to the actual event.

I'm glad Google didn't let this through. I wish they'd go a step further, though, and make it a CDD requirement that this change isn't there, since otherwise, all Xiaomi phones will end up with it anyway.

Can they? When one Googler commented:

> If Xiaomi needs this, I think it should be done in the device-specific sepolicies.

Another responded that:

> Xiaomi cannot remove policy in device specific policy.

That means they wouldn't be able to use this exact method to block APK extraction. I'm worried they'll find another, though, so I want the CDD to be updated to say APK extraction must be allowed. (I suppose I could have worded my original comment better.)

Xiaomi still can, just not with that mechanism (device-specific policies).

I'm pretty sure they already ship a customized android distribution, so they could apply this exact patch, the one they proposed upstream, to their fork of android. I give it quite good odds they already have applied such a patch.

And it will continue to be useless for what Xiaomi claims is the patch's purpose, because the same "private" APK data can be pulled unmodified from the same device with a userdebug build, or from the numerous devices available which do not have this patch applied.

I liked the last comment in this PR:

"I think Xiaomi should share the open source code as requested by the users before finding more ways to obfuscate things.

https://github.com/MiCode/Xiaomi_Kernel_OpenSource/issues/23...

There are dozens of pages filled with such request in the issue tracker."

I wish the US government would block import of Xiaomi phones for infringing on Linux kernel contributors' copyright, just like they seem to already do in basically every other case of IP infringement except this one.

Double negative in the HN headline seems needlessly confusing. It was a Xiaomi-authored patch to disable APK copies (via an SELinux policy as the mechanism), and Google NAKed it.

Each to their own. I can parse a double negative but don't know what "NAKed" is.

NAK means "negative acknowledge".

Reply on news.ycombinator.com