[HN Gopher] Google Play limiting Android 11 apps from seeing wha...
___________________________________________________________________
Google Play limiting Android 11 apps from seeing what's installed
on devices
Author : 1cvmask
Score : 67 points
Date : 2021-04-01 18:19 UTC (4 hours ago)
(HTM) web link (9to5google.com)
(TXT) w3m dump (9to5google.com)
| oedmarap wrote:
| > Meanwhile, temporary exceptions will be granted to dedicated
| banking and digital wallet apps so that they can "obtain broad
| visibility into installed apps solely for security based
| purposes."
|
| I'm sorry but why does a banking app need to see a list of
| system-wide packages? And for what security-purpose? If all apps
| were tightly sandboxed in the first place then this wouldn't be a
| problem that requires edge-case solutions.
|
| Either way, based on the same quoted paragraph, my prediction is
| that Facebook will now roll out a dedicated wallet app; along
| with regular wallet functionality it will gleefully take
| advantage of this exact loophole.
| elliekelly wrote:
| I wonder if they're "finger printing" the device to determine
| whether a login is likely to be legitimate or not?
| skynet-9000 wrote:
| Couldn't they just generate a unique fingerprint then?
| Daniel_sk wrote:
| Banking apps sometimes integrate 3rd party AV / threat
| detection SDKs (there are several available, e.g.
| https://www.wultra.com/malwarelytics which is part of a bigger
| banking security SDK solution). Sandboxing isn't the only
| problem on Android - a lot of malware is using Accessibility to
| control the device and read what's on your screen. Then there
| are overlays that can be drawn over your app (e.g. display a
| fake login over your app). Access to notification content.
| Reading SMS content (2FA). Different combinations of other
| permissions, device manager rights etc. Or even simple attacks
| like launching a fake app just when you launch the real one
| (phishing). Google is trying to limit a lot of these
| permissions, at least from apps installed from Google Play but
| so far they are still pretty widespread with malware hidden on
| Google Play targeting banking apps.
| RKearney wrote:
| I don't believe this is the only reason. If it were, they
| would be blocking logins through mobile web browsers since
| there's no JavaScript API that dumps the list of installed
| apps. All those same attack vectors could exist on top of the
| users web browser as far as I know.
| wmf wrote:
| They don't have to block the login completely but they may
| treat it as less trusted and require additional
| authorization for, say, an outgoing wire transfer. Of
| course, this assumes banks are doing actual risk modeling
| not just security theater.
| TeMPOraL wrote:
| Can't they do this for apps too? Treat them as "less
| trusted", instead of doing all that bullshit with
| shipping bundled scanners, and the insane policies that
| make it impossible for me to take a screenshot of
| transaction details in the app...
|
| (Yes, I know. My role as a user isn't to have opinions -
| it's to dutifully enjoy the software as-is, and visit the
| "offers" section on a regular basis.)
| lupire wrote:
| A less trusted app is annoying to use.
| criddell wrote:
| > Banking apps sometimes integrate 3rd party AV / threat
| detection SDKs
|
| Do they do the same thing on iOS?
| kitsunesoba wrote:
| As far I know they more or less stop at detecting if the
| device has been jailbroken or not and if it has, refusing
| to function.
| Daniel_sk wrote:
| I don't think so - or if they do, then the functionality
| won't be very effective. A lot of the most common attack
| vectors have never existed in iOS. Applications on iOS
| can't draw over other apps, you can't implement your own
| accessibility service, you can't launch apps from the
| background without user interaction, you can't install apps
| outside of the App Store, you can't run a service in the
| background for unlimited time, you can't implement your own
| keyboard (key logger), or read SMS messages, notifications,
| system events and a lot of other things have never been
| accessible to developers on iOS. I haven't heard about
| banking malware on iOS. But on Android you can find
| hundreds of examples and even right now there are several
| circulating on Google Play. The openness of Android OS has
| advantages and disadvantages, but Google has been heavily
| limiting most of these options recently.
| summm wrote:
| 3rd party AV sdks? This reeks of snake oil. They should just
| stop treating the device as a hardware security anchor. And
| how is it still ok that most android phones in the wild do
| not get security upgrades, let alone timely ones?
| UncleMeat wrote:
| It is snake oil. But they want it and this makes it tricky
| for Google.
| kiwijamo wrote:
| Why wasn't this done before?
| justapassenger wrote:
| It's great for security, but also great for Google.
|
| OS and their frameworks still get full visibility into apps, and
| given how much data they collect, it's cutting off this data
| (rightly) from others, and keeping it only for themselves (both
| for good and bad reasons).
| [deleted]
| qwerty456127 wrote:
| Great. No app should see anything besides what is logically
| necessary to fulfill their actual function.
| rektide wrote:
| is there any way to broadcast or make known that there is an
| Intent handler registered?
|
| im wondering if apps have the capability to signal to each other
| that they exist. it's been so long since I've touched android,
| but I remember Intents were often the main sort of rpc engine
| across apps. Even if apps can't ambient survey the system now,
| I'm wondering if they can still make smoke smoke signals to each
| other.
| Red_Leaves_Flyy wrote:
| Why isn't this feature behind a permission flag already?
|
| Matter of fact, why aren't a lot more abilities behind
| permissions?
| kjjjjjjjjjjjjjj wrote:
| Because Android doesn't take security and privacy seriously. No
| one who is worried about those two things should be using
| android
| tialaramex wrote:
| There's a balancing act. Historically Android would just
| provide a list of what permissions each app wants, and you
| either take it or leave it. That's transparent in a sense, if
| researchers care they can do the analysis and produce a paper,
| "Hey, 80% of the top X apps request permission Y which they
| have no Earthly reason to need" - but almost no end users will
| read this boring technical stuff to make decisions. See also
| pre-Baseline Requirements "class based" X.509 certificates.
| Adding more permissions to this list is easy... but also has
| almost no effect. There's a good chance you've never looked at
| the permissions you granted most apps you have.
|
| In the modern era some of these abilities also require an
| explicit grant of permission when used. Location is an example
| we've all seen.
|
| But that incurs fatigue so it has to be used cautiously. For
| example Android could ask if apps are allowed to use the
| Network, but you'd likely get sick of that really quickly, so
| instead you can explicitly _disable_ network access for an app
| if you want, but it doesn 't ask "Can Daily-quiz-app-1234
| access the network?" when you run it.
|
| One option Google has that's more extreme than a fatigue-
| inducing prompt, is to just refuse permission anyway, which is
| what's happening here.
|
| And unlike iOS, an Android phone can run other browsers, but
| for a modern browser on a nice phone you want WebAuthn. If any
| app can just say "I'm actually a web browser" then WebAuthn's
| phishing protection blows away when you install some Flappy
| Bird clone to try it out - the app just tells the OS it's a web
| browser, comes up with some excuse as to why you should touch
| your fingerprint sensor, and it says to the OS it's browsing
| https://your-bank.example/ so it gets credentials for your
| bank. So in this case Google manages some high risk permissions
| only for known safe developers. Mozilla's public Firefox builds
| have this "I'm really a web browser, I get to do WebAuthn"
| permission, but if you build the exact same source and sideload
| it, it can't do WebAuthn.
|
| [Apps all get the same, likewise unphishable, feature on
| capable phones, Android or iOS, but without this "web browser"
| permission it's fixed so that they can't ask for credentials
| for a web site, only for their own app]
| f6v wrote:
| > There's a balancing act. Historically Android would just
| provide a list of what permissions each app wants
|
| That's one of the many design choices that made truly filthy
| apps possible on Android. I worked on a device
| monitoring(wink) app back in the day(which I'm not proud of).
| The things we did there...Installing apps without an app
| store, hiding application icon(!), recording phone
| calls(!!!), reading messages(!!!). And all of that was done
| using official APIs on a non-rooted device.
| izacus wrote:
| It also made truly powerful apps possible as well. Apps
| which allowed innovation without asking our corporate
| overlords for permission to exist.
|
| Funny to see people on hacker news demand that some OS
| capabilities be only allowed to corporations themselves and
| noone else.
| curt15 wrote:
| "Google is limiting what apps can use the QUERY_ALL_PACKAGES
| permission that "gives visibility into the inventory of
| installed apps on a given device." "
|
| Sounds like it already is. Google Play is simply changing its
| policy on which apps may request that permission.
| grishka wrote:
| IMO internet access (android.permission.INTERNET) needs to be a
| runtime permission. Ideally with the same kind of granularity
| as location -- one time, while app is in use, in the background
| (through settings). And give an app a brief window to access
| the internet after an FCM push, but FCM pushes are also a
| runtime permission.
|
| But Google being an advertising company would, of course, never
| ever do this.
| kevincox wrote:
| IIRC part of the problem is that there are other leaks
| through the intent system. So the system is so broken that
| adding a permission for INTERNET would just be an illusion of
| safety.
| grishka wrote:
| What do you mean? If you don't have the INTERNET permission
| in your manifest, you won't be able to create network
| sockets. So this enforcement is already in place, it has
| always been. The only possibility I see of leaking internet
| access through the intent system is when an app that does
| have internet access would give content:// URIs with
| granted URI permissions to an app that does not, so it
| would indirectly and unknowingly download something from
| the internet through that app's content provider. I don't
| think it's possible to grant anything on an http(s) URI.
| For that matter, almost any permission can be "leaked" this
| way. You could even skip the intents and content providers
| and just do it with straight AIDL if you're so inclined.
|
| Android's permission system is pretty solid and almost
| impossible to work around.
| matkoniecz wrote:
| And this way even when forced to put it behind permission,
| it will be meaningless.
|
| It is not acccidental that this part would be so hard to
| fix.
| izacus wrote:
| Because that capability is required for apps to interoperate.
| Sandboxing by definition breaks the ability for apps to share
| data and work together. It's a balance to be struck, a
| perfectly secure system is a useless system.
|
| In this case it was mostly used to render custom share dialogs
| (you need to list apps for that), in-line share buttons
| (checking if other app exists is useful to not show the ones
| that aren't installed) and some other possible optimizations
| (e.g. mostly bug fixes for broken apps that couldn't handle
| types of data).
|
| From developers perspective it's useful because it makes your
| app more reliable and easy to use. With the downside that
| malicious people can abuse it.
| f6v wrote:
| I see absolutely no reason for this. You want to share a
| picture? Fine! Just specify a content type, and the system
| will present a list of apps capable of handling it to the
| user.
| izacus wrote:
| Sharing pictures isn't the only use case. The APIs were
| widely used for quite a few other use-cases as well (this
| is why it's a permission now and not removed completely).
|
| Please remember that but everyone subscribes to your exact
| model of safety and capability. There are people that want
| more from their pocket computers than a restricted consumer
| device.
| m00x wrote:
| It does add some benefits and can result in a slightly
| better experience for some apps, but the risk/reward is not
| worth it at all.
| uoaei wrote:
| I hope you are aware that permission flags can be toggled by
| the user.
| izacus wrote:
| This one can't be. (It's not exposed in UI, at least not
| right now.)
| uoaei wrote:
| I think it's pretty clear from the discussion above that
| we are in the realm of the hypothetical.
|
| Why is HN like this?
| TrianguloY wrote:
| I find it hilarious how Play Store is slowly banning permissions
| (some justified, some not) in regards to 'privacy', yet the
| internet permission is still classified as a low dangerous
| permission [0], which means that when you install an app, this
| permission is not even shown. (And you can't even turn it off!)
|
| [0]
| https://developer.android.com/reference/android/Manifest.per...
| Groxx wrote:
| Run a local vpn like netguard! https://netguard.me/ I leave
| mine on deny by default.
|
| That said, I _completely_ agree. Google 's approach to
| permissions on Android has been _wildly_ user-hostile, and full
| of nonsense bundling like (relatively harmless) device-ID and
| (very much not) access to all call logs. Stuff like XPrivacy[1]
| demonstrates how they could have done this with far more user
| control and far less app interruption, but they haven 't.
|
| [1]: not the UI, the UI is terrible. but "send fake contacts"
| or "block outright" for every API is _excellent_ , and doesn't
| require changing apps to support. the fact that the apps can
| query the state _and I cannot lie about it_ is a problem,
| because they often require lots of bullshit that 's not
| required.
| tjohns wrote:
| The Internet permission was largely useless. If you knew what
| you were doing, it was trivial to bypass it to exfiltrate data.
| On top of that, almost every app requests it, which contributed
| to alarm fatigue in users.
|
| Permissions are only useful if they can be enforced and users
| pay attention to them.
___________________________________________________________________
(page generated 2021-04-01 23:02 UTC)