- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 20 Sep 2019 02:29:09 +0000
- To: public-device-apis-log@w3.org
The Devices and Sensors Working Group just discussed `Battery Status`, and agreed to the following: * `RESOLUTION: Replace SecurityError with NotAllowedError in step 2 of getBattery() algorithm and merge #13.` <details><summary>The full IRC log of that discussion</summary> <reillyg> Topic: Battery Status<br> <anssik> github: https://github.com/w3c/battery/pull/13<br> <reillyg> Anssi: In Chrome the battery status API is currently available in cross-origin iframes.<br> <reillyg> ... Mozilla had concerns about this API and dropped it a long time ago.<br> <reillyg> Tom: Looking at stats on HTTP Archive ads are the biggest user of this cross-origin.<br> <reillyg> Reilly: It doesn't seem like we've seen a clearly articulated reason not to land this PR.<br> <tomayac> Usage stats: https://chromestatus.com/metrics/feature/timeline/popularity/2198<br> <reillyg> Anssi: The issue is breaking sites.<br> <reillyg> flaki: If you have metrics for APIs like this then from a standardization point of view we should provide more restrictive versions of these APIs.<br> <reillyg> ... For example, "is on battery power" vs. "what is the current battery level"<br> <reillyg> Anssi: In retrospect, agreed.<br> <reillyg> ... The current usage is very high for taking this API away for cross-origin contexts.<br> <reillyg> Reilly: Ian, do we have exerience taking away APIs like this with FP in other contexts?<br> <reillyg> ... What has been the reaction?<br> <reillyg> Ian: Geolocation is currently under feature policy.<br> <reillyg> Tom: We didn't hear massive outcry.<br> <reillyg> Ian: It's easy to fix in legitimate use cases.<br> <reillyg> Anssi: Do we know what will break?<br> <reillyg> Reilly: chromestatus.com includes top URLs using the API.<br> <tomayac> The post from geolocation days: https://developers.google.com/web/updates/2016/04/geolocation-on-secure-contexts-only<br> <reillyg> Reilly: We should post an Intent to Implement/Deprecate and just do it.<br> <reillyg> Ian: Some people think we should just cut it down to a small number of buckets.<br> <reillyg> Reilly: I think we should do both.<br> <tomayac> Intent to deprecate: insecure usage of powerful features: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ<br> <reillyg> Ian: Is the proposal still to never resolve the promise?<br> <reillyg> Reilly: Why not reject with NotAllowedError?<br> <reillyg> Anssi: For compatibility with existing content.<br> <reillyg> Reilly: Shouldn't script have already been written to handle other failures?<br> <reillyg> Ian: We could browse the web with canary running with this disabled and see how bad it is.<br> <reillyg> Reilly: Both mechanisms will break content but never resolving will break content in weirder ways.<br> <tomayac> and wronger ways<br> <reillyg> Reilly: The current PR text rejects with a SecurityError. It should be a NotAllowedError but otherwise is the right behavior.<br> <reillyg> PROPOSED RESOLUTION: Replace SecurityError with NotAllowedError and merge existing PR.<br> <reillyg> PROPOSED RESOLUTION: Replace SecurityError with NotAllowedError and merge #13.<br> <reillyg> PROPOSED RESOLUTION: Replace SecurityError with NotAllowedError in step 2 of getBattery() algorithm and merge #13.<br> <reillyg> Anssi: Any concerns given wide-scale implications?<br> <reillyg> [None heard]<br> <reillyg> Ian: Are there other interfaces in the Battery API which should be gated by FP?<br> <reillyg> Anssi: getBattery() is the only entrypoint.<br> <reillyg> RESOLUTION: Replace SecurityError with NotAllowedError in step 2 of getBattery() algorithm and merge #13.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/battery/pull/13#issuecomment-533378170 using your GitHub account
Received on Friday, 20 September 2019 02:29:10 UTC