WebVR should follow security and privacy considerations for Generic Sensors

[ddorwin]

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

[anssiko]

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.

[annevk]

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.

[annevk]

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

[NellWaliczek]

This issue was moved to immersive-web/privacy-and-security#8