IRC log of dap on 2021-10-28

Timestamps are in UTC.

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