W3C home > Mailing lists > Public > public-device-apis-log@w3.org > December 2018

Re: [wake-lock] Give advice on how UAs should infer consent to take a wakelock (#140)

From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
Date: Thu, 27 Dec 2018 19:39:31 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-450217060-1545939570-sysbot+gh@w3.org>
@feross On mobile devices, sites loaded in tabs other than the frontmost one generally get killed pretty quickly due to memory pressure, so even though they could in theory track a user who isn't looking at them, they don't usually get to in practice. The "system" wake lock makes it much more likely that the site will succeed in tracking the user. On desktop, I agree this is less of a problem.

The other mechanisms for preventing the browser from suspending a site are indeed problems, but we should improve users' awareness of them instead of holding the "system" wake lock to the lowest existing bar. Chrome on Android already exposes sites playing audio using a persistent notification, so users get to see that. I think other mobile browsers should do the same, if they're not already, and that we should put similar notices in place for the other mechanisms (or require a "system" wake lock where that's web-compatible).

GitHub Notification of comment by jyasskin
Please view or discuss this issue at https://github.com/w3c/wake-lock/issues/140#issuecomment-450217060 using your GitHub account
Received on Thursday, 27 December 2018 19:39:32 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:56 UTC