04:57:26 RRSAgent has joined #dap 04:57:26 logging to https://www.w3.org/2021/10/29-dap-irc 04:57:28 RRSAgent, make logs Public 04:57:29 please title this meeting ("meeting: ..."), anssik 04:57:31 Meeting: Devices and Sensors WG - TPAC 2021 vF2F Day 3 04:57:40 Chair: Anssi, Reilly 04:57:43 xfq has joined #dap 04:57:44 Agenda: https://github.com/w3c/devicesensors-wg/issues/47 04:57:45 present+ 04:58:49 arma has joined #dap 05:00:12 npdoty has joined #dap 05:00:13 scribe+ reillyg 05:00:19 present+ Reilly_Grant 05:00:20 cpn has joined #dap 05:00:27 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html xfq 05:00:29 Agenda: https://github.com/w3c/devicesensors-wg/issues/47 05:00:32 Maryammjd has joined #dap 05:00:59 Topic: Privacy, security, and architecture 05:01:14 present+ Fuqiao_Xue 05:01:26 present+ Chris_Needham 05:01:26 present+ Raphael_Kubo_da_Costa 05:01:28 RRSAgent, draft minutes 05:01:28 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 05:01:37 present+ Anssi_Kostiainen 05:01:39 scribe+ anssik 05:01:41 Good morning (noon, evening) all! 05:01:59 present+ Maryam Mehr 05:02:09 present+ Marcos Caceres 05:02:09 present+ sathya 05:02:17 mattreynolds has joined #dap 05:02:25 present+ Lars_Knudsen 05:02:36 present+ Arnaud_Mandy 05:02:41 present+ Nick_Doty 05:02:55 present+ tomayac 05:02:55 present+ 05:03:16 present+ Juha_Vainio 05:03:36 present+ Matt_Reynolds 05:04:17 Topic: Introducing privacy and security community guests 05:04:46 present+ Lukasz 05:05:10 weiler: I work at MIT for the W3C on privacy. 05:05:30 plh has joined #dap 05:05:59 Lukasz: I work on research on privacy and security. 05:06:28 npdoty: I am at the Center for Democracy and Technology. 05:07:05 Maryammjd: I am a researcher at Newcastle University in the UK. I work on privacy and security issues related to sensing technology. 05:07:22 ... Today I will be talking about a recent user study I have done on these topics. 05:07:39 present+ plh 05:08:02 Subtopic: AB/TAG experiment recommendations update 05:08:19 -> https://github.com/w3c/dap-charter/issues/103#issuecomment-744446928 Report of AB/TAG experiment 05:08:56 -> https://www.w3.org/2021/04/07-dap-minutes.html 2021 Q2 virtual meeting session 05:09:18 anssik: At the Q2 meeting we made a number of commitments related to security and privacy reviews. 05:09:27 DONE: 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:10:46 DONE: 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:11:03 WIP: Investigate retrofitting the new use cases enabled by the Geolocation Sensor API to the Geolocation API 05:11:55 DONE: Publish a FPWD of the Geolocation API 05:12:15 WIP: 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. 05:12:55 ... I would like to focus on this last part because it is the next work ahead of us. 05:13:55 ... plh, what are your thoughts on our progress on these commitments? 05:13:58 Sathya has joined #dap 05:14:08 plh: Where are the horizontal review requests for these documents? 05:14:34 anssik: The reviews have not been requested yet. The Security and Privacy documentation still needs to be revised. 05:15:17 q? 05:16:05 plh: I'm not going to be able to point the Council at progress on reviews because it hasn't been started. 05:16:08 q+ 05:16:37 q- 05:16:46 is there some particular timeline in the Council or otherwise in this plan? 05:17:20 npdoty, we're waiting on the council to take on the objection. no timeline yet. 05:17:30 anssik: Question to weiler: What can we do in order to make the review process easier for PING? 05:18:20 plh, oh, I thought this December 2020 comment was the Council recommendation. are they going to provide further input again? 05:18:40 ... Is it the right approach to algorithmic privacy mitigations as well as a summary in the considerations section? Should the consideration section have its own normative requirements? 05:19:03 npdoty, there is a new objection on the proposed revised charter 05:19:07 RRSAgent, draft minutes 05:19:07 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 05:19:10 marcosc: Putting mitigations into the algorithms is better than a generic "don't allow fingerprinting" normative requirement in the S&P considerations section. 05:19:37 ... Would the PING appreciate both algorithmic mitigations as well as a discussion of those mitigations in the S&P considerations section? 05:19:56 ... This does create duplicate work and the potential for specification text to get out of sync. 05:20:12 s/Topic: Introducing privacy and security community guests// 05:20:13 RRSAgent, draft minutes 05:20:13 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 05:20:15 ... In particular non-normative descriptions which don't translate to testable assertions. 05:21:12 npdoty: I see review as a non-mechanical process. The reviewers are coaches. The best reviewers are the editors because they know the subject area. 05:21:17 yeah, I think normative requirements inline and then use priv/sec considerations to explain the threats and overview how they're mitigated (referring to those other sections) 05:21:30 s/npdoty/weiler/ 05:22:19 q? 05:22:19 weiler: The questionnaire is meant to guide your thinking. The TAG requires it but the PING is looking for documentation of what you've figured out while considering those questions. 05:23:17 ... Ask for feedback as early as you can, while there is still opportunity to change things. 05:23:33 ... I agree with marcosc that mitigations are defined algorithmicly. 05:24:07 ... Two categories of recommendations: 05:24:13 ... 1. Make users look the same. 05:24:21 ... 2. Make users look different to different origins. 05:24:44 ... (Additional recommendation for this group) Be careful of ephemeral fingerprinting. 05:24:44 xfq_ has joined #dap 05:24:57 ... Two sites looking at the same sensor values can determine that the user is the same. 05:26:25 npdoty: I think the re-review idea from the AB recommendations is a really good review. 05:26:41 lknik has joined #dap 05:26:53 ... Geolocation API was one of the first APIs I looked into that raised a number of permissions questions like what we are thinking about today. 05:27:32 q+ 05:27:40 ack anssik 05:27:44 ... Since we are looking at a lot of sensor specifications we should use this as an opportunity to pull out the most general principles. 05:28:13 anssik: The Generic Sensors API defines a baseline for these sensor APIs and the baseline privacy mitigations for all of these sensors. 05:28:36 ... We should make sure that this specification provides good mitigations so that each sensor API doesn't need to rebuild these mitigations from the ground up. 05:28:52 ... However, each sensor should be considered for its own individual privacy considerations. 05:29:02 xfq_ has joined #dap 05:29:17 q+ Lukasz 05:29:30 npdoty: Information disclosure is our primary privacy risk. 05:29:41 ... This disclosure may be obvious or non-obvious. 05:30:34 RRSAgent, draft minutes 05:30:34 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 05:31:15 ... We should also consider carefully the ways in which these API allow a site to actuate capabilities of the device (e.g. vibration, screen brightness). 05:31:39 ... We need a lot more work on whether users understand permissions and now long permissions should last. 05:31:42 q+ 05:31:53 ack Lukasz 05:33:03 Lukasz: I had the opportunity to extract some general considerations from analysis of APIs like battery and light sensor. 05:33:18 ... I believe that these takeaways are applicable to other API concepts. 05:34:03 ... When reading the latest Network Information API's S&P considerations I am happy to see the minimization of data collected. 05:34:45 q? 05:35:52 we should definitely have on our list going through some academic work (lukasz, maryam, others?) and see if we have those general considerations/principles 05:36:25 ... The question I would pose is, what is the progress on the Network Information API and what major things should we be looking at? 05:37:45 reilly: any ideas whether the mitigations proposed by Idle Detection API are sufficient? 05:37:53 q+ Maryammjd 05:37:55 PING definitely had a lot of serious open questions about network-info when it was at the CG level, but I'm encouraged that we should expect it to be better filled out when we next look at it 05:38:46 q? 05:38:49 ack weiler 05:38:50 ack weiler 05:39:00 (I also haven't looked at Idle recently; that was certainly one that had the threat of simultaneous-event firing, which weiler referred to earlier in the category of ephemeral fingerprinting) 05:39:18 weiler: To marcosc's earlier question: Do you expect us to document mitigations in two places in the specification? 05:39:39 ... Think of the S&P section as a table-of-contents. 05:39:53 s/Do you expect us to/Would you like us to 05:39:54 :) 05:40:07 ... It will contain an analysis of the considerations and pointers to the mitigations. 05:41:25 q? 05:41:30 anssik: An explainer for how to write an S&P section would be appreicated. 05:41:41 weiler: The IETF has good documentation in RFCs for now to do that. 05:41:47 ack Maryammjd 05:42:03 xfq has joined #dap 05:42:09 that's great feedback. we should include the RFC pointers, or have a friendly version for how to write a good web privacy and security considerations section 05:42:30 Maryammjd: We discussed previous how Android and iOS were handling sensors in contrast to how the web is handling mitigations. 05:42:32 [linked from https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review ] 05:42:51 q? 05:42:57 ... How are we trying to accommodate all these approaches and how are we considering the ways that other platforms are handling these issues. 05:43:18 [ https://tools.ietf.org/html/rfc6973#section-7 https://tools.ietf.org/html/rfc3552#section-5 ] 05:43:53 I think sometimes the user experience just will be different between platforms. the Web has different affordances, and I think we often prefer how the Web does it (not assuming that apps are vetted, etc.) 05:44:21 reilly: challenge we're facing in browser implementations is the native platforms we're building on top of are changing 05:44:33 but I also hope we can learn from what works well in macOS, windows, android, ios -- like providing good inline explanations of purposes in permissions requests, for example 05:44:57 ... Android has done changes in terms of sensor accuracy 05:45:20 ... rates in Android are higher than what spec requires, e.g. Android 200 Hz, spec 60 Hz 05:45:59 Maryammjd, do you have some good examples we can read from user studies on those confusions? 05:46:03 ... vague consensus build across native platforms on what the mitigation baseline should be 05:46:32 ... we had a permission in generic sensor spec, not fully rolled out in specs, we should be able to keep the model of the web similar to what the model is on native platforms 05:46:39 @npdoty, yes, I present in my talk today 05:46:54 ... web platform should always be strictly safer due to the nature of how the platforms are layered 05:47:09 xfq has joined #dap 05:47:11 Maryam: are you in contact with Web of Things? 05:47:22 q? 05:48:37 reilly: during Q2 F2F we had ECMA TC member talking about this topic 05:49:31 -> https://github.com/w3c/proximity/issues/44 Behavior of distance attribute when sensor cannot provide distance measurements? #44 05:49:37 anssik: That was TC53. 05:49:52 q? 05:50:42 q+ 05:50:48 ack larsgk 05:51:01 Maryammjd: It's good to have the bigger picture of how sensors are being used in the IoT space. 05:51:24 larsgk: I've been working on adoption of device APIs in the enterprise space. 05:51:39 ... I am concerned that what is being done in the consumer space doesn't align with the enterprise space. 05:51:50 q? 05:52:01 Peter_B_Andersen has joined #dap 05:52:31 present+ Peter Bruhn Andersen 05:52:33 oh, gosh, I thought we had been brainstorming already ;) 05:52:38 Subtopic: Privacy cross-group brainstorming 05:53:26 -> https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review How to get horizontal review 05:55:28 yes, we definitely want folks to feel welcome to come discuss and request reviews 05:58:10 reilly: we seem to be on track to satisfy AB/TAG recommendations and our minutes today contain good references 05:58:56 RRSAgent, draft minutes 05:58:56 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 06:08:11 yes, absolutely, thanks for raising that aloud Maryammjd. diversity of participation is an ongoing challenge in W3C and other Internet governance settings 06:10:21 [Slides will be shared after the meeting] 06:10:38 [Slide 1] 06:11:28 Maryammjd: This work is currently under review for a conference. I will discuss with my coauthors and prepare a public version. 06:13:48 [Slide 2] 06:14:07 Maryammjd: These are ambient sensors found in mobile devices. 06:14:09 [Slide 3] 06:14:29 Maryammjd: We have been looking at the risks these sensors provide alone and in combination. 06:14:44 [Slide 4] 06:15:25 Maryammjd: It is not shocking to learn that users are not familiar with these sensors and there is significant disparity between actual and perceived risk. 06:15:55 ... Geolocation has been better studied, ambient sensors less so. 06:16:09 ... Smart building studies have covered ambient sensors to some extent. 06:16:45 ... At TPAC 2019 I pointed out some research into using AI/ML for managing sensors but there have been no user studies in this space. 06:17:36 [Slide 5] 06:18:18 [Slide 6] 06:18:45 [Slide 7] 06:18:48 [Slide 8] 06:19:18 Maryammjd: Users are not familiar with ambient sensors and are not concerned. Around 50% of participants are not concerned at all. 06:19:25 [Slide 9] 06:19:49 Maryammjd: Although they are not concerned user feel very annoyed if sensors are accessed without their permission. 06:20:02 ... Could be install-time or at runtime. First time or each use. 06:20:46 anssik: Was the question framed in terms of all of the sensors from slide 2? 06:20:57 Maryammjd: Yes, we gave a description of the ambient sensors. 06:21:00 [Slide 10] 06:21:27 Maryammjd: Users expected native apps to have access to ambient sensors but not websites. 06:21:40 ... Expected the OS to handle sensor access automatically in a privacy-preserving way. 06:21:57 ... Some users preferred being notified over being asked permission. 06:22:11 ... Others preferred an opt-in over an opt-out approach. 06:22:28 ... Users would prefer sites to justify their use of sensor. 06:22:35 [Slide 11] 06:23:03 Maryammjd: Users were specifically worried that ambient sensors would reveal location. 06:24:12 ... Participant identified a concern over their child's safety, recognizing that these sensors are also present on devices such as toys. 06:24:15 [Slide 12] 06:24:45 Maryammjd: Generally the actions users take to protect themselves are consistent across apps and websites. 06:25:14 q+ 06:25:16 q? 06:25:17 ... With the exception of closing the site being more common than closing an app, with uninstalling the app being correspondingly more frequent. 06:25:55 that's a big privacy advantage that web can have other platforms (closing the website as a mitigation) -- if we ensure that it actually does still make a difference that web sites can't get background access 06:26:00 Maryammjd: Users would like some notification of sensors being used. 06:26:03 [Slide 13] 06:26:23 Maryammjd: Users would like a sensor privacy management system on their device. 06:26:38 [Slide 14] 06:27:18 Maryammjd: Users want control and usability. 06:27:24 [Slide 15] 06:28:30 Maryammjd: Users are receiving too many notifications about security and privacy, many of them fake. Users would like communication through other channels about these real risks. 06:28:35 [Slide 16] 06:29:06 [Slide 17] 06:29:28 Maryammjd: If the notification is annoying then it is no good. 06:30:06 [Slide 18] 06:30:48 Maryammjd: Male participants expressed more knowledge about sensors and risks. Female participants expressed more concerns in relation to their privacy and security. 06:31:03 ... No difference in level of annoyance or protective actions. 06:31:28 ... Younger participants prefer less involvement in permission management. 06:31:43 [Slide 19] 06:32:32 Maryammjd: Given lack of permission controls in real-world systems participants feel that they just have to learn to live with the idea that they are being tracked. 06:32:44 ... Feel that legislation should protect them. 06:32:48 [Slide 20] 06:33:23 Maryammjd: In summary, the majority of participants are not or only a little concerned about ambient sensors. 06:33:39 ... However they would be strongly annoyed if sensors are accessed without their concent. 06:34:04 ... Majority preferred a smart management system to handle sensors on their behalf. 06:34:05 q? 06:34:13 q+ 06:34:26 ack anssik 06:36:05 q+ 06:37:21 yeah, I think we should try to learn from this and other research. I think there's a lot on permissions and how users might respond to them 06:37:47 q? 06:38:11 Maryammjd: Note that a "take it or leave it" approach is not compliant with the GDPR. 06:39:07 q? 06:39:10 yes, this is a big advantage for the Web! you can close the tab 06:39:11 ack tomayac 06:39:13 A new recommendation in the Permissions spec is to show when permissions are being queried -> https://w3c.github.io/permissions/#privacy-considerations 06:39:54 RRSAgent, draft minutes 06:39:54 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 06:40:00 tomayac: Permissions spec now recommends that the user be notified when permission state is being queried. 06:40:28 ... Tricking people into granting permission has been seen in the past. 06:40:52 yeah, I raised that threat (using a permission more often once it's been granted), and I'm still not real happy about the lack of effective mitigations we have for that 06:41:03 q? 06:41:07 but yeah, *ambient notice* can be helpful 06:41:48 ... What do you think of these types of usage indicators? 06:42:22 q+ npdoty 06:42:33 q- 06:43:16 Maryammjd: Inconsistency in permission models makes things difficult for users. 06:43:31 ... Younger users are frustrated and want all the questions to go away. 06:43:58 q? 06:44:02 ack larsgk 06:44:46 larsgk: Is there a correlation between the results and users who have installed major social media applications? 06:45:00 q+ 06:45:15 Maryammjd: We didn't find a correlation between the number of apps and websites that are used and their security and privacy concerns. 06:46:32 ack marcosc 06:47:54 marcosc: How representative was the population. I am concerned about whether these were users who did not feel that they were under threat and so would respond with "I don't care." 06:48:13 Maryammjd: Participants were English-speakers across EU and UK. 06:49:07 marcosc: We generally know that people in well-off countries won't be concerned. 06:49:41 Maryammjd: In human user studies we often find that what users say and do are very different. 06:50:06 ... For example, they say they will be very annoyed or that they will protect themselves but take no action to protect themselves. 06:50:27 RRSAgent, draft minutes 06:50:27 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 06:50:36 ... I believe that when we design the protection mechanisms they aren't user-centered enough, contributing to these behaviors. 06:51:27 marcosc: Reminds me of people being surprised when people dig up very old emails when people assumed they would be deleted. 06:51:44 Maryammjd: We find that these kinds of wrong mental models are very common. 06:51:57 q? 06:52:03 ... We find that women feel more fear and are not confident in using these protective technologies. 06:53:54 Topic: Sensors 06:53:59 thanks for the discussion, all 06:54:07 and thanks for the data and presentation, Maryammjd 06:54:46 Subtopic: Sensors and permission bundles, low-level vs. high-level permissions 06:55:01 -> https://github.com/w3c/permissions/issues/191 Semantic Permission Bundles permissions #191 06:55:32 tomayac: this is an idea that mic and cam could go together in terms of permissions 06:56:06 ... at some point we could define e.g. produtive app semantic bundles for things like filesystem, protocol handlers 06:56:20 ... or maker apps for BT, USB combined 06:56:35 ... the idea is to reduce the mental load on people who react to permissions 06:56:56 ... clipboard is required for MS Word, you assume it is there 06:57:10 ... lowering the cognitive load on people would help in here 06:57:23 ... I don't not anyone on Chrome working on this, an idea at this point 06:58:10 reillyg: the area where this is discussed most in the WG is around whether motion sensors should be considered one high-level permission 06:58:19 ... iOS has a single motion sensors permission 06:58:39 ... I was in support of deprecating low-level permissions in favor of high-level permissions 06:58:57 ... WG discussed ALS gated on camera permission as one potential way to get access to that sensor 06:59:15 ... the general question of bundling, I'd say there's UX question in Chromium related to devices 06:59:32 q+ 06:59:44 ... user's concern rel device as in a single physical device, alternative view is there can be multiple ways to access these deviecs 07:00:04 ... how to model the device as a single entity so need to only grant permission only once 07:00:21 ... today if you request a camera, you can access *all* cameras 07:00:32 q? 07:00:39 ack marcosc 07:01:09 marcosc: I try to delineate Permissions API from this discussion and renaming of things 07:01:39 ... powerful features require express user permission, on the developer side, to get access to an API is a policy decision, the two come together at some point 07:02:08 ... the mental model has been a bit unclear, but we're converging on more reasonable model now 07:02:57 q+ 07:03:07 reillyg: agree, just because access to camera does not always mean access to mic as well, this is a UX question 07:03:26 ... asking good questions, when there are two many questions, active space of user research 07:03:30 ack larsgk 07:03:51 larsgk: I think there's differentiation between user and enterprise 07:04:10 ... what is MVP required for the app to work at all, optional features could come on demand 07:05:16 q? 07:05:36 tomayac: Microsoft is considering app front permissions, in the manifest 07:05:51 ... so that stores can display this permissions the app can ask for at some point 07:06:39 s/app front/up front 07:07:29 -> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/InstallTimePermissionsPrompt/Explainer.md 07:07:51 q? 07:08:13 reillyg: Microsoft proposal originally actually did propose up front permissions 07:08:44 ... this opportunity to grant permissions up front if the user wanted to, "if you want the app to use cam and mic, you can grant it now of leave it for later" 07:09:09 ... Chromium people looking at the idea of declaring these permissions up front for install time 07:10:04 ... proposals out there trying to propose more questions at once 07:10:14 q+ 07:10:44 ... there's a question in the sensor space: do we want to make this type of bundling part of the API or permissions UX? 07:11:36 ... API modelled in terms of low-level permissions that the UA can consider to present to the user as a bundle, or high-level bundle alone -- do we want to preserve the expressiveness? 07:12:19 anssik: low-level gives more freedom to implementers 07:12:40 marcosc: I don't have a good solution to this, we can go either way 07:12:55 ... the freedom to implementers, I agree, but don't want that to be in the spec 07:13:15 ... in Screen Wake Lock API, for example, the permission was implemented sometimes but not always 07:13:26 ... implementers should have freedom to experiment 07:13:55 reillyg: Wake Lock example: we assumed it is better to have perms spec'd 07:14:22 ... if it'd not be in the spec, the API evolutions would be harder 07:14:37 ... maybe too much future-proofing? 07:15:00 ... if we think low-level is better but put high-level in the spec, is that hard to change? 07:15:23 ... or, as long as promise-based, we can evolve without breaking existing websites that rely on current API behavior? 07:15:40 marcosc: these are just strings 07:15:54 reillyg: we should probably keep the existing permissions as is 07:16:18 marcosc: developers want policy controlled features they can disable certain features 07:16:32 ... 1:1 mapping between the strings not a requirement 07:16:33 s/existing permissions/existing permission policies/ 07:17:23 reillyg: "motion sensors" permission makes sense to me, defining a singular permission is worth prototyping 07:17:26 +1 for merging the motion sensors permissions 07:18:03 marcosc: mental model, request a permission for each, not optimal situation 07:18:29 q+ 07:18:38 q? 07:19:31 proposed RESOLUTION: Explore update to the specs to add high-level "motion-sensors" permission to encourage prototyping 07:21:15 proposed RESOLUTION: Explore update to the sensors specs to add high-level "motion-sensors" permission to encourage prototyping 07:21:31 +1 07:21:54 RESOLUTION: Explore update to the sensors specs to add high-level "motion-sensors" permission to encourage prototyping 07:22:06 q- 07:22:29 ack larsgk 07:22:42 q+ 07:22:54 larsgk: any work on required and optional permissions in manifest to reflect that into UI/UX? 07:22:59 ack marcosc 07:23:26 marcosc: these enterprise scenarios would have a separate permissions policy in the browser 07:24:12 reillyg: from Chromium perspective, we have a policy mechanism for enterprise admins to deploy a policy to users that grants access to selected features 07:24:27 larsgk: works for enterprises that have Chrome for Enterprise? 07:25:05 reillyg: there's a cloud-based service that uses Google's management console, but policies are configurated through Windows AD, Mac corresponding client, and in some similar way for Android 07:25:32 q? 07:25:45 xfq: For normal users, there is currently no such mechanism, right? 07:26:25 reillyg: you can set policies on Linux, but issues related in non-managed scenarios 07:26:44 ... Chrome does not allow policies to be set on non-managed devices to mitigate abuses 07:26:55 q? 07:27:34 s/does not allow policies/does not allow frequently abused policies/ 07:28:08 Subtopic: Ambient Light Sensor, consider making granularity of the data normative 07:28:24 -> https://github.com/w3c/ambient-light/issues/63 Consider making granularity of the data normative #63 07:29:07 reillyg: since last discussion, we spec'd a normative privacy mitigation by limiting motion sensors to limit granularity 07:29:26 ... ALS mitigation was not made normative, but the mitigation has been implemented in Chromium 07:30:13 marcosc: makes sense when you reach a baseline and adapt it as we go 07:30:14 q+ 07:30:39 ... similar situation with Gamepad API, and anything to do with timing, domtimestamp etc. 07:30:40 q? 07:30:51 ack rakuco 07:31:29 rakuco: adding this to the spec is pretty easy, I was not involved with ALS when we reached conclusion 50 lux is a reasonable threshold 07:31:41 ... need to document why we landed on this 07:32:22 q? 07:32:40 proposed RESOLUTION: Make Ambient Light Sensor granularity of the data normative 07:33:02 proposed RESOLUTION: Specify Ambient Light Sensor data granularity as normative 07:35:15 proposed RESOLUTION: Make Ambient Light Sensor granularity of the data normative, including round off to nearest 50 lux and only fire event if the previous and current raw values differ significantly 07:37:12 proposed RESOLUTION: Make Ambient Light Sensor granularity of the data normative 07:37:21 +1 to (1) then 07:37:41 RESOLUTION: Make Ambient Light Sensor granularity of the data normative 07:38:02 Subtopic: Ambient Light Sensor, revisit developer feedback 07:38:24 -> https://github.com/w3c/ambient-light/issues/64 Request for Ambient Light Sensor web developer feedback 07:40:34 q+ 07:40:42 anssik: getUserMedia misused to get data that could be provided through ALS adhering to data minimization principles 07:40:47 ack larsgk 07:41:14 larsgk: we have a concrete ALS use case for dashboards in vessels 07:41:32 ... they could not say "yes" to camera access but would grant access to ALS 07:41:33 q+ 07:41:42 ack marcosc 07:42:02 marcosc: I wonder how much overlap there is with OS level control, CSS dark/light mode? 07:42:14 larsgk: we have tri-state, not boolean dark/light 07:42:38 marcosc: documenting a use case would help 07:43:08 ... it feels like we have light mode, and how that translates to CSS level, are we pitching it on the right forum? 07:43:28 reillyg: there's an opportunity for the web to provide access to low-level capability OS does not understand 07:43:59 ... a long-tail use cases on the system OS does not provide an API for, there's value in innovating in this space where OS vendor have not standardized APIs 07:44:28 ... Lars' case is true, there's a context that's different from a regular user case, in Chrome we call this Kiosk device 07:44:46 ... a sensor on the device, the permission and access model is a little different from the general user 07:45:15 ... there's a higher level concept we want to understand, websites want to know on which light level they want to be "dusk" and "dawn" 07:46:04 ... no conclusion other than, in Chromium we've considered a number of APIs that fall in the Kiosk mode 07:46:30 ... figuring a best permission model is important, restricting generalization of the general consumer case 07:46:33 q? 07:47:48 reillyg: we'd be willing to enable the ALS API for websites that use camera already 07:48:11 ... we could consider ALS augmenting the camera 07:48:22 q? 07:49:00 rakuco: with my Intel hat on the biggest difficulty is to know if there's enough demand for this feature 07:49:28 ... we can land optimizations to the implement, we want to know if it makes sense to spend time on this 07:49:52 reillyg: we know there's demand, but how loud that demand is 07:49:54 ... we have a few developers who'd be happy if we'd get this past the finish line 07:50:21 rakuco: right, for implementation specific discussions, let's follow up on that 07:50:36 reillyg: also spec PR to bundle ALS and camera permissions together 07:51:07 propose RESOLUTION: Bundle ALS and camera permissions in the to unblock shipment of the API 07:51:31 propose RESOLUTION: Bundle ALS and camera permissions in the spec enable shipment of the API 07:51:44 propose RESOLUTION: Bundle ALS and camera permissions in the spec to enable shipment of the API 07:52:15 propose RESOLUTION: Bundle ALS and camera permissions in the spec to help enable shipment of the API 07:52:24 propose RESOLUTION: Correlate ALS and camera permissions in the spec to help enable shipment of the API 07:53:09 proposed RESOLUTION: Add camera permission requirement to ALS spec to help enable shipment of the API 07:53:23 s/propose RESOLUTION: Bundle ALS and camera permissions in the to unblock shipment of the API// 07:53:29 s/propose RESOLUTION: Bundle ALS and camera permissions in the spec enable shipment of the API// 07:53:36 s/propose RESOLUTION: Bundle ALS and camera permissions in the spec to enable shipment of the API// 07:53:42 s/propose RESOLUTION: Bundle ALS and camera permissions in the spec to help enable shipment of the API// 07:53:49 RRSAgent, draft minutes 07:53:49 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 07:54:28 +1 07:54:32 s/propose RESOLUTION: Correlate ALS and camera permissions in the spec to help enable shipment of the API// 07:54:36 RRSAgent, draft minutes 07:54:36 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 07:54:59 +1 07:55:00 RESOLUTION: Add camera permission requirement to ALS spec to help enable shipment of the API 07:55:34 Subtopic: Magnetometer, discuss any spec blockers for shipping 07:55:58 reillyg: have we gotten developer interest? 07:56:16 rakuco: I'm not aware 07:56:49 -> https://www.w3.org/TR/magnetometer/#usecases-and-requirements Use Cases and Requirements 07:57:12 reillyg: input methods involving magnets, gesture recognition, detection of direction 07:57:40 ... not aware of other use cases? 07:57:59 anssik: do we have data from Android app usage of Magnetometer? 07:58:41 q+ 07:58:45 reillyg: there's value in having these specs around, e.g. Unity asked for Linear Acceleration and it was shipped quickly 07:59:37 s/Linear Acceleration/Gravity Sensor/ 07:59:48 larsgk: I think there are opportunities in the accessibility space, this API is possible an enabler of innovation in that area 08:01:46 ... this API could be used to detect e.g. if you're inside a Faraday cage and will face connectivity issues 08:02:07 tomayac: in the context of cardboard, how did this API come to be? 08:02:26 reillyg: crbug from 2015 referring to cardboard device that is enabled by this API 08:02:50 ... that issue also mentions generic sensor API, that came after 08:03:46 tomayac: pressing a button on a handheld device, is that the latest approach in cardboard-style usage (instead of magnet-based input)? 08:04:51 reillyg: there's detection of hand movement, e.g. in Meta's announcement hand movement can be used to map hand motions into virtual space 08:06:01 anssik: sounds like we need to modernize use cases for Magnetometer 08:06:24 ... OT expectations, do you need developer pull to start OT? 08:06:55 reillyg: strongly preferred to have enthusiastic developers using a feature behind a flag first 08:07:51 q+ 08:08:04 reillyg: worth adding a note to the spec that this spec is requesting developer feedback and use cases 08:08:06 q? 08:08:11 ack larsgk 08:09:01 marcosc: metal detector use case, useful on a beach!! 08:10:06 mc: channeling PLH, we've had this published for a while. How much more interest can we expect to get for the API? 08:10:46 reillyg: I'd like to have an explicit status that points developers to a place to provide their feedback 08:11:12 marcosc: WICG is usually a place where we gather this type of feedback 08:11:34 reillyg: in this case we have a good design, but have "a solution looking for a problem", not incubation really 08:12:56 proposed RESOLUTION: "Update Status of the Document to indicate Magnetometer is looking for developer feedback" 08:14:03 s/proposed RESOLUTION: "Update Status of the Document to indicate Magnetometer is looking for developer feedback"// 08:14:09 RRSAgent, draft minutes 08:14:09 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 08:15:12 RESOLUTION: Update Status of the Document to indicate Magnetometer is looking for developer feedback and high value use cases 08:15:26 RRSAgent, draft minutes 08:15:26 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 08:16:51 anssik: thank you everyone for amazing 3 days of exciting device-centric discussions! 08:17:54 RRSAgent, draft minutes 08:17:54 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 08:20:33 xfq_ has joined #dap 08:24:11 s/proposed RESOLUTION: Make Ambient Light Sensor granularity of the data normative// 08:25:14 RRSAgent, draft minutes 08:25:14 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 08:25:46 s/proposed RESOLUTION: Specify Ambient Light Sensor data granularity as normative// 08:26:08 RRSAgent, draft minutes 08:26:08 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 08:26:19 s/proposed RESOLUTION: Make Ambient Light Sensor granularity of the data normative// 08:26:28 s/proposed RESOLUTION: Specify Ambient Light Sensor data granularity as normative// 08:26:30 RRSAgent, draft minutes 08:26:30 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 08:26:44 s/proposed RESOLUTION: Make Ambient Light Sensor granularity of the data normative// 08:26:52 s/proposed RESOLUTION: Make Ambient Light Sensor granularity of the data normative, including round off to nearest 50 lux and only fire event if the previous and current raw values differ significantly// 08:26:54 RRSAgent, draft minutes 08:26:54 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 08:27:32 s/proposed RESOLUTION: Make Ambient Light Sensor granularity of the data normative 08:27:32 08:27:32 , including round off to nearest 50 lux and only fire event if the previous and current raw values differ significantly// 08:27:35 RRSAgent, draft minutes 08:27:35 I have made the request to generate https://www.w3.org/2021/10/29-dap-minutes.html anssik 10:56:21 xfq_ has joined #dap 12:24:04 Zakim has left #dap 14:09:01 marcosc has joined #dap 15:37:03 npdoty has joined #dap