|
|
| (111 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| <h1><i>Where's My Fox</i></h1>
| | #REDIRECT [[CloudServices/FindMyDevice]] |
| ==Overview==
| |
| To provide a means for users to locate, track and purge devices remotely.
| |
| | |
| ==Project Contacts==
| |
| ''Principal Point of Contact'' - <i>Doug Turner</i> <i>dougt@mozilla.com</i>
| |
| | |
| ''IRC'' - #<i>services-dev</i>
| |
| | |
| ''Group Email'' - TBD
| |
| | |
| ==Goals==
| |
| * Be able to provide a simple, secure means for FirefoxOS users to remotely locate, track and purge their devices.
| |
| ==Use Cases==
| |
| '''TB provided'''
| |
| | |
| ==Requirements==
| |
| # The user must use a secure credentialing and authorization system to identify self and associate to a device.
| |
| ## The login system is currently Out of Scope of these requirements, but should be or substantially similar to Firefox Accounts.
| |
| ## A user may have one or more devices.
| |
| ## A device shall have a Globally Unique Identifier (WTFID).
| |
| ## A device shall be associated with a single user.
| |
| # Data exchanged between client and server shall be via [http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/ JSON Web Signature format]
| |
| ## The secret shall be generated and stored on the client, and sent to the server ONLY on initialization.
| |
| ### The secret shall be a 128bit value.
| |
| ### The secret shall be stored on the device as long as the WTFID remains unchanged.
| |
| ### A new WTFID shall require a new secret to be generated and the device to reconnect as if new.
| |
| ### No data shall be preserved in the case of a WTFID changing.
| |
| ## Data signatures shall use HMAC SHA-256 or any more secure signing method for any exchange EXCEPT for Initialization.
| |
| * Only allow registered user to display and remotely control devices.
| |
| * Securely send commands to:
| |
| ** report location on a regular interval (for motion tracking)
| |
| *** record tracking information keeping latest location for device
| |
| *** older records expired after ? period ?
| |
| ** play a default audio alarm.
| |
| *** For known period? Forever? What happens if multiple of these commands sent?
| |
| ** remove all user information from a device
| |
| *** Remotely lock/unlock device?
| |
| *** Factory reset or brick?
| |
| * Securely display UI for phone including
| |
| ** current location
| |
| ** previous locations
| |
| ** available commands
| |
| ** help
| |
| ** login page
| |
| * store user & device information (multiple devices)
| |
| ** How long to store data?
| |
| ** How reliable does storage need to be?
| |
| | |
| ==Get Involved==
| |
| <i>Call to action for folks who want to help.</i>
| |
| =Design=
| |
| ==Points of Contact==
| |
| Engineer - <i>Name</i> <i>jr@</i>
| |
| ==API Reference/Documentation==
| |
| | |
| API calls will be a combination of REST calls and BOSH where possible. This avoids some of the issues with the fragility of websockets in areas where connectivity is sub-optimal or sporadic.
| |
| | |
| In addition, packet identifiers have been reduced as much as possible. This is to both reduce bandwidth costs as well as require less time to exchange data (remember, this content is being converted and wrapped in JWS)
| |
| | |
| === Data Schema ===
| |
| <i>How will data be stored</i>
| |
| === API ===
| |
| For this API discussion:
| |
| | |
| <i>$v</i> - API Version (currently 1)
| |
| | |
| <i>$id</i> - Globally unique ID for a device
| |
| | |
| Unless otherwise specified, all exchanged JSON blocks are wrapped in JWS (not shown here for simplicity).
| |
| | |
| ==== POST /<i>$v</i>/init ====
| |
| Post the Init JSON block to the WMF server.
| |
| | |
| From Client (not wrapped in JWS):
| |
| | |
| {"secret":<i>bin64encoded 128b value</i>}
| |
| | |
| Server Reply:
| |
| | |
| 200 {"id": $id}
| |
| | |
| ==== GET /<i>$v</i>/cmd/<i>$id</i> ====
| |
| GET the next command from the Server. This call is triggered by a SimplePush version update.
| |
| | |
| From Server:
| |
| | |
| {"c":<i>COMMAND</i>,
| |
| <i>ARGS</i>}
| |
| | |
| where COMMAND is:
| |
| <dl>
| |
| <dt><b>r</b>ing
| |
| <dd>cause the phone to ring constantly for <b>d</b>uration seconds.<br>
| |
| e.g. <code>{"c":"r","d":60}</code> will cause the phone to ring for 60 seconds or until dismissed on the device by the user.</dd>
| |
| <dt><b>t</b>rack
| |
| <dd>Have the phone report back it's location every <b>p</b>eriod seconds<br>
| |
| e.g. <code>{"c":"t","p":20}</code> will cause the phone to POST to <code>/<i>$v</i>/cmd/<i>$id</i></code>
| |
| {"c":"t", "la":<i>$lattitudeDecimal</i>, "lo":<i>$longitudeDecimal</i>}
| |
| The server may reply back to the "track" POST with either an empty 200 or a <i>COMMAND</i> object
| |
| <dt><b>c</b>ancel
| |
| <dd>Cancel the current activity ("ring" or "track").
| |
| <dt><b>n</b>uke
| |
| <dd>Factory Reset your phone.
| |
| </dl>
| |
| | |
| For each command the client receives, the client optionally POSTs an Ack:
| |
| {"<i>c</i>ommand":"<i>a</i>ck",
| |
| "<i>a</i>ction":"<i>command letter</i>}
| |
| | |
| e.g. for the "ring" command:
| |
| {"c":"a", "a":"r"}
| |
| | |
| Each client Ack may return an additional <i>COMMAND</i> object from the server.
| |
| | |
| ==Platform Requirements==
| |
| <i>What are the things this needs (OS, language, databases, etc.)?
| |
| | |
| ==Libraries Required==
| |
| <i>List of external project dependencies. (Stuff that's not pulled in via the installation script)</i>
| |
| | |
| ==Code Repository==
| |
| <i>Links to the published code bases</i>
| |
| ==Release Schedule==
| |
| <i>Predicted code delivery dates</i>
| |
| | |
| =QA=
| |
| ==Points of Contact==
| |
| Engineer - <i>Ed Wong</i> <i>edwong@</i>
| |
| | |
| ==Test Framework==
| |
| =Security and Privacy=
| |
| Tracking bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=935724 935724]
| |
| | |
| * Bug 935725 - Security Review: Where's My Fox
| |
| * Bug 935726 - Legal Review: Where's My Fox
| |
| * Bug 935727 - Privacy-Technical Review: Where's My Fox
| |
| * Bug 935728 - Privacy-Policy Review: Where's My Fox
| |
| ==Points of Contact==
| |
| ==Questionnaire Answers==
| |
| ===1.1 Goal of Feature ===
| |
| ===2. Potential Threat Vectors and Mitigation Points===
| |
| ==Review Status==
| |
| https://bugzilla.mozilla.org/show_bug.cgi?id=935725
| |
| | |
| see https://wiki.mozilla.org/Security/Reviews
| |
| ==Issues and Resolutions==
| |
| | |
| =Operations=
| |
| | |
| ==Points of Contact==
| |
| ==Deployment Architecture==
| |
| ''Bugzilla Tracking # '' -
| |
| ==Escalation Paths==
| |
| ==Lifespan Support Plans==
| |
| =Logging and Metrics=
| |
| ==Points of Contact==
| |
| ==Tracking Element Definitions==
| |
| ==Data Retention Plans==
| |
| ==Dashboard URL==
| |
| =Customer Support=
| |
| ==Points of Contact==
| |
| ==Sumo Tags==
| |
| ==Review Meeting==
| |