04:50:52 RRSAgent has joined #dap 04:50:52 logging to https://www.w3.org/2021/10/28-dap-irc 04:51:01 Meeting: Devices and Sensors WG - TPAC 2021 vF2F Day 2 04:52:29 present+ Fuqiao_Xue 04:52:39 scribe+ 04:52:44 rrsagent, make log public 04:52:47 rrsagent, make minutes 04:52:47 I have made the request to generate https://www.w3.org/2021/10/28-dap-minutes.html xfq 04:56:36 Juha has joined #dap 04:56:48 Zakim, prepare meeting 04:56:48 RRSAgent, make logs Public 04:56:49 please title this meeting ("meeting: ..."), anssik 04:56:55 Meeting: Devices and Sensors WG - TPAC 2021 vF2F Day 2 04:57:02 Chair: Anssi, Reilly 04:57:07 Agenda: https://github.com/w3c/devicesensors-wg/issues/47 04:57:15 Scribe: Anssi 04:57:18 present+ Arnaud_Mandy 04:57:20 scribeNick: anssik 04:57:23 Present+ Anssi_Kostiainen 04:57:39 present+ Juha_Vainio 04:59:08 present+ Diego_Gonzalez 04:59:09 mattreynolds has joined #dap 04:59:51 present+ Alexis_Menard 05:00:18 present+ Lars_Knudsen 05:00:27 arnaud_mandy has joined #dap 05:00:33 present+ Matt_Reynolds 05:00:37 larsgk has joined #dap 05:00:52 present+ Reilly_Grant 05:01:11 arnaud_mandy has left #dap 05:01:13 present+ tomayac 05:01:15 RRSAgent, draft minutes 05:01:15 I have made the request to generate https://www.w3.org/2021/10/28-dap-minutes.html anssik 05:01:30 present+ Raphael_Kubo_da_Costa 05:01:34 arma has joined #dap 05:01:35 present+ scheib 05:01:43 present- scheib 05:01:49 present+ Vincent_Scheib 05:02:23 scribe+ reillyg 05:03:06 present+ Marcos_Caceres 05:04:37 Topic: Device Posture API 05:05:40 Agenda: https://github.com/w3c/devicesensors-wg/issues/47 05:05:53 RRSAgent, draft minutes 05:05:53 I have made the request to generate https://www.w3.org/2021/10/28-dap-minutes.html reillyg 05:08:38 Subtopic: Revised posture types 05:08:52 RRSAgent, draft minutes 05:08:52 I have made the request to generate https://www.w3.org/2021/10/28-dap-minutes.html marcosc 05:09:34 diekus: Recall, this API allows the developer to detect the physical posture that the device is in. 05:09:59 ... Originally presented as the Fold Angle API, providing the angle between the two halves of a foldable devices. 05:10:00 RRSAgent, draft minutes 05:10:00 I have made the request to generate https://www.w3.org/2021/10/28-dap-minutes.html anssik 05:10:21 Present+ Laura_Morinigo 05:10:41 ... Now, as the Device Posture API, supporting devices with any type of posture, regardless of whether they use a folding screen. 05:11:24 Present+ Thomas_Steiner 05:11:35 ... Abstract postures into three groups. 05:12:13 ... "Continuous" represents a device in a flat (or flat-ish) position. 05:13:06 present- tomayac 05:13:17 ... "Folded" represents devices that can physically fold. 05:13:19 Laura_M has joined #dap 05:13:34 RRSAgent, draft minutes 05:13:34 I have made the request to generate https://www.w3.org/2021/10/28-dap-minutes.html anssik 05:13:49 sudeep has joined #dap 05:14:18 ... Want to differentiate between a device which is folded and one which is folded over (the third posture) which occurs when the device is folded beyond the continuous mode. 05:14:23 -> https://w3c.github.io/device-posture/#posture-types 05:14:57 q? 05:15:04 q+ 05:15:11 Alexis: Simplification driven by TAG feedback. 05:15:51 anssik: Has the TAG approved these final posture types? 05:15:55 q+ to ask about more than one fold angle. 05:16:10 Alexis: Yes, the review was left open until the new postures were defined. 05:16:22 q? 05:17:06 ... Working on backends for more platforms. Android requires additional SDK changes. 05:17:35 ... Windows has no OS APIs for posture (e.g. hinge angle sensor). Intel is engaged with Microsoft to determine a path. 05:19:20 Laura: Concerns with privacy were resolved by the latest changes. 05:19:30 ... Current postures are working okay for Samsung. 05:19:47 ... Some developers are still interested in the angle. 05:21:17 anssik: We expect that the editors will continue to evolve the specification to track the ecosystem of new foldable devices. 05:21:21 ack marcosc 05:21:23 q? 05:21:49 marcosc: Have the posture names been approved by the CSS working group? 05:22:43 ... In particular "folded-over" includes a dash which might have special meaning. 05:23:03 Alexis: We have not. We can reach out to the CSS WG. 05:23:36 Present+ Kenneth_Christiansen 05:23:52 Kenneth: It was looked at by members of the CSS WG as part of the TAG review. 05:24:33 Alexis: I will take that action. 05:25:55 -> https://www.w3.org/2020/11/das-wg-charter.html#coordination DAS WG Coordination with CSS WG 05:26:01 ... Would like to keep everything in the Device Posture specification because it hasn't gotten enough developer feedback. 05:26:53 ... Regarding the fold angle, it was removed as a privacy matter. 05:27:05 ... The balance of use cases vs. the privacy risk wasn't compelling. 05:27:20 q? 05:27:37 ... If there are use cases from developers for the hinge angle let's open an issue to track those. 05:28:09 ... We know that in the future the posture won't be only dependent on the angle. 05:28:24 anssik: It might make sense to separate these two. 05:28:36 q? 05:28:43 Alexis: Let's provide that issue as a landing zone for developers who are looking for this. 05:28:56 q+ Laura_M 05:28:59 ack Laura_M 05:29:49 Laura_M: One of the first things developers ask for when we explain the API is how to get the exact angle. After we explain the postures developers stop asking about the angle. We haven't found specific use cases for the angle. 05:30:04 ... This ends up being an area of confusion rather than a developer need. 05:30:43 ack tomayac 05:30:43 tomayac, you wanted to ask about more than one fold angle. 05:31:16 tomayac: So far this assumes that there is only one fold axis. What about future devices which fold out from both sides? 05:31:45 -> https://www.ubergizmo.com/2021/02/expanscape-aurora-7-laptop-seven-displays/ 05:32:04 ... In this example there are 7 displays. Maybe this could be handled by Multiscreen Window Placement. 05:32:18 Alexis: This is why we moved away from the exact fold agnel. 05:32:33 ... No matter the number of screens there is only a single posture. 05:32:34 s/agnel/angle 05:32:49 ... Multiscreen Window Placement can be used to understand the layout of the displays. 05:33:47 ... Another posture could be added if a new device introduced a truly unique posture. 05:33:56 q+ 05:34:14 reillyg: do you consider this type of laptop to be presented flat in from of the user? 05:34:31 alexis: correct, then you'd use Multi-Screen Window Placement API 05:35:20 anssik: This is an opportunity to coordinate with Multi-Screen Windows Placement API. 05:35:23 q? 05:36:07 Subtopic: TAG review status 05:36:30 q- 05:37:03 Alexis: TAG review drove simplification of posture types. 05:37:35 ... Review closed as satisfied. 05:38:03 ... TAG suggested looking out for multi-hinged devices, which are not yet a reality. 05:38:16 ... It's hard to know yet what they would look like and what you could do with them. 05:39:55 ACTION alexis to add a note for possible future work to support new form factors 05:40:16 ACTION: alexis to add a note for possible future work to support new form factors 05:40:44 q? 05:40:49 Subtopic: Semantic postures 05:42:10 RRSAgent, draft minutes 05:42:10 I have made the request to generate https://www.w3.org/2021/10/28-dap-minutes.html anssik 05:42:15 diekus: Can this API include devices which physically change their posture (e.g. the Surface Laptop Studio)? 05:42:36 ... but don't actually involve a screen fold. 05:43:15 s/ACTION alexis to add a note for possible future work to support new form factors// 05:43:17 RRSAgent, draft minutes 05:43:17 I have made the request to generate https://www.w3.org/2021/10/28-dap-minutes.html anssik 05:43:28 darktears has joined #dap 05:43:39 q+ 05:43:43 q? 05:43:48 diekus: Windows does change UI presentation based on these posture changes. 05:44:16 q+ 05:44:17 q? 05:44:27 ack darktears 05:45:03 Alexis: When you switch to stage mode is the only difference from "continuous" that you cannot access the keyboard? 05:45:16 -> https://github.com/w3c/device-posture/issues/94 Device Posture API to include "Semantic Postures"? #94 05:45:27 kenneth has joined #dap 05:45:31 ... I assume that Windows triggers tablet mode and the developer can detect that using CSS media query for pointer accuracy to create a touch-friendly interface. 05:45:36 present+ Kenneth_Christiansen 05:45:43 ... Today this can be detected. Is a new posture needed. 05:45:55 diekus: I wasn't aware that tablet mode was detectable. 05:46:12 Alexis: CSS pointer fine vs. coarse. 05:47:23 diekus: If this is detectable then there's no need to make this a posture unless there is enough of a pattern here that this would be easier for developers. 05:47:34 Alexis: Developers are already used to doing this. 05:47:54 ... We should try it with this device to make sure it works as expected. 05:48:04 diekus: I will go back to the Windows team with this. 05:48:08 https://patrickhlauke.github.io/touch/pointer-hover-any-pointer-any-hover/results/ 05:48:30 diekus has joined #dap 05:48:36 https://patrickhlauke.github.io/touch/pointer-hover-any-pointer-any-hover/results/ 05:49:27 q? 05:49:27 ack reillyg 05:49:29 ack reillyg 05:49:40 fbeaufort_ has joined #dap 05:50:13 reillyg: the same comment as alexis, I think this goes back to an earlier question, what the use cases were for detection each of these posture modes? 05:50:22 ... want to understand how folded over differentiates? 05:50:38 alexis: one use case is a game with two sides, for example 05:51:02 kenneth: multiplayer game 05:51:46 reillyg: in Studio device, in slate mode, is there a way to detect that stylus mode is active? 05:52:34 alexis: when the device is flat and using pen as the primary input, CSS properties will return pointer-coarse 05:53:00 reillyg: questions for diego: is there a developer need to differentiate between stage and studio modes? 05:53:34 ... is adaption the UI something the developers are looking for? 05:53:46 diekus: I'll go back to Edge team to ask 05:54:21 alexis: user interaction issue, you assume the pen is primary, but the computer does not know that unless the pen is close to the computer 05:54:29 ... e.g. could be out of battery 05:54:52 ... there's a problem with UX changing from touch to pen and back 05:55:07 reillyg: similar situation in stage mode, when keyboard is covered but trackpad isn't 05:55:19 q? 05:55:45 reillyg: need to go ask developers whether this is something they want to differentiate 05:56:41 RRSAgent, draft minutes 05:56:41 I have made the request to generate https://www.w3.org/2021/10/28-dap-minutes.html reillyg 05:56:56 Laura_M: I will add an issue so we can collect developer feedback on this. 05:57:12 https://www.youtube.com/watch?v=f9Bwc_Hqfcc 05:59:06 ACTION: diego to open a GH issue to collect developer feedback on whether they want to differentiate pen input from touch input 05:59:28 q? 06:00:11 Topic: Screen Wake Lock API 06:00:27 Subtopic: Wide review tracker 06:01:02 anssik: Marcos and Raphael have been doing good work here. 06:01:28 ... All reviews have been requested and resolved. 06:01:44 ... Next step is to take specification to CR. 06:02:33 rakuco: If further development happened would it be Screen Wake Lock V2? 06:02:57 anssik: Easier: we can refresh the CR and only do a review for the delta. 06:03:22 marcosc: We have lots of options but we won't be able to get out of CR anyways until we have another implementation. 06:03:33 ... We can have another CR when we have changes. 06:04:46 https://github.com/w3c/screen-wake-lock/issues/324 06:04:55 https://github.com/w3c/screen-wake-lock/pull/326 06:04:59 rakuco: Do we need to merge the outstanding pull request removing permissions checks. 06:05:08 marcosc: Yes, this one is important. 06:05:39 proposed RESOLUTION: Start the process to publish Screen Wake Lock API as a CR, check if the PR #326 triggers wide review for this delta 06:05:53 anssik: Would this change trigger another wide review? 06:05:58 marcosc: I don't think so. 06:06:48 q? 06:07:03 [no objections to publish CR] 06:07:20 anssik: We can do a limited review on this PR, probably only affects privacy. 06:09:23 ACTION: Add a note mentioning future screen brightness work to the specification. 06:10:11 RESOLUTION: Start the process to publish Screen Wake Lock API as a CR, check if the PR #326 triggers wide review for this delta 06:10:18 RRSAgent, draft minutes 06:10:18 I have made the request to generate https://www.w3.org/2021/10/28-dap-minutes.html anssik 06:11:05 Subtopic: Interaction with Page Lifecycle 06:11:12 -> https://github.com/w3c/screen-wake-lock/issues/139 06:11:44 reilly: original questions was how Screen Wake Lock API interacts with Page Life Cycle 06:12:14 ... since page lifecycle affects visibility, that's already exposed 06:12:39 q+ 06:12:41 ... issue was open after last meeting to add informative examples how we acquire locks 06:12:51 q- 06:12:54 ... then reopen with a different question on doc being fully active 06:13:12 ... marcosc correct me if doc can become fully active again? 06:13:17 marcosc: it can 06:13:38 ... page hide event etc. can become fully active again if not destroyed 06:14:06 reillyg: the question is how much language the spec needs to handle becoming fully active? 06:14:36 ... if the doc can in future become fully active then the event could fire 06:14:54 ... "wait until the doc becomes active and then fire", is this prose needed? 06:15:11 marcosc: maybe it'd fire automatically if hidden, need to look at the implementation 06:15:49 ... should the page fire events if it is frozen into background cache? 06:16:13 s/background/back-forward 06:17:03 ... if page visibility handles this, then I'd be hesitant adding prose for this 06:17:49 marcosc: prefer closing this issue with a comment along the lines of this discussion 06:18:15 ... I'll re-read the issue and have another look 06:18:47 reillyg: if you remove an iframe you lose visibility at the same time 06:19:15 ... implementations may not fire visibilitychange in all cases 06:20:55 anssik: marcos to research WakeLock and Page Life Cycle #139 issue and report back in a follow-up meeting 06:22:02 RRSAgent, draft minutes 06:22:02 I have made the request to generate https://www.w3.org/2021/10/28-dap-minutes.html anssik 06:30:10 Topic: Battery Status API 06:30:11 Scribe+ tomayac 06:32:43 reillyg: Reading summarizing Issue #29 06:32:56 s/Reading summarizing/Summarizing 06:33:16 anssik: Was it Brave that chose to always return a static value? 06:33:59 ... Are we in agreement that we want to make the recommendation stricter? 06:34:08 reillyg: We need to clean the text up. 06:34:20 anssik: No implementation uses a permission. 06:34:33 reillyg: There's a permission policy integration, but no prompt. 06:35:06 reillyg: An issue with the Geolocation API comes into mind. We are in a similar situation here. 06:35:16 -> https://datatracker.ietf.org/doc/html/rfc2119 Key words for use in RFCs to Indicate Requirement Levels 06:35:16 s/into mind/to mind 06:35:39 anssik: Do we have hooks for this? 06:36:08 Raphael: I don't think we do. 06:36:28 ACTION: Add normative text for private browsing mode behavior. 06:36:49 anssik: Are other APIs special-casing private browser mode? 06:37:04 ACTION: Remove reference to user permission as no implementation implements a permission prompt. 06:37:14 Raphael: Happens in implementation, but as far as I can tell not in specs 06:37:37 marcosc: Specs may have some "special mode" prose 06:38:09 reillyg: Idle Detection API has an example for this. We say that private browsing mode should be dealt with care when implementing this API. 06:38:29 ... If there is a prompt, it should be automatically denied after a timeout. 06:38:51 ... Battery Status should make all devices to appear plugged in and fully charged. 06:39:01 anssik: Presentation API did something similar. 06:39:15 marcosc: In the Tor browser, all activity can be considered private. 06:39:35 ... You don't need to differentiate this. 06:39:49 anssik: It should be SHOULD in RFC language then. 06:39:59 q+ 06:40:05 Raphael: I understood reillyg was suggesting something stronger. 06:40:29 reillyg: Having this as guidance might be good, since private browsing mode is defined differently per UA 06:40:32 ack marcosc 06:40:41 ... Browsers should be reminded to make it not easy to detect 06:40:51 RRSAgent, draft minutes 06:40:51 I have made the request to generate https://www.w3.org/2021/10/28-dap-minutes.html anssik 06:40:53 marcosc: It could be made an `if` statement in the steps 06:41:14 ... If you are in private mode, return a new instance of battery and return this. 06:41:23 anssik: Do we need to create such a condition? 06:41:35 marcosc: We have this in Payments. 06:41:48 marcosc: As long as the condition is understood it might work 06:42:01 anssik: I remember using this for Vibration API. 06:42:24 ... (Shows Note we have in Vibration API) 06:42:37 "Optionally, if the user agent wishes to disallow the call to show() to protect the user, then return a promise rejected with a "SecurityError" DOMException. For example, the user agent may limit the rate at which a page can call show(), as described in section § 14. Privacy and Security Considerations. 06:42:38 " 06:42:45 W3C TAG Observations on Private Browsing Modes -> https://w3ctag.github.io/private-browsing-modes/ 06:42:56 marcosc: Yes, we do that for Payment Request 06:43:17 -> https://w3c.github.io/vibration/#dfn-perform-vibration Vibrate "An implementation MAY return false and terminate these steps." 06:43:24 marcosc: It's a UA choice. There are reasons for this. 06:43:49 anssik: We acknowledge that this is important and that we converge to a solution 06:44:02 ... Raphael has recently picked up speed with this spec. 06:44:19 Raphael: One option is to patch the security section, or to make it normative. 06:44:32 marcosc: Might be worth making it normative. 06:44:47 Rahpael: Would be a matter of not changing the initial values. 06:45:09 anssik: It could stay static right after the instance is created. 06:45:32 Raphael: If the UA doesn't want to report status. 06:45:40 anssik: We thought about this before. 06:45:47 ... it's informative, though 06:46:02 ... Raphael, maybe you come up with a proposal and seek review. 06:46:06 Raphael: OK 06:46:21 anssik: There is general agreement that we want to do something about this. 06:46:38 ... Use issue #29 to submit feedback, and also from Samuel Weiler. 06:47:00 Raphael: Can anyone assign me the issue? 06:47:29 marcosc: Everyone in the WG should have write access to the repo. Checking. 06:47:43 anssik: marcosc will check permissions. 06:48:20 proposed RESOLUTION: Upgrade private browsing mode from MAY to SHOULD, integrate a hook into normative prose 06:48:58 RESOLUTION: Upgrade private browsing mode from MAY to SHOULD, integrate a hook into normative prose 06:49:22 anssik: Raphael should now be able to assign himself 06:49:25 Subtopic: Make privacy mitigations normative 06:50:36 anssik: Made the change to make section 3 (formally 4) no longer informative 06:50:57 q? 06:51:00 s/no longer informative/normative 06:51:45 anssik: We have worked on Generic Sensors, and have informative line items and matching line items 06:52:20 ... We had to do this at the request of the privacy review 06:52:29 marcosc: You can always push back 06:52:54 anssik: From an implementer's PoV it's redundant, but not for privacy folks 06:53:15 ... One option could be to allow for spec tooling to annotate this 06:53:28 marcosc: Potentially, but not sure if it could work. 06:53:43 ... The HTML spec has the fingerprinting icon 06:53:56 https://www.w3.org/TR/payment-request/#privacy 06:54:01 anssik: I just want to acknowledge their work 06:54:15 s/their work/the privacy reviewers' work 06:54:24 anssik: We should make their work easier 06:54:37 marcosc: They might get misguided 06:54:57 ... If the privacy and security section doesn't match the reality, that's bad 06:55:06 ... Finding the balance is hard. 06:55:17 anssik: TAG is asking for an explainer 06:55:27 kenneth: Not sure if they were writing explainers 06:55:56 anssik: I want to raise this discussion with Sam, who is a leader in privacy 06:56:08 ... Want to make our WG to be the most friendly to work with 06:56:34 q? 06:56:34 anssik: It's a very important topic to me personally 06:56:54 Subtopic: Depreciation of non-SecureContext access to the getBattery() 06:57:10 s/Depreciation/Deprecation/ 06:57:43 Raphael: Everything is in shape 06:58:33 tomayac: YouTube let us know that they "will get all the data [they] need from that even if [they] no longer see data from embeds". 06:58:37 q+ 06:58:50 ack marcosc 06:59:00 q+ marcosc 06:59:13 reillyg: The last comment was waiting for Tim, who is no longer working on Chrome 06:59:25 reilly: tim volodine no longer with Chrome project so don't block on his response 06:59:27 Raphael: Making slow progress 06:59:34 ack marcosc 06:59:41 https://hacks.mozilla.org/2020/07/securing-gamepad-api/ 06:59:53 marcosc: If it's not self-evident, we did something similar for the Gamepad API 06:59:58 tomayac: And Geolocation 07:01:13 Raphael: I will write an email to blink-dev and maybe write a blog post 07:02:48 tomayac: Offering to get a blog post out on this with Raphael on web.dev or developer.chrome.com 07:03:03 Topic: Network Information API 07:03:10 ... And heavily recommending to be vocal about this. 07:03:29 scribe+ marcosc 07:04:46 tomayac: rebooting network information API. 07:04:53 07:05:24 tomayac: people have been confused about effective connection... "this is about technology, not about speed?" 07:05:58 tomayac: looking at caniuse.com, it's mostly red... Firefox has an outdated network info API 07:06:05 wanming has joined #dap 07:06:31 tomayac: nevertheless, it's a popular API - it's used on 42% of pages in the dataset 07:06:57 tomayac: overlaps with "save data API" 07:07:00 RRSAgent, draft minutes 07:07:00 I have made the request to generate https://www.w3.org/2021/10/28-dap-minutes.html anssik 07:07:05 present+ Francois_Beaufort 07:07:26 present+ sudeep 07:08:13 tomayac: there are privacy issues, and Mozilla considers it harmful... Mozilla would prefer declarative solutions. Apple also has privacy concerns. The TAG says (see presentation) ... There is an acknowledged use case. 07:08:23 tomayac: so, maybe it's time for a reboot! 07:09:13 tomayac: looking at the open issues - we should look at fixing effective connection and "metered" 07:09:25 -> https://raw.githack.com/tomayac/netinfo/relaunch/index.html Proposal for Network Information API reboot 07:09:35 tomayac: metered is supported on windows, where the user sets it explicitly 07:10:02 tomayac: this issue of "metered" is a concern around the world 07:10:37 tomayac: so, I trimmed the spec down to a simple event target, with `metered` and `sustainedSpeed` 07:10:56 tomayac: plus an onchange event 07:11:08 q+ what's onchange map to? 07:12:02 tomayac: use case - not downloading non essential content, like background sync 07:13:19 tomayac: another use case is limiting bandwidth usage, like with the Web Torrent network... when Torrent sees you have a lot of bandwidth, it will use as much as possible. So, this allows some restrictions to be applied (or adapt to). 07:14:00 tomayac: client hint is also part of the proposal... can send a hint if the connection is the metered and send the sustained speed 07:14:27 tomayac: this allows the server to adapt the experience ... like metered and non-metered experience 07:15:10 tomayac: I have some collected resources... I have a doc that collects some feedback from developers and users 07:15:51 tomayac: 80+ of users would be ok with sharing metered with websites 07:16:38 tomayac: we also recorded the different things that people would consider a good tradeoff for metered and sustained speed 07:17:09 tomayac: things like not playing videos, not loading heavy data things, etc. 07:17:56 tomayac: this lead to interesting discussion around sustainability and the environment 07:18:17 tomayac: someone also said they might use it for ads targeting... 07:18:20 -> https://goo.gle/netinfo-reboot-motivation Rebooting the Network Information API, motivational doc 07:18:34 tomayac: I asked Mozilla about their position 07:18:40 q? 07:18:45 q+ 07:19:15 tomayac: I also reached out Apple 07:19:53 tomayac: but unfortunately, that didn't in a positive interaction 07:20:06 tomayac: asked Brave also, but didn't get any feedback yet 07:20:27 tomayac: I also looked at how implementable this is 07:20:38 tomayac: I also reached out to partners 07:20:54 q? 07:20:55 tomayac: they were interested 07:21:30 tomayac: here is a link to the presentation 07:21:31 Slides: goo.gle/netinfo-reboot-slides 07:21:31 Motivation: goo.gle/netinfo-reboot-motivation 07:21:31 Explainer: goo.gle/netinfo-reboot-explainer 07:21:31 Spec: goo.gle/netinfo-reboot-spec 07:21:35 ack marcosc 07:22:09 MC: what does onchange map to? 07:22:22 tomayac: it maps to both attributes... either changing 07:22:27 q+ 07:22:31 ack anssik 07:22:37 wanming has joined #dap 07:22:57 anssik: I heard that 40% of APIs are using the old API... is this new API backwards compatible? 07:24:29 q? 07:24:36 -> https://www.w3.org/2020/11/das-wg-charter.html#tentative DAS WG Tentative Deliverables: Network Information API 07:24:41 tomayac: yes, from what I've seen... a bunch of different big sites use it... youtube, tinder, facebook, etc. all use it. From my reverse engineering, what they do some analytics (so these changes may affect that). The content adaption that the current API provides would still be supported. 07:24:42 DAS WG Charter says "Note: the group will determine in collaboration with the WICG whether the existing implementations of this API on mobile warrant restarting the standardization process" 07:25:35 anssik: my question is, what is the temperature of WICG? are they interesting in continuing with this work? 07:26:22 -> https://github.com/WICG/netinfo/issues/91 WICG meta-issue for spec status discussion 07:26:29 tomayac: chats are happening across multiple working groups... could be web perf and us... or some privacy group that owns this. This is about reducing the finger printable area of the API. 07:26:57 anssik: this is great background info. And you shared it with browser vendors. 07:28:00 tomayac: yes, but it's not super positive... Mozilla says they can't really do sustained speed. And Apple are fairly against "metered" on privacy ground. 07:28:46 tomayac: I'd still like to reach out to Brave because they do have their own implementation (privacy preserving) 07:28:59 q? 07:29:12 tomayac: what has worked so far is going through WICG... 07:29:56 marcosc: I mentioned previously this API is "poisoned" due to its history perhaps in the eyes of some folks 07:31:06