diff --git a/index.bs b/index.bs index 16daeee..04968de 100644 --- a/index.bs +++ b/index.bs @@ -155,8 +155,7 @@ explainer documents. This section is non-normative. The scope of this specification is currently limited -to specifying primitives -which enable expose data from local sensors. +to specifying primitives which enable exposing data from [=device sensors=]. Exposing remote sensors or sensors found on personal area networks (e.g. Bluetooth) diff --git a/index.html b/index.html index d4350f8..e060f1e 100644 --- a/index.html +++ b/index.html @@ -1458,7 +1458,7 @@

Generic Sensor API

-

Editor’s Draft,

+

Editor’s Draft,

This version: @@ -1669,8 +1669,7 @@

1. 2. Scope

This section is non-normative.

The scope of this specification is currently limited -to specifying primitives -which enable expose data from local sensors.

+to specifying primitives which enable exposing data from device sensors.

Exposing remote sensors or sensors found on personal area networks (e.g. Bluetooth) is out of scope. @@ -1756,10 +1755,10 @@

4. Security and privacy considerations

Sensor readings are sensitive data and could become a subject of various attacks from malicious Web pages. Before discussing the mitigation strategies we -briefly enumerate the main types of the sensor's privacy and security threats. +briefly enumerate the main types of the sensor's privacy and security threats. The [MOBILESENSORS] categorizes main threats into location tracking, eavesdropping, keystroke monitoring, device fingerprinting, and user identification. This categorization is a good fit for this specification.

-

The risk of successful attack can increase when sensors are used with each other, +

The risk of successful attack can increase when sensors are used with each other, in combination with other functionality, or when used over time, specifically with the risk of correlation of data and user identification through fingerprinting. @@ -1782,11 +1781,11 @@

User agents should consider providing the user -an indication of when the sensor is used +an indication of when the sensor is used and allowing the user to disable it. Additionally, user agents may consider allowing the user to verify past and current sensor use patterns.

-

Web application developers that use sensors should +

Web application developers that use sensors should perform a privacy impact assessment of their application taking all aspects of their application into consideration.

Ability to detect a full working set of sensors on a device can form an @@ -1894,9 +1893,9 @@

5.

5.1. Sensors

The term device sensor refers to a device’s underlying physical sensor instance.

-

The device sensors measure different physical quantities +

The device sensors measure different physical quantities and provide corresponding raw sensor readings which are a source of information about the user and their environment.

-

Each reading is composed of the values of the different physical quantities measured by the sensor at time tn which is called the reading timestamp.

+

Each reading is composed of the values of the different physical quantities measured by the sensor at time tn which is called the reading timestamp.

Known, predictable discrepancies between raw sensor readings and the corresponding physical quantities being measured are corrected through calibration.

Known but unpredictable discrepancies need to be addressed dynamically @@ -1904,15 +1903,15 @@

Calibrated raw sensor readings are referred to as sensor readings, whether or not they have undergone sensor fusion.

The term platform sensor refers to platform interfaces, -with which the user agent ineracts to obtain sensor readings for a single sensor type originated from one or several device sensors.

+with which the user agent ineracts to obtain sensor readings for a single sensor type originated from one or several device sensors.

Platform sensor can be defined by the underlying platform (e.g. in a native sensors framework) -or by the user agent, if it has a direct access to device sensor.

+or by the user agent, if it has a direct access to device sensor.

From the implementation perspective platform sensor can be treated as a software proxy for the -corresponding device sensor. It is possible to have multiple platform sensors simultaneously -interacting with the same device sensor if the underlying platform suppports it.

-

In simple case a platform sensor corresponds to a single device sensor, +corresponding device sensor. It is possible to have multiple platform sensors simultaneously +interacting with the same device sensor if the underlying platform suppports it.

+

In simple case a platform sensor corresponds to a single device sensor, but if the provided sensor readings are product of sensor fusion performed -in software, the platform sensor corresponds to a set of device sensors involved in the sensor fusion process.

+in software, the platform sensor corresponds to a set of device sensors involved in the sensor fusion process.

Note: platform sensors created through sensor fusion are sometimes called virtual or synthetic sensors. However, the specification doesn’t make any practical distinction between them.

@@ -1961,17 +1960,17 @@

5.3. Default sensor

The Generic Sensor API is designed to make the most common use cases straightforward while still enabling more complex use cases.

-

Most of devices deployed today do not carry more than one device sensor providing sensor readings of the same type. -The use cases which require a set of similar device sensors are rare +

Most of devices deployed today do not carry more than one device sensor providing sensor readings of the same type. +The use cases which require a set of similar device sensors are rare and generally limited to specific sensor types, such as multiple accelerometers in 2-in-1 laptops.

The API therefore makes it easy to interact with -the device’s default (and often unique) sensor for each type simply by instantiating the corresponding Sensor subclass.

-

Indeed, without specific information identifying a particular sensor of a given type, the default sensor is chosen by the +the device’s default (and often unique) sensor for each type simply by instantiating the corresponding Sensor subclass.

+

Indeed, without specific information identifying a particular sensor of a given type, the default sensor is chosen by the user agent.

If the underlying platform provides an interface to find the default sensor, the user agent must choose the sensor offered by the platform, otherwise the user agent -itself defines which of the sensors present on the device is +itself defines which of the sensors present on the device is the default sensor.

Listening to the default accelerometer changes: @@ -1982,10 +1981,10 @@

Note: extension to this specification may choose not to define a default sensor when doing so wouldn’t make sense. -For example, it does not make sense to explicitly define a default sensor for geolocation sensor type as the +For example, it does not make sense to explicitly define a default sensor for geolocation sensor type as the implementation of its interface can use multiple backends.

In cases where -multiple device sensors corresponding to the same type may coexist on the same device, +multiple device sensors corresponding to the same type may coexist on the same device, specification extension will have to define ways to uniquely identify each one.

@@ -1999,10 +1998,10 @@

platform sensor reports readings to the user agent considering the reading change threshold.

The reading change threshold refers to a value which indicates whether or -not the changes in the device sensor's measurements were significant enough to +not the changes in the device sensor's measurements were significant enough to update the corresponding sensor readings.

The threshold value depends on the surrounding software and hardware -environment constraints, e.g., software power consumption optimizations or the underlying device sensor's accuracy.

+environment constraints, e.g., software power consumption optimizations or the underlying device sensor's accuracy.

5.5. Sampling Frequency and Reporting Frequency

For the purpose of this specification, sampling frequency for a platform sensor is defined as a frequency at which the user agent obtains sensor readings from the underlying @@ -2017,7 +2016,7 @@

requested sampling frequency exceeds upper or lower sampling frequency bounds supported by the underlying platform.

  • -

    the threshold value is significant so that some of the device sensor's measurements are skipped and the sensor readings are not updated.

    +

    the threshold value is significant so that some of the device sensor's measurements are skipped and the sensor readings are not updated.

    The reporting frequency for a concrete Sensor object is defined as a frequency at which onreading notification is called.

    A Sensor object cannot access new readings at a higher rate than the @@ -2089,9 +2088,9 @@

    This example illustrates a possible implementation of the described Model.

    In the diagram below several activated Sensor objects from two -different browsing contexts interact with a single device sensor.

    +different browsing contexts interact with a single device sensor.

    -

    The Sensor object in "idle" state is not among the platform sensor's activated sensor objects and thus it does not interact with the device sensor.

    +

    The Sensor object in "idle" state is not among the platform sensor's activated sensor objects and thus it does not interact with the device sensor.

    In this example there is a platform sensor instance per browsing context.

    The latest reading map is shared between Sensor objects from the same context and is updated at rate equal to requested sampling frequency of the corresponding platform sensor.

    @@ -2214,7 +2213,7 @@

    Note: the nodes in the diagram above represent the states of a Sensor object and they should not be -confused with the possible states of the underlying platform sensor or device sensor.

    +confused with the possible states of the underlying platform sensor or device sensor.

    When a Sensor object is eligible for garbage collection, the user agent must invoke deactivate a sensor object with this object as argument.

    7.1.2. Sensor internal slots

    @@ -2434,16 +2433,16 @@

    Let type be the sensor type of sensor_instance.

  • -

    If the device has a single device sensor which can provide readings for type, then

    +

    If the device has a single device sensor which can provide readings for type, then

    1. Associate sensor_instance with a platform sensor corresponding - to this device sensor.

      + to this device sensor.

    2. Return true.

  • -

    If the device has multiple device sensors which can provide readings for type, then

    +

    If the device has multiple device sensors which can provide readings for type, then

    1. If type has an associated default sensor, then

      @@ -2914,7 +2913,7 @@

      A default sensor. Generally, devices are equipped with a single platform sensor of each type, so defining a default sensor should be straightforward. - For sensor types where multiple sensors are common, extension specifications may choose not to define a default sensor, + For sensor types where multiple sensors are common, extension specifications may choose not to define a default sensor, especially when doing so would not make sense.

      9.7. Extending the Permission API

      @@ -2938,7 +2937,7 @@

      9.8. Example WebIDL

      Here’s example WebIDL for a possible extension of this specification -for proximity sensors.

      +for proximity sensors.

      [Constructor(optional ProximitySensorOptions proximitySensorOptions),
  SecureContext, Exposed=Window]
 interface ProximitySensor : Sensor {
@@ -3053,7 +3052,7 @@ 
      This is an example of an informative example.

    • Because this document doesn’t itself define APIs for specific sensor types—that is the role of extensions to this specification—all examples are inevitably (wishful) fabrications. - Although all of the sensors used a examples + Although all of the sensors used a examples would be great candidates for building atop the Generic Sensor API, their inclusion in this document does not imply that the relevant Working Groups are planning to do so.

    @@ -3478,16 +3477,17 @@

    I