05:00:55 RRSAgent has joined #dap 05:00:55 logging to https://www.w3.org/2021/04/07-dap-irc 05:00:57 RRSAgent, make logs Public 05:00:58 please title this meeting ("meeting: ..."), anssik 05:01:05 Meeting: Devices and Sensors WG - 2021 Q2 virtual meeting - Privacy and architecture 05:01:10 Chair: Anssi, Reilly 05:02:47 Agenda: https://www.w3.org/events/meetings/947245c6-b7eb-4b38-9a34-358d19f97c9d 05:03:01 RRSAgent, draft minutes v2 05:03:01 I have made the request to generate https://www.w3.org/2021/04/07-dap-minutes.html anssik 05:04:05 Present+ Anssi_Kostiainen 05:04:12 Present+ Arnaud_Mandy 05:04:19 present+ Fuqiao_Xue 05:04:21 Present+ Vincent Scheib 05:04:29 Present+ Kenneth_Christiansen 05:04:39 Present+ Reilly_Grant 05:04:49 kenchris has joined #dap 05:04:53 Present+ Vincent_Scheib 05:05:02 present+ Raphael_Kubo_da_Costa 05:05:04 Present+ Kenneth_Christiansen 05:05:11 marcosc has joined #dap 05:05:14 Present+ Marcos_Caceres 05:05:17 arno_ has joined #dap 05:05:30 Present+ Raphael_Kuco_da_Costa 05:05:44 Present+ Thomas_Steiner 05:05:49 Scribe: Marcosc 05:05:59 Scribenick: Marcosc 05:06:04 Present+ Fuqiao_Xue 05:06:32 s/Present+ Raphael_Kubo_da_Costa// 05:06:34 RRSAgent, draft minutes v2 05:06:34 I have made the request to generate https://www.w3.org/2021/04/07-dap-minutes.html marcosc 05:06:42 s/Present+ Raphael_Kuco_da_Costa// 05:06:49 RRSAgent, draft minutes v2 05:06:49 I have made the request to generate https://www.w3.org/2021/04/07-dap-minutes.html anssik 05:07:12 Present- Raphael_Kuco_da_Costa 05:07:16 RRSAgent, draft minutes v2 05:07:16 I have made the request to generate https://www.w3.org/2021/04/07-dap-minutes.html anssik 05:07:35 Present+ Lars_Knudsen 05:07:48 Present- Vincent Scheib 05:09:09 RRSAgent, draft minutes 05:09:09 I have made the request to generate https://www.w3.org/2021/04/07-dap-minutes.html xfq_ 05:09:15 TOPIC: AB TAG Recommendations 05:09:43 RRSAgent, draft minutes v2 05:09:43 I have made the request to generate https://www.w3.org/2021/04/07-dap-minutes.html anssik 05:11:33 -> https://github.com/w3c/dap-charter/issues/103#issuecomment-744446928 05:12:31 -> https://github.com/w3c/dap-charter/issues/103#issuecomment-744446928 Report of AB/TAG experiment 05:12:34 reillyg: following TPAC, the AB+TAG did an experiment to figure out a way to move forward from Mozilla's objection to the Charter. In recognition of the W3C operating without a Director, the AB+TAG acted a council and held a meeting with the Chairs and Mozilla and minutes were published. Link above. 05:13:05 reillyg: I wanted to go through the recommendations and make resolutions as a group. 05:13:37 reillyg: there is a long list of tasks that we could pursue. Let's triage them in this meeting. 05:14:23 ...reillyg presents the recommendations.... 05:15:41 reillyg: the first recommendation, they recommended publishing a bunch of specs as a working draft. 05:16:22 reillyg: I know we are publishing the Geolocation, so wondering if we need to get wide review? 05:16:51 xfq_: we don't need to get wide review for FPWD. 05:17:00 q+ 05:17:38 reillyg: I was confused about the review processes for Geolocation 05:18:04 marcosc: that was because we ere going to REC again... but now FPWD doesn't require it. 05:18:38 q? 05:18:45 ack anssik 05:19:26 reillyg: if it's indeed not a heavy process to republish drafts, then we should publish those those documents. Then we can publish all as working drafts, and then seek review one or two at a time. 05:19:48 proposed RESOLUTION: Republish WDs of Battery Status API, Proximity Sensor, Ambient Light Sensor, System Wake Lock, Geolocation Sensor, Orientation Sensor 05:19:52 reillyg: then we can do some of the spec modernization. 05:20:47 anssik: we need to decide the what level of work we want to do on them... and if we want to triage issues on those specs. 05:21:24 reillyg: we need to decide if these are truly living documents. Or can we leverage the w3c publication process ? 05:21:25 q+ 05:21:53 anssik: if we have a resolution, we can just automate the publication process. 05:22:11 q- 05:22:28 q? 05:23:01 marcosc: that sounds great 05:23:18 proposed RESOLUTION: Republish WDs of Battery Status API, Proximity Sensor, Ambient Light Sensor, System Wake Lock, Geolocation Sensor, Orientation Sensor with a note warning readers that these specifications are being reviewed with reference to the AB/TAG decision and set up automatic re-publishing. 05:23:19 reillyg: that sounds like the minimal things to get us started 05:23:35 +1 05:23:43 proposed RESOLUTION: Republish WDs of Battery Status API, Proximity Sensor, Ambient Light Sensor, System Wake Lock, Geolocation Sensor, Orientation Sensor with a note warning readers that these specifications are being reviewed with reference to the AB/TAG decision 05:24:23 proposed RESOLUTION: Republish WDs of Battery Status API, Proximity Sensor, Ambient Light Sensor, System Wake Lock, Geolocation Sensor, Orientation Sensor with a note warning readers that these specifications are being reviewed with reference to the AB/TAG decision and set up automatic re-publishing. 05:24:48 reillyg: what we want to communicate is that we plan to continue working on these specs actively 05:25:11 RESOLUTION: Republish WDs of Battery Status API, Proximity Sensor, Ambient Light Sensor, System Wake Lock, Geolocation Sensor, Orientation Sensor with a note warning readers that these specifications are being reviewed with reference to the AB/TAG decision and set up automatic re-publishing. 05:25:13 reillyg: we can discuss in the next resolution what are out next steps 05:25:36 s/out next steps/our next steps 05:25:56 RRSAgent, draft minutes v2 05:25:56 I have made the request to generate https://www.w3.org/2021/04/07-dap-minutes.html anssik 05:27:28 reillyg: ok, so then, this makes the rest of what I have in my notes easier... looking at the specs that were highlighted in the recommendation I idetified two categories. Battery and orientation, and Ambient and system lock are implemented. The proximity and Geolocation sensor have not been implemented at all. I propose we prioritize the ones that are implemented, and review the orientation sensor API... and the we move to the other APIs a 05:27:28 s we get to them. 05:27:41 reillyg: We then limit to around two specs at once 05:28:08 anssik: yeah, we should limit what we work on, so not to flood reviewers. 05:29:00 anssik: there is evidence that there in interest in doing some retrofitting work, as shown by implementer interest in the Geo spec 05:29:38 q+ 05:31:47 reillyg: the battery API needs a fair bit of love. It would be good to bring Geolocation API and Geolocation Sensor together spec to the TAG. The argument in favor of Geolocation Sensor is that the design of the API has limitations as it relates to extensibility. So it would be good to bring to the TAG if it worth pursuing the Geo Sensor or if we can figure out a way to extend the olde Geolocation API 05:32:04 kenchris: is there an explainer that covers this? 05:32:13 reillyg: I'm not sure there is. 05:33:04 anssik: the value of the Geosensor is the teasing out of use cases, which tomayac did a great job in teasing out and capturing into the API 05:33:15 s/API/Geo Sensor API 05:33:36 anssik: the aim here is to make sure developers get their use cases covered. 05:33:47 anssik: by some API 05:36:51 q+ to note there's a one-off read() https://w3c.github.io/geolocation-sensor/#geolocationsensor-read that is similar to getCurrentPosition() https://w3c.github.io/geolocation-api/#getcurrentposition-method 05:36:52 tomayac: I see that we've had a review of Generic sensor. But we never had a review of Geosensor. There are some things the legacy API does easier, like watching a position. For background geo, it's not covered by the old API. Geofencing, we discussed notification triggers. For geo tracking use cases, we could have a system wake lock that would keep the geosensor alive. 05:36:58 ack tomayac 05:37:36 ack anssik 05:37:36 anssik, you wanted to note there's a one-off read() https://w3c.github.io/geolocation-sensor/#geolocationsensor-read that is similar to getCurrentPosition() 05:37:39 ... https://w3c.github.io/geolocation-api/#getcurrentposition-method 05:37:52 tomayac: if we could do the use cases in the old api, we might not need the new API... specially as we are facing some resistance to the generic sensor API. 05:39:16 anssik: we need to address the use cases, with hopefully a better API surface that can provide better privacy assurances. We don't need to make any decisions today. Yesterday we discussed privacy issues with our friends at Brave. We should make time to discuss that further. 05:39:27 The privacy concerns around the _current_ API seem to be mostly around permission (persistence) and not so much about the actual sharing and tracking (in the foreground) of one's location. 05:39:36 reillyg: to bring this back to a proposed resolution... 05:40:59 q+ 05:41:57 reillyg: there a few places where the battery API doesn't match implementation. We need to investigate privacy improvements. rakuco was having a look at some of the privacy issues. 05:42:05 anssik: that work has already been done 05:42:32 https://w3c.github.io/battery/#security-and-privacy-considerations 05:42:43 anssik: I need to check how quantization is done... and if we need to fix up the use of the RFC2119 keywords 05:43:26 q+ to propose we pursue more modern security and privacy reviews for all these documents and based on that feedback modernize the API 05:43:31 tomayac: should we clarify what modernizing means... does it means showing a prompt in places? making the api async... adding SecureContext, which could break sites potentially 05:44:03 reillyg: what I mean is making editorial changes to algorithms to better match implementations 05:44:44 ack anssik 05:44:44 anssik, you wanted to propose we pursue more modern security and privacy reviews for all these documents and based on that feedback modernize the API 05:44:52 reillyg: we could look at if there would be "breaking changes" to the specification - but generally we want to take the specs to a better place 05:45:52 anssik: supporting what reillyg said. Plus we need to go and talk to the PING folks and see what their suggestions are. And if they want to us to change things to MUST etc. 05:46:16 tomayac: there is stuff that is obvious, like adding SecureContext, etc. 05:46:41 reillyg: we should do a cleanup round on our own. And then send this to PING. 05:46:49 q- 05:47:25 anssik: I agree that we should update the specs before showing them to PING... or maybe they can review pull requests. 05:48:01 anssik: I know we have privacy experts in this group, but it's good to have interactions with the PING folks as they provide a lot of good feedback. 05:50:14 reillyg: I'd like to timebox discussions of specifics at this point. 05:51:15 reillyg: we know that "doing the right thing", specifically around bot detection + fingerprinting, we might need to break some sites - but there are good alternatives in the platform. 05:52:20 RESOLUTION: Apply editorial modernizations to the Battery Status API, perform a round of self-review and revisions on the Security and Privacy aspects of the API before requesting horizontal review from the PING. 05:53:14 marcosc: do we have an editor 05:53:29 reillyg: we voluntold rakuco to do it (heheh) 05:54:34 scribeNick tomayac 05:54:35 scribeNick: tomayac 05:55:04 marcosc We can go to a First Public Working Draft and then straight to CR 05:55:22 marcosc Since everything is implemented universally, we can go to REC next 05:55:55 reillyg Sounds great. Question to the group: do we want to get the Geolocation API back to a living standard mode? 05:56:11 reillyg Should Geolocation Sensor be included? Or abandoned? 05:56:13 q+ 05:56:31 ack marcosc 05:56:55 marcosc Ideally I'd like to sit down with tomayac and other interested folks and make a determination from there. 05:57:06 marcosc Need to work out what's missing 05:57:13 q+ 05:57:17 ack anssik 05:57:30 q+ 05:57:33 anssik That background work that marcosc is offering is very much in need 05:58:01 anssik What use cases are really top priority for web developers? Once we understand that, which of those can be retrofitted? 05:58:17 anssik And what is the implementors' feedback on these new use cases? 05:58:33 anssik Knowing all this, we can then invest our effort accordingly. 05:58:48 anssik Is this your priority, marcosc? 05:58:52 marcosc Correct 05:58:54 ack larsgk 05:59:32 larsgk When you mentioned Geolocation Sensor being abandoned, we talked about sensors to step back on granularity 06:00:12 larsgk This makes it easier for developers to understand the budget they may be overstepping. The more APIs are involved, the harder it is to figure that budget out for developers. 06:00:40 reillyg Do we feel the new privacy mitigation can be applied to the legacy API, or do we need a new API for that? 06:01:07 reillyg Not proposing to make a decision now. Proposing to make a decision as part of moving the Geolocation API to be a Living Standard. 06:01:21 q+ 06:01:22 reillyg Some of the discussion motivates a new API. 06:01:25 ack anssik 06:01:50 anssik Want to make a final point that the most vocal developers have been not the most constructive. 06:02:06 anssik Some developers think it's the world's most popular feature. 06:02:23 anssikMaybe we need to get marcosc legitimate data. 06:02:36 reillyg That's the area where the new design has promise. 06:03:00 q+ 06:03:12 reillyg Because the new API has this document event structure it doesn't make certain use cases easy like geofencing 06:03:34 reillyg Acknowledging that it may not be easy to drum up implementor interest to implement. 06:03:47 ack marcosc 06:04:19 marcosc To speak in general, there needs to be the general problem that needs solving of doing things in the background, not just geolocation, but others. 06:04:45 marcosc Some discussion happened in the service worker repo, but service worker is not the place according to Jake Archibald 06:04:59 marcosc As a larger community we need to figure this out. 06:05:19 marcosc That way there will be less resistence 06:05:45 reillyg This unfortunately hasn't answered my questions. Do we want to consider this as part of Geolocation REC track, or after? 06:06:09 marcosc Let's do it after (in parallel) 06:06:24 tomayac +1, let's tackle these questions independently 06:06:30 anssik We can do both indeed 06:06:43 anssikLet's not block on experimentation 06:06:57 s/anssikLet's/anssik Let's 06:07:09 marcosc Please ask for help, marcosc. 06:07:25 proposed RESOLUTION: Investigate the future of the Geolocation Sensor API in parallel with bringing the Geolocation API to REC track. 06:07:45 s/marcosc Please ask for help/anssik Please ask for help 06:07:53 proposed RESOLUTION: Investigate the new use cases of the Geolocation Sensor API in parallel with bringing the Geolocation API to REC track. 06:08:48 marcosc Before we break, do we make a resolution to publish as FPWD? 06:08:53 proposed RESOLUTION: Investigate the retrofitting of the new use cases enabled by the Geolocation Sensor API to the Geolocation API in parallel to bringing the Geolocation API to REC track. 06:09:07 reillyg Because you were working on it, marcosc, I took it as a given 06:09:40 marcosc This would be edition 3, or we drop the editions entirely, since we're moving it to living 06:10:06 proposed RESOLUTION: Investigate retrofitting of the new use cases enabled by the Geolocation Sensor API to the Geolocation API in parallel to bringing the Geolocation API to REC track. 06:10:11 proposed RESOLUTION: Investigate the retrofitting of the new use cases enabled by the Geolocation Sensor API to the Geolocation API in parallel to bringing the Geolocation API to REC track. 06:10:23 proposed RESOLUTION: Investigate retrofitting the new use cases enabled by the Geolocation Sensor API to the Geolocation API in parallel to bringing the Geolocation API to REC track. 06:10:48 proposed RESOLUTION: Investigate retrofitting the new use cases enabled by the Geolocation Sensor API to the Geolocation API 06:10:49 tomayac Can we split it in two resolutions? 06:11:08 reillyg The thing we want to note is that we're doing both things in parallel 06:11:15 proposed RESOLUTION: Publish a FPWD of the Geolocation API 06:11:22 anssik By definition they are not blocking 06:11:29 RESOLUTION: Investigate retrofitting the new use cases enabled by the Geolocation Sensor API to the Geolocation API 06:11:33 reillyg Looks good 06:11:42 RESOLUTION: Publish a FPWD of the Geolocation API 06:11:45 RRSAgent, draft minutes v2 06:11:45 I have made the request to generate https://www.w3.org/2021/04/07-dap-minutes.html anssik 06:14:42 [Break ☕️] 06:21:48 scribeNick: anssik 06:22:00 scribeNick: tomayac 06:22:59 reillyg We said what we do for Battery Status and Geolocation. That's two high prio specs cleared. The third is Orientation Sensor. 06:23:16 q+ 06:23:30 reillyg I think we should do a review of Orientation Sensor. Do we just want to do this for Orientation Sensor, or make it broader? 06:23:53 reillyg Concretely that means Accelerometer, Gyroscope, Gravity Sensor 06:24:51 reillyg Within those specs, we have Orientation, Relative Orientation,… a bunch of others 06:24:55 ack anssik 06:25:36 anssik When we say "should do a review", is that do a wide review and horizontal review? What did the TAG recommend? 06:25:49 reillyg This is where we get in the later points of the document 06:26:24 reillyg They recommend the group start with the second point (proactively pursue more modern security and privacy reviews" 06:26:40 s/reviews"/eviews) 06:26:53 s/eviews)/reviews) 06:27:25 reillyg There should be a clear improvement in the shape improvement and the privacy section 06:28:03 reillyg We added a Gravity Sensor since, which is a small addition, but it proves the architecture of the Generic Sensor API, so we can just add new sensors without much hassle 06:28:19 reillyg It's an extension of the device motion sensors 06:28:41 reillyg Had we extended the Device Motion API, it'd have been a lot harder 06:29:25 anssik Why did Chromium decide to adopt this work? 06:29:38 anssik Particular use cases were enabled 06:29:54 anssik There was a customer demand for Gravity Sensor (Unity) 06:30:15 anssik What would help TAG convincing, kenchris? 06:30:16 q+ 06:30:55 kenchris For the TAG, there is a lot of work, so not much time for individual issues. Have a good explainer helps, so we don't lose time when we need to dive in again 06:31:17 q+ 06:31:17 kenchris Generic Sensor is generic and doesn't define individual sensors, this is not clear to everyone for example 06:31:28 reillyg Can we get a resolution? 06:31:40 -> https://w3c.github.io/motion-sensors/ Motion Sensors Explainer 06:32:07 q+ to note we have a nice Motion Sensors explainer that might benefit from an editorial update for the horizontal review purposes 06:32:54 q? 06:33:01 ack larsgk 06:33:14 larsgk I'm missing something on power consumption 06:33:46 larsgk I remember that being a big problem in Nokia. I don't think the current API helps people use the hardware in reasonable ways without draining the battery 06:34:08 anssik It's worth opening a new issue for. The sensor could hint at how it wants to be polled. 06:34:24 larsgk If we move into background polling, then we need this 06:34:30 q? 06:34:38 anssik Open it for Generic Sensor or the particular sensor. 06:35:03 reillyg One of the aspects of the API are that it has parameters which allow you to configure things accordingly 06:35:20 reillyg It provides controls for making power consumption more optimal by making data minimization 06:35:29 reillyg There are other things that could be done 06:35:40 reillyg For example setting triggers or batching events 06:35:54 q? 06:35:57 reillyg Generally, this suggests that it's good to have a new shape 06:35:59 ack rakuco 06:36:03 q 06:36:16 rakuco Would like to doublecheck if I understand correctly 06:36:49 rakuco The APIs have been maintained for years, but not much changes. Are we asking the same questions to the TAG again, like the TAG has evolved but not the spec? 06:36:55 reillyg It's a combination 06:37:20 reillyg The other recommendation from the TAG was to improve the privacy and security sections to better document concerns 06:37:24 q- 06:37:41 reillyg I did a review of these sections, but there wasn't full clarity on what the TAG actually asked 06:37:56 reillyg But we can definitely always do a better job on these sections 06:38:17 anssik Agreed. The world has changed, it wasn't ready when we published initially. But now it is ready 06:38:23 rakuco So a new checkup. 06:38:37 anssik The Motion Sensor API is still in progress 06:38:55 anssik It should be Generic Sensor based 06:39:22 reillyg I think the Generic Sensor API is a good framework but discussing it requires concrete examples. 06:39:30 reillyg Like motions sensors 06:39:42 reillyg And use those for the discussion 06:40:06 reillyg We can take that for the discussion for other sensors that are out of the pure motion sensors 06:40:16 reillyg Sticking with something we understand help 06:40:24 s/understand help/understand helps 06:40:38 anssik I like this. 06:40:59 anssik Leaving this to marcosc to decide how this should look like for Geolocation Sensor 06:41:19 anssik Could be a markdown file with a fancy name like findings.md 06:41:28 s/findings.md/findings 06:41:43 RRSAgent, draft minutes 06:41:43 I have made the request to generate https://www.w3.org/2021/04/07-dap-minutes.html anssik 06:42:51 tomayac Is "wide review" defined? 06:43:07 https://www.w3.org/Guide/documentreview/ 06:43:10 anssik It is defined and is a mailing list. It's also known as horizontal review. 06:43:45 rakuco Are we leaving out some sensors? 06:43:59 reillyg Yes, focusing on sensors that are already part of the platform 06:44:12 reillyg Leaving out new sensors that haven't been implemented yet 06:44:37 reillyg By including new sensors we water down the discussion by triggering justification discussions for the existence of the new sensors 06:44:51 proposed RESOLUTION: Pending completion of other horizontal review work, revise Security and Privacy sections of the Generic Sensors specifications, provide the TAG with a revised explainer for motion sensors and seek horizontal review for already shipping Generic Sensor API, Accelerometer API, Gyroscope API and Orientation Sensor API. 06:45:00 reillyg Instead, we focus on the existing sensors 06:45:24 rakuco When ALS came to mind, I imagined people already to complain about it 06:46:03 RESOLUTION: Pending completion of other horizontal review work, revise Security and Privacy sections of the Generic Sensors specifications, provide the TAG with a revised explainer for motion sensors and seek horizontal review for already shipping Generic Sensor API, Accelerometer API, Gyroscope API and Orientation Sensor API. 06:46:11 q? 06:46:26 scheib With Geolocation Sensor, what is the carrot for developers? 06:46:47 scheib Other groups of Chrome have pushed the concept of privacy budget 06:46:58 scheib Maybe some new APIs might use this carrot 06:47:11 reillyg Not aware of any specific discussions 06:47:37 reillyg Remember similar disucssions around putting sensors behind a permission prompt 06:48:14 reillyg: If we allow frequency readings without prompts, that could be possible 06:48:40 marcosc: I haven't seen discussions in Mozilla about this 06:48:52 scheib: Maybe kenchris or anssik? 06:49:01 anssik: I like the idea of carrots. 06:49:21 s/in Mozilla about this/in Mozilla about this while I was there previously 06:49:21 anssik: Who is the person who's the most into privacy budgets? 06:49:47 kenchris: Not sure, not sure if it is pursued. Haven't followed to be honest. 06:49:57 scheib: There are people in Google who are behind it 06:50:05 reillyg: I haven't had discussions 06:50:16 reillyg: Don't know the current status 06:50:31 kenchris: It was discussed in the TAG, but they were not very fond 06:50:43 anssik: I expect PING to have opinions on this 06:51:48 https://developer.chrome.com/devsummit/sessions/introducing-privacy-budget/ 06:52:05 q? 06:52:21 reillyg: We have our existing plan of republishing our specs 06:52:46 reillyg: There are a lot of things the TAG advises. 06:52:57 reillyg: We already do many of these 06:53:21 reillyg Like providing developer incentives 06:53:47 reillyg The start of this is the notes on the specs 06:54:16 reillyg: The decision around the Network Information API can happen now 06:54:35 reillyg: On this API, we haven't made much progress 06:54:51 reillyg: It's on the backlog, it occasionally comes up. 06:55:12 reillyg: For example with xxxxx pressure. 06:55:49 s/xxxxx/compute 06:56:09 reillyg: Olivier presented the API in the last meeting 06:56:25 reillyg: It's an API that tells the site how busy the device is 06:56:26 -> https://github.com/oyiptong/compute-pressure Compute Pressure API 06:57:01 FTR, I reached out to PING co-chairs to ask whether PING has reviewed or discussed the Privacy Budget proposal 06:57:08 reillyg: So sites can avoid thermal throttling or adapt their behavior if the device is too busy 06:57:18 -> https://github.com/bslassey/privacy-budget Privacy Budget proposal 06:57:39 tomayac: It's not directly connected to Network Information 06:57:49 reillyg: Correct, it's in a similar space 06:58:11 reillyg: The summary is that like System Wake Lock it's on our backlog 06:58:24 reillyg: We agree with the concerns raised by the current draft 06:58:26 RRSAgent, draft minutes 06:58:26 I have made the request to generate https://www.w3.org/2021/04/07-dap-minutes.html anssik 06:58:37 reillyg: And would like to revise it, given enough time 06:59:52 tomayac: met with Yoav, and with some folks from Microsoft... we couldn't work out exactly what the use cases were for it. There were other outside scope use cases, like fraud detection 07:00:52 tomayac: we still need to look at other use cases that are already covered by the platform... like CSS prefers-low-data or something. So there are alternative approaches. The tl;dr: we don't fully understand the use cases. 07:00:54 q+ 07:01:02 ack marcosc 07:01:19 marcosc: We wrote an extensive use cases doc 07:01:52 https://www.w3.org/TR/netinfo-usecases/ 07:02:04 tomayac: we did look at those 07:02:15 tomayac: We looked at those, we also acknowledged there's a black hole of use cases like tracking, bot detection, fraud detection,… 07:02:32 reillyg: It's too early to have a propsoed resolution 07:02:43 anssik: It's lower priority at the moment 07:03:03 reillyg: We will pursue work on this 07:03:09 RRSAgent, draft minutes v2 07:03:09 I have made the request to generate https://www.w3.org/2021/04/07-dap-minutes.html anssik 07:03:42 new Promise((resolve) => {}) 07:03:52 anssik: It feels like we have discussed the TAG concerns 07:04:07 anssik: We have a number of resolutions, which is good 07:04:20 anssik: We made great progress 07:04:37 reillyg: We ended up discussing a lot of the remaining agenda items 07:05:06 reillyg: The one thing we didn't discuss was the PING, because Peter couldn't make it 07:05:23 anssik: Already reached out regarding privacy budget 07:05:34 s/because Peter/because Pete 07:05:54 RRSAgent, draft minutes 07:05:54 I have made the request to generate https://www.w3.org/2021/04/07-dap-minutes.html anssik 07:56:50 xfq_ has joined #dap 08:46:01 xfq_ has joined #dap 11:07:50 xfq_ has joined #dap 11:10:18 Zakim has left #dap 11:18:26 xfq_ has left #dap