Who is the primary contact for this API?
Who will be responsible for this API?
The Chrome OS UI team.
This API is intended to provide a way for extensions and apps to temporarily disable aspects of system power management on Chrome OS. It is a modified version of an earlier proposed API (see also additional implementation details).
When the user is inactive, Chrome OS dims the screen, turns it off, and eventually suspends the system. It attempts to avoid some or all of these actions when the user is watching video or listening to audio. Some apps may wish to trigger similar behavior on their own; imagine e-book or presentation apps that need to prevent the screen from being dimmed or turned off, or a communication app that needs to prevent the system from suspending so that incoming calls may be received.
Do you know anyone else, internal or external, that is also interested in this API?
Yes, there is an internal need for this API (http://crbug.com/178944). External users have requested the ability to e.g. disable power management entirely on desktop machines; this API makes it possible to write a simple extension that does so.
Could this API be part of the web platform?
Likely, although the level of control over system power management available to Chrome may vary between different OSes.
Do you expect this API to be fairly stable? How might it be extended or changed in the future?
Yes, it should be stable. I don't foresee any need to add additional levels of power-management-disabling.
If multiple extensions used this API at the same time, could they conflict with each others? If so, how do you propose to mitigate this problem?
Requests will be tracked per-extension. Since requests are additive, conflicts should not be possible.
List every UI surface belonging to or potentially affected by your API:
No UI changes are planned.
Actions taken with extension APIs should be obviously attributable to an extension. Will users be able to tell when this new API is being used? How?
This isn't currently planned. It would be possible to add UI that notifies the user when an extension creates a request, though.
How could this API be abused?
Extensions could use this API to disable power management features indefinitely.
Imagine you’re Dr. Evil Extension Writer, list the three worst evil deeds you could commit with your API (if you’ve got good ones, feel free to add more):
1) Disable power management features indefinitely while the extension is running, increasing power consumption, decreasing battery life, and possibly confusing the user.
What security UI or other mitigations do you propose to limit evilness made possible by this new API?
Extensions will only be able to override power management while the system's lid is open; closing the lid will still suspend the system.
Alright Doctor, one last challenge:
Could a consumer of your API cause any permanent change to the user’s system using your API that would not be reversed when that consumer is removed from the system?
No. Any outstanding requests will be abandoned when an extension is stopped.
How would you implement your desired features if this API didn't exist?
An extension could perform actions that trigger Chrome OS's existing automated power-management-disabling behavior. For example, playing a silent audio file would prevent the system from suspending.
Draft API spec