Document Overview

Timeline:

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

This API gives you knowledge about two separate classes of things. For the "api" namespace as described in https://wiki.mozilla.org/WebAPI/Navigator.hasFeature#.22api.22_namespace, the information is basically directly derivable from the user agent string.

For the "hardware" namespace as described in https://wiki.mozilla.org/WebAPI/Navigator.hasFeature#.22hardware.22_namespace, the API queries the OS to detect the amount of physical memory available to the OS. The returned values are always powers of two (for example, 256MB, 512MB, 1GB, etc.)

User Data Risk Minimization

This API does not expose any data describing the user.

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

The feature appears to be designed in such a way as to assist users in finding apps or services that are compatible with the hardware of their phone/tablet device. However, the use of this api outside of privelaged applications or the Marketplace application itself should be closely examined as the possibility exists such that the API could be misused to fingerprint an individual users.

Recommendations:
In Mozilla's use of the api we should not store this information other than for point in time usage or it should be gathered and stored in such a way that we can not identify and individual user but can still in aggregate see usage statistics for research purposes.
bug 1004123 - Feature Detection API Transparency

Principle: Real Choice

There does not appear to be a user exposed interface that allows users to choose if the request for information is appropriate.
Recommendations:
bug 1004106 - Feature Detection API User Choice

Principle: Sensible Defaults

Consideration should be given to how the API will be used by various levels of FirefoxOS apps
Recommendations:
bug 1004112 - Feature Detection API Sensible Defaults

Principle: Limited Data

We should consider if an application or content request should be limited in the number of items it can request at any one time or if some items should be mutually exclusive to prevent user fingerprinting.
Recommendations:
bug 1004115 - Feature Detection API Limited Data

Follow-up Tasks and tracking