sensors
sensors copied to clipboard
w3c
Generic Sensor & Wake Lock API use cases
For the privacy and security reasons sensor readings are only delivered to the currently visible tabs, which means that sensor notification suspends when screen turns off. This could break certain potential use cases, for example:
- a Web application collecting sensor data while the user is doing sport exercises over a long period of time without interacting with device all the time.
Use of Sensor APIs and Wake Lock API together could enable such use case.
In order to make it more battery friendly the screen could be dimmed, so that more power is saved on the device. Maybe a new wake lock type?
Another (maybe more apparent) way is to expose sensor APIs from workers (pls see version 2 features ), but it brings hard-to-solve security and privacy issues.
I think the wake lock approach does not address the privacy and security reasons why sensor data is available only to visible tabs in the first place. It is just forcing the tab to remain technically visible. Also I am not sure if a screen wake lock can be implemented without also keeping the CPU awake which would be wasteful as modern devices are capable of collecting sensor data using a low-power co-processor while the CPU is powered down and only occasionally waking up the CPU to process a new batch.
Perhaps a distinction should be made between cases when a tab is invisible due to the screen being turned off and cases when a tab is invisible because it is not the foreground tab or the browser is not the foreground app.
Also per definition https://w3c.github.io/page-visibility/#dfn-steps-to-determine-the-visibility-state merely turning the screen off does not render a document invisible, not sure how implementations handle this case in reality.
@andrey-logvinov thanks for your comments! I share your concerns regarding keeping CPU awake and etc. IMO it looks fine if an app is wake locking screen and CPU for a limited amount of time. "Long time" in the use case from the description does not necessarily mean hours, the duration of an exercise can be just a few minutes but it still is enough for screen lock. There are other sensors use cases that would benefit from wake lock: e.g. a game web app controlled by the device motion sensors input => the screen should be awake even though the user does not touch it during the game.
Exposing sensors to workers (v2 feature under consideration) is orthogonal to the issue discussed herein. Geolocation is currently not in scope for this group.
[Deleted off-topic comment to keep us focused on the issue at hand.]
Geolocation is currently out of scope and is used in the spec text as an informative example only.
Please restrain from posting further off-topic comments.
Edit: [Deleted another off-topic comment.]