WebAPI/Security/Camera: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "Name of API: Camera API References: http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html ("Section 2 Scenarios") are use case scenarios from the media capt...")
 
No edit summary
Line 1: Line 1:
Name of API: Camera API
Name of API: Camera API


References:
References:<br>
http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html ("Section 2 Scenarios") are use case scenarios from the media capture task that is creating getUserMedia() which is what this API is based on.
http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios... ("Section 2 Scenarios") are use case scenarios from the media capture task that is creating getUserMedia() which is what this API is based on.


Brief purpose of API: Let content take photos and capture video and/or audio
Brief purpose of API: Let content take photos and capture video and/or audio


Use cases: have been moved to their respective app categories
Generic use cases: See per-category use cases below


Inherent threats: Steal or spy on user video/audio
Inherent threats: Steal or spy on user video/audio
Threat severity: High per https://wiki.mozilla.org/Security_Severity_Ratings
Threat severity: High per https://wiki.mozilla.org/Security_Severity_Ratings


Line 17: Line 18:
*App allows user to record a video with audio to send to someone else
*App allows user to record a video with audio to send to someone else
*App allows user to record an audio clip to send to someone else
*App allows user to record an audio clip to send to someone else
*App allows the user to start a podcast, open other tabs/apps while the recording continues (to look up and comment on
*App allows the user to start a podcast, open other tabs/apps while the recording continues (to look up and comment on information, etc) and then comes back to the tab/original app to finish the podcast.  Note: the user may continue to record while opening or switching  to other tabs/apps
information, etc) and then comes back to the tab/original app to finish the podcast.  Note: the user may continue to record while opening or switching  to other tabs/apps
*App allows foreground photo sharing with realtime preview and special effects.  Needs live video stream and the ability to manipulate the stream on the fly (this one might be a bit of a stretch; can work with the magic button or WebGL shader approach but requires some more research)
*App allows foreground photo sharing with realtime preview and special effects.  Needs live video stream and the ability
to manipulate the stream on the fly (this one might be a bit of a stretch; can work with the magic button or WebGL shader approach but requires some more research)


Authorization model for normal content: user-mediated OS UI
Authorization model for normal content: user-mediated OS UI
Authorization model installed content: user-mediated OS UI
Authorization model installed content: user-mediated OS UI
Potential mitigations: App can launch a user-mediated viewfinder UI take a picture, record the video, or use the
 
camera/mic feed which user approves prior to it being provided to the content.  Uses<video>
Potential mitigations:  
tag (or some such) and is validated to have a non-collapsed extent, not be off-screen, not be (mostly) obscured by other
*App can launch a user-mediated viewfinder UI take a picture, record the video, or use the camera/mic feed which user approves prior to it being provided to the content.   
content. Additionally (contingent upon addressing UX and clickjacking concerns), we could potentially use a "magic button" rendered by OS with the app context. There is a persistent recording indicator (blinking red light?).  App can continuing recording if it loses focus.  Only top level content can request access. There is no "always allow" option in this app category.
*Uses video tag (or some such) and is validated to have a non-collapsed extent, not be off-screen, not be (mostly) obscured by other content.
TBD: Appropriate limitations to device fingerprinting
*Additionally (contingent upon addressing UX and clickjacking concerns), we could potentially use a "magic button" rendered by OS with the app context.
*There is a persistent recording indicator (blinking red light?).   
*App can continuing recording if it loses focus.   
*Only top level content can request access.
*There is no "always allow" option in this app category.
*TBD: Appropriate limitations to device fingerprinting


== Trusted (authenticated by publisher) ==
== Trusted (authenticated by publisher) ==
Line 34: Line 39:
*App allows users to record video from multiple webcams
*App allows users to record video from multiple webcams
*App allows video monitoring such as a baby monitor or security camera that can run for extended periods of time
*App allows video monitoring such as a baby monitor or security camera that can run for extended periods of time
*App can continuing recording if it loses focus.
Authorization model: Explicit


Authorization model: explicit
Potential mitigations: Prompt for camera access, app then retains access to video/audio stream until exit. There is a persistent recording indicator.
Potential mitigations: Prompt for camera access, app then retains access to video/audio stream until exit. There is a persistent recording indicator.
  App can continuing recording if it loses focus.


== Certified (vouched for by trusted 3rd party) ==
== Certified (vouched for by trusted 3rd party) ==
Line 44: Line 50:
* App can continuing recording if it loses focus.
* App can continuing recording if it loses focus.


Authorization model: implicit
Authorization model: Implicit
Potential mitigations:
 
Settings manager could enumerate which apps have implicit access to camera.
Potential mitigations: Settings manager could enumerate which apps have implicit access to camera.
There is a persistent recording indicator.
There is a persistent recording indicator.


  Notes:
==Notes==
*Trusted& certified apps have access to the constraints/capabilities API
*Trusted & certified apps have access to the constraints/capabilities API
 
__NOTOC__

Revision as of 12:03, 25 June 2012

Name of API: Camera API

References:
http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios... ("Section 2 Scenarios") are use case scenarios from the media capture task that is creating getUserMedia() which is what this API is based on.

Brief purpose of API: Let content take photos and capture video and/or audio

Generic use cases: See per-category use cases below

Inherent threats: Steal or spy on user video/audio

Threat severity: High per https://wiki.mozilla.org/Security_Severity_Ratings

Regular web content (unauthenticated)

Use cases:

  • App allows user to take a picture for a profile
  • App allows user to take a picture and record an audio clip
  • App allows user to record a video with audio to send to someone else
  • App allows user to record an audio clip to send to someone else
  • App allows the user to start a podcast, open other tabs/apps while the recording continues (to look up and comment on information, etc) and then comes back to the tab/original app to finish the podcast. Note: the user may continue to record while opening or switching to other tabs/apps
  • App allows foreground photo sharing with realtime preview and special effects. Needs live video stream and the ability to manipulate the stream on the fly (this one might be a bit of a stretch; can work with the magic button or WebGL shader approach but requires some more research)

Authorization model for normal content: user-mediated OS UI

Authorization model installed content: user-mediated OS UI

Potential mitigations:

  • App can launch a user-mediated viewfinder UI take a picture, record the video, or use the camera/mic feed which user approves prior to it being provided to the content.
  • Uses video tag (or some such) and is validated to have a non-collapsed extent, not be off-screen, not be (mostly) obscured by other content.
  • Additionally (contingent upon addressing UX and clickjacking concerns), we could potentially use a "magic button" rendered by OS with the app context.
  • There is a persistent recording indicator (blinking red light?).
  • App can continuing recording if it loses focus.
  • Only top level content can request access.
  • There is no "always allow" option in this app category.
  • TBD: Appropriate limitations to device fingerprinting

Trusted (authenticated by publisher)

Use cases:

  • App allows users to record video from multiple webcams
  • App allows video monitoring such as a baby monitor or security camera that can run for extended periods of time
  • App can continuing recording if it loses focus.

Authorization model: Explicit

Potential mitigations: Prompt for camera access, app then retains access to video/audio stream until exit. There is a persistent recording indicator.

Certified (vouched for by trusted 3rd party)

Use cases:

  • Main Camera app
  • App can continuing recording if it loses focus.

Authorization model: Implicit

Potential mitigations: Settings manager could enumerate which apps have implicit access to camera. There is a persistent recording indicator.

Notes

  • Trusted & certified apps have access to the constraints/capabilities API