15:07:10 <RRSAgent> RRSAgent has joined #das
15:07:10 <RRSAgent> logging to https://www.w3.org/2021/04/06-das-irc
15:07:12 <Zakim> RRSAgent, make logs Public
15:07:13 <Zakim> please title this meeting ("meeting: ..."), anssik
15:07:14 <Laura_> Laura_ has joined #das
15:07:14 <anssik> Meeting: Devices and Sensors WG - 2021 Q2 virtual meeting - Other device capabilities
15:07:25 <anssik> Chair: Anssi, Reilly
15:07:30 <anssik> Agenda: https://www.w3.org/events/meetings/a8a1448f-049b-468e-8b45-8eae6b8e75be
15:07:35 <anssik> RRSAgent, draft minutes v2
15:07:35 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-das-minutes.html anssik
15:08:07 <anssik> Present+ Anssi Kostiainen
15:08:16 <xfq> present+ Fuqiao_Xue
15:08:20 <anssik> Present+ Arnaud_Mardy
15:08:20 <reillyg> Present+ Reilly Grant
15:08:21 <kenchris> Present+ Kenneth_Christiansen
15:08:23 <scheib> Present+ Vincent Scheib
15:08:25 <tomayac> tomayac has joined #das
15:08:26 <lgombos> Present+ Laszlo_Gombos
15:08:29 <anssik> Present+ Lars_Knudsen
15:08:37 <anssik> Present+ Alexis_Menard
15:08:38 <Laura_> Present+ Laura _Morinigo
15:08:43 <anssik> Present+ Reilly_Grant
15:08:47 <Laura_> Present+ Laura_Morinigo
15:08:48 <anssik> Present+ Thomas_Steiner
15:08:54 <anssik> Present+ Fuqiao_Xue
15:09:09 <anssik> Present+ Laura_Morinigo
15:09:21 <anssik> Present+ Laszlo_Gombos
15:09:23 <rakuco> present+ Raphael_Kubo_da_Costa
15:09:28 <anssik> Present+ Vincent_Scheib
15:09:39 <anssik> Present+ Peter_Burrows
15:09:50 <anssik> RRSAgent, draft minutes v2
15:09:50 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-das-minutes.html anssik
15:10:19 <arno_> arno_ has joined #das
15:10:24 <anssik> Scribe: Anssi
15:10:30 <anssik> scribeNick: anssik
15:11:12 <anssik> Topic: Device Posture API
15:11:30 <anssik> -> https://w3c.github.io/device-posture/ Device Posture API
15:11:51 <PeterB> PeterB has joined #das
15:12:37 <anssik> Kenneth: had some difficulties in exposing the fold, privacy issues and upcoming devices not ready yet
15:13:12 <anssik> ... we're considering on postures driven by key use cases, spec renamed to Device Posture API to reflect the new tighter scope
15:13:35 <anssik> ... waiting for more devices to come to the market
15:13:55 <anssik> ... Alexis has been implementing this API on Windows and can give an update
15:14:24 <anssik> Alexis: in Chromium some bits are landing, including Media Query parts
15:14:37 <anssik> ... Samsung has submitted a path for IDL parts in review as of now
15:14:43 <anssik> s/path/patch
15:14:53 <anssik> Alexis: next step Android and Windows backend implementations
15:15:04 <anssik> ... Android backend implementation expected to be more straightforward
15:15:18 <anssik> ... on Windows no official API to access hinge angle so a bit challenging
15:15:56 <anssik> ... some  devices exposing a custom sensor, working with Intel's fw team to improve reliability of readout to meet the requirements
15:16:37 <anssik> ... in the future we expect an OS level support on Windows, considering other factors e.g. keyboard attached etc.
15:16:50 <lgombos> q+
15:16:54 <anssik> q?
15:16:59 <anssik> ack lgombos
15:17:17 <anssik> lgombos: thanks for the update, you mentioned adding support for Windows
15:17:27 <anssik> ... any information, which actual browsers on Windows would support that?
15:17:43 <anssik> Alexis: from Intel's POV we're indifferent
15:17:57 <larsgk> larsgk has joined #das
15:17:58 <anssik> ... working to get the feature behind flags on all Chromium-based browsers
15:18:11 <anssik> lgombos: any feedback from Microsoft?
15:18:28 <anssik> Kenneth: positive
15:19:10 <anssik> Alexis: OEMs such as Lenovo are extremely keep and eager to get something on the web, not just web sites supporting new form factors, but making the browser a better citizen
15:19:20 <anssik> q?
15:19:42 <anssik> lgombos: the API doesn't depend on a foldable device
15:19:54 <anssik> Alexis: you could retrofit the API in a 2-in-1
15:21:23 <anssik> anssik: any high priority open issues for the spec?
15:22:15 <anssik> Alexis: more open discussion on the posture computation in which case we return which posture
15:22:52 <anssik> anssik: that is mapping of angle range to postures?
15:22:57 <anssik> Alexis: correct
15:23:03 <anssik> q?
15:23:52 <Laura_> q?
15:24:00 <anssik> ack Laura_
15:24:26 <anssik> Laura: to clarify, in the short term we can discuss how to define the "posture", that is missing
15:24:41 <anssik> ... should be a quick fix
15:24:58 <anssik> -> https://github.com/w3c/device-posture/issues Open issues
15:25:13 <anssik> q?
15:25:46 <anssik> Reilly: looks like the spec had been recast from the Fold Angle to Device Posture API
15:25:56 <anssik> ... mitigates privacy and fingerprinting concerns
15:26:06 <anssik> ... what is the current privacy review status?
15:26:27 <anssik> Kenneth: PING has not looked at this, TAG has and the new scope seems good for the TAG
15:27:14 <anssik> proposed RESOLUTION: Initiate PING review for the Device Posture API
15:28:02 <anssik> Reilly: PING review can happen in parallel with Origin Trial
15:29:45 <anssik> ... the number of bits of entropy are the minimum necessary to implement the use case
15:30:10 <anssik> ... seems to mitigate most of the concerns of sharing device state between the pages, hopeful this gets through PING revie
15:30:14 <anssik> s/revie/review
15:30:50 <anssik> Alexis: not too many foldable devices at this moment, so could help narrow down on devices of this class, but time will take care of this as more devices become available
15:30:56 <scheib> q+
15:31:29 <anssik> ack scheib
15:31:54 <anssik> Vincent: the more explicit use cases we can provide, the easier it is to reason about them
15:32:17 <anssik> ... the current spec explains the concepts, but should add some easy to understand use cases to the spec
15:32:43 <anssik> proposed RESOLUTION: Refine use cases and then initiate PING review for the Device Posture API
15:33:16 <anssik> RESOLUTION: Refine use cases and then initiate PING review for the Device Posture API
15:33:40 <anssik> Topic: Screen Wake Lock API
15:33:52 <reillyg> scribeNick: reillyg
15:34:02 <anssik> -> https://w3c.github.io/screen-wake-lock/ Screen Wake Lock API
15:34:24 <anssik> Recent updates to modernize the spec language e.g. https://github.com/w3c/screen-wake-lock/pull/299
15:34:52 <reillyg> Raphael: I'm happy to report that nothing too exciting or controversial has been happening.
15:35:07 <reillyg> ... Since TPAC there's been cleanups and tidying of spec language.
15:35:11 <tomayac> Usage overall goes slowly up: https://chromestatus.com/metrics/feature/timeline/popularity/3005.
15:35:49 <reillyg> ... Improved "in parallel", added a task source, fixed up permissions API integration.
15:36:00 <anssik> q+
15:36:02 <reillyg> ... Most of these changes don't have user-visible effects.
15:36:18 <reillyg> ... Chromium is in sync with the current version of the specification.
15:36:44 <reillyg> ... Not much future work in the queue. Screen brightness could be added as an extension. Will discuss on Thursday.
15:37:31 <reillyg> ... There are implementation details which could be improved. For example, Anssi's request to integrate with user proximity detection.
15:37:32 <anssik> -> https://github.com/w3c/screen-wake-lock/pull/298 editorial: Remove the "obtain a permission" algorithm
15:38:05 <anssik> q?
15:38:22 <anssik> ack anssik
15:38:27 <reillyg> ... The spec has a custom model for obtaining permissions. There is an open question about whether it should be removed and/or this logic merged into the Permissions API.
15:39:23 <reillyg> Anssi: Do you see any other specs that should be similarly refactored?
15:39:51 <reillyg> Raphael: It is worth taking a look at those specs. I will take that AI.
15:40:38 <anssik> ACTION: Raphael to check if other DAS WG specs are doing "in parallel" properly
15:41:00 <larsgk> q+
15:41:05 <anssik> ack larsgk
15:41:41 <reillyg> Lars: Maersk is using User Presence for dashboard applications.
15:42:06 <anssik> larsgk: we use Screen Wake Lock API for our use cases for mission critical monitor
15:42:33 <reillyg> ... We use the Screen Wake Lock API for mission critical monitors.
15:42:35 <anssik> q?
15:43:06 <anssik> Topic: System Wake Lock API
15:43:40 <anssik> scribeNick: anssik
15:43:46 <anssik> scribeNick: scheib
15:44:32 <scheib> Reilly: Last TPAC resolved to write new explainer.  Separated repositories from screen lock.
15:44:34 <anssik> q+
15:44:53 <anssik> q?
15:44:57 <anssik> ack anssik
15:44:57 <scheib> .. No recent movement on use cases or preasure to implement.
15:45:25 <scheib> s/preasure/pressure/
15:45:53 <scheib> Anssi: Dev rel folks, have we heard anything?
15:46:37 <anssik> q?
15:46:46 <scheib> Tom: There was a partner with geo-tracking use case which considered keeping phone active.  However, noting this would have poor power impact.
15:47:03 <anssik> -> https://www.w3.org/2020/10/22-dap-minutes.html#r02 TPAC 2020 resolution
15:47:24 <scheib> Reilly: From TPAC resolution, noted we shoujld find non-geo-tracking usecases.
15:47:30 <tomayac> GeoMover: https://geo-mover.vercel.app/
15:48:14 <scheib> .. Nascent use-cases of large operations, e.g. compute, are in progress and the system should stay awake.
15:49:07 <anssik> q?
15:49:19 <scheib> Anssi: Situation similar to last TPAC then, awaiting further clarifying motivating use-cases.
15:50:52 <scheib> Topic: Battery Status API
15:50:58 <anssik> -> https://w3c.github.io/battery/ Battery Status API
15:51:10 <anssik> -> https://github.com/w3c/battery/issues/15 Assess compatibility risk of using [SecureContext] (issue #15)
15:51:53 <scheib> Anssi: This is an old API which could use improvements.
15:52:17 <scheib> .. This is one of the rare APIs with custom/explicit SecureContext checks vs current IDL constructs.
15:53:21 <scheib> .. Chrome implementation did not use this custom spec wording.  Wording has been removed from spec with reference to issue #15.
15:53:54 <rakuco> q+
15:54:04 <anssik> ack rakuco
15:54:52 <scheib> .. Seeking implementor to update e.g. chromium and spec.  Raphael might do so.
15:54:58 <reillyg> q+
15:55:08 <anssik> ack reillyg
15:55:21 <scheib> Raphael: Might be a smaller/moderate change.
15:56:09 <anssik> RRSAgent, draft minutes v2
15:56:09 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-das-minutes.html anssik
15:56:22 <tomayac> https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins
15:56:23 <scheib> Reilly: Support for Deprecating, with measurement of usage etc.  Might frame this as an intervention for privacy.  Step 1 is to measure.
15:56:54 <scheib> Anssi: Use counters are in place.
15:56:56 <anssik> Non-secure HTTP usage is now at ~0.38% per https://www.chromestatus.com/metrics/feature/popularity#BatteryStatusInsecureOrigin
15:57:15 <tomayac> https://chromestatus.com/metrics/feature/timeline/popularity/2199
15:58:04 <anssik> q?
15:58:39 <scheib> Reilly: Since measurement exists, then next chromium step is Intent to Deprecate
15:58:58 <scheib> .. Create a chrome status entry, send Intent with links to spec discussions.
15:59:02 <scheib> q+
15:59:07 <anssik> q?
15:59:51 <anssik> proposed RESOLUTION: Advance with deprecation of non-secure usage of the Battery Status API in coordination with implementation
16:00:09 <anssik> q?
16:00:11 <anssik> ack scheib
16:01:36 <xfq> present+ Peter_Snyder
16:01:38 <anssik> scheib: we should circulate the intent to deprecate within a group of involved people to ensure it is well crafted, include measurements
16:01:48 <rakuco> q+
16:01:58 <anssik> ack rakuco
16:03:02 <scheib> scheib: Noted current shipping status is Chrome only, other chromium browsers e.g. Samsung, Edge, not indicated as shipping on https://caniuse.com/wake-lock
16:03:18 <anssik> proposed RESOLUTION: Advance with deprecation of non-secure usage of the Battery Status API in coordination with implementation
16:03:53 <anssik> RESOLUTION: Advance with deprecation of non-secure usage of the Battery Status API in coordination with implementation
16:04:13 <scheib> .. Apologies, that information is wrong, was looking at wrong API.  Battery: https://caniuse.com/battery-status has shiped.
16:04:39 <anssik> scribeNick: anssik
16:04:51 <anssik> Topic: Geolocation API
16:05:42 <anssik> -> https://github.com/w3c/permissions/issues/231 Explicitly limit permission lifetimes
16:06:33 <anssik> Pete: -> https://github.com/w3c/geolocation-api/issues/69 Explicitly limit permission lifetimes #69
16:08:02 <anssik> Pete: this issue is a result of PING review, geolocation information is very sensitive, so privacy considerations need to be carefully reviewed
16:10:41 <tomayac> FWIW, Chrome now has a new "Only once" option
16:10:42 <anssik> ... the issue is the fire and forget permission grant for the Geolocation API
16:10:58 <reillyg> q+
16:12:09 <anssik> ack reillyg
16:12:12 <tomayac> We now have [On every visit] [Block] [Only this time]
16:12:53 <anssik> Reilly: wanted to ask Pete, what language you'd like to see added to the Geolocation API assuming Permissions API includes language for session or time limiting grants
16:13:24 <anssik> q?
16:13:42 <pete> pete has joined #das
16:14:25 <anssik> Pete: I'm intentionally not suggesting UI related prose
16:14:46 <anssik> ... such as the like characters appear in the UI
16:15:21 <anssik> ... I would expect Geolocation to say this permission must include option scopes A, B and C
16:17:05 <pete_snyder> pete_snyder has joined #das
16:18:42 <anssik> -> https://github.com/w3c/geolocation-api/issues/69#issuecomment-652041324 Proposal for normative changes
16:19:08 <anssik> anssik: Pete's strawman proposal:
16:19:11 <anssik> 9. The Geolocation API MUST allow users to specify whether the
16:19:11 <anssik> requesting site has access to geolocation data for
16:19:11 <anssik> (i) the length of the frame,
16:19:11 <anssik> (ii) for the length of the session, or
16:19:12 <anssik> (iii) any number of longer periods of time, which can be decided by implementors.
16:19:12 <larsgk> q+
16:19:37 <anssik> ack larsgk
16:20:07 <anssik> larsgk: question, often you don't care about geo tracking when at home?
16:20:26 <pete_snyder> (i dont think it is correct that many people don't care about geolocation tracking in their home, though i appreciate its a different category of concern)
16:22:47 <pete_snyder> q+
16:22:54 <anssik> Reilly: I'd love to see more informative text in the spec to describe guidance to implementers how to implement such UX/UI
16:22:56 <anssik> q?
16:23:06 <anssik> ack pete_snyder
16:23:24 <anssik> Pete: I agree this discussion comes up often in privacy review
16:23:54 <anssik> ... as normatively as we can often can we can should define UI and UX behavior
16:24:56 <pete_snyder> https://www.fastcompany.com/90454921/apple-and-googles-tough-new-location-privacy-controls-are-working
16:25:43 <reillyg> q+
16:26:01 <pete_snyder> q-
16:26:55 <anssik> Pete: specs often do specify UI or UX behaviour
16:27:35 <anssik> q?
16:27:52 <anssik> Reilly: I think I agree with Pete's comment on specs implicitly defining UX
16:28:17 <anssik> ... over time a number of specs have defined things in ways that even though not mandating UI it can be inferred
16:28:47 <anssik> ... newer specs have tried to spec permission hooks in such a way that there's room to ask the user without blocking
16:29:35 <anssik> ... Geolocation spec is an example that predates this more recent permission work
16:29:43 <larsgk> (clarification on my comment: perhaps if transitioning to roaming, revoke geo permission/ask user - not "don't care when home")
16:29:53 <anssik> ... maybe we'll add a new API that'd allow the sites to ask for much more restricted permissions
16:30:50 <anssik> ... can we change the compatibility requirements, or is the current shape of the API fine and all we're talking here is recommendation on the mitigations
16:31:32 <anssik> ... there are examples such as Gamepad API, a sync API does not allow browsers to offer a prompt, the platform needs to respond immediately
16:32:04 <anssik> ... that we got wrong in the past in some specs, not the case with Geolocation API that is async and offers means to hook in permission UI
16:32:26 <anssik> Pete: I see there's a feature that's specified very tightly(?)
16:32:38 <anssik> Reilly: is there a change to the API itself or implementation that'd mitigate your concern?
16:32:57 <anssik> Pete: I don't have a strong opinion about that
16:33:42 <anssik> Reilly: the developers aren't going to call a method that will give the geolocation but only for 5 minutes, otherwise it'll break their app
16:33:55 <anssik> ... it is in the developers' interest to get the permission as long as possible
16:34:39 <anssik> ... developers have to handle the case when the permission goes away
16:35:14 <anssik> q?
16:36:56 <anssik> Reilly: there's room for the spec to offer implementer guidelines to help surface these privacy concerns more clearly
16:37:10 <pete_snyder> for example, WebXR says "The user agent MUST use trusted UI to show permissions prompts." (https://www.w3.org/TR/webxr/#trustedenvironment-security).  I only mean there is a spectrum of how tightly or narrowly UX issues are defined
16:37:14 <pete_snyder> ie +1 to Reilly
16:37:27 <scheib> q+
16:38:59 <anssik> -> https://w3c.github.io/geolocation-api/#security Privacy and security considerations
16:39:46 <anssik> Reilly: question to Pete, I'd like to see developer interest in a version of the API that offers less information
16:41:26 <scheib> q?
16:41:39 <anssik> ack scheib
16:41:44 <anssik> ack reillyg
16:41:50 <scheib> -> https://w3c.github.io/geolocation-api/#enablehighaccuracy-member
16:42:23 <anssik> Vincent: I think the desired outcome is the browsers facilitate more privacy-aware enviroment
16:42:33 <anssik> ... some of that happens in spec, some outside the spec work
16:42:47 <anssik> ... e.g. high accuracy is one considerations of the spec
16:43:14 <anssik> ... temporal capability of the API, another dimension controlling how much information is exposed
16:43:48 <anssik> ... how precision is currently handles is complicated, nothing stops an implementation to provide a mm accuracy
16:44:06 <anssik> ... for some APIs we quantize the precision of orientation sensors, a valid mitigation
16:44:20 <anssik> ... should think of the temporal nature, also think of non-temporal
16:45:04 <anssik> anssik: noting a bunch of these issues have been discussed in the next-gen Geolocation Sensor spec https://github.com/w3c/geolocation-sensor/issues
16:48:55 <pete_snyder> Update spec to include ability to restrict lifetime and scope of geolocation capabilities, and include S&P guidance on UI and UX
16:50:36 <anssik> Reilly: agree on "include S&P guidance on UI and UX" portion
16:51:02 <anssik> ... would like to see the references Pete provided earlier on developers looking for ways to ask for restricted lifetime and scope
16:51:03 <pete_snyder> q+
16:51:35 <anssik> proposed RESOLUTION: Update spec to include ability to restrict lifetime and scope of geolocation capabilities per gathered developer feedback, and include S&P guidance on UI and UX
16:53:12 <anssik> ack pete_snyder
16:54:08 <anssik> Pete: ability to allow well-behaving sites to ask for less, then limit ability of malicious sites to ask too much
16:55:29 <anssik> Pete: some issues have been closed without my consent
16:56:18 <anssik> anssik: comment on issues you feel have been closed prematurely
16:56:43 <pete_snyder> the request is for normative changes though
16:57:34 <anssik> Reilly: it seems we're going back and forth on the normative aspects for UX, that is up to the implements to decide how they present those things to users
16:57:45 <anssik> ... changing spec does not change that
16:57:57 <anssik> Pete: the ask is to allow browser vendors to do that
16:59:05 <anssik> ... there must be a way for users to grant permission for a day, a week, a month
17:05:51 <anssik> RRSAgent, draft minutes v2
17:05:51 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-das-minutes.html anssik
17:08:46 <anssik> RESOLUTION: Expand Privacy and Security considerations with discussion of privacy harms from long-lived permissions and Gather developer feedback on restricted lifetime and scope of geolocation capabilities.
17:08:49 <anssik> RRSAgent, draft minutes v2
17:08:49 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-das-minutes.html anssik
17:09:19 <anssik> Topic: Network Information API
17:09:53 <anssik> Reilly: nothing new to report, focus now on Compute Pressure API  that is somewhat related
17:09:59 <anssik> Topic: HTML Media Capture
17:10:11 <larsgk> q+
17:10:20 <anssik> FYI, this is being integrated into HTML Living Standard per W3C/WHATWG Update
17:10:23 <anssik> ack larsgk
17:11:07 <anssik> RRSAgent, draft minutes v2
17:11:07 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-das-minutes.html anssik
19:13:31 <Zakim> Zakim has left #das