Allow users to link their social media accounts (Facebook, Twitter, Instagram, etc) in the Alexa App itself. Then allow skills to query which accounts are linked and request permission to use those links, without requiring each skill to perform account linking separately (and perhaps not even exposing the account details to the skill, for greater privacy!).

This would allow a skill to request permission to post to Facebook, for example, to share their new high score. The skill would request this permission at the time of the interaction, and the approval would be delegated to Amazon's built-in handling (to make sure the skill did not deceive the user into granting permission). Once permitted, the skill would be able to use an Amazon API that would in turn call the social media API.

This would abstract this common interaction away from each skill, provide greater consistency, and encourage organic growth of skills.

Currently (10.2018) there is an 8 second timeout for Custom Skills that is standard across all interactions and isn't customizable.

We are aiming to develop a skill that would allow users to opt-in to a skill that is not constrained by time. I.e. the skill will be designed to listen for an unlimited amount of time.

The application for an unlimited amount of time is educational: for families with children with learning disabilities or language development issues there is an opportunity for specialists to be able to measure and analyze a family's "language environment" by using Alexa. Specialists would be able to access the data to proscribe intervention plans based on objectively collected data (as opposed to human recorded data or intermittently collected recordings/transcriptions).

There would be strict permissions and privacy controls and very clear opt-in language for this skill. It would likely even be advised that Amazon provide restricted access to this skill based on the intended application for each developer's use case.

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).

Rationale:
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:

1. 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.
2. 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.
3. 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.

Currently an Alexa response includes permission scopes for "payments:autopayconsent" and "alexa::devices:all:geolocation:read" if the Skill manifest requests those permissions. The status will either be "GRANTED" or "DENIED". If "DENIED" the Skill can request the user enable the permission. However, for all other permissions such as "alexa:devices:all:address:countryandpostalcode:read" or "read::alexa:device:all:address", there is no permission scope provided and the only way to check for the permission is to actually attempt an operation that requires the permission and see if it fails. I would like to request that all permissions requested by a Skill be included in the permission scopes as either "GRANTED" or "DENIED" so that a check can be made by the Skill before attempting an operation that requires a specific permission.

Currently, the Echos have to be linked to an account (which is fine), however, only devices logged into that account are able to cast to an Echo from Amazon Music on iOS/Android.

I have 5 Echo Devices, all linked to my own account, though, I have an Amazon Music Family Subscription and my account is also the Primary Account of Amazon Household.

My suggestion is that any other accounts linked by Amazon Household to the account used on the Echos should be able to cast to those devices too... in fact, my suggestion is that the other Adult Account in the Amazon Household should have the same permissions to the device(s) as the account registered to the Echo.

I definitely feel that the use of Voice Pattern Recognition (i.e., Alexa's ability to understand who is talking to her) coupled with the above suggestion would offer a far more fluid feel to the Echo line of Devices. It would remove the feeling of "ownership" of Echo Devices, and allow the household to feel like a household.

Allow a command to put Alexa to sleep for spoken time or schedule her as well.

Example, Alexa Sleep for 30 minutes, alexa will no longer respond to commands for 30 minutes. I would still want her to be accessible from the app.

Also, Alexa go to sleep at 1:00 p.m. for 30 minutes.

So same thing but at 1:00 p.m. she goes to sleep.

This may be alarming to some users, if they do not know it is asleep so also allow it to be unplugged and turned back on without this enabled.

The reasons I am suggesting this, is now that more and more people working from home especially through the corona virus, people are in meetings and conferences from home. People have co workers named Alexis. This sets her off and she responds in the middle of meetings.

Worse, now several of my coworkers think its hilarious in the middle of meetings to shout Alexa, Set and Alarm for 1 a.m. or start playing music or shut off my lights.

Also several times I am watching a movie and Alexa gets set off my a character name or something it would be nice to just shut her off. Yes I know you can do this by going over and hitting the mic button, but it would be a lot more convenient. This could lead to a lot of security issues and things. There are threads of people all over the internet buying plug to they can just kill the power to her at scheduled times so I am not the only person that would find this handy.

Our service needs account linking to work. Implementing OAuth2 is a lot of work. Using LWA is awkward since the user has already signed in Amazon and also requires the user to LWA in our app again. Using user's email is another way to do it, with the same down side that the user has to LWA in our app. All these force users to give up information that's is not really necessary.

I propose to let apps use Alexa user id to authenticate the user. This way users don't need to do anything on Alexa side besides enabling our skill. In our app, the user sign in using the Alexa client so we could associate the Alexa user id with the current user.

Today, skill permissions (push notifications, device location, etc) are configured for a given skill on a global basis - if I turn on list management permissions to use with en-US, it will be enabled for every language model my skill implements. This doesn't mean that I have to use those permissions in every locale - it's still up to my skill to choose when to take advantage of them. But it does mean that users will be prompted for them.

This is a problem for a couple reasons:
1. As a developer, I may have legitimate reasons for not using a feature in a given locale. (More on this later)
2. The behavior of my skill (specifically, the process of skill enablement) is likely to change without any input on my side when a new feature, which I've implemented in one locale, is suddenly made available by Amazon in another.

A counterpoint here might be "who cares if users are prompted for permissions they can't use in another locale?", but this has concrete (negative) effects: Some portion of users who are prompted for permissions are going to abandon the skill entirely - in this case those users would be lost for no reason. Further, users who blindly grant me permissions even though they can't be used have now put themselves in a state that runs contrary to best practices (that Amazon specifically pushes) where permissions are granted and used only to the degree that they are actually needed.

Now, what I believe to be the rationale behind the current design is that it is meant to provide a consistent experience for the user between different language models. And there's certainly some value to that. But this is already not the de facto state (features are almost never released globally on Amazon's side). More importantly I believe strongly that this is a case where the developer's right to self-determination and control over the interaction between their skill and their skill's users outweighs the benefits of the extremely rare case where a user is moving between language models. Take for example the following scenario:

My skill InsultiBot is currently in the process of implementing both ISP and push notifications. The new feature that uses push notifications is gated by entitlement to products from the ISP feature. This means that in any locale where push notifications are available, users will be prompted to grant me push notification permissions. But in any locale where ISP is NOT available, it will be literally impossible for those users to take advantage of that feature. And indeed, the intents for managing that feature do not even exist in the skill models for those locales.

ERGO,
As a developer, I need the ability to choose which requests for skill permissions are presented to users on a per-locale basis.