ChromeOS Power Interface API Proposal

Please see the updated proposal.

You’re about to propose a new extension API, what a marvelous road you have ahead of you.  Before you venture forth, though, we’d like to get a sense for your new API and offer you some guidance on your way.  Fill out this proposal and post it under For Developers‎ > ‎Design Documents‎ > ‎Extensions‎ > ‎Proposed & Proposing New Changes‎ > ‎API Proposals in the list of proposed APIs, then include a link in your Extension Review request in go/extensionsreview.  

Proposal Date
11th September 2012

Who is the primary contact for this API?
rkc@chromium.org

Who will be responsible for this API? (Team please, not an individual)

ChromeOS UI Team.


Overview
The ChromeOS power management interface is an API made available via the Chrome extensions subsystem. The purpose of this API is to be able to turn power management on and off in Chrome OS. Since power is a very sensitive area, any changes to this setting will only be allowed while the extension requesting it is alive. To handle multiple extensions changing the setting, we’ll implement an API similar to Android's. An extension can add a request to keep the machine awake and release the request once it’s done. Power management will be kept disabled while there are keep awake requests alive. Once all extensions that have requested this have either released their requests power management will be enabled again. An extension can choose to not release the keep awake request while it is loaded on the system. If an extension gets unloaded and has pending keep awake requests, they’re automatically released.
Use cases
Since Chrome has a minimalist approach to settings, we really only want to introduce a setting if a majority of users would use it. Power settings is one area that doesn't qualify that bar. Our purpose with power was to try to figure out what settings work best for a given scenario and provide them automatically but this is not predictable in all cases.
Unfortunately, for the scenarios where power setting changes are needed, their not being available makes ChromeOS unusable. This extension API provides a way for applications that encounter such scenarios to be able to turn off power management while they are loaded.

Certain examples for this are,
  • Media player applications
  • Slideshow apps
  • Guitar Tabs/Sheet Music display apps

Do you know anyone else, internal or external, that is also interested in this API?
There has been a need expressed for this from various people, particularly some enterprise customers.

Could this API be part of the web platform?
This is very specific to Chrome and that too on ChromeOS, hence this isn't a good fit for the web platform.

Do you expect this API to be fairly stable?  How might it be extended or changed in the future?
The API might evolve over time but the current methods exposed will always be supported. To address future needs we may add methods that allow finer tuning of power settings.

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?
The API spec has the mechanism to handle multiple extensions using it.

List every UI surface belonging to or potentially affected by your API:
This should not touch the UI at all.

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?
The users will only be able to see the effects of the API.

How could this API be abused?
Rogue extensions can use this API to keep a machine awake forever, potentially causing battery life issues.

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) Keep the machine on till the battery runs out.

What security UI or other mitigations do you propose to limit evilness made possible by this new API?
The security issues with the API are minimal. The worst effect possible with this API doesn't compromise user data in any way.

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. We explicitly undo all changes made by the extension using this API once the extension is unloaded.


How would you implement your desired features if this API didn't exist?
Provide a command through Crosh for a user to do this manually.

Draft Manifest Changes 
As of right now this should not require any manifest changes.

Draft API spec
The draft is available at https://docs.google.com/a/google.com/document/d/1CrZJRH5Eoh8A_6o8PwERzVSDSwEr2DDOOn14gekVCb0/edit

Open questions
The comments on the draft spec have a few open questions.

Comments