04:53:29 <RRSAgent> RRSAgent has joined #dap
04:53:29 <RRSAgent> logging to https://www.w3.org/2020/10/23-dap-irc
04:53:53 <xfq> Meeting: Devices and Sensors F2F - Day 2/2
04:54:02 <xfq> present+
04:54:12 <xfq> rrsagent, make log public
04:54:17 <xfq> rrsagent, make minutes v2
04:54:17 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html xfq
04:57:05 <hazel_> hazel_ has joined #dap
04:58:12 <takio> takio has joined #dap
05:00:34 <larsgk> larsgk has joined #dap
05:07:00 <tomayac> present+
05:07:05 <scheib> present+
05:07:31 <amandy> present +
05:08:06 <marcosc> marcosc has joined #dap
05:08:35 <marcosc> we are in https://mit.zoom.com.cn/j/91237600443?pwd=SjdPOWtRaC8wRkc4ZzU2Q1JjSUFlUT09
05:09:50 <marcosc> s/https://mit.zoom.com.cn/j/91237600443?pwd=SjdPOWtRaC8wRkc4ZzU2Q1JjSUFlUT09/https://mit.zoom.com.cn/
05:09:53 <marcosc> :)
05:10:17 <Mizushima> Mizushima has joined #dap
05:11:16 <anssik> RRSAgent, make logs public
05:11:18 <xfq> rrsagent, make minutes v2
05:11:18 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html xfq
05:11:22 <anssik> Meeting: Devices and Sensors F2F - Day 2/2
05:11:40 <anssik> RRSAgent, draft minutes v2
05:11:40 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html anssik
05:11:56 <anssik> Chair: Anssi, Reilly
05:12:00 <anssik> Agenda: https://github.com/w3c/devicesensors-wg/issues/31
05:12:08 <reillyg> Scribe: reillyg
05:12:29 <reillyg> present+ reillyg
05:12:47 <reillyg> Laura_Morinigo: Samsung SR UK
05:13:01 <reillyg> ... Here to discuss mobile devices and foldables.
05:13:13 <anssik> Present+ amandy_, Anssi_Kostiainen, Arno Mandy, Eric_Mcobobia, Hazel, Heejin_Chung, Intel Corporation, James_Hollyer, JamesH, Kenneth_Christiansen, Lars_Knudsen, marcosc, Mark_Foltz, Matt_Reynolds, Peter Burrows, Peter_Burrows, Philippe_Le_Hageret, plh, rakuco, reillyg, Satotu_Takagi, scheib, Takio_Yamaoka, tomayac, Tomoaki_Mizushima, xfq, Zoltan_Kis, Laura_Morinigo, Lukasz_Olejnik
05:13:24 <reillyg> TOPIC: Introductions
05:13:38 <sangwhan> present+ Sangwhan_Moon
05:13:47 <anssik> RRSAgent, draft minutes v2
05:13:47 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html anssik
05:14:13 <reillyg> Sangwhan_Moon: TAG Invited Expert (@cynthia on GitHub)
05:14:38 <JamesH_> JamesH_ has joined #dap
05:14:49 <JamesH_> present+
05:15:03 <reillyg> TOPIC: Agenda Bashing
05:15:16 <anssik> https://github.com/w3c/devicesensors-wg/issues/31
05:15:18 <reillyg> -> https://github.com/w3c/devicesensors-wg/issues/31
05:16:36 <reillyg> RG: Shuffle privacy discussions first and then follow with the technical topics which fell off of the agenda from yesterday.
05:16:49 <reillyg> AK: Move WebHID first since it has the most concrete discussion to be had.
05:17:34 <reillyg> Lukasz: I have a specific privacy concern to discuss as well.
05:18:47 <Eric> Eric has joined #dap
05:19:37 <reillyg> ... The Network Information API seems like a type of sensor which has privacy concerns beyond what is discussed in the Generic Sensors API.
05:22:06 <tomayac> q+ To ask about ALS
05:24:34 <anssik> RRSAgent, draft minutes v2
05:24:34 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html anssik
05:24:37 <anssik> q?
05:24:57 <anssik> q?
05:25:01 <anssik> ack tomayac
05:25:01 <Zakim> tomayac, you wanted to ask about ALS
05:25:19 <sangwhan> ALS = Ambient Light Sensor
05:25:20 <reillyg> TS: I would like to discuss ALS. Where are we today?
05:25:38 <reillyg> s/ALS/Ambient Light Sensor/
05:26:03 <larsgk> q+ Should we spend a few minutes discussing what are *not* actual privacy issues - but gets a lot of FUD in media/twitter?
05:26:08 <anssik> q?
05:26:18 <larsgk> q+ Should we spend a few minutes discussing what are *not* actual privacy issues but gets a lot of FUD in media/twitter?
05:26:48 <lmorinigo> lmorinigo has joined #dap
05:27:26 <lukasz> present+
05:27:37 <lmorinigo> present+
05:27:42 <Peter_Burrows> Peter_Burrows has joined #dap
05:27:54 <reillyg> larsgk: Can we discuss non-goals for addressing privacy concerns as these APIs often collect a lot of FUD arguments.
05:28:51 <reillyg> AK: Historically this group started with a much broader and non-browser view of these APIs which didn't focus on privacy and that has given us a bad reputation.
05:29:10 <reillyg> MC: 2012 was a different time. We didn't have the permissions models we do today.
05:29:33 <reillyg> AK: It's not easy to fight the fake news. Let's stay professional and stick to the data.
05:30:41 <reillyg> RG: I think we need to apply common patterns to avoid re-litigating discussions for each API.
05:31:20 <anssik> q?
05:31:25 <reillyg> AK: We should liaise with the PING and we thank Lukazs for being here today.
05:31:37 <reillyg> TOPIC: Privacy Discussion: WebHID
05:32:17 <reillyg> MR: WebHID is the API for accessing human interface devices.
05:32:23 <reillyg> ... It is shaped very similarly to WebUSB.
05:32:44 <anssik> -> https://wicg.github.io/webhid/ WebHID API spec
05:32:45 <reillyg> ... human interface devices are typically USB or Bluetooth but are excluded from WebUSB and Web Bluetooth.
05:33:14 <reillyg> ... Keyboards and mice are excluded from WebHID because they are already covered by existing APIs and allowing low-level access would allow for keyloggers and such.
05:33:57 <reillyg> ... Sangwhan raised concerns during the TAG review over the read/write capabilities of the API and the shared access model.
05:34:27 <reillyg> ... The HID protocol allows devices to declare the data they provide in a standardized format. This provides high entropy.
05:34:43 <reillyg> ... Devices may also provide access to data (i.e. serial numbers) which would provide high entropy.
05:34:59 <reillyg> ... The API does not directly provide access to this data.
05:35:01 <anssik> RRSAgent, draft minutes v2
05:35:01 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html anssik
05:35:02 <anssik> q?
05:35:51 <reillyg> ... Another concern, the API could be used to change the behavior of the device to cause malicious behavior towards the user or the host the device is connected to.
05:36:46 <reillyg> MS: Any device which allows writing can be used as a side channel and that breaks the same origin model.
05:37:11 <anssik> q?
05:37:12 <reillyg> ... No ideas for how to mitigate this. Read-only or exclusive access only get you so far.
05:37:47 <reillyg> MR: Existing strategy is providing a blocklist to deny access to known vulnerable devices and to block access to data that looks like keyboard or mouse input.
05:38:03 <reillyg> ... We are building an intake for vendors to propose new blocking rules for their devices.
05:38:29 <reillyg> ... WebUSB and Web Bluetooth have similar blocklists. HID may be more granular than USB because of the report info.
05:38:43 <anssik> Present+ Keiko_Itakura
05:39:06 <reillyg> Lukasz: Why a blocklist instead of an allowlist?
05:39:07 <scheib> q+
05:39:13 <anssik> q?
05:39:30 <reillyg> MR: There is a long tail of devices. An allowlist couldn't cover enough devices to make the API broadly useful.
05:39:56 <reillyg> MS: Usages to block is being communicated directly to the browser vendors?
05:39:58 <reillyg> MR: Yes.
05:40:47 <reillyg> Lukasz: A blocklist could create a bad impression.
05:40:48 <anssik> ack scheib
05:41:45 <reillyg> VS: Regarding allow- vs. block-lists. We explored this for WebUSB. That API originally chose an allow-list approach and the community saw many downsides and not many upsides.
05:42:02 <anssik> RRSAgent, draft minutes v2
05:42:02 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html anssik
05:42:04 <sangwhan> q+ to ask about how to make the deny-allow list consistently applied across implementations
05:42:39 <lukasz> q+ to ask about user interface
05:42:44 <anssik> q?
05:42:53 <reillyg> q+
05:43:45 <tomayac> I think that's the Medium article @scheib was referring to: https://medium.com/dev-channel/the-webusb-security-model-f48ee04de0ab.
05:44:03 <reillyg> VS: Regarding same-origin policy, APIs such as file access already "violate" the policy and users understand that this violates the model by allowing data to be transmitted between sites if chosen by the user.
05:44:07 <tomayac> scribenick: tomayac
05:44:22 <anssik> q?
05:44:58 <tomayac> scheib: It's hard to take over a device, there's a picker model, and one that would have to be overcome for multiple origins.
05:45:33 <tomayac> We're solving a computing need on the web, instead of on the native platform, which would be more dangerous.
05:45:36 <anssik> ack sangwhan
05:45:36 <Zakim> sangwhan, you wanted to ask about how to make the deny-allow list consistently applied across implementations
05:46:00 <tomayac> sangwhan: Would like to know if there's a path forward to make the blocklists and blocked messages shareable across implementations?
05:46:21 <tomayac> reillyg: The block list is part of the repo
05:46:27 <tomayac> It's the plan to share this
05:46:32 <anssik> q?
05:46:36 <anssik> ack lukasz
05:46:36 <Zakim> lukasz, you wanted to ask about user interface
05:46:37 <tomayac> sangwhan: Sounds reasonable
05:46:53 <tomayac> lukasz I see that the spec is very closely related to WebUSB
05:47:10 <tomayac> I wonder how the process of connecting to the device look like?
05:47:13 <tomayac> A picker?
05:47:46 <tomayac> For hubs(?) you would need to reassure a better reception
05:48:02 <tomayac> Does the spec define the UI
05:48:21 <tomayac> ...improve the reputation
05:48:42 <tomayac> mattreynolds The current implementation uses the same picker model
05:48:51 <JamesH_> q+
05:48:59 <tomayac> ...We can probably take some lessons from WebUSB and apply them
05:49:07 <larsgk> q+
05:49:08 <anssik> q?
05:49:17 <anssik> ack reillyg
05:49:49 <sangwhan> q+ to ask if exclusive access can be mandated by the spec
05:50:02 <tomayac> reillyg: The SOP aspect of this and the existenmce of the picker model brings this out of the SOP, it's the user bringing the decvice to the page and making it interact with it.
05:50:15 <sangwhan> s/existenmce/existence/
05:50:27 <sangwhan> s/decvice/device/
05:51:00 <tomayac> ...in terms of bringing in WebUSB lessons, the article that I wrote, I spec'ed browsers should announce to the browser that there is a device that accompanies it
05:51:13 <tomayac> ...so sort of bringing the SOP to this
05:51:39 <tomayac> ...even for device vendors interested in this, they were reluctant, since updating devices in the field is hard
05:51:47 <tomayac> ...so it was hard to make progress
05:52:03 <anssik> q?
05:52:04 <tomayac> ...therefore we came up with vendors registering in the allowlist
05:52:14 <tomayac> ...we are reasonable comfortable to accept blocklists
05:52:30 <tomayac> ...like this device gives everyone access to your bitcoin
05:52:43 <tomayac> ...we need to validate that the site owns a device
05:53:01 <tomayac> ...the third aspect was (feedback from Mozilla or marcosc)
05:53:11 <tomayac> ...it runs counter to open development and innovation
05:53:23 <tomayac> ...once the vendor goes out of business, the device is lsot
05:53:32 <tomayac> ...so we moved to another model.
05:53:42 <tomayac> ...(see my article)
05:53:54 <tomayac> ...Web Bluetooth didn't have this at the time
05:54:09 <tomayac> ...so I felt bad about it for a while for Web Bluetooth being less secure
05:54:13 <tomayac> ...but I was wrong
05:54:23 <tomayac> ...The change was difficult to make.
05:54:35 <tomayac> ...since we opened ourselves to more vectors of attack
05:54:46 <tomayac> ...Can the user make security decisions with a picker
05:55:04 <tomayac> ...that's why we still have the blocklist and a way to inform other vendors of this list
05:55:12 <tomayac> ...we also have security key tokens
05:55:30 <anssik> q?
05:55:38 <tomayac> ...but that attack was never used in the wild, but a security researcher found it and reported it
05:55:49 <anssik> q?
05:55:55 <tomayac> ...but there are, apart from the security keys, no other devices on the block list.
05:55:57 <anssik> ack JamesH_
05:56:09 <tomayac> JamesH: I like what reillyg said
05:56:27 <tomayac> ...There should be something in the spec saying that there should be a picker
05:56:40 <lukasz> q+ to ask about user awareness and  intentionally malicious devices
05:56:44 <tomayac> ...sounds like lukasz would be a good person to do this
05:56:49 <anssik> q?
05:57:00 <tomayac> ...I feel like that this is the case, but I don't have data
05:57:11 <anssik> ack lukasz
05:57:11 <Zakim> lukasz, you wanted to ask about user awareness and  intentionally malicious devices
05:57:35 <tomayac> anssik: lukasz, do you have research on pickers?
05:57:48 <tomayac> lukasz: Thanks for the explanations, reillyg.
05:58:04 <tomayac> ...sorry for disrupting this a bit. We all have pickers and SOP.
05:58:17 <tomayac> ...It's unclear if users understand SOP.
05:58:29 <tomayac> ...It should be designed well from the ground up.
05:59:08 <tomayac> ...Did you consider, as another attack scenario, malicious devices being distributed to users, like thousands, that advertise a software that makes browsing bank sites more secure
05:59:22 <tomayac> ...when users connect such a device, unlikely, but let's assume.
05:59:46 <tomayac> ...Can we assume users will understand the risk.
06:00:04 <anssik> q?
06:00:04 <tomayac> ...So maybe allowlists would be better suited.
06:00:35 <tomayac> reillyg: The attacks that we consider are attacks by a site on a device causes it to be malicious on its own
06:00:52 <tomayac> ...for example, a site takes a device and pokes the user in the eye
06:01:03 <tomayac> ...if the user can be convinced to connect a device
06:01:18 <tomayac> ...that device already can do a looot of things without the browser
06:01:41 <tomayac> ...The distribution of such a device doesn't change the attack vector from a UA point of view
06:01:43 <anssik> q?
06:02:00 <tomayac> lukasz: HID and Web USB would not change anything?
06:02:04 <tomayac> reillyg: Correct
06:02:12 <tomayac> lukasz: Would not make anything easier?
06:02:15 <tomayac> reillyg: No
06:02:30 <tomayac> anssik: Wanted to come back on picker UI research?
06:02:46 <tomayac> anssik: It's the same model as used by file pickers
06:03:17 <tomayac> marcosc: It's context driven for files
06:03:29 <tomayac> ...So pickers are closely connected mentally
06:03:35 <tomayac> ...unlike with device pickers
06:03:55 <tomayac> ...it becomes ridiculous to ask for research on the research
06:04:06 <tomayac> anssik: otherwise it becomes opinion
06:04:08 <anssik> q?
06:04:25 <tomayac> marcosc: W eknow the attacks take place. If something hasn't been hacked today means it'll be hacked tomorrow
06:04:41 <tomayac> ...plugging in things that were never designed for the web is dangerous
06:04:55 <tomayac> ...like raw sockets, if you connect a random printer it could do bad things
06:05:02 <tomayac> ...we've seen those attacks
06:05:25 <tomayac> ...concrete example: the US attacking Iranian centrifuges over USB
06:05:31 <tomayac> ...These cases exist
06:05:33 <anssik> ack larsgk
06:05:49 <tomayac> larsgk: Huge Web USB and WebHID fan
06:06:06 <tomayac> ....WebHID can connect to Corsair keyboards
06:06:21 <scheib> Related article from a Chrome security member discussing permissions https://emilymstark.com/2020/07/14/debunking-the-users-always-click-yes-myth.html
06:06:21 <anssik> q?
06:06:25 <tomayac> ...I can store colors, right. There's a chance someone may not understand this.
06:06:48 <tomayac> ...we can consider if it makes sense to use a token based model, even if it means extra work
06:07:01 <tomayac> anssi: Let's flush the queue
06:07:01 <anssik> ack sangwhan
06:07:01 <Zakim> sangwhan, you wanted to ask if exclusive access can be mandated by the spec
06:07:36 <JamesH_> qq+
06:07:37 <tomayac> sangwhan Question plus suggestion: the current spec allows multiple origins to access. Is there a particular use case when you designed it this way? Could it be restricted to a single tab?
06:08:03 <tomayac> mattreynolds Would be possible, but might make the API harder
06:08:40 <tomayac> ...The use cases for multiple tabs were: you might want to draw a picture of gamepad interaction in different tabs. Streamers use this to show gamepad state while playing
06:08:55 <tomayac> ...Or lights used as a notification from multiple sources
06:08:55 <anssik> q?
06:09:14 <anssik> ack JamesH_
06:09:14 <Zakim> JamesH_, you wanted to react to sangwhan
06:09:44 <anssik> q?
06:09:49 <tomayac> JamesH: Espruino devices have a serial port. I connect to it from different tabs. One for flashing, one for interacting with the flashed code. Doesn't work for Web USB
06:10:00 <tomayac> sangwhan This are same origins?
06:10:18 <tomayac> mattreynolds Not necessarily. Could be stadia.com and gamepadviewer.com
06:10:31 <tomayac> anssik: We're getting close to the break. Resolutiuon?
06:10:57 <tomayac> reillyg: The concerns I'm hearing: general question of malicious devices
06:11:23 <tomayac> ...and I hear a concern about users understanding the impact of connecting devices, with SOP, but also general trust
06:11:33 <tomayac> ...we covered allow and block lists
06:11:44 <tomayac> ...We discussed this and answered questions
06:11:58 <tomayac> anssik: User studies would be much welcome
06:12:09 <tomayac> ...Does Google have resources?
06:12:17 <tomayac> reillyg: We've studied permissions in general
06:12:31 <tomayac> ...our experience with these APIs has been limited enough.
06:12:52 <tomayac> ...we're seeing developers build interesting things. But not enough to require a deep study
06:13:08 <tomayac> anssik We have some university members in the group who are interested
06:13:21 <tomayac> ...maryam (?) and (?name)
06:13:39 <tomayac> JamesH: We have a note about using the picker
06:13:59 <tomayac> reillyg: The spec provides some language to use about the question to ask
06:14:24 <tomayac> anssik: Can you formulate a resolution?
06:14:36 <anssik> s/maryam/Maryam Mehrnezhad
06:14:41 <tomayac> reillyg Want to make sure this is productive for sangwhan and help the TAG.
06:14:50 <scheib> q
06:14:51 <anssik> s/name/Ehsan Toreini
06:14:55 <anssik> q?
06:14:58 <tomayac> sangwhan: I have to ask other questions through GitHub. Thanks!
06:15:31 <tomayac> scheib: There's enough appreciation for raising concerns. But also important to understand what it takes for a user to get a task done.
06:16:01 <tomayac> ...Our goal is to make the interaction easy. We know users happily install high priviilege software.
06:16:09 <anssik> RRSAgent, draft minutes v2
06:16:09 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html anssik
06:16:23 <tomayac> ...Web Bluetooth and WebHID lower this risk, but are still somewaht risky.
06:16:34 <anssik> q?
06:16:39 <tomayac> ...Definitely more secure than installing native programs
06:16:52 <tomayac> ...of larger range of permission and of longer time. Need to find a balance.
06:17:00 <tomayac> anssik: Let's break with this.
06:17:05 <tomayac> [break]
06:19:13 <reillyg6> reillyg6 has joined #dap
06:31:28 <anssik> scribenick: Anssi
06:32:01 <anssik> Topic: Privacy Discussion: Ambient Light Sensor
06:32:48 <anssik> reillyg: the ALS API looks for more interest to move forward
06:33:24 <anssik> ... in Chromium we implemented mitigation to too much data exposed limiting the brightness interval to 50 lux, so can defer whether the user is in a dark room or a light room
06:33:46 <anssik> ... use cases include identifying is the conditions are good for taking a photo etc.
06:33:59 <tomayac> Another use case is the maps one: you drive through a tunnel during the day, and the map would switch to dark mode temporarily
06:34:24 <anssik> ... in the context of Orientation Sensor we discussed data precision and fingerprinting last year
06:35:02 <anssik> ... Chromium implements mitigations for that spec, bugs filed for Firefox and not sure what is the Safari's status
06:35:29 <anssik> ... reason for not shipping yet is not enough people asking for it to make a decision to ship -- the current state is good, we could ship it as is
06:36:02 <anssik> ... use cases for ALS with camera may need more precise readings, maybe we can provide more precision if camera permission granted alongside
06:36:44 <anssik> -> https://bugs.chromium.org/p/chromium/issues/detail?id=606766 ALS crbug
06:37:01 <marcosc> maybe: https://bugzilla.mozilla.org/show_bug.cgi?id=1057185 bugzilla bug?
06:37:33 <anssik> anssik: what could be done to help this API ship?
06:37:45 <lukasz> I wrote a small assessment of the ambient light sensors privacy design https://blog.lukaszolejnik.com/shedding-light-on-designing-web-features-with-privacy-risks-impact-assessments-case-study/ including with a paper (linked inside)
06:37:55 <lauram> lauram has joined #dap
06:37:57 <lukasz> (if anyone finds this of interest)
06:38:14 <anssik> reillyg: the API is available behind a flag and when developers have increased interest in it, we look into shipping
06:38:16 <marcosc> q+
06:38:24 <anssik> ack marcosc
06:38:52 <anssik> marcosc: reillyg mentioned use cases, given the current state of the world and how the cameras are used in the world
06:39:13 <tomayac> I don't see an origin trial for ALS.
06:39:27 <anssik> ... on the iPhone you can adjust the brightness when taking the picture?
06:40:11 <anssik> reillyg: clarifying the use case, developer to get absolute signal for exposure so instructions can be provided to the user "please turn on the light" or "go outside"
06:40:30 <anssik> ... there's another use case to do facial recognition and use ALS to assist the user to fix lightning conditions
06:40:33 <anssik> q?
06:40:57 <kenchris> kenchris has joined #dap
06:40:57 <anssik> tomayac: another use case, drive through tunnel and it becomes dark, when you leave the tunnel switch back
06:40:59 <anssik> q?
06:41:00 <larsgk> q+
06:41:10 <anssik> ... this should a reasonable use case
06:41:19 <marcosc> q+ to say, darkmode is OS controlled
06:41:28 <anssik> ... discussion on prefers color scheme etc. but this is a temporary situation
06:41:44 <anssik> reillyg: ambient light level signal could be exposed through CSS to complement the API
06:41:48 <anssik> q?
06:42:00 <xfq> https://github.com/w3c/csswg-drafts/issues/5359
06:43:00 <anssik> Anssi: there are use cases for having both JS API and CSS feature for ALS
06:43:23 <anssik> tomayac: there are some customer requests for ALS
06:43:42 <anssik> Rafael: iProof company is very interested in this API
06:43:51 <rakuco> s/Rafael/Raphael/
06:43:54 <rakuco> s/iProof/iProov/
06:44:15 <anssik> reillyg: as with the dark more, there's a bit of developer trendiness issue, if we make light level reactive sites trending more sites might take advantage of this
06:44:16 <anssik> q?
06:44:25 <anssik> ack larsgk
06:45:00 <anssik> Lars: we have a very concrete need for this with shipping, avoiding the people to get blinded using ALS
06:45:08 <anssik> q?
06:45:46 <marcosc> We ack Mandy Michael's demo https://www.youtube.com/watch?v=ivz1hdAhJmE&ab_channel=MandyMichael
06:45:57 <anssik> reillyg: there's a question how reactive this API should be, there's signal from the environment (what's the lightning like) and from the user (use dark mode)
06:46:14 <sangwhan> s/lightning/lighting/
06:46:25 <anssik> q?
06:46:26 <anssik> ack marcosc
06:46:26 <Zakim> marcosc, you wanted to say, darkmode is OS controlled
06:46:56 <anssik> marcosc: dark more being both OS and user controlled is important
06:47:16 <anssik> ... on macOS it switched dark mode based on sunset
06:47:26 <anssik> ... it is about the balance
06:47:31 <anssik> q?
06:47:46 <tomayac> Two nice demos: https://codepen.io/arnofiva/pen/VJjxRZ and https://variablefonts.dev/posts/light-sensor-demo/
06:48:21 <anssik> -> https://w3c.github.io/ambient-light/#usecases-requirements ALS use cases
06:52:04 <anssik> -> https://w3c.github.io/ambient-light/#security-and-privacy ALS Security and Privacy consideration
06:52:27 <marcosc> relevant gecko bugs https://bugzilla.mozilla.org/show_bug.cgi?id=1359076 - AmbientSensor was removed from Gecko
06:52:40 <anssik> sangwhan: curious if the 50 lux stepping should be tracked in a GH issue to make it normative
06:53:49 <marcosc> q+ to say, should we consider implementer interest?
06:54:02 <anssik> ack marcosc
06:54:02 <Zakim> marcosc, you wanted to say, should we consider implementer interest?
06:54:06 <lukasz> q+ normative aspects of 50 lux recommendation
06:54:24 <sangwhan> q?
06:54:30 <lukasz> q+ to say about normative aspects of 50 lux recommendation
06:54:48 <anssik> reillyg: we set developer interest first, implementer interest second
06:56:39 <larsgk> q+ are enterprises counted as 1 developer? (dev need counting)
06:57:15 <anssik> q?
06:57:50 <xfq> q+ larsgk
06:57:58 <anssik> q?
06:59:48 <anssik> q?
06:59:57 <anssik> ack lukasz
06:59:57 <Zakim> lukasz, you wanted to say about normative aspects of 50 lux recommendation
07:00:06 <marcosc> MC: agree with everything reillyg said
07:00:57 <anssik> Lukasz: perhaps 50 lux cap should be specified in a way it is normative, but just want to point out it might be a rare example security and privacy consideration become normative?
07:01:29 <anssik> q?
07:01:33 <anssik> ack larsgk
07:01:49 <sangwhan> rrsagent, draft minutes
07:01:49 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html sangwhan
07:02:30 <anssik> Lars: traditional enterprises migrate tools to the web, it is dangerous if browser vendors only consider vocal developers who are well known, new domains do not have as strong voices in the process of making standards
07:03:06 <anssik> reillyg: with Thomas we talk to many enterprise developers so we're aware of this, we agree with you that enterprises do work more behind closed doors
07:05:35 <reillyg> +1
07:05:39 <anssik> RESOLUTION: Continue monitoring ALS API developer interest. Encourage developers the experiment with existing prototypes.
07:06:16 <anssik> s/RESOLUTION: Continue monitoring ALS API developer interest. Encourage developers the experiment with existing prototypes.//
07:07:15 <tomayac> +1
07:07:21 <anssik> RESOLUTION: Continue monitoring ALS API developer interest and work with more browser vendors. Encourage developers to experiment with existing prototypes.
07:07:28 <anssik> RRSAgent, draft minutes v2
07:07:28 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html anssik
07:08:05 <anssik> Topic: Privacy Discussion: Network Information API
07:08:43 <anssik> -> https://lists.w3.org/Archives/Public/public-device-apis/2020Oct/0004.html DAS WG and Web Perf WG collaboration opportunity
07:08:55 <anssik> reillyg: when you raised this topic you mentioned couple of topics
07:10:04 <anssik> ... all the fields in the current proposed spec, as resolved yesterday, we are interested in collaboration with Web Perf WG on aspects that have to do with the signal about saving data or metered connection info
07:10:21 <anssik> ... other signals may provide more info than the site needs or poorly specified
07:10:47 <anssik> ... looking at the current users of the API, we ask, what those more problematic fields in the API are and could they be deprecated?
07:11:06 <anssik> ... moving forward we'd focus on this privacy-preserving subset and better specify other parts of the API
07:11:08 <anssik> q?
07:11:21 <xfq> The Web & Networks Interest Group is also exploring this topic: https://www.w3.org/wiki/Network_Quality_Monitoring_and_Prediction
07:11:40 <anssik> -> https://www.w3.org/2020/10/22-dap-minutes.html#t04 DAS WG F2F Day 1 minutes
07:12:37 <lukasz> +q to ask about aptness of generic sensors considerations as applied to NIA
07:13:16 <anssik> Lukasz: ack lukasz
07:15:22 <anssik> Lukasz: the actual API differs from the other specifications in this group, it is unclear if the Generic Sensors considerations could be casted on the Netinfo API
07:15:44 <anssik> -> https://w3c.github.io/sensors/#security-and-privacy Generic Sensor API S&P Considerations
07:16:09 <anssik> Lukasz: when the user is roaming, you expect these changes to happen often, an event might fire quite often(?)
07:16:15 <anssik> ... could allow profiling the user
07:16:37 <anssik> ... re RTT, I don't fully understand the semantics, is it RTT of the base station?
07:16:43 <anssik> q?
07:16:47 <anssik> ack lukasz
07:16:47 <Zakim> lukasz, you wanted to ask about aptness of generic sensors considerations as applied to NIA
07:17:36 <anssik> -> https://wicg.github.io/netinfo/#rtt-attribute RTT attribute
07:17:49 <anssik> reillyg: RTT might not survive the refactor of the spec
07:18:05 <anssik> ... marcos feedback was that Firefox has difficulty in implementing RTT
07:18:13 <marcosc> MC: nit, EffectiveConnectionType is hard
07:18:26 <anssik> s/RTT/EffectiveConnectionType
07:19:07 <anssik> reillyg: we're reduce the spec to "save data" and "on metered connection" signals
07:19:19 <anssik> Lukasz: is there a way to get rid of the RTT
07:19:47 <marcosc> q+
07:19:57 <marcosc> q-
07:19:59 <anssik> Lukasz: maybe too premature to assess privacy of this API at this point?
07:20:18 <anssik> reillyg: privacy experts should engaged when we possibly refactor this spec
07:20:24 <anssik> s/should/should be
07:21:01 <anssik> q?
07:21:19 <anssik> marcos: without interest, it likely won't be edited
07:21:44 <anssik> ... these issues are in the Netinfo API tracker on GH, I'm not expecting any work to happen unless DAS WG wants to take this work on
07:22:47 <anssik> q?
07:23:01 <anssik> sangwhan: curious how this ties into the network goodness hints that WebRTC has, and also hints one can pull out of adaptive streaming (e.g. DASH) - feels like there are three places where this information can be retrieved, all probably in different formats
07:23:52 <anssik> reillyg: that level of information is in WebRTC and should stay there and we don't want to duplicate that in the context of the Netinfo API
07:24:35 <anssik> sangwhan: I'm interesting in non-WebRTC use cases then?
07:24:55 <anssik> reillyg: use case is for the user to express to the site the user is on metered connection
07:25:05 <anssik> ... this is about expressing a preference for low data usage
07:25:29 <anssik> ... the use cases have not been updated as the scope of the API shifted
07:25:33 <sangwhan> So summarized - the "I'm not on wifi" API
07:25:50 <anssik> ... the first order biz would be to update the use cases  to match the revised scope
07:27:09 <anssik> reillyg: the proposed refactor of the Netinfo API is to provide a signal "I'm on WiFi that is free and unlimited"
07:27:36 <anssik> RRSAgent, draft minutes v2
07:27:36 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html anssik
07:29:26 <tomayac> +1
07:29:37 <sangwhan> +1
07:29:45 <tomayac> +1
07:29:52 <lukasz> +1
07:30:09 <lukasz> (I've already provided some preliminary points)
07:32:32 <anssik> RESOLUTION: Engage with privacy experts in the proposed refactor of the Network Information API, figure out coordination between DAS, WebPerf, and WICG; and possible standards track adoption at a later stage
07:32:54 <anssik> RRSAgent, draft minutes v2
07:32:54 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html anssik
07:33:17 <anssik> Topic: Test automation
07:33:24 <tomayac> scribenick: tomayac
07:33:55 <tomayac> reillyg: There was a question raised on specifying test automation
07:34:03 <tomayac> ...one was to use webdriver
07:34:32 <tomayac> ...the other was take the approach of Web XR to make a full Web API available for testing purposes.
07:34:42 <tomayac> ...I have opinions.
07:35:12 <tomayac> ...There are two audiences: 1: us as web platform community. This audience is interested in testing if the impl is correct.
07:35:34 <tomayac> 2: web developers, who are interested if their sites work correctly.
07:35:46 <tomayac> ...sometimes these interests align, sometimes not.
07:36:24 <tomayac> ...If there is a sensor that is expressing a certain value, implementors want to make sure it goes through correctly.
07:36:37 <tomayac> ...whereas developers just want to know if their site behaves correctly.
07:36:56 <tomayac> ...The Web USB testing API is capable of emulating certain device conditions and signals.
07:37:08 <tomayac> ...If you're a developer writing a site, you might not need much of this infra.
07:37:19 <tomayac> ...You can just mock out the entire browser APIs.
07:37:33 <anssik> RRSAgent, draft minutes v2
07:37:33 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html anssik
07:37:38 <tomayac> ...You can test if your site behaves properly, maybe even outside of the browser through unit tests.
07:37:47 <tomayac> ...Browser automation is different.
07:38:01 <tomayac> ...You probably want to loop in real devices, and detect the presence of devices.
07:38:16 <tomayac> ...Without any kind of permission UI so it can be scripted.
07:38:34 <tomayac> ...Implementors care about pretending devices.
07:38:58 <tomayac> ...When we define webdriver extensions, it's the thing developers use when they need a browser involved.
07:39:09 <tomayac>  ...Those are the kinds of things I'd need to consider.
07:39:41 <tomayac> ...Defining a test-only API targeted to web platform tests, and another targeted to developers: both might make sense.
07:39:52 <tomayac> ...This would be orthogonal to the existing testing API.
07:40:34 <tomayac> ...To a certain degree none of this matters, the goal is to provide an automation API, if it's shaped like web driver or something else, no matter
07:40:41 <tomayac> ...People can use it either way
07:40:52 <marcosc> q+
07:41:13 <tomayac> marcosc: Just wanted to say that's great. But need to balance the resources of the WG.
07:41:31 <tomayac> ...If it doesn't serve the purpose of interop, I'm not sure it should be focus of the group.
07:42:05 <tomayac> ...Sending the permissions API through webdriver might make sense, but, striking that balance is additional work.
07:42:16 <tomayac> reillyg: Maybe I misunderstand you.
07:42:39 <tomayac> ...Disagree. Developer infra is important for interop
07:42:53 <tomayac> ...If we have a way for developers to test at all, it should be interoperable.
07:43:03 <tomayac> ...There is a W3C group that owns that
07:43:11 <tomayac> It's good for developers to have them.
07:43:21 <tomayac> marcosc: My question is if _we_ design those
07:43:31 <tomayac> ...Or working with another community.
07:43:48 <tomayac> ...Like "click this button", etc. (describes the flow)
07:43:59 <tomayac> reillyg: If you want it done, you gotta do it yourself
07:44:17 <tomayac> ...I got a lot of stars on the bugs for adding it
07:44:42 <tomayac> The question is: should it be a default, so all specs need to come with one. Or write it later when developers ask for it?
07:44:59 <tomayac> marcosc: Agree. Then the question becomes to which APIs we add this.
07:45:15 <tomayac> ...If there's a strong case coming from developers if it would help, we should add it.
07:45:32 <tomayac> reillyg: Ironically currently there is just an ad-hoc testing impl.
07:45:52 <tomayac> ...The interesting thing is that we have refactored the entire architecture of the device orientation API.
07:46:02 <tomayac> ...This uses the same infra as generic sensors.
07:46:18 <tomayac> ...But currently there are no WPT tests.
07:46:38 <tomayac> ...This raises the question how to, in an ionteroperable way, to express this.
07:47:06 <tomayac> scheib: I have a humble opinion when to do the impl work for the webdriver tests
07:47:38 <tomayac> ...It's faster to start early.
07:47:48 <tomayac> ...Sometimes there's churn in what we need.
07:47:55 <tomayac> ...There is an upfront cost.
07:48:45 <tomayac> reillyg: It's easier to say there's this API, rather than having certain endpoints APIs need to specify.
07:49:11 <tomayac> scheib: It priotizes to have implementeations of tests for multiple purposes.
07:49:32 <tomayac> reillyg: It took us forever to get testdriver.click. Why was that? It's ridiculous.
07:49:47 <tomayac> ...Someone maybe back in the 90ies should have thought about this.
07:50:34 <tomayac> marcosc: To reillyg's points> scheib said including tests as we specify tests
07:51:04 <tomayac> ...is hard
07:51:15 <tomayac> reillyg: Do we want to wrap up with a resolution?
07:51:19 <marcosc> MC: add tests as you specify
07:51:35 <tomayac> reillyg: Like webdriver not formally required
07:52:15 <tomayac> Rafael: reillyg's summary is a fair summary of the status quo
07:52:25 <tomayac> ...there is no conclusion either
07:52:35 <tomayac> ...there is interest in reaching a common ground.
07:52:54 <tomayac> ...It's hard to commit to a stable webdriver impl if your spec is in early stage
07:53:11 <anssik> RRSAgent, draft minutes v2
07:53:11 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html anssik
07:53:13 <tomayac> ...this should work with Web Bluetooth and -USB
07:53:25 <tomayac> reillyg: I complained last year in the testing WG that it's hard
07:53:48 <tomayac> reillyg It might make sense to start with something less formal, that then converges into something more formal.
07:53:57 <tomayac> ...Having webdriver hooks is a sign of a stable impl.
07:54:18 <xfq> s/Rafael/Raphael/
07:54:20 <tomayac> Raphael: Currently there is no process for moving to a formal model
07:54:50 <tomayac> reillyg: Yeah. There has been an effort, so these tests should work outside of the Chromium CI now.
07:55:18 <tomayac> ...At least documenting the APIs should be given. Just uploading the tests without docs wasn't good.
07:55:27 <tomayac> ...WebXR may have done a similar thing.
07:55:53 <tomayac> ...Maybe we want a policy: to have a certain amount of documentation that explains how it works and what the expectations are
07:56:07 <tomayac> anssik: I let reillyg converge on a resolution
07:56:33 <tomayac> reillyg: Starting with my initial idea: testing should be given. We have it in our charter
07:56:41 <tomayac> ...And we need to define a process
07:57:07 <tomayac> ...Webdriver tests. And what counts as a truly interoperable way?
07:57:41 <tomayac> Raphael: Is the goal to make spec writer do this?
07:58:02 <tomayac> marcosc: That's a good point. Wondering if we have the expertise to do this.
07:58:13 <tomayac> Raphael: At least as we did for generic sensors.
07:58:24 <tomayac> marcosc: Who did Generic Sensors?
07:58:36 <tomayac> Raphael: A colleague at Intel
07:58:53 <tomayac> anssik The specs are now back in WD stage
07:59:03 <tomayac> marcosc: If we have the know-how that is great
07:59:33 <tomayac> reillyg: This was my exact complaint. In my attempt, I searched around, and it was hard.
07:59:34 <anssik> -> https://w3c.github.io/sensors/#automation Generic Sensor API - Web Driver extensions
07:59:53 <tomayac> ...Maybe there is some more infra work that needs to be done.
08:00:03 <tomayac> ...Specifying a webdriver extension isn't that hard.
08:00:07 <anssik> -> https://w3c.github.io/ambient-light/#automation Ambient Light Sensor - Web Driver extensions
08:00:31 <tomayac> marcosc: If we have the resources to do this ourselves, that's great
08:00:41 <tomayac> anssik: Dropped a number of links
08:00:54 <tomayac> marcosc: The spec part is easy, the impl is harder in C++ etc.,
08:01:04 <tomayac> anssik: What reillyg said isn't documented
08:01:49 <tomayac> Raphael Have reached some experience with that. It's complicated, and in addition, one would also need to implement the driver and spec it with the WPT community. It's a lot of work.
08:02:24 <tomayac> reillyg This was my complaint. Was then told that it's not that hard by someone from Chromium.
08:02:37 <tomayac> Raphael: Talking about the WPT meeting?
08:02:47 <tomayac> reillyg Talking about the Testing and Tools meeting
08:02:57 <tomayac> reillyg: Talking about the proposed resolution
08:03:28 <marcosc> +1
08:03:29 <tomayac> +1
08:03:47 <reillyg> RESOLUTION: Developing tests in parallel to specifications is best practice. The WG should develop a policy on when to consider specifying Web Driver extensions and a policy for the level of formal specification of test-only APIs before they can be used in Web Platform Tests.
08:03:54 <xfq> +1
08:03:56 <anssik> RRSAgent, draft minutes v2
08:03:56 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html anssik
08:05:43 <tomayac> TOPIC: Adjourn
08:06:20 <anssik> scribenick: anssik
08:06:37 <marcosc> Eric: to join the group http://www.w3.org/2004/01/pp-impl/43696/join
08:06:50 <marcosc> s/Eric:/Eric,
08:07:04 <anssik> Anssi: Thank you all for participating! Thank you scribes, speakers, we'll follow up with possible another F2F in not so distant future.
08:07:17 <marcosc> 🎉🎉🎉
08:08:00 <marcosc> ah, thanks for reminding me
08:08:19 <anssik> RRSAgent, draft minutes v2
08:08:19 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-dap-minutes.html anssik
09:14:02 <xfq> xfq has joined #dap
09:41:40 <Zakim> Zakim has left #dap