User:Mconnor/Current/DevMgr
|
THIS PAGE IS A WORKING DRAFT | 
|
| The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page. |
Status
| Device Manager | |
| Stage | 1 |
| Version | TBD |
| Health | "OK" |
| Status note | Defining requirements |
Team
| Product Manager | Jennifer Arguello |
| Feature Manager | |
| Lead Developer | TBD |
| Security | |
| Privacy | |
| Localization | |
| Accessibility | |
| Quality assurance | |
| User experience |
- Feel free to list other team members below the table here.
Open issues/risks
- Compromise of this service could allow a brute-force attack on users' devices. Assuming a shared secret (i.e. PIN) is used, this will mitigate success of these attacks based on the strength of the secret. However, it must be a user-known secret, so entropy will be minimal.
Stage I: Definition
1. Feature overview
Required This feature will allow users, on an opt-in basis, to remotely track and/or wipe data from their devices.
2. Users & use cases
Required
- The initial target user base is our mobile browser users.
- “Find my device” == view (with gmaps/other provider link to get time and location of last automatic check-in)
- “Wipe my device” == wipe device remotely by entering a shared secret.
3. Dependencies
- Requires a high-availability storage solution to store device info
- Need to build an Android service to do the check-ins and wipes (Fennec sessions are frequently short-lived, leaving an in-browser solution as impractical)
4. Requirements
- Service must be high-availability (five nines?)
- Android client must use very little memory when not checking in.
- Both wipe and tracking will require explicit opt-in
- Wipe command must rely on a shared secret to prevent a mass wipe of users
Non-goals
- Enable this for all users by default
- One-click wipe
Stage II: Design
5. Functional specification
What the feature will do to satisfy the requirements, in written form.
6. User experience design
Designs, interactions, etc., mainly in visual form, if relevant.
Stage III: Planning
7. Implementation plan
Summary of the high-level approach to be taken
8. Security
Are there security risks; has the design been reviewed; what needs to be changed before we proceed?
9. Privacy
Are there privacy risks; has the design been reviewed; what needs to be changed before we proceed?
Stage IV: Development
10. Implementation
Links to bugs -- we don't try to track the detailed progress here, that should happen in bugzilla.
Stage V: Release
11. Landing criteria
Final checklist for everything the feature team feels should happen before a feature can land -- could be a scalability model, security code review, etc. Will eventually develop a standard table for this.
Feature details
| Priority | "unprioritized", "P1", "P2", "P3" |
| Roadmap | whichever Roadmap this Feature is from, or set by Prod Mgr |
| Secondary Roadmap | {{{secondary roadmap}}} |
| Feature List | "Services" |
| Engineering Team | Engineering team who will be doing primary development. |
- Property "Roadmap" (as page type) with input value "whichever Roadmap this Feature is from, or set by Prod Mgr" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- Property "Secondary roadmap" (as page type) with input value "{{{secondary roadmap}}}" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- ""Services"" is not in the list (`, BYOB, Desktop, Marketplace, Mobile, Platform, Plugin Directory, Services, Thunderbird, Jetpack, ...) of allowed values for the "Feature list" property.
Team status notes
Teams are welcome to use these fields however they see fit. Both fields can be used in queries to generate lists on other wiki pages. If you would like help or have questions, please contact Deb.
| status | notes | |
| Products | ||
| Engineering | ||
| Security | ||
| Privacy | ||
| Localization | ||
| Accessibility | ||
| Quality assurance | ||
| User experience |
Revision history
| date | author | change |
| 2011/06/16 | mconnor | Initial feature proposal. |
