04:04:07 RRSAgent has joined #das-charter 04:04:07 logging to https://www.w3.org/2020/09/01-das-charter-irc 04:04:17 present+ 04:04:22 present+ 04:04:40 marcosc_ has joined #das-charter 04:05:55 plh: mozilla has been pushing back on @@ due to security and privacy concerns 04:05:55 ... which we've been trying to address as much as possible 04:05:55 ... but not satifsy moz yet 04:05:55 ... is that a proper summary? 04:06:16 plh has joined #das-charter 04:06:32 marcos: @@ geolocation work 04:06:50 plh: other apis like proximity sensor etc. 04:07:15 marcosc_: css-based solutions for ambient light 04:07:28 ... like prefers-color-scheme 04:07:30 https://github.com/w3c/dap-charter/issues/100 04:07:32 ... better privacy 04:08:31 plh: no mention of use cases 04:08:37 ... only security & privacy 04:08:59 marcosc_: generic sensor is a rehash of the stuff we did 04:09:34 anssi: privacy and security researchers 04:09:50 ... state-of-the-art papers 04:10:31 ... maybe objector did not even read the security & privacy section of the specs 04:10:39 s/objector/the objector/ 04:11:10 marcosc_: mitigated by limit this to 20hz or something 04:11:24 ... does not as useful as the css-based solution 04:11:48 anssi: a number of use cases can not be solved by the css solution 04:12:17 ... css media feature did not make any progress 04:12:43 ... @@ rework 04:13:47 https://drafts.csswg.org/mediaqueries-5/#descdef-media-prefers-color-scheme 04:14:28 related issue: https://github.com/w3c/csswg-drafts/issues/5359 04:14:56 reilly: @@ 04:15:16 ... @@ for login and authentication purposes 04:15:32 ... i understand mozilla's concerns 04:16:03 ... my reaction is that we can solve it in a much aggressive way 04:16:18 ... i'd like to see we move forward with the charter as is 04:16:25 ... and come to better solutions 04:16:45 ... last TPAC marcos and I figured a lot of details in screen wake lock api and use cases 04:17:20 ... i'd like to have this wg as space where we can have those kinds of conversation 04:17:37 tantek: 4 categories 04:17:58 ... stuff we implemented and deliberatedly dropped 04:18:04 ... like battery status api 04:18:20 ... it's not in the user's interest 04:18:29 ... used in tracking scripts 04:18:41 ... we implemented it and find it harmful 04:18:50 ... and unimplemented it 04:19:28 reilly: the current ambient light sensor api is completely different from the one mozilla unshipped 04:19:47 ... turned into the generic sensor proposal 04:20:09 ... the existing design of the orientation sensor api @@ 04:20:22 ... I'll argument "yes and no" 04:21:19 anssi: the spec was reworked for privacy protection 04:22:01 ... the attack described by the paper was no longer effective 04:22:13 ... mozilla could have implemented the mitigation 04:22:25 ... rather than dropping the whole idea 04:22:42 ... we've been working on this for @@ years 04:23:37 rrsagent, make minutes v2 04:23:37 I have made the request to generate https://www.w3.org/2020/09/01-das-charter-minutes.html xfq 04:23:58 marcosc: I have to drop many of my own apis in these years 04:24:04 ... sysapps 04:24:11 ... and dap 04:24:33 ... we come to different conclusions, different approaches to achieve the same thing 04:25:03 ... the use cases may no longer relevant for the web itself 04:25:44 ... performance optimizations to switch the codecs is already possible 04:25:53 ... without battery status api 04:26:21 ... youtube widget may not use battery status for this use case 04:27:19 anssi: that's why we emphasized that the group will document use cases and requirements in the charter 04:27:58 anssik has joined #das-charter 04:28:01 plh: just because my battery is below 10% not mean I don't wan to watch the video in HD 04:28:09 s/wan to/want to/ 04:29:38 reilly: developers want something better than the default behavior 04:29:54 s/developers want/Zoom wants 04:29:55 ... i agree with problem-based approach 04:30:20 ... i'm probably the newest person here to standards work 04:30:44 ... if we need to complete redesign it in order to have it solve their problem 04:31:26 ... let's bring in the browser vendors and app developers and come up with something better 04:31:37 ... the goal of this meeting is to address the objections 04:32:02 ... leave it open to the possibilities @@ 04:32:44 tantek: refine the use case to redesign the solution 04:33:08 ... send the use cases to wing to incubate an alternative solution 04:33:28 anssik: i'd like to understand why WICG? 04:34:07 ... das is a focused place 04:34:18 ... we have built this community for the last 10 years 04:34:30 ... many specs are in CR 04:35:03 ... not particularly fond of the WICG approach 04:35:19 tantek: WICG is not the only solution for incubation 04:35:25 ... but it is our default 04:36:22 ... @@ 04:37:00 plh: several apis have been harmful to users a few times 04:37:43 tantek: we fundamentally have differences in perspectives 04:38:09 ... related to where do we actually put our implementations resources 04:38:27 ... in reality there's only two browser vendors participating in this WG 04:38:33 ... Google and Mozilla 04:38:46 anssik: Apple has implemented multiple specs in this group 04:39:02 ... they may have reasons not to participate in this group 04:39:40 tantek: we didn't list every deliverable in this group in the FO 04:39:58 ... we only list specs having sufficient reason to drop from the wg charter 04:40:17 marcosc: given resource constraints 04:40:36 ... we have things in the rec-track confusing developers 04:40:43 ... with no implementations 04:41:13 ... if no browsers are interested in implementing this at all then why do we put it on rec-track 04:41:29 ... @@ use cases 04:41:34 ... back to the WICG issue 04:41:47 ... 90% ideas in WICG will fail 04:42:05 ... but fail in good ways that we've had a whole bunch of specs 04:43:49 anssik: in process 2020 we have patent protection in CR 04:45:11 ... problematic from a culture perspective participants sometimes in CG sometimes in WG 04:45:37 marcosc: we have a W3C logo in the spec 04:45:41 ... and specStatus 04:46:17 tantek: longstanding problems in W3C, for 5+ years 04:46:24 s/problems/problem/ 04:47:01 ... miscommunication or misrepresentations of things that are not standards 04:48:19 ... the problem is not there's only one implementation, but there's only interest from one implementer 04:48:47 ... not try to pretend as if they keep advancing 04:49:20 ... until we get multiple implementers again we can pull them off CR 04:50:10 anssik: we can use can i use integration to show the history that firefox implemented the api before 04:50:22 s/can i use/caniuse 04:52:14 anssik: we implemented webdriver extensions for these apis to better test the hardware features 04:53:07 tantek: normally when we're doing WD development there are multiple implementers involved 04:53:44 xfq_ has joined #das-charter 04:54:50 tantek: WD not necessily means implementations, but means possibility of implementations 04:55:08 ... having them in /TR cheapens the value of /TR 04:56:27 ... for better or worse there were many thumb-ups in the GitHub issues I raised 04:56:47 plh: reilly said he's open to look back to the use cases and the goals 04:57:52 ... having two implementations seems impossible from today's conversation 04:58:06 ... for existing apis 04:58:28 s/for existing apis/for some of the current apis in the group/ 04:59:21 anssik: in the charter there's a note: 04:59:25 ... "To advance to Proposed Recommendation, each specification must have two independent implementations of all defined features, at least one of which is on a mobile device." 04:59:55 ... predicting the future is difficult 05:00:27 ... looking back in history i wouldn't have believed the FxOS story 05:01:26 tantek: not has to be true for all time 05:01:32 ... we can reevaluate every year 05:02:06 plh: sympathetic to we have a dedicated place to do this work just in this WG 05:02:19 ... this is my current sentiment on that 05:02:38 tantek: mozilla is not going to put resources in this area 05:02:47 ... at least in short term 05:02:55 ... we might reevaluate it every year 05:03:12 plh: think we've done as much as we can for today 05:03:19 ... thank you for participating 05:03:27 ... we'll keep thinking about it 05:03:44 ... hope to have a decision before TPAC 05:04:16 rrsagent, make minutes v2 05:04:16 I have made the request to generate https://www.w3.org/2020/09/01-das-charter-minutes.html xfq_ 05:24:53 xfq__ has joined #das-charter 05:40:56 xfq_ has joined #das-charter 06:21:26 xfq_ has joined #das-charter 07:01:02 xfq__ has joined #das-charter 07:18:20 xfq has joined #das-charter 07:18:41 rrsagent, make log public 07:18:47 rrsagent, make minutes v2 07:18:47 I have made the request to generate https://www.w3.org/2020/09/01-das-charter-minutes.html xfq 07:19:54 present+ marcos, reilly, anssik, plh 07:20:01 rrsagent, make minutes v2 07:20:01 I have made the request to generate https://www.w3.org/2020/09/01-das-charter-minutes.html xfq 07:47:52 xfq_ has joined #das-charter 08:01:58 xfq__ has joined #das-charter 08:17:03 xfq__ has joined #das-charter 09:33:08 Zakim has left #das-charter