Allow developers to choose just-in-time permissions
Today, there are two ways that a user may be asked to grant permissions to a skill: At the time they enable the skill, and when the skill returns a Permission card with its response. For a developer of a skill that uses permissions, the second of these approaches is optional, and entirely controlled by the skill. The first is mandatory, and completely out of our control.
As a developer, I would like the ability to configure whether any individual permission is prompted for upon skill enablement (and concordantly, whether a permission upsell is triggered when voice enablement is used).
Just because my skill uses permissions does not mean that EVERY user of my skill needs to grant me those permissions. It is reasonable to assume that a skill can contain both permission-gated and permission-free use cases concurrently. Requiring all users to hear about permissions up front, before they need them, has several undesirable effects:
- Users grant me permission I don't need to have yet, which frankly runs contrary to Amazon's security policies, and which makes me liable in a way I don't want to be.
- I am robbed of the opportunity to explain the permissions I'm requesting before the user makes a choice, thereby forcing them into an uninformed decision.
- It drives away users. It has long been known in the mobile world that asking users to agree to permissions at install time causes many users to just drop entirely, even if their use cases would've been covered outside of the permissions in question.
My own skills provide two perfect examples of this:
Astrobot is a skill about providing space launch information. For the most part, it's an information querying skill. You can open a session, ask questions, and be done. But it also provides the option to subscribe to push notifications. A very small fraction of users choose to do this, and it was added on later to the skill which had been working just fine without the feature. But now every single user who enables astrobot is going to be asked for push notifications, regardless of the fact that the vast majority of them have no reason to use it.
Even more frustrating for the user would be how InsultiBot's permissions work. InsultiBot is currently undergoing a massive update to add ISP. As part of that, new "premium" features have been added, and these features require permissions to be granted, where none were requested before. So it is extremely likely that some portion of my users will now enable the skill and grant me permissions, only to find out that not only were the permissions not absolutely required, but that the permissions cannot even be relevant unless they spend money on my skill.
In both of these cases, I would absolutely choose to manage permissions only through the Permission cards.
This would be amazing to have! I use permissions for emailing but if the user never asks for that they may wonder why they gave email permission.
Mark Tucker commented
Also to be considered is whether you can give permission with your voice or require leaving the skill and going to the Alexa app.
I can see scenarios where voice-only permission can be granted once for each session or enabled for all future sessions via a permission in the Alexa app. Developer's can choose which experience fits the situation for their skill.
Nick Schwab commented
The ability to turn off on-enablement Customer Contact permissions and only use just-in-time permissions would be very valuable as well. In the world of apps (voice or otherwise), obtaining contact information often requires an existing trusted relationship with a customer and clear context regarding why the contact information is being requested. Asking for contact information before the user has established a trustful relationship with your skill (such as at enablement) runs a high risk of accumulating negative user reviews and feedback.