Fixed
Status Update
Comments
he...@google.com <he...@google.com> #2
My application offers 'suggested applications' that it can install and then use the functionality of, acting as a plug-in. Tasker is one of those.
My only work-around is to prompt the user to reinstall my application after the suggested applications have been installed, so permissions are detected.
It's of course a horrible 'solution'. Have starred the issue.
brandall
My only work-around is to prompt the user to reinstall my application after the suggested applications have been installed, so permissions are detected.
It's of course a horrible 'solution'. Have starred the issue.
brandall
ap...@google.com <ap...@google.com> #3
he...@google.com <he...@google.com> #4
Using the terminology from the original issue report, one workaround is for App A *and* App B to define the same <permission>. This gets a bit dicey in plugin situations, where App A is not written by the author of App B, only because App A would need all relevant resources (e.g., internationalized strings). OTOH, it works.
pr...@google.com <pr...@google.com> #5
This has security implications as well. Consider the following:
---
App HOST allows access to personally-identifying information through a permission.
App PLUGIN can get access to this information by defining the <permission> as well, and using its own permission.
However, if HOST is not already installed, this permission is not shown to the user when PLUGIN is installed.
When HOST is later installed, PLUGIN now has access to HOST's data, even though the user was never aware of it.
---
Perhaps this is a separate bug. The expected behavior is, if an app has a <uses-permission>, that permission should be shown to the user REGARDLESS of whether the permission exists in another app or doesn't.
---
App HOST allows access to personally-identifying information through a permission.
App PLUGIN can get access to this information by defining the <permission> as well, and using its own permission.
However, if HOST is not already installed, this permission is not shown to the user when PLUGIN is installed.
When HOST is later installed, PLUGIN now has access to HOST's data, even though the user was never aware of it.
---
Perhaps this is a separate bug. The expected behavior is, if an app has a <uses-permission>, that permission should be shown to the user REGARDLESS of whether the permission exists in another app or doesn't.
sh...@gmail.com <sh...@gmail.com> #6
It doesn't work this way. Permissions are granted at install time *only*, so if you install HOST after PLUGIN, PLUGIN doesn't get any extra permissions. Of course, if they are using sharedUserId you get the union of both sets of permissions, but that's a different story.
va...@shopify.com <va...@shopify.com> #7
Perhaps it's not meant to work this way, but I just tested and it does. I installed PLUGIN first (which has both <permission> and <uses-permission>), which obviously doesn't work correctly because HOST is not installed. Then I installed HOST (which has the same <permission> defined). PLUGIN now has access to HOST.
va...@shopify.com <va...@shopify.com> #8
#9: However, you were presented with the custom permission at install time of PLUGIN, as you had <uses-permission>. The exception to this is signature-level permissions, which are never presented to the user, as the signature match alone is sufficient.
he...@google.com <he...@google.com> #9
The problem here is that the PLUGIN can have a different description of the permission in its <permission> tag than the HOST.
You could even use descriptions that look like a boring android permission like INTERNET.
You could even use descriptions that look like a boring android permission like INTERNET.
va...@shopify.com <va...@shopify.com> #10
@mmurphy: That's the thing - at the time of PLUGIN's install, I did *not* see that permission. Could be my ROM though - running 4.2.2/SlimROM/Galaxy Nexus. Would be good if someone could confirm.
@domschuermann: But yes, different descriptions/icons/names are also a problem, and the solution to this isn't trivial.
@domschuermann: But yes, different descriptions/icons/names are also a problem, and the solution to this isn't trivial.
he...@google.com <he...@google.com> #11
Might I add, the permission level was kept at the default, and I signed the two packages with different signatures (one with a debug key, the other with a release).
Description
Component used: Credentials
Version used: 1.0.0-alpha03
Devices/Android versions reproduced on: Huawei P30 Pro (VOG-L29)
I have multiple Google accounts on my phone. After triggering the passkey registration modal, I pressed the "Cancel" button and I got a CreatePublicKeyCredentialDomException with ConstraintError instead of the expected CreateCredentialCancellationException
Here are some logs (PasskeyUtils is from my application):