[HN Gopher] Google blocked patch to disable extraction to APK
___________________________________________________________________
Google blocked patch to disable extraction to APK
Author : NicoJuicy
Score : 75 points
Date : 2022-05-22 15:21 UTC (7 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| ajross wrote:
| 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.
| josephcsible wrote:
| 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.
| Wowfunhappy wrote:
| 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.
| josephcsible wrote:
| 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.)
| TheDong wrote:
| 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.
| tadfisher wrote:
| 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.
| xt00 wrote:
| 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.."
| Arnt wrote:
| 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.
| TheDong wrote:
| 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.
| tadfisher wrote:
| Even if you left ADB enabled, the phone needs to be
| unlocked to approve connections from untrusted devices.
| car_analogy wrote:
| 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?"
| Arnt wrote:
| 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?
| Arnt wrote:
| 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...
| josephcsible wrote:
| If granting me root access is incompatible with blocking
| malware, then I don't want my phone to block malware.
| Arnt wrote:
| 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.
| cowtools wrote:
| >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.
| car_analogy wrote:
| "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.
| josephcsible wrote:
| 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?
| cowtools wrote:
| If the OS developer has authority over the end user, then
| the OS itself is malware. Simple as that.
| car_analogy wrote:
| 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?
| Arnt wrote:
| 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?
| cowtools wrote:
| 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).
| Arnt wrote:
| 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?
| wly_cdgr wrote:
| Yes
| josephcsible wrote:
| The requirement to get root on it should be that you know
| the password to it, which thieves won't.
| hulitu wrote:
| Yes. When you have physical access all bets are off.
| htkibar wrote:
| 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.
| cowtools wrote:
| 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.
| htkibar wrote:
| 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.
| cowtools wrote:
| >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.
| josephcsible wrote:
| 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.
| [deleted]
| josephcsible wrote:
| To be clear, Google did the right thing here. Xiaomi proposed
| an evil user-hostile patch, which Google refused to merge.
| mistrial9 wrote:
| > evil user-hostile patch
|
| I do not doubt you, but that is not a fact-based statement.
| Can we do better?
| saagarjha wrote:
| What would "better" be in this context? The decision to
| merge a patch is functions correctly is necessarily
| opinionated.
| josephcsible wrote:
| The patch inhibits the owner of the phone from accessing
| data stored on the phone.
| tomc1985 wrote:
| 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.
| pjmlp wrote:
| 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.
| cowtools wrote:
| 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.
| pjmlp wrote:
| 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.
| renewiltord wrote:
| 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.
| edumucelli wrote:
| 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."
| josephcsible wrote:
| 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.
___________________________________________________________________
(page generated 2022-05-22 23:01 UTC)