Meeting minutes
<anssik> Anssi Kostiainen, Intel
Anssi_Kostiainen: WG Chair
<xfq> Fuqiao Xue, W3C
<hazel> Hazel Kuok, W3C Southeast Asia Chapter Evangelist
<kenchris> Kenneth Christiansen, Intel + TAG
Marcos Caceres, Invited Expert
<plh> PLH, W3C
<rakuco> Raphael Kubo da Costa, Intel
<larsgk> Lars Knudsen, Invited Expert
Eric Mwobobia, Safari Telecom
Alexis Menard, Intel
Leon Han, Intel
<plh> me https://www.w3.org/2020/10/22-dap-minutes.html is now visible
<kenchris> Peter Burrows, Fiserv
<JamesH> James Hollyer, Google Chrome
Lars Knudsen, Invited Expert
<Peter_Burrows> Peter Burrows, Fiserv
Mark Foltz, Google
Matt Reynolds, Google
Satotu Takagi, KDDI
Thomas Steiner, Google
<tomayac> Thomas Steiner, Google, Web/Chrome Developer Advocate working on Web capabilities (Project Fugu 🐡)
Takio Yamaoka, Yahoo Japan
<scheib> Vincent Scheib, Google Chrome, Software Engineer on Web Capabilities
Anssi_Kostiainen: good participation
Charter 2020
<xfq> Current charter: https://www.w3.org/2019/03/devices-sensors-wg-charter.html
<xfq> Proposed charter: https://www.w3.org/2020/05/proposed-das-wg-charter.html
Philippe_Le_Hégaret: Mozilla raised a Formal Objection to rechartering of the Working Group based on proposed deliverables.
<xfq> Mozilla's FO: https://lists.w3.org/Archives/Public/public-new-work/2020Jun/0012.html
Philippe_Le_Hégaret: Two reasons: 1) Security and privacy concerns. 2) Would prefer refactoring existing APIs over new Generic Sensors framework.
… W3C staff found the FO interesting and wants to explore a Director-free process.
Philippe_Le_Hégaret: We need to find a way to replace Tim Berners-Lee.
… Creating a council consisting of the Advisory Council and TAG to make decisions.
… Advisory Board has decided to take on the FO as an example to test the process for making a decision.
… Director will still make the decision but the AB will discuss as if they were making the decision.
… Director will make a decision no later than Nov 20th.
… Charter will be extended through Nov 20th.
… PH will be acting as team contact for this experiment. Co-chairs will be invited to present on the first call.
<tomayac> (Addendum) Mozilla's formal objection: https://lists.w3.org/Archives/Public/public-new-work/2020Jun/0012.html
Anssi_Kostiainen: What are the practical implications for the participants of the group?
Philippe_Le_Hégaret: There is currently no effect. Work can continue to happen. Adopting proposals from the WICG is currently blocked because the charter requires it.
Anssi_Kostiainen: Proposed new deliverable "Screen Fold API" cannot be published as a TR.
Philippe_Le_Hégaret: Correct, but we can discuss the proposal in the group.
Thomas_Steiner: What does "blocked" mean?
Philippe_Le_Hégaret: The charter is required to publish a TR. Discussing the proposal is allowed.
Anssi_Kostiainen: Can you talk about Process 2020?
Philippe_Le_Hégaret: As of today this group (and other groups) are working under Process 2020.
… This group is not (and won't be with the current proposed charter) under Patent Policy 2020.
… Patent Policy 2020 allow patent policy to cover working drafts and proposed recommendations.
… DASWG currently under Patent Policy 2017.
… Transition plan is to ask chairs about switching in November.
… In this group's case we will issue the new charter with the revised patent policy so that members only have to rejoin once.
<anssik> https://github.com/w3c/devicesensors-wg/issues/31
Agenda Bashing
Anssi_Kostiainen: First day discussing technical topics. Second day addressing privacy concerns.
… kenchris invited to discuss screen fold topic anticipated in new charter.
… marcosc invited to discuss network information and describe use cases etc. Proposal variations exist, with larger, smaller scope
… reillyg to discuss Wake Lock split to screen and system locks earlier this year.
… anssik noticed interesting application of sensors with orientation sensors being used in AirPods Pro
… Comments, suggestions regarding this agenda?
reillyg: Checking in with marcosc - prepared to discuss? marcosc: yes.
<anssik> https://www.w3.org/das/roadmap
Anssi_Kostiainen: Inviting participants to review https://www.w3.org/das/roadmap, suggest any other topics today.
reillyg: Battery use cases would be good to discuss, but we may not have an appropriate speaker for this.
<anssik> https://github.com/w3c/battery/issues/25
Anssi_Kostiainen: Re Battery, use cases are in old email archives, https://github.com/w3c/battery/issues/25 filed to recall adding them.
reillyg: We're aware we need to work on this - but not ready to discuss in this meeting.
Anssi_Kostiainen: Noting that motion sensors work is mostly done. At CR.
… Test automation a blocking factor.
<marcosc> Marcos_Caceres: the hard part is getting cross browser API for testing
Anssi_Kostiainen: Might need to discuss how to handle test automation. Perhaps web driver isn't the solution? WebXR and USB use a different API?
reillyg: Web Driver is an ideal way.
Philippe_Le_Hégaret: What are these other APIs?
reillyg: We can place testing on agenda.
reillyg: Had discussed in testing meeting, we're short on time today, can add for tomorrow.
Anssi_Kostiainen: Any other items, please send to anssik for inclusion tomorrow.
Anssi_Kostiainen: Moving on to Screen fold API
Screen Fold API
<plh> [this will get into the minutes]
Kenneth_Christiansen: Starting with use cases for screen fold.
… [presenting use case document with diagrams of devices with many different folding configurations]
<reillyg> Fold Angle Explainer
Kenneth_Christiansen: Some screens right next to each other considered one virtual screen.
… Consideration: Should screens not so close together still be joinable?
… What about hinges between screens and keyboards as well.
… [skimming quickly through spec draft]
Kenneth_Christiansen: May need to standardize angles of fold
… Goal would be consistent behavior between different devices types.
… One solution is JavaScript, events on angle changes
… Others are CSS solutions... timelines... exposing the angle value. However downsides are that some computations are not possible (e.g. angle to position).
<anssik> acl marcosc
Marcos_Caceres: Has this been taken to CSS WG?
Kenneth_Christiansen: Individually explored, and taken to some CSS experts.
<anssik> Discussed with Alan Stearns, CSS WG co-chair
Anssi_Kostiainen: Did confer with CSS co-chair Alan Stearns, Adobe
Kenneth_Christiansen: Would still desire JavaScript for some applications, such as 'children's book'.
reillyg: Can a CSS value be pulled out of CSS to JS?
Thomas_Steiner: Media query ... this might be possible?
… just in theory at least
… Why was this raised for CSS in general?
Kenneth_Christiansen: [discussing some calculation challenges, e.g. degree conversion to other unit types]
<xfq> See also: https://drafts.csswg.org/css-values-4/#example-1daf921b
Thomas_Steiner: Houdini seemed to have related solutions, may be able to bring something from there.
JH: Why is CSS desired?
Kenneth_Christiansen: For basic layout / animations, want to avoid JavaScript
reillyg: [similar statement]
Marcos_Caceres: Performance, smoother animations
<tomayac> Here it is: https://drafts.css-houdini.org/css-properties-values-api/
Thomas_Steiner: See https://drafts.css-houdini.org/css-properties-values-api/
Marcos_Caceres: Are postures bound to angles? Can variables be used, e.g. 'this is a laptop'
<tomayac> This would of course require to register something like "degree" in https://drafts.csswg.org/css-values-3/
Marcos_Caceres: Can we avoid pre-sets, which might limit devices used?
Kenneth_Christiansen: There has been feedback requesting standardization
Kenneth_Christiansen: Intel working with partners has heard this desire that multiple devices function similarly
<tomayac> For the record, I love this API, I'm purely curious to hear why folks said it couldn't be done in CSS
AM: for each posture desire OS actions to also be consistant
Marcos_Caceres: Concern of exposing both angle and mapping, because developers may use the wrong one.
AM: One solution is to start with posture, and see if it is sufficient and wait for requests to read the angle
reillyg: Will need to react to changes in the ecosystem, and new hardware. Need to be selective for what is standardized.
Thomas_Steiner: Fingerprinting concern with fine grained angle
Kenneth_Christiansen: Without fine grained the animations will be poor. A mitigation may be to only report when changing.
reillyg: Each time a laptop is opened it will be to a different amount
<tomayac> ... but during a session, the screen probably stays static for longer periods
reillyg: Do we have more use cases for fine grained angles?
Philippe_Le_Hégaret: To access API are permissions needed?
Kenneth_Christiansen: Integration with screen placement may affect permissions
Anssi_Kostiainen: Can we generate synthetic (fake) values for legacy devices?
Philippe_Le_Hégaret: Fingerprinting concern if not behind a permission.
reillyg: How does this differ vs screen / window resolution?
Philippe_Le_Hégaret: This will add to the problem
Marcos_Caceres: Resolution is used as a vector
Anssi_Kostiainen: The specification should describe the concern and address it
MC also noting angle may be constantly changing
<plh> Mitigating Browser Fingerprinting in Web Specifications
reillyg: Concern that permissions can solve the fingerprinting concern. Can browsers describe the risk sufficiently?
Philippe_Le_Hégaret: Discuss with the Privacy IG sooner than later
Anssi_Kostiainen: Should address in spec and address anticipated questions and then request review.
Kenneth_Christiansen: Discussions in github issues appreciated.
Marcos_Caceres: I'll send stuff to github
Network Info
<tomayac> Spec: https://w3c.github.io/screen-fold/ Repo: https://github.com/w3c/screen-fold/issues
<mfoltzgoogle> * It's past my curfew, so I will say good night. Thank you chairs for allowing me to observe the meeting.
<xfq> https://wicg.github.io/netinfo/
Anssi_Kostiainen: A long history in this WG, was previously discussed.
Anssi_Kostiainen: Inviting Marcos to discuss
https://wicg.github.io/netinfo/
Marcos_Caceres: Original use cases:
Marcos_Caceres: What type of connection is being used?
… Raised many concerns of exposing too much information
… Picture element came along, which allows responsiveness to environment. Also media queries, lazy loading, etc.
… Needs of the API were reduced.
… Notably: Did not address if the connection is "Metered" or not.
… Does the connection cost money.
… Metered or not could be a signal.
<tomayac> We have Save-Data (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data) and prefers-reduced-data now (https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-data)
<xfq> https://github.com/WICG/netinfo/issues/84
Anssi_Kostiainen: Does metered mean there's a data limit? Or a charge?
Marcos_Caceres: Up to the user + user agent.
reillyg: Some OSes may make assumptions, or get a signal from a carrier.
Thomas_Steiner: On windows, when tethered to a phone, poor results can happen, but there are heuristics to detect connection type.
Marcos_Caceres: iOS option briefly shown
<tomayac> Windows link: https://support.microsoft.com/en-us/windows/metered-connections-in-windows-10-7b33928f-a144-b265-97b6-f2e95a87c408
<tomayac> Low data mode on iOS: https://support.apple.com/en-ca/HT210596#:~:text=Wi%2DFi%3A-,Open%20the%20Settings%20app.,Turn%20on%20Low%20Data%20Mode.
Marcos_Caceres: Confusion around heuristics working well enough, and what some OS signals even mean.
Marcos_Caceres: Connection Type
Marcos_Caceres: What type of bandwidth may be available, may influence what is downloaded
Marcos_Caceres: Concerns around connection type being poorly identified, e.g. due to transient conditions.
Anssi_Kostiainen: Where has this API shipped?
<tomayac> https://caniuse.com/mdn-api_networkinformation
Anssi_Kostiainen: Data from real-world use cases?
JH: Seeing Chrome is behind a flag
Thomas_Steiner: notes https://caniuse.com/mdn-api_networkinformation
reillyg: [details missed]
Thomas_Steiner: Differential Serving == adjusting what applications do based on connection type / quality.
Thomas_Steiner: We have Save-Data (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data) and prefers-reduced-data now (https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-data)
Thomas_Steiner: concern isn't about use cases, but concern is that information is too fine grained.
<anssik> Repeating what TS said earlier, we have Save-Data (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data) and prefers-reduced-data now (https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-data)
Thomas_Steiner: precision now is more than needed for adaptive loading
<marcosc> https://www.w3.org/TR/netinfo-usecases/
Marcos_Caceres: Problem is that API is overzealous
Anssi_Kostiainen: Is earlier editor Ilya Grigorik still working on this?
<tomayac> https://addyosmani.com/blog/adaptive-loading/
Thomas_Steiner: Correcting use cases term that are known employed: adaptive loading https://addyosmani.com/blog/adaptive-loading/
Vincent_Scheib: what use cases remain that we want to solve... seems like we want this adaptive loading use case solved
Thomas_Steiner: One problem remaining is a site changing behavior even though the user prefers another. E.g. a user who would want to wait and see a higher resolution image.
reillyg: Yes, issue is "what is the signal"
reillyg: A) the carrier indicating connection type, or B) User indicating what type of bandwith usage they want
<tomayac> Chrome Lite mode reillyg was referring to: https://support.google.com/chrome/answer/2392284?co=GENIE.Platform%3DAndroid&hl=en
reillyg: Related: browser 'data saving' features that can be toggled by users.
Thomas_Steiner: Chrome Lite mode reillyg was referring to: https://support.google.com/chrome/answer/2392284?co=GENIE.Platform%3DAndroid&hl=en
JH: The site will need to implement functionality
<tomayac> On extremely slow connections Chrome would proxy pages through Google Web Light: https://support.google.com/webmasters/answer/6211428?hl=en
Marcos_Caceres: Hard part is network signal in an interoperable manner.
Marcos_Caceres: Also: are client hint and CSS media-query sufficient for use case?
reillyg: Interop is challanging. But "is metered" and "user wants to save data" should be achievable
<tomayac> Nit: it's not a client hint (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH), but just a header
<tomayac> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data
<marcosc> /me thanks for clarifying tomayac
Thomas_Steiner: (Nit: it's not a client hint (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH), but just a header
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data)
Anssi_Kostiainen: Reviving user override desired
reillyg: Yes, apps need to implement the app behavior ... so a poorly behaving app may be corrected by the browser sending a different signal
Anssi_Kostiainen: Need a refresh of specification for 2020 context.
Thomas_Steiner: Will check in with editor Ilya Grigorik to see status
reillyg: Seems we're discussing around a minimal sub-set that is already in the platform. Could drop the spec
reillyg: Research warranted to understand what sites are using this functionality, can e.g. Chrome deprecate them?
reillyg: If not, at least document status quo and try to get interop
Thomas_Steiner: Is it fingerprinting use, or legitimate use?
<tomayac> +1
Resolution: Revise Network Info use cases for 2020 drawing from real-world usage experience e.g. for adaptive loading pattern, review what API knobs are required given the new properties HTTP Save-Data header and prefers-reduced-data CSS media feature are made available
System Wake Lock
reillyg: Where we left the discussion as of last TPAC: we split the spec into screen and rest. Screen has shipped in Chrome, with "worth prototyping" from Mozilla.
… Last TPAC I (@reillyg) had some ideas around system, but didn't want to distract from screen.
reillyg: The observation was that there is work that sites are doing
… that the site wants to tell the user they are doing
… It's separate from background geolocation and geofencing
… They are fascinating, but a different discussion
… Examples of sites doing work would be Figma and Squoosh doing data processing
… Work, which, if canceled, would be lost
… Another example would be an IDE compiling code
<anssik> System Wake Lock use cases meta issue
reillyg: While also allowing the user to know that an operation is in process
… On OS like Android, there is the concept of foreground operation
… Like downloading updates or processing photos
reillyg: The proposal I hinted at last TPAC was an integration between screen wake lock and the notifications API
… Along with some UI elements (indicators)
… UAs can implement some heuristics when to show this indication
… Developers would take these locks eagerly, and the UA could then decide whether or not to show the indicator
… This is a signal the site could provide to the UA
… Similar to what we have today with onunload handlers, I know that's frowned upon
… Used to say I have unsaved changes
Anssi_Kostiainen: What you describe at the user experience is alongside notification
… Would this be dismissible UI by the user?
… In your idea, if the user wishes, could the user break the lock?
reillyg: Yes, this would be interruptible
… There is a second level to this. Background tab throttleing
<marcosc> https://github.com/WICG/page-lifecycle
reillyg: Users have a lot of tabs open, and UAs try to throttle. But heuristics are hard. Is it just a carousel sliding, or something actually important?
… You can balance that against the system policy
Anssi_Kostiainen: Am I right in assuming the API shape would be different from screen wake lock?
reillyg: We're not there yet. Not concerned about that yet.
… More interested in use cases that need to be ack'ed
… When you play a video, you get a screen wake lock for free. Maybe we should be stopping this.
… Like when videos are used to replaced animated GIFs
… Browsers will take a system wake lock when downloads run
… There are cases where the browser can't decide alone and needs help
<Zakim> marcosc, you wanted to say my concern is separating the lock from the processing
Marcos_Caceres: My concern would be separating wake lock and actually doing the work
… Maybe we should have a dedicated worker
reillyg: I don't understand the difference. If it is main thread work or a worker.
Marcos_Caceres: You would not be doing work on the main thread, it would enforce a best practice of working on workers
… and not the main thread
reillyg: This makes sense. Sites can work around this. Sites could spawn a fake worker and still do work on the main thread
Marcos_Caceres: If you do work on the main thread you get the "this site is blocked" UI
reillyg: Not talking about blocking like with loops, but just regular work
<Zakim> anssik, you wanted to ask about abuse mitigations
Anssi_Kostiainen: How do we prevent every site declaring they are doing important work?
reillyg: Not concerned about this. Sites already today compete for resources.
… There's a visibility tied up with that
… The user agent can make the intention visible to the user
Anssi_Kostiainen: SGTM
JH: This also doesn't hog resources. The system would just go to sleep.
… When some timer has gone up, a popup could appear. Saying "this tab is preventing the system from sleeping"
… I would not watch a compiler do its work
… I hope the indication would be in the tab
reillyg: User agents could adjust the way this gets displayed
… Including not showing it at all
… For example, if a site is in the foreground, the timer could be longer
… But if you're in the background, the timer could be shorter
… You could then see some popup that tells you about ongoing work
… The UA is given more ability to decide how to show the UI
<Zakim> anssik, you wanted to react to "queue
Anssi_Kostiainen: Is there use for allowing web pages to explain the reason?
… Like "I'm doing video encoding"
reillyg: My strawman is that it's a type of notification that includes progress
… You would have to upgrade that progress periodically
Anssi_Kostiainen: I like that
Thomas_Steiner: We have iOS' camera usage indication, but there's nothing like this on desktop
reillyg: We have tabs red dot for recording
… Also screen sharing
<anssik> ack +
<Zakim> tomayac, you wanted to react to tomayac
Thomas_Steiner: Clarifying that I was talking about OS level indication
… Not browser-level
reillyg: Windows has the concept of in-taskbar icon progress
Marcos_Caceres: macOS shows geolocation in the title bar
Marcos_Caceres: Tying it to "progress" sounds good
reillyg: We also need an indetermined mode
… For things that don't know how long something will take
Anssi_Kostiainen: It would be like a heartbeat
… If there's no heart beat you could ask for aliveness
Marcos_Caceres: If you see the worker is working based on CPU, you know it's busy
reillyg: The heartbeats are important to know if progress is being made at all
… Does the code think it's making progress
Marcos_Caceres: For example when I'm walking I would turn off the screen, but might still be interested in progress
reillyg: On mobile, it's different. You're more likely to put it away instead.
… The notification could still be useful
… Like in the aftermath. You could discover abusive behavior
… On the other hand, it could feed into systems like battery consmption
… So you could see which sites have taken a lot of system locks
Marcos_Caceres: It could be managed by the OS or the UA
LK: One example from enterprise would be where there is no progress for days, but the need to wake up the screen when something important happens
reillyg: This would be more like a kiosk mode
… This is a policy the admin sets
… There is a proposal for Microsoft to set install-time permissions
… Like a site is run in kiosk mode. The site would declare this in its meta data
… Tied in with monitoring: one of the use cases for this:
… you have WebUSB where you might be flashing a device
… You need to download the data, then flash
… The hint is important to make the UA understand
Anssi_Kostiainen: I feel like there is need to do more work
… We have collected use cases
… and excluded background geolocation
… which helps frame the scope
reillyg: Understanding the scope helps. I would like to hear from @marcosc how he sees Mozilla perceive this?
Marcos_Caceres: There is definitely a clear case for this
… They need to be outlined a little bit more clearly, and then we need to think about the API shape
… I don't think anything is blocking here
Anssi_Kostiainen: Maybe we need an Explainer
reillyg: Yes. Something with the goals and non-goals defined. And the rough API shape.
Marcos_Caceres: Some discussion of the pros and cons of the worker route
JH: Do you think worker is more feasible?
Marcos_Caceres: Depends on how much work the browser needs to do. It's also less of a footgun
… There are lots of things to consider there
Anssi_Kostiainen: We need to agree on what the Explainer should contain
… there is this template
… Please provide key concerns and questions
<xfq> Template: https://w3ctag.github.io/explainers
<marcosc> clear use case + real world examples from native apps or things that web apps are doing today
reillyg: Not sure we need to go into that much detail. The template is probably good enough
<anssik> proposed RESOLUTION: Write System Wake Lock explainer and draft an API shape
<reillyg> /me +1
<marcosc> +1
Resolution: Write System Wake Lock explainer and draft an API shape
<xfq> +1
+1
reillyg: This is on my/Fugu's plate. People asking for this are coming to me (@reillyg)
… Wanted to get a signal from folks in thew WG if this is valid
… And it seems the answer is yes
Marcos_Caceres: Especially since screen wake lock has gone well. Offloading this cognitive load is helping us.
Anssi_Kostiainen: Reilly, do you want to own this action?
reillyg: Sure
Action: Reilly to kick off the System Wake Lock explainer work
Anssi_Kostiainen: Thanks for today. We'll be back tomorrow
Giving outlook on the agenda
<anssik> https://github.com/w3c/devicesensors-wg/issues/31