Friday, February 24, 2017

6.0 marshmallow - Android 6+ and account permissions: where have they gone to?


I was just browsing the Android Developers Permissions list, and noticed most of the account permissions are gone – in fact, all but GET_ACCOUNTS as it seems. What does that mean, what implications does it have to the end-user – and what else got messed up (apart from the fact there's practically no INTERNET permission anymore)?


As usual, I tried my best Google-Fu but found no answers. Instead, some unanswered questions asking the same. I cannot put it into better words than these:



Marshmallow dropped several Account permissions, including MANAGE_ACCOUNTS and USE_CREDENTIALS, but kept GET_ACCOUNTS. I haven't seen much documentation of what this means for the user in practice, though. I assume that the app that creates an account can automatically use/manage it. However, if a 3rd party app wants to log in with a Google/Facebook/etc account that it did not create:



  • Does it still have to request my interaction/approval the first time each account is accessed/used, or can it just use my accounts automatically now?

  • If I deny the GET_ACCOUNTS permission, can the app still prompt me to log in with an account from my Nexus? Or do I have to grant the app permission to view all of my accounts in order to let it use one of them?




Additionally: if access to accounts is still protected (which I hope it is!) – which permission is protecting it now?




Related questions (whose answers might need to be updated now):





Summing up information collected in the (cleaned-up) comments


The following details came up in the comments. They are not answering my question, but give valuable hints – which is why I'm including them with my question (credits given to their authors):



  • "there's practically no INTERNET permission": It's still there, but automatically granted to each app. No way to revoke it with on-board tools/settings. Which is why I linked to In Android 6, how to deny an app permission to access the network? above. Why that's important? See below.


  • Dan Brown points out that access to accounts is now bound to some _CONTACTS permission. Indeed, using an app to "login with Google" prompts: "Allow X to access your contacts?"
    contacts access
    It's not clear whether you grant read access only (bad enough) or even write access. So now even a cloud storage app (like Dropbox, Mega, etc) gets access to your contacts – which is why always granting INTERNET becomes a privacy nightmare.
    As it's now obvious this part of the account permissions went to contacts (kudos to Dan for the pointer!), I'd really like to read some details on that: how was it changed, why was it changed, what are the implications, how to deal with it.
    Update: As the latest version of the SE app no longer requires to access contacts, Dan created a dedicated question concerning this app on the main Meta, which might be worth checking: How does the new sign-in system work for the Android app? In short, they are using a new version of the "Google Sign In SDK", which no longer requires contacts access. As that only affects Google Sign-In, it doesn't answer my question, though.

  • Dan also pointed out that apps use their own account managers. That was already the case before MM – and the reason why there was the MANAGE_ACCOUNTS permission (see above): they registered their service with Android, so other apps could use it.

  • As I already mentioned with my question, GET_ACCOUNTS is the only surviving account permission. It was already required before MM, and probably still serves the same purpose: In order to use an account, our app first needs to know that it's there – so it has to obtain a list of available accounts to start with. If something has changed in this regard, please include it with your answers.




No comments:

Post a Comment

samsung galaxy s 2 - Cannot restore Kies backup after firmware upgrade

I backed up my Samsung Galaxy S2 on Kies before updating to Ice Cream Sandwich. After the upgrade I tried to restore, but the restore fails ...