WebVR should follow security and privacy considerations for Generic Sensors

[NellWaliczek]

From @ddorwin on June 27, 2017 19:21

WebVR exposes sensor data to the Open Web Platform. The Generic Sensor API specification “defines a framework for exposing sensor data to the Open Web Platform in a consistent way.” [1] WebVR should follow this framework, especially the security and privacy considerations ([2]). The Security check algorithm ([3]) and other parts may also be useful.

The DeviceOrientation API is the most similar to WebVR, which essentially exposes a higher-resolution/frequency version of the same data. This spec defers entirely to [2]. [4]

One might argue that some items may not apply when a user gesture is required, but a gesture is not required for magic window. Thus, such differentiation would place more requirements on non-presenting WebVR than the more powerful presenting mode.

Note that integration with the Permissions API, which is recommended by [2], is also preferred for features that use Feature Policy (#86).

In particular, note that [2] requires that “all interfaces defined by this specification or extension specifications must only be available within a secure context.” Note also that Chrome intends to deprecate DeviceOrientation on insecure origins [5] (this is an older API that predates the guidance in the current spec).

In the context of these similar specs, it is hard to argue that WebVR, especially when not presenting, should be available on insecure contexts. Furthermore, if non-presenting WebVR is not available on insecure contexts, it seems weird to allow the more powerful presenting mode in such contexts.

[1] https://w3c.github.io/sensors/
[2] https://w3c.github.io/sensors/#security-and-privacy
[3] https://w3c.github.io/sensors/#security-check
[4] https://w3c.github.io/orientation-sensor/#security-and-privacy
[5] https://crbug.com/481604

Copied from original issue: immersive-web/webxr#249

[NellWaliczek]

From @anssiko on June 29, 2017 8:48

Looping in the Generic Sensor API editors @rwaldron @pozdnyakov @alexshalamov who can help iron out the security and privacy considerations for the WebVR API when you start flesh out these aspects in the "v2.0" spec.

I agree with @ddorwin's assessment that this problem space is largely shared with that of the Generic Sensor API and the concrete sensor APIs that extend it, and as such it'd make sense to tap into this existing body of knowledge on the topic where appropriate.

Edit: related #250.

[NellWaliczek]

From @annevk on July 25, 2017 7:41

FWIW, Mozilla has a policy of sorts that new APIs should use secure contexts. We haven't really consistently enforced it thus far, but I think it would make sense for VR to add the [SecureContext] annotation to its objects.

[NellWaliczek]

From @annevk on September 29, 2017 8:49

A commit by @toji linked from here indicates [SecureContext] has been added to some of the APIs, but https://w3c.github.io/webvr/spec/1.1/ still lacks those annotations. What's the status here?

cc @bfgeek @dbaron

[peterclemenko]

I have to agree. This looks like a valid thing to implement given the nature and fidelity of the data involved. As a red teamer I could use data science methods to look at sensor data so I can analyze and deanonymize/identify the user.