[HN Gopher] Google Play is reinstating the app permissions section
___________________________________________________________________
Google Play is reinstating the app permissions section
Author : MishaalRahman
Score : 88 points
Date : 2022-07-21 15:28 UTC (7 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| MBCook wrote:
| I honestly don't understand why they thought removing them was a
| good idea.
| anaisbetts wrote:
| The thing is, that Android permissions don't really map to user
| privacy in a way that's useful, and definitely not in a way
| that makes sense to users; simply listing them is actively
| misleading.
|
| For example, every app gets INTERNET by default, meaning that
| _lots_ of privacy-violating things don 't have to be declared
| at all! Other permissions like ACCESS_FINE_LOCATION being
| required until recently for accessing Bluetooth devices meant
| that users would think that every BLE app was spying on them.
| People don't understand the implications of what a permission
| means for their data / privacy
|
| A developer-written description of exactly what an app is doing
| with user data and why is much better (with of course the issue
| that developers can simply lie)
| [deleted]
| dundarious wrote:
| Yes, because they can lie, and because given how the Play
| store operates, Google is probably going to be worse than
| Apple at detecting lies, it's nice to see permissions because
| they function as an upper bound on the extent of the lie. And
| while there are issues with using permissions for this
| because they are not always easy to interpret, they often
| are, so the benefit is clear.
| politelemon wrote:
| > with of course the issue that developers can simply lie
|
| And not something that should be hand waved away in the quest
| to say that written descriptions are better. They are not,
| but having both in other can help to a great extent. A
| practice I've rarely seen is the description containing each
| permission name, and what it's needed for, in other words,
| explaining that mapping that's missing.
| cptskippy wrote:
| I want the programmatically generated list of permissions. I
| want those permissions to be more granular, not less. I want
| the developer to explain why they're using each permission.
| pydry wrote:
| >Other permissions like ACCESS_FINE_LOCATION being required
| until recently for accessing Bluetooth devices meant that
| users would think that every BLE app was spying on them.
|
| This was a dumb hack by Google. "BLE can be used to spy on
| your location" => "you must grant all location data to said
| app".
|
| This is something that is better dealt with a clear privacy
| warning next to the actually relevant permission rather than
| conflating it with GPS.
| tesseract wrote:
| And of course what users generally really care about is
| "does this app upload my location to somewhere?
| continuously or only when I take a specific action?" but
| permissions of that type are basically impossible to
| enforce by technical measures.
| winternett wrote:
| At this point I'm cynical of it all... Any conduct promisses by
| modern device and app makers is worth a pilar of salt after the
| constant breeches of trust by them.
|
| A lot of security settings (especially on the privacy level)
| are often too over-complex or total placebo in nature. A big
| problem is that these settings often get wiped and unstick
| themselves every time an app or OS update occurs, which totally
| defeats the purpose of having to configure apps independently.
| Many apps like TikTok and Instagram barely even function unless
| you grant them invasive camera and microphone access regularly
| (not even selectively).
|
| Regulators need to pursue device makers instead of trying to
| address each individual app maker... Samsung and Apple grant
| access to accelerometers, cameras, contacts, etc. to begin with
| to apps (even when it's nowhere necessary), rather than just
| restricting access at the device and OS level... This allows
| device makers to grant certain apps backdoors for a fee.
|
| Modern phones make me miss Blackberries so much, it's a damn
| shame they're barely compatible with modern networks now or I'd
| light my old one up and forget about these overpriced touch
| screen snitch/spy devices.
| googlryas wrote:
| Like most things Google/mobile, Apple did it, so they had to
| follow suit.
| yccs27 wrote:
| They did? I'm not in the Apple ecosystem, but I thought
| privacy and control over your apps was Apple's thing?
| ajayyy wrote:
| Has Apple shown a list of raw app entitlements? They always
| prefer "simplicity" to user control
| duskwuff wrote:
| Entitlements aren't permissions. There are a lot of
| operating system services which are privacy-relevant, but
| which don't have associated entitlements (e.g. location
| services or contacts access), and a lot of entitlements
| that aren't related to permissions (like ones that let an
| application request an increased memory limit, or allow
| it to store data in iCloud).
|
| Here's a full list of entitlements from Apple. You'll
| find that a lot of them wouldn't make sense to display on
| a store page:
|
| https://developer.apple.com/documentation/bundleresources
| /en...
| MBCook wrote:
| Never. But they have "privacy nutrition labels" that show
| what data is tracked either anonymously or linked to you.
| It's quite helpful, and likely easier to read than a raw
| list of permissions.
|
| https://www.businessinsider.com/what-are-apple-privacy-
| nutri...
|
| When I saw this post I assumed Google was rolling back
| their privacy nutrition label like things they added. I
| didn't realize it was about the granular list.
| LordDragonfang wrote:
| No question that Google has just been trying to ape Apple
| lately, but for mobile specifically there are actually lots
| of features that android and its ecosystem had for years
| before Apple finally added (copied) it for iOS.
| GeekyBear wrote:
| With permissions, before Google started to copy Apple's
| system, there was no such thing as an Android user being
| able to deny an app permission to do something. Either you
| gave the app permission to do everything it wanted, or you
| couldn't install the app at all.
|
| Isn't the next version of Android the first time users will
| be allowed to deny an app permission to send notifications?
| That's been in iOS from the start and has always provided a
| way to silence apps that spam notifications.
| bsoft16385 wrote:
| Android has had the ability to disable notifications for
| at least the last few years.
| GeekyBear wrote:
| >Android 13 (API level 33) introduces a new runtime
| permission for sending non-exempt notifications from an
| app: POST_NOTIFICATIONS. This change helps users focus on
| the notifications that are most important to them.
|
| https://developer.android.com/about/versions/13/changes/n
| oti...
| easrng wrote:
| Android has had the ability to turn off notifications
| since Android 4.1 (July of 2012) and I'm pretty sure the
| ability to turn off notifications on iOS was added in iOS
| 5 (October 2011)
|
| iOS only added permissions at all in iOS 6, before that
| apps had access to photos, calendars, contacts and
| reminders automatically.
| GeekyBear wrote:
| >One of the most notable changes in Android 13 is the new
| runtime permission model for notifications. In previous
| Android versions, apps could post notifications by
| default without requesting any permission.
|
| https://www.xda-developers.com/android-13-beta-3-review-
| noti...
| LordDragonfang wrote:
| Yes, notification permission was previously granted _by
| default_ , because the ability to block an app from
| sending notifications predates the concept of affirmative
| app "permissions".
|
| Android has recently been refining their notifications
| model, increasing the granularity of the notifications by
| splitting them into "types" and user-assigned "priority"
| levels. It seems default-off is the newest step in that,
| apparently.
| ape4 wrote:
| How is it working for Apple?
| [deleted]
| politelemon wrote:
| As with many inexplicable decisions that come from many large
| companies: it's what happens when teams make decisions in a
| vacuum chamber maintained inside a bubble held inside an ivory
| tower surrounded by a silo. I exaggerate but the teams will not
| always be in touch with The external feedback often comes as a
| surprise and if they care, they will scramble for a response.
| MishaalRahman wrote:
| For context: https://news.ycombinator.com/item?id=31698148
| awinter-py wrote:
| > The Data safety section provides users with a simplified view
| of how an app collects, shares, & secures user data, but we also
| want to make app permissions information easily viewable ...
|
| ^ are these vetted in any way? are they enforced? I'm okay with
| this being 'vendor says this', but if app stores are reporting it
| next to permissions (which are _programmatic_ constraints), feels
| like it 's at best aspirational, potentially deceptive. Are there
| real penalties? Or is this just a system for wrist slapping in
| the rare case someone is caught in a lie.
| saagarjha wrote:
| From Google's page on this:
|
| > When Google becomes aware of a discrepancy between your app
| behavior and your declaration, we may take appropriate action,
| including enforcement action.
|
| (https://support.google.com/googleplay/android-
| developer/answ...)
| elliotmurray wrote:
| There are at least some checks in place. I was filling it out
| for an app that I work on, and forgot about a feature where we
| shared a GPS location with an API to get a street address. I
| checked the box to say that the users GPS position never leaves
| the phone and I pretty much instantly got an email saying that
| the app was rejected and to fill out the form again.
| yjftsjthsd-h wrote:
| That's good to hear, but how do they tell? I mean, following
| a GPS API call through to something that talks over the
| network seems like the kind of thing that would be a decent
| amount of work even with the source code; am I
| underestimating the state of modern analysis on binaries?
| awinter-py wrote:
| agree, but also this is where tech needs to get if we want
| to have private experiences + actual control over
| downloaded binaries
|
| (could also do dataflow analysis on code in a trusted third
| party CI system)
___________________________________________________________________
(page generated 2022-07-21 23:02 UTC)