W3C home > Mailing lists > Public > public-device-apis-log@w3.org > March 2017

Re: [sensors] Javascript 120Hz devicemotion events for high end inertial applications

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Mon, 20 Mar 2017 16:36:20 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-287818130-1490027779-sysbot+gh@w3.org>
Hey @timvolodine.

Thanks for chiming in.

There are two reasons why high frequencies might be warranted, which map directly to a bunch of key uses case we want to unlock.

1. Faster frequency allows to lower latency, which is key to fight motion sickness in VR.
2. You might just require more data points for certain things (e.g. inertial apps as described by OP).

As you mentioned, increased latency increased battery consumption, though I'm not sure how the numbers stack-up compared to say using a gyroscope vs. an accelerometer (i.e. from a battery usage perspective, is polling a gyroscope at 60 Hz cheaper or more expensive than polling an accelerometer at 240Hz). It would be nice to have more data on this.

The security concerns are more worrying. They're pretty serious and hard to explain to users which isn't a good combo.

As you mentioned, we have a number of lines of defence for those:

- liming sensor access to secure contexts,
- limiting sensor access to top level browsing contexts (and ultimately opening that up through [Feature policy](https://docs.google.com/document/d/1k0Ua-ZWlM_PsFCFdLMa8kaVTo32PeNZ4G7FFHqpFx4E/edit)),
- pausing sensors when page visibility changes to hidden,
- caping polling frequency,
- fuzzing frequency /  timestamps,
- limiting data accuracy,
- relying on permissions (either by letting users set them on through whatever other heuristics),
- disable sensor usage when user becomes inactive (that might be a tough one if you have both highly sensitive sensors and are only using sensors as user input).

You also added user gesture in there, which I hadn't thought about and aren't too familiar with. Pointers to how this would be helpful here would be welcomed. 

Each of those have different advantages and disadvantages. The key is to tie it all back to the use cases we want to enable.

I was hoping to move forward with a binary approach to permissions, but it sounds like we might want to consider a more fine-grained strategy using dedicated [`PermissionDescriptor`s](https://w3c.github.io/permissions/#dictdef-permissiondescriptor), for example to require non-fuzzy data, higher frequencies, or high-accuracy.

GitHub Notification of comment by tobie
Please view or discuss this issue at https://github.com/w3c/sensors/issues/98#issuecomment-287818130 using your GitHub account
Received on Monday, 20 March 2017 16:36:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 12:18:52 UTC