Document Overview
| Feature/Product: | Feature Detection API |
| Projected Feature Freeze Date: | (tbd) |
| Product Champions: | Caitlin Galimidi, Alphan Chen, Ehsan Akhgari |
| Privacy Champions: | Curtis Koenig |
| Security Contact: | Paul Theriault |
| Document State: | [NEW] |
Timeline:
| Architectural Overview: | (date TBD) |
| Recommendation Meeting: | (date TBD) |
| Review Complete ETA: | tbd |
Architecture
In this section, the product's architecture is described. Any individual components or actors are identified, their "knowledge" or what data they store is identified, and data flow between components and external entities is described.
The main objective of this feature/product is: We have a number of use cases for detecting features in the platform which are not directly detectible through the usual way of feature detection (which is |"foo" in object|) because of various reasons, such as lack of sufficient permissions, or the information not being exposed through other parts of the platform, such as the amount of memory available on the device. This information is useful for Market Place because it needs to figure out whether to offer apps that will not work for the user because of things such as lack of support for a feature, not having enough memory, etc.
Note that the initial implementation of this API will be hidden behind a privilege which will only be available to the MarketPlace app. We're hoping to expose this API to unprivileged contexts once we get more experience with it.
Important note: this is not designed to replace the usual feature detection practices on the Web. This is only intended to address the use cases which are not possible to satisfy using the conventional feature detection techniques because the APIs are hidden behind permissions that the calling code does not possess.
Design Documents: https://wiki.mozilla.org/WebAPI/Navigator.hasFeature
Components
Describe any major components in the system and how they interact. Also include any third-party APIs (those Mozilla does not control) and what type of data is sent or received via those APIs.
Component X
This component does A, B and C and interacts with component Y to do D.
The tables below simply summarize the data encountered by this component.
Stored Data:
| What | Where |
|---|---|
| data type | where stored |
Communication with Component Y
| Direction | Message | Data | Notes |
|---|---|---|---|
| In: | message 1 | types of data received from component Y with the message | |
| Out: | message 2 | types of data sent to component Y with the message |
User Data Risk Minimization
In this section, the privacy champion will identify areas of user data risk and recommendations for minimizing the risk.
Alignment with Privacy Operating Principles
In this section, the privacy champion will identify how the feature lines up with Mozilla's privacy operating principles.
See Also: Privacy/Roadmap_2011#Operating_Principles:
Principle: Transparency / No Surprises
(How the feature addresses this)
Recommendations: (what can be improved)
Principle: Real Choice
Recommendations:
Principle: Sensible Defaults
Recommendations:
Principle: Limited Data
Recommendations:
Follow-up Tasks and tracking
| What | Who | Bug | Details |
|---|---|---|---|
| [NEW] Initial Overview Discussion | ? | Meeting time TBD |