[wakelock] for discussion: [w3ctag/spec-reviews] Review of WakeLock API and suitability for overall platform ...

TAG comments on wake lock API on public TAG spec-reviews issues list:

see https://github.com/w3ctag/spec-reviews/issues/126 <https://github.com/w3ctag/spec-reviews/issues/126>


hadleybeeman <https://github.com/hadleybeeman> commented 16 hours ago <https://github.com/w3ctag/spec-reviews#issuecomment-278482276>
We've just noticed in the Security and Privacy Considerations section that if you request a wakeLock and it were denied because the battery was low, this might accidentally expose the device's battery level to the site. You might want to mention that.

triblondon <https://github.com/triblondon> commented 16 hours ago <https://github.com/w3ctag/spec-reviews#issuecomment-278485608>
Thanks, this looks like it is much improved. Aside from Hadley's point above, we also came up with the idea that for some use cases currently addressed by WakeLock, there may be a more elegant solution involving a subscription to events in a ServiceWorker. For example, if my jogging application requires the continuous tracking of a person's GPS position, with (say) a 20 second interval sample rate, and then wants to write that data to storage for later processing, then a Serviceworker could be woken up with an event each time the GPS position changed outside of that time-window debounce tolerance. This might be more power efficient, and we wonder if the spec wants to anticipate that future solution at all.

Finally, I wonder if a system wakelock is cancelled by locking the device, and we feel this should be in the spec. If a screen wakelock exists, then manually placing the device in standby (using a hardware lock button) would presumably cancel the wakelock, whereas manually hitting the lock button on a device with an active system wakelock would (we assume) not affect the wakelock and the page would continue to run as if it were foregrounded on an active screen.
 <https://github.com/andrey-logvinov>
 
andrey-logvinov <https://github.com/andrey-logvinov> commented 6 hours ago <https://github.com/w3ctag/spec-reviews#issuecomment-278581680>
@triblondon <https://github.com/triblondon> in the jogging application case, I think you shouldn't need to explicitly request a wake lock at all, as you want the device to be woken up on external events vs not going to sleep in the first place. I think this case is best addressed by the API which provides your GPS position, such as Generic Sensors API <https://github.com/w3c/sensors>. In the end, the CPU already needs to wake up to process each sample and decide whether the position has changed beyond your tolerance threshold, so no wake lock should be needed there.
 <https://github.com/triblondon>
 
triblondon <https://github.com/triblondon> commented 3 minutes ago <https://github.com/w3ctag/spec-reviews#issuecomment-278662374>
@andrey-logvinov <https://github.com/andrey-logvinov> Would the generic sensors API provide continuous data even if the application is backgrounded? Sorry I'm not so familiar with how generic sensor events work. If that use case is already enabled by generic sensors, brilliant. It seems like your use cases could do with updating to be clearer about the specific scenarios you are targeting with system wake locks. Currently it is very heavy on screen lock scenarios.

Let me bring mine and Hadley's feedback together for convenience:

Use cases could be improved to include system lock use cases and comment on the RioRun scenario (eg describe scenarios in which developers might be tempted to use a wakelock but should not)
We'd like the security and privacy implications to acknowledge the information leakage risk if wakelocks are denied when battery level is low. You might want to say you're happy with that leakage but it's worth acknowledging it.
Specify how wakelocks interact with the user manually activating the hardware lock mechanism of the device
 <https://github.com/fhirsch>
 
    


Write