diff --git a/webdriver-extension/explainer.md b/webdriver-extension/explainer.md
new file mode 100644
index 0000000..9d841a5
--- /dev/null
+++ b/webdriver-extension/explainer.md
@@ -0,0 +1,103 @@
+# WebDriver Extension API for Generic Sensor Explained
+**Written**: 2018-09-18
+
+## What’s all this then?
+
+The [Generic Sensor API](https://w3c.github.io/sensors/) and its concrete Sensor APIs pose a challenge to test authors, as fully exercising those interfaces requires physical hardware devices that respond in predictable ways.
+
+At best some vendors have their own automation by using a mocking mechanism, which however introduces the challenge of duplicate efforts across different browsers as well as inconsistency in terms of automation, as different proprietary automation implementations may not do the exact same thing.
+
+To address these challenges, this proposal attempts to define extension commands to the [WebDriver](https://w3c.github.io/webdriver/) specification for controlling mock sensors on the host that the user agent is running on. With these extension commands devices with particular properties can be created and their responses to requests are well defined.
+
+### Why prefer a WebDriver Extension API?
+The reasons for preferring a WebDriver API where appropriate are twofold. First of all, exposing things through WebDriver allows web developers to use them to test sites, an important part of the story around making the web a more appealing platform. The second reason is that integrating with an existing spec makes it obvious what quality bar has to be met for these testing features, which helps alleviate the concern around ending up with tests that are nominally cross-vendor but actually tied to a specific implementation.
+
+### Goals
+
+ - Allow user agents to create mock sensor devices that have certain characteristics and behave in a specific way.
+ - Easily controlling mock sensors via [WebDriver Protocol Extension Commands](https://w3c.github.io/webdriver/#protocol-extensions).
+
+### Non-goals
+
+ - The Mock Sensor API is not intended for direct use in websites as part of the web platform. It is only intended to be an aid for testing.
+
+### Draft Spec
+
+[Draft Spec](https://w3c.github.io/sensors/webdriver-extension)
+
+## What is a Mock Sensor?
+
+A mock sensor simulates the behavior of a [platform sensor](https://w3c.github.io/sensors/#concept-platform-sensor) in controlled ways for the purpose of sufficiently meeting requirements of automated testing of the Generic Sensor API. A mock sensor should have the following capabilities:
+ - Reporting mock sensor readings, which are a source of mock information about the environment, to [Sensor](https://w3c.github.io/sensors/#sensor) objects at the rate of its requested sampling frequency if the user agent is [allowed to expose sensor readings](https://w3c.github.io/sensors/#can-expose-sensor-readings).
+ - User-specified mock sensor readings.
+ - A sampling frequency, which is defined as the frequency at which the user agent obtains sensor readings from a mock sensor. The sampling frequency has upper and lower bounds, which are designed for the purpose of calculating an expected sampling frequency. For instance, when construct a `Sensor` object with a frequency option that exceeds the maximum supported sampling frequency, the exact requested sampling frequency should be capped to the maximum sampling frequency.
+ - A requested sampling frequency, used for calculating the expected sampling frequency.
+ - A connection flag that is used to cause sensor creation and connection to always fail (e.g. for testing the `NotReadableError` exception when calling [`sensor.start()`](https://w3c.github.io/sensors/#sensor-start) fails).
+
+## Getting started
+
+### Basic Flow
+
+This is a basic work flow that demonstrates how WebDriver interacts with browsers and tests that run on an HTTP client.
+
+Tests could be written in any languages, as long as they wrap the WebDriver HTTP APIs. Basically, tests send commands across the common WebDriver API through the [WebDriver wire protocol](https://w3c.github.io/webdriver/#protocol). On the other side, WebDriver, which runs an HTTP server that implements the extension APIs in the WebDriver spec, receives those commands and executes them on the actual browser to manipulate mock sensors and return the results all the way back.
+
+
+
+### Create mock sensor
+
+ To create an "accelerometer" mock sensor with session ID 21, the local end would send a `POST` request to `/session/21/sensor` with the body:
+ ```
+{
+ "mockSensorType": "accelerometer",
+ "maxSamplingFrequency": 60,
+ "minSamplingFrequency": 5,
+ "connected": true
+}
+ ```
+A mock sensor could be configured with following properties:
+- `mockSensorType`: a string that indicates a [sensor type](https://w3c.github.io/sensors/#sensor-type)'s associated [Sensor](https://w3c.github.io/sensors/#sensor) subclass.
+- `maxSamplingFrequency`: a double representing frequency in Hz, used for specifying a mock sensor's maximum supported sampling frequency.
+- `minSamplingFrequency`: a double representing frequency in Hz, used for specifying a mock sensor's minimum supported sampling frequency.
+- `connected`: a boolean that indicates a mock sensor's connection flag.
+
+Once a mock sensor instance is presented, the user agent must force the same sensor type of activated Sensor objects to associate with this mock sensor, and only one mock sensor of a given mock sensor type can be created in current browsing context.
+
+### Get mock sensor
+
+To get an "accelerometer" mock sensor with session ID 22, the local end would send a `GET` request to `/session/22/sensor/accelerometer` without body. On success, the remote end would respond with the serialized mock sensor as data:
+ ```
+{
+ "maxSamplingFrequency": 60,
+ "minSamplingFrequency": 5,
+ "requestedSamplingFrequency": 30
+}
+ ```
+
+### Update mock sensor reading
+
+To update the mock sensor reading of an "accelerometer" mock sensor with session ID 23, the local end would send a `POST` request to `/session/23/sensor/accelerometer` with body:
+ ```
+{
+ "x": 1.12345,
+ "y": 2.12345,
+ "z": 3.12345
+}
+ ```
+
+A mock sensor reading may contain the following attributes:
+ - Attributes defined by the [sensor type](https://w3c.github.io/sensors/#sensor-type)'s associated [extension sensor interface](https://w3c.github.io/sensors/#extension-sensor-interface), which could be updated with this command.
+ - `timestamp`: For all tests, mock sensor readings should have a monotonically increasing timestamp, whose value is a high-resolution timestamp that estimates the [reading timestamp](https://w3c.github.io/sensors/#reading-timestamp) expressed in milliseconds since the time origin. A user agent could easily implement it by using the [Performance API](https://www.w3.org/TR/hr-time-2/#sec-performance).
+
+A user agent must provide the mock sensor readings that are initially exposed to the Sensor objects for the convenience of testing some cases that do not need a user-specified mock sensor reading.
+
+### Delete mock sensor
+
+To delete an "accelerometer" mock sensor with session ID 24, the local end would send a `DELETE` request to `/session/24/sensor/accelerometer` without body.
+
+## References & acknowledgements
+
+ - Discussion on public-test-infra mailing list: [UserAgent-specific files in Web Platform Tests](https://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-name=subject&hdr-1-query=%22UserAgent-specific+files+in+Web+Platform+Tests%22&index-grp=Public_FULL&index-type=g&type-index=)
+ - [Generic Sesnor API](https://w3c.github.io/sensors/#sensor)
+
+Many thanks to Anssi Kostiainen, Raphael Kubo da Costa, Alexander Shalamov, Tobie Langel, Philip Jägenstedt, Jonathon Kereliuk, John Chen, and Mike Pennisi for their comments and contributions to the discussions that have informed it.
diff --git a/webdriver-extension/images/flow_diagram.png b/webdriver-extension/images/flow_diagram.png
new file mode 100644
index 0000000..4f2d542
Binary files /dev/null and b/webdriver-extension/images/flow_diagram.png differ
diff --git a/webdriver-extension/index.bs b/webdriver-extension/index.bs
new file mode 100644
index 0000000..717cd16
--- /dev/null
+++ b/webdriver-extension/index.bs
@@ -0,0 +1,567 @@
+
+Title: WebDriver Extension API for Generic Sensor
+Shortname: webdriver-extension
+Level: none
+Status: ED
+Group: dap
+ED: https://w3c.github.io/sensors/webdriver-extension
+Editor: Wanming Lin 91067, Intel Corporation, https://intel.com/
+Abstract: This document defines extension commands to the [[WebDriver|WebDriver specification]] for the purposes of testing a user agent’s implementation of [[GENERIC-SENSOR|Generic Sensor API]] and its concrete Sensor APIs.
+Version History: https://github.com/w3c/sensors/commits/gh-pages/index.bs
+!Bug Reports: via the w3c/sensors repository on GitHub
+Indent: 2
+Repository: w3c/sensors
+Markup Shorthands: markdown on
+Inline Github Issues: true
+Boilerplate: omit issues-index, omit conformance
+
+
+Introduction {#intro}
+=====================
+
+The Generic Sensor API [[GENERIC-SENSOR]] and its concrete Sensor APIs pose a challenge
+to test authors, as fully exercising those interfaces requires physical hardware
+devices that respond in predictable ways. To address this challenge this specification
+defines extension commands to the [[WebDriver]] specification for controlling
+[=mock sensor=] on the host that the user agent is running on.
+With these extension commands, devices with particular properties can be created
+and their responses to requests are well defined.
+
+Mock Sensors {#mock-sensors}
+=====================
+
+A mock sensor simulates the behavior of a platform sensor in controlled ways.
+
+A [=mock sensor=] reports a corresponding mock sensor reading, which is a source of
+mocking information about the environment, to the Sensor objects.
+
+The current browsing context's [=mock sensor=] has an associated [=mock sensor reading=] [=ordered map|map=].
+
+The [=mock sensor reading=] [=ordered map|map=] contains an [=map/entry=] whose [=map/key=] is
+"timestamp" and whose [=map/value=] is a high resolution timestamp that estimates the time [=mock sensor reading=]
+sent to observers of the Sensor object, expressed in milliseconds since the [=time origin=].
+
+The other [=map/entries=] of the [=mock sensor reading=] [=ordered map|map=] whose [=map/keys=] must match the
+[=dictionary members=] [=identifier=] defined by the [=mock sensor type=]'s {{MockSensorReadingValues}}
+and whose initial [=map/values=] are implementation-dependent.
+
+Note: The user agent must provide the [=mock sensor reading=] that are initially exposed to the Sensor objects.
+
+A [=mock sensor=] has an associated requested sampling frequency. Its default value is implementation-dependent
+but must be set within a [=mock sensor=]'s associated sampling frequency bounds.
+
+A [=mock sensor=] has an associated sampling frequency with supported bounds. The default values of
+supported bounds are implementation-dependent.
+
+A [=mock sensor=] must report the [=mock sensor reading=] at the rate of its [=requested sampling frequency=]
+if the user agent can expose sensor readings to the current browsing context's active document.
+
+
+Note: The [=mock sensor=] defined in this specification is not intended be used by non-testing-related web content.
+The UA MAY choose to expose [=mock sensor=] interface only when a runtime or compile-time flag has been set.
+
+
+The {{MockSensorConfiguration}} dictionary is used to [[#create-mock-sensor-command|create a mock sensor]].
+
+: {{MockSensorConfiguration/mockSensorType}} member
+:: A {{MockSensorType}} that is used to set [=mock sensor type=].
+
+: {{MockSensorConfiguration/connected}} member
+:: A boolean that indicates a [=mock sensor=]'s connection flag which is used for switching the connection
+ between Sensor object and [=mock sensor=]. When set to false the user agent must force the result of invoking
+ connect to sensor with [=mock sensor=]'s associated Sensor object as argument to false, otherwise true.
+
+: {{MockSensorConfiguration/maxSamplingFrequency}} member
+:: A double representing frequency in Hz that is used to set maximum supported sampling frequency for the associated [=mock sensor=].
+
+: {{MockSensorConfiguration/minSamplingFrequency}} member
+:: A double representing frequency in Hz that is used to set minimum supported sampling frequency for the associated [=mock sensor=].
+
+## MockSensor dictionary ## {#dictionary-mocksensor}
+
+
+The {{MockSensor}} dictionary provides information about a [=mock sensor=].
+
+: {{MockSensor/maxSamplingFrequency}} member
+:: A double representing frequency in Hz that indicates the maximum supported sampling frequency of the associated [=mock sensor=].
+
+: {{MockSensor/minSamplingFrequency}} member
+:: A double representing frequency in Hz that indicates the minimum supported sampling frequency of the associated [=mock sensor=].
+
+: {{MockSensor/requestedSamplingFrequency}} member
+:: A double representing frequency in Hz that indicates the requested sampling frequency of the associated [=mock sensor=].
+
+A serialized mock sensor is a JSON Object where a [=mock sensor=]'s fields listed in the {{MockSensor}} dictionary are mapped
+using the |JSON Key| and the associated field’s value from the available [=mock sensor=] in current browsing context.
+
+## Mock sensor type ## {#section-mock-sensor-type}
+
+A mock sensor type is equivalent to a sensor type’s associated {{Sensor}} subclass.
+
+
+
+Each enumeration value in the {{MockSensorType}} enum identifies a [=mock sensor type=].
+Each [=mock sensor type=] has a [=mock sensor reading values=] dictionary:
+
+: Mock Sensor Reading Values dictionary
+:: {{MockSensorReadingValues}} dictionary represents a user-specified [=mock sensor reading=] used for
+ [[#update-mock-sensor-reading-command|updating a mock sensor reading]]. Its members must match the
+ [=attribute=] [=identifier=] defined by the sensor type's
+ associated extension sensor interface. Each [=mock sensor type=]
+ has a specific {{MockSensorReadingValues}}, which is defined in each section of [[#section-mock-sensor-type|mock sensor type]].
+
+
+ dictionary MockSensorReadingValues {
+ };
+
+
+### Ambient Light Sensor ### {#mock-ambient-light-sensor}
+The "ambient-light" type is the mock sensor type
+associated with the usage of the AmbientLightSensor interface.
+
+
+### Accelerometer ### {#mock-accelerometer}
+The "accelerometer" type is the mock sensor type
+associated with the usage of the Accelerometer interface.
+
+
+### Linear Acceleration Sensor### {#mock-linear-acceleration-sensor}
+The "linear-acceleration" type is the mock sensor type
+associated with the usage of the LinearAccelerationSensor interface.
+
+
+### Magnetometer ### {#mock-magnetometer}
+The "magnetometer" type is the mock sensor type
+associated with the usage of the Magnetometer interface.
+
+
+### Uncalibrated Magnetometer ### {#mock-uncalibrated-magnetometer}
+The "uncalibrated-magnetometer" type is the mock sensor type
+associated with the usage of the UncalibratedMagnetometer interface.
+
+
+### Absolute Orientation Sensor ### {#mock-absolute-orientation-sensor}
+The "absolute-orientation" type is the mock sensor type
+associated with the usage of the AbsoluteOrientationSensor interface.
+
+
+### Relative Orientation Sensor ### {#mock-relative-orientation-sensor}
+The "relative-orientation" type is the mock sensor type
+associated with the usage of the RelativeOrientationSensor interface.
+
+
+### Geolocation Sensor ### {#mock-geolocation-sensor}
+The "geolocation" type is the mock sensor type
+associated with the usage of the GeolocationSensor interface.
+
+
+### Proximity Sensor ### {#mock-proximity-sensor}
+The "proximity" type is the mock sensor type
+associated with the usage of the ProximitySensor interface.
+
+
+The create mock sensor extension command creates a
+new [=mock sensor=].
+
+The remote end steps are:
+1. Let |configuration| be the |configuration| parameter, converted to an IDL value
+ of type {{MockSensorConfiguration}}. If this throws an exception, return a
+ WebDriver error with WebDriver error codeinvalid argument.
+2. Let |type| be the |configuration|.{{MockSensorConfiguration/mockSensorType}}. If the current browsing context
+ already has this |type| of [=mock sensor=], return a WebDriver error with WebDriver error code
+ [=mock sensor already created=].
+3. If the current browsing context is no longer open, return a WebDriver error with
+ WebDriver error codeno such window.
+4. Handle any user prompts, and return its value if it is a WebDriver error.
+5. Run these sub-steps [=in parallel=] to create a [=mock sensor=] in the current browsing context:
+ 1. Let |mock| be a new [=mock sensor=].
+ 2. Set |mock|'s [=mock sensor type=] to |type|.
+ 3. Let |connected| be the |configuration|.{{MockSensorConfiguration/connected}}, set |mock|'s associated
+ [=connection flag=] to |connected|.
+ 4. If |configuration|.{{MockSensorConfiguration/maxSamplingFrequency}} is [=present=], then:
+ 1. Set |mock|'s maximum supported sampling frequency to |configuration|.{{MockSensorConfiguration/maxSamplingFrequency}}.
+ 5. If |configuration|.{{MockSensorConfiguration/minSamplingFrequency}} is [=present=], then:
+ 1. Set |mock|'s minimum supported sampling frequency to |configuration|.{{MockSensorConfiguration/minSamplingFrequency}}.
+ 6. Let |sensor_instance| be a |type| of Sensor object, set |sensor_instance|'s associated platform sensor to |mock|.
+6. Return success with data `null`.
+
+
+ To create an "ambient-light" mock sensor in the current browsing context of the session with ID 23,
+ the local end would POST to `/session/23/sensor` with the body:
+
This is a public copy of the editors’ draft.
+ It is provided for discussion only and may change at any moment.
+ Its publication here does not imply endorsement of its contents by W3C.
+ Don’t cite this document other than as work in progress.
+
If you wish to make comments regarding this document, please send them to public-device-apis@w3.org (subscribe, archives).
+ When sending e-mail,
+ please put the text “webdriver-extension” in the subject,
+ preferably like this:
+ “[webdriver-extension] …summary of comment…”.
+ All comments are welcome.
This document was produced by a group operating under
+ the W3C Patent Policy.
+ W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group;
+ that page also includes instructions for disclosing a patent.
+ An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
The Generic Sensor API [GENERIC-SENSOR] and its concrete Sensor APIs pose a challenge
+to test authors, as fully exercising those interfaces requires physical hardware
+devices that respond in predictable ways. To address this challenge this specification
+defines extension commands to the [WebDriver] specification for controlling mock sensor on the host that the user agent is running on.
+With these extension commands, devices with particular properties can be created
+and their responses to requests are well defined.
+
2. Mock Sensors
+
A mock sensor simulates the behavior of a platform sensor in controlled ways.
+
A mock sensor reports a corresponding mock sensor reading, which is a source of
+mocking information about the environment, to the Sensor objects.
Note: The mock sensor defined in this specification is not intended be used by non-testing-related web content.
+The UA MAY choose to expose mock sensor interface only when a runtime or compile-time flag has been set.
A boolean that indicates a mock sensor's connection flag which is used for switching the connection
+ between Sensor object and mock sensor. When set to false the user agent must force the result of invoking connect to sensor with mock sensor's associated Sensor object as argument to false, otherwise true.
+ To create an "ambient-light" mock sensor in the current browsing context of the session with ID 23,
+ the local end would POST to /session/23/sensor with the body:
+