Security/Firefox/Fennec/WebVibrator: Difference between revisions
Jump to navigation
Jump to search
(Created page with ";Items to be reviewed: https://bugzilla.mozilla.org/show_bug.cgi?id=679966 Agenda: ==Introduce Feature == === Goal of Feature, what is trying to be achieved (problem solved, u...") |
mNo edit summary |
||
Line 1: | Line 1: | ||
;Items to be reviewed: | ;Items to be reviewed: | ||
https://bugzilla.mozilla.org/show_bug.cgi?id=679966 | https://bugzilla.mozilla.org/show_bug.cgi?id=679966 | ||
==Introduce Feature == | ==Introduce Feature == | ||
=== Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) === | === Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) === | ||
Line 11: | Line 11: | ||
* mobile only, if device does not have the function this does nothing, although the API still exists to help prevent fingerprinting | * mobile only, if device does not have the function this does nothing, although the API still exists to help prevent fingerprinting | ||
** the vibrator can be turned on when the accelerometer is on, so there's a potential fingerprinting channel here | ** the vibrator can be turned on when the accelerometer is on, so there's a potential fingerprinting channel here | ||
* | * separate API later for notifications (later) | ||
=== What solutions/approaches were considered other than the proposed solution? === | === What solutions/approaches were considered other than the proposed solution? === | ||
* wanted for mobile web | * wanted for mobile web |
Latest revision as of 17:22, 27 October 2011
- Items to be reviewed
https://bugzilla.mozilla.org/show_bug.cgi?id=679966
Introduce Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- uses the vibrator in a mobile device
- can vibrate in a pattern
- format of messages is a list of numbers that correlate to the num of miliseconds that the device operates
- list has a max length, but a page could send multiple lists
- max length is 10s
- can vibrate in a pattern
- mobile only, if device does not have the function this does nothing, although the API still exists to help prevent fingerprinting
- the vibrator can be turned on when the accelerometer is on, so there's a potential fingerprinting channel here
- separate API later for notifications (later)
What solutions/approaches were considered other than the proposed solution?
- wanted for mobile web
Why was this solution chosen?
- wanted hardware access to vibrator for mobile web
- see this as a vector for mobile games
Any security threats already considered in the design and why?
- aware of fingerprinting attacks with the accelerometer
- aware of possible fingerprinting with devices that don't have a vibrator
- tab has to be visible/active
Threat Brainstorming
- permissions for use
- tab has to be visible
- doesnt require user initiation
- draining the battery
- there are many other vectors to this