Security/Reviews/ScreenSaverAPI

Please use "Edit with form" above to edit this page.

Item Reviewed

Create API for content to keep the screensaver from turning on (or to prevent phone/tablet's screen from turning off)
Target	Full Query ID Summary Priority Status 697132 Create API for content to keep the screensaver from turning on (or to prevent phone/tablet's screen from turning off) -- RESOLVED 749376 SecReview: Resource Lock API -- RESOLVED 2 Total; 0 Open (0%); 2 Resolved (100%); 0 Verified (0%);

{{#set:SecReview name=Create API for content to keep the screensaver from turning on (or to prevent phone/tablet's screen from turning off)

|SecReview target=

Full Query

ID	Summary	Priority	Status
697132	Create API for content to keep the screensaver from turning on (or to prevent phone/tablet's screen from turning off)	--	RESOLVED
749376	SecReview: Resource Lock API	--	RESOLVED

2 Total; 0 Open (0%); 2 Resolved (100%); 0 Verified (0%);

}}

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

1) Expose power management features to privileged gaia apps 2) Allow content to request a wake lock for a resource - for each resource, content can hold a lock of state of locked, locked but not visible and unlocked. - not visible is only observed for some topics (e.g. it doesn't make sense for network or, perhaps, CPU)

• Topics: Are they defined yet (apparently not)?
• Mentioned so far:
  • CPU
  • Screen lock / brightness
  • Network lock
• Suggestion from Lucas - At least on the Desktop, being able to grab the screenlock could be implicit if you're fullscreen or playing a video.

2 weird things:

1. it has 2 surfaces that are exposes; 1 to content,
2. to privileged (see interface link above) - doesn't allow you to actually do anything - it allows you to request and monitor lock state

• All the policy ends up happening either in gaia or chrome.js
• 1 policy - things that aren't visible can't affect the

What solutions/approaches were considered other than the proposed solution?

• see bug 697132

Why was this solution chosen?

`

Any security threats already considered in the design and why?

• Battery flattening (by carelessly developed / malicious content) are discussed in bug 697132

Threat Brainstorming

• There's a question around what kind of apps should be able to do various things (e.g. turn screen on / off, lock, CPU, etc)
• What could go wrong with notifications (from the backend); these essentially result in js being executed

{{#set: SecReview feature goal=1) Expose power management features to privileged gaia apps 2) Allow content to request a wake lock for a resource - for each resource, content can hold a lock of state of locked, locked but not visible and unlocked. - not visible is only observed for some topics (e.g. it doesn't make sense for network or, perhaps, CPU)

• Topics: Are they defined yet (apparently not)?
• Mentioned so far:
  • CPU
  • Screen lock / brightness
  • Network lock
• Suggestion from Lucas - At least on the Desktop, being able to grab the screenlock could be implicit if you're fullscreen or playing a video.

2 weird things:

1. it has 2 surfaces that are exposes; 1 to content,
2. to privileged (see interface link above) - doesn't allow you to actually do anything - it allows you to request and monitor lock state

• All the policy ends up happening either in gaia or chrome.js
• 1 policy - things that aren't visible can't affect the

|SecReview alt solutions=* see bug 697132 |SecReview solution chosen=' |SecReview threats considered=* Battery flattening (by carelessly developed / malicious content) are discussed in bug 697132 |SecReview threat brainstorming=* There's a question around what kind of apps should be able to do various things (e.g. turn screen on / off, lock, CPU, etc)

• What could go wrong with notifications (from the backend); these essentially result in js being executed

}}

Action Items

Action Item Status	In Progress
Release Target	`
Action Items
Who bug Action By When Completed date [NEW] new [DONE] Done [MISSED] Miss jlebar 764131 Fixing the b2g screen wake lock to have permissions [NEW] new Full Query ID Summary Priority Status 764131 SecReview: Resource Lock API - Fixing the b2g screen wake lock to have permissions -- RESOLVED 1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

{{#set:|SecReview action item status=In Progress

|Feature version=`

|SecReview action items=

Who	bug	Action	By When	Completed date [NEW] new [DONE] Done [MISSED] Miss
jlebar	764131	Fixing the b2g screen wake lock to have permissions		[NEW] new

Full Query

ID	Summary	Priority	Status
764131	SecReview: Resource Lock API - Fixing the b2g screen wake lock to have permissions	--	RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

}}

Other

Discussion on whether origin is appropriate in the context of apps - most of the detail around this exists elsewhere (permission discussion, etc)