14:09:45 <RRSAgent> RRSAgent has joined #webscreens
14:09:45 <RRSAgent> logging to https://www.w3.org/2022/09/16-webscreens-irc
14:09:47 <Zakim> Zakim has joined #webscreens
14:09:59 <tidoust> Meeting: Second Screen WG/CG - TPAC 2022
14:10:05 <tidoust> Chair: Anssi, Louay
14:10:10 <tidoust> Agenda: https://github.com/w3c/secondscreen-wg/issues/6
14:10:45 <tidoust> tidoust has changed the topic to: Second Screen WG/CG - TPAC 2022 - https://github.com/w3c/secondscreen-wg/issues/6
14:54:41 <amandy> amandy has joined #webscreens
14:58:46 <amandy> present+
14:59:08 <cpn> cpn has joined #webscreens
14:59:20 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
14:59:27 <mfoltzgoogle> Present+ Mark_Foltz
14:59:32 <tovep> tovep has joined #webscreens
14:59:59 <cpn> present+ Chris_Needham
15:00:27 <tovep> present+ Tove_Petersson
15:00:28 <mfoltzgoogle> Agenda: https://github.com/w3c/secondscreen-wg/issues/6
15:00:32 <rakuco> rakuco has joined #webscreens
15:01:15 <tidoust> present+ Francois_Daoust
15:01:42 <plh> plh has joined #webscreens
15:02:57 <tidoust> present+ Fangzhen_Song
15:03:08 <tidoust> present+ Louay_Bassbouss
15:03:27 <tidoust> present+ Raphael_Kubo_da_Costa
15:03:40 <tidoust> present+ Arno_Mandy
15:04:03 <plh> present+
15:05:15 <Louay> Louay has joined #webscreens
15:05:28 <tidoust> scribe: tidoust
15:05:30 <Louay> present+ Louay_Bassbouss
15:06:25 <tidoust> present+ Alexis_Menard, Firtz_Heiden
15:06:28 <anssik> Present+ Anssi_Kostiainen
15:07:12 <anssik> scribe+
15:07:21 <anssik> Topic: Welcome
15:07:57 <alexis_menard> alexis_menard has joined #webscreens
15:08:03 <tidoust> anssik: Welcome to TPAC 2022 meeting. Hybrid meeting, let's make it as good as it can be!
15:08:03 <alexis_menard> present+
15:08:10 <anssik> -> Health rules https://www.w3.org/2022/09/TPAC/health.html
15:08:21 <anssik> -> Code of Ethics and Professional Conduct https://www.w3.org/Consortium/cepc/
15:08:23 <christianliebel> christianliebel has joined #webscreens
15:08:42 <tidoust> ... [Anssi reminds participants about health rules and CEPC]
15:09:12 <tidoust> ... Type "q+" on IRC to put yourself on queue, "q-" to remove yourself from the queue
15:09:29 <ChrisLorenzo> ChrisLorenzo has joined #webscreens
15:09:34 <benmorss__> benmorss__ has joined #webscreens
15:09:48 <anssik> Subtopic: Introductions
15:10:05 <Fangzhen_Song> Fangzhen_Song has joined #webscreens
15:10:24 <jwaterman> jwaterman has joined #webscreens
15:10:29 <tidoust> anssik: Working for Intel. co-chair of the group.
15:10:51 <tidoust> benmorss__: Ben, working on Chromium with Mike.
15:10:59 <tidoust> present+ Ben_Morss
15:11:30 <tidoust> ericc: Eric Carlson from Apple. Engineer.
15:11:36 <tidoust> present+ Eric_Carlson
15:11:50 <tidoust> jwaterman: I'm James Waterman.
15:12:15 <tidoust> chrislemon: Working for Comcast, observing the meeting
15:12:34 <cpn> present+ Chris_Lemon
15:13:08 <tidoust> mfoltzgoogle: Mark Foltz, from Google. Engineer working on Chrome, second screen features and APIs.
15:13:39 <cpn> present+ Youenn_Fablet
15:13:40 <tidoust> plh: Philippe le Hégaret. W3C staff. I installed plenty of TVs for the meeting, not sure if that counts ;)
15:14:03 <tidoust> youennf: I'm Youenn Fablet, Apple, working on Webkit.
15:14:23 <tidoust> cpn: Chris Needham, BBC. Also co-chair of the Media WG and Media & Entertainment IG.
15:14:50 <plh> tovep, Google
15:15:10 <christianliebel> present+
15:15:13 <benmorss__> I'll also be going back and forth between a few meetings, but glad to be able to observe
15:16:02 <tidoust> alexis_menard: Intel. Interested in topics discussed here. Not actively contributing but want to make sure I'm up-to-date.
15:16:28 <tidoust> Arno: Same as Alexis. multi-screen Window placement APIs is typically of interest.
15:16:34 <tidoust> present+ Chris_Lorenzo
15:16:39 <eric-carlson> eric-carlson has joined #webscreens
15:16:55 <tidoust> ChrisLorenzo: Comcast. Interested in second screen scenarios, in particular with relation with TV.
15:17:06 <christianliebel> Christian Liebel from Thinktecture. I'm spectating and will switch back and forth between WICG and Second Screen today.
15:17:23 <tidoust> Fangzhen_Song: ByteDance for 2 years.
15:17:46 <tidoust> anssik: Welcome, I think Fangzhen joined the WG a week ago
15:18:11 <tidoust> tidoust: Francois Daoust, W3C, staff contact of the Second Screen WG
15:18:51 <tidoust> Fritz_Heiden: Fraunhofer. involved in CTA WAVE project. Extended the test runner. Looking at extending tests for the Remote Playback API.
15:19:17 <tidoust> Louay: Louay Bassbouss, also from Fraunhofer FOKUS. Co-chair of this group. We're supporting testing activities of this working group.
15:19:31 <tidoust> anssik: Louay has been a long term supporter and contributor of the group.
15:20:08 <tidoust> Raphael: Intel, same team as Anssi. Interested in tests in particular, so looking forward to e.g. discussion on testing with virtual displays.
15:20:44 <tidoust> mike: I'm Mike Wasserman. Google. Editor of the Multi-Screen Window Placement spec.
15:20:51 <tidoust> present+ Mike_Wasserman
15:21:02 <tidoust> anssik: We have a bigger team than I thought, thanks for joining!
15:21:52 <anssik> Subtopic: Patent Advisory Group report
15:22:40 <plh> present+ Christopher_Martin
15:22:49 <tidoust> anssik: Patent Advisory Group completed its work about one month ago, and issued a report that recommends that the WG continue to work on the Open Screen Protocol.
15:22:51 <anssik> -> Report from the Second Screen Working Group PAG
15:22:51 <anssik>  https://www.w3.org/2021/08/secondscreen-pag/report.html
15:23:03 <tidoust> ... If you're a technical contributor to the group, that's basically all you need to know.
15:23:05 <msw> msw has joined #webscreens
15:23:31 <tidoust> ... I'd like to thank all PAG contributors. We actually received contributions from outside this group which were impactful. Thank you to these people!
15:24:05 <anssik> q?
15:24:09 <anssik> q+
15:24:13 <tidoust> tidoust: Nothing to add. Report is public.
15:24:13 <anssik> ack anssik
15:24:17 <mfoltzgoogle> Q+
15:24:21 <anssik> ack mfoltzgoogle
15:24:39 <tidoust> mfoltzgoogle: Will the PAG continue to exist or will it be dissolved?
15:24:55 <youenn> youenn has joined #webscreens
15:25:01 <tidoust> anssik: The PAG was chartered for one and it delivered what it was supposed to deliver.
15:25:09 <tidoust> ... So it's closed. End of business.
15:25:27 <anssik> Topic: Virtual Display proposal
15:25:53 <tidoust> anssik: During our previous virtual meeting in June, we had an interesting discussing around virtual display concepts.
15:26:12 <tidoust> ... I haven't prepared any replay of my presentation then.
15:27:01 <jwaterman> Name Correction: Jason Waterman - Mozilla
15:27:08 <tidoust> ... Mike contacted me following this discussion and it turns out that the notion of virtual display is needed to test some of the APIs that we develop.
15:27:18 <msw> q+
15:27:56 <tidoust> Anssi: [showing slides presented during previous meeting]
15:28:40 <tidoust> ... Use case: sidecar where you're using your tablet screen on the side of your laptop.
15:29:10 <tidoust> ... A virtual display is a display instance without a physical connection to the graphics card, in other words a software representation of a physical display.
15:29:27 <tidoust> ... In June, we looked at UX consideration for integrating virtual displays into the web platform.
15:29:30 <benmorss> benmorss has joined #webscreens
15:29:51 <plh> --> https://anssiko.github.io/virtual-display/ Slides
15:29:54 <tidoust> ... We'd need to figure out display arrangement, how the user might choose the virtual display, how those could be created, etc.
15:30:00 <tidoust> ... We explored that last time.
15:30:27 <tidoust> ... Some UI screenshots from a couple of operating systems to setup one's multi-screen setup.
15:30:49 <tidoust> ... A popup window to pick-up a second screen.
15:31:06 <tidoust> ... A UI window from deskscreen. Very similar.
15:31:12 <tidoust> s/second screen/display source
15:31:49 <tidoust> anssik: We discussed how some of the APIs today are dealing with these concepts.
15:32:28 <tidoust> ... Example of a popup to give permission to a site to get info about screens to open and position windows.
15:32:45 <tidoust> ... Also OS prompts.
15:33:07 <tidoust> ... Not exactly consistent between browsers and OS. This might be a bit confusing for users.
15:33:42 <tidoust> ... Hopefully, you have many questions in your head now. Mike will share the current state of Multi-Screen Window Placement API testing.
15:34:02 <msw> https://docs.google.com/presentation/d/1D7Ks1weFmWSmASKKeuMxEM1FW-0c-rdO22KIXh5Tgio/edit#slide=id.g1398642441d_0_24
15:34:02 <tidoust> ... And perhaps how this work would enable us later on to surface virtual displays to web developers.
15:34:04 <anssik> q?
15:34:13 <anssik> ack msw
15:34:25 <tidoust> Slideset: https://docs.google.com/presentation/d/1D7Ks1weFmWSmASKKeuMxEM1FW-0c-rdO22KIXh5Tgio/edit#slide=id.g1398642441d_0_24
15:35:12 <tidoust> [slide 10]
15:35:46 <anssik> q?
15:35:46 <tidoust> msw: The problem we were trying to solve in Chrome was lack of automated multi-screen device testing in our continuous integration environment.
15:35:54 <tidoust> ... We made a lot of progress in that field.
15:36:32 <tidoust> ... To add a test framework support for virtual displays. The slide shows some (awful) pseudocode.
15:37:07 <tidoust> ... Code shows how to assert expectations on virtual displays and positions.
15:37:29 <tidoust> ... A number of window configurations could not be tested to the level that we wanted.
15:38:46 <tidoust> ... I want to thanks Fangzhen for help on Mac environment. The work there has created a utility class that makes it feasible, and integrating that in pre-existing tests.
15:38:59 <tidoust> [slide 11]
15:39:00 <cmartin> cmartin has joined #webscreens
15:39:54 <tidoust> Fangzhen_Song: For Mac OS, using the core graphics API of Mac to implement VirtualDisplayMacUtil as you can see here.
15:40:05 <anssik> q?
15:40:25 <tidoust> ... Now we can enable more platforms for testing out APIs.
15:41:31 <tidoust> ... [details support across platforms]
15:41:40 <tidoust> [slide 12]
15:42:27 <tidoust> msw: Support across platforms is summarized on this slide. For Windows, the indirect display driver seems like the right direction. On Linux, xvfb, etc.
15:42:33 <anssik> q?
15:42:34 <mfoltzgoogle>  Q+
15:42:39 <anssik> ack mfoltzgoogle
15:43:14 <tidoust> mfoltzgoogle: Question about the last bullet on this slide. How do you see this work be made available for web platform tests?
15:43:42 <tidoust> msw: The easiest integration points are often with our Chrome application code. Getting initial support for browser cast was a first step.
15:43:55 <tidoust> ... I think it would be very valuable to offer the same capabilities to Web Platform Tests.
15:44:12 <tidoust> ... But the web platform itself does not offer much in the way of functionalities for multiple screens.
15:44:23 <tidoust> ... There are things that we can test and it is useful.
15:45:03 <tidoust> ... Otherwise you're essentially testing "does that content show up on another display?", in which case there's a problem.
15:46:03 <tidoust> mfoltzgoogle: For the testing model here, is it always the browser that drives and creates the virtual displays? Or can multiple browsers make use of virtual displays?
15:46:15 <tidoust> ... E.g. one creates it, the other drives it?
15:46:57 <anssik> q?
15:46:58 <anssik> q+
15:47:07 <anssik> ack anssik
15:47:10 <tidoust> msw: Being a construct created by the operating system, any sort of window could be placed on that surface. It does not have to be a browser window at all.
15:47:50 <tidoust> anssik: I wanted to ask Eric. Sidecar seems to be a mainstream feature. In Safari, are you integrating Sidecar support, e.g. for videos?
15:48:17 <tidoust> eric-carlson: Nothing explicit. It's just a monitor. You can use it as any other monitor. I don't think there is a need to add any additional support.
15:48:28 <anssik> q?
15:48:29 <rakuco> q+
15:49:24 <anssik> ack rakuco
15:50:10 <tidoust> rakuco: Virtual displays are currently used to test the internals of window placement. But not much that would be observable from a web application perspective. Is that the problem from a WPT perspective?
15:50:46 <tidoust> msw: The Multi-Screen Window Placement API certainly exposes more functionalities to control multiple screens.
15:51:06 <benmorss_> benmorss_ has joined #webscreens
15:51:17 <tidoust> ... Otherwise, is web applications were able to create virtual display, they could test that things don't spill over other displays, etc.
15:51:53 <tidoust> ... I don't know if there's any need to test placement of specific windows, on top of what's already there for the window interface.
15:53:13 <tidoust> anssik: Related to the WebDriver infrastructure, is there something we should know?
15:53:21 <cmartin> ls
15:53:55 <mfoltzgoogle> Q+
15:54:01 <anssik> ack mfoltzgoogle
15:54:02 <tidoust> rakuco: I used to be more aware of what's going on. Some discussions for exposing end points, but you'd need to have support across browser for these endpoints extension.
15:54:44 <tidoust> mfoltzgoogle: For the scope of the virtual screen you build, do you see as the way to target virtual desktops in the future?
15:55:35 <tidoust> msw: Each OS is going to operate its own set of APIs. You may have multiple virtual desktops on the same display, with windows only visible when you switch to the right desktop.
15:56:09 <tidoust> ... Our work is more around configuring things for window placement. This would go a bit beyond the scope of what we're trying to achieve.
15:56:24 <tidoust> ... That space is super interesting to explore.
15:56:46 <anssik> q?
15:56:48 <tidoust> mfoltzgoogle: On Mac, apps sometimes create their own virtual desktops, so maybe worth exploring.
15:57:30 <tidoust> anssik: What is the next step with regards to implementation? Anything that this group may help with?
15:58:15 <tidoust> msw: That's the plans listed on the slide. Windows, Linux (X11), and then Wayland.
15:58:50 <tidoust> ... I wish there would be a common abstraction across platforms so that a broad set of tests could use a consistent set of APIs to manage the displays.
15:59:05 <reillyg> reillyg has joined #webscreens
15:59:12 <tidoust> ... Work done by Fangzhen is going in that direction.
16:00:01 <tidoust> Fangzhen: Once work on Mac is finished, Window, Linux (Wayland) are on our plate.
16:00:11 <tidoust> ... We want to unify the interfaces.
16:00:21 <tidoust> ... That's the plan.
16:01:30 <tidoust> anssik: If you run into issues with IDD (Indirect Display Driver), I can perhaps find contact points. Mike, have you exchanged with people from Microsoft on this?
16:02:22 <tidoust> msw: Not yet. I'm happily surprised by the feedback here. It hasn't been something so actively pursued in our organization. I think it's important and a good occasion to bring people from the different companies together on the topic.
16:02:54 <tidoust> anssik: Right. I'm trying to split the workload. I can try to look for Microsoft people who might have relevant expertise.
16:02:55 <anssik> q?
16:03:35 <anssik> -> Virtual Displays For Automated Tests https://docs.google.com/document/d/1rtxO2FEg0Zl_-oXHzIBsJo6py7wkySUpYruteNMlPys/edit?resourcekey=0-yLkX6DGPwNFn1ARMpM-zLQ
16:03:39 <tidoust> msw: Appreciate that. The best point of contact is on my very informal document that highlights some of this work. Very living work in progress document.
16:03:59 <tidoust> anssik: A document with "living" in the title shows progress.
16:05:07 <tidoust> ... Thanks for the presentation. This seems to be unchartered space. Test automation seems a first concrete outcome. Maybe one day we can expose an interface for web developers to maybe instanciate virtual surfaces.
16:05:10 <anssik> q?
16:05:22 <anssik> Topic: Remote Playback API
16:05:46 <anssik> ghurlbot, this is w3c/remote-playback
16:05:50 <ghurlbot> anssik, OK
16:06:13 <anssik> #92
16:06:13 <ghurlbot> https://github.com/w3c/remote-playback/issues/92 -> Issue 92 Remote Playback API test automation (Honry) F2F
16:06:24 <tidoust> anssik: For the Remote Playback API, we're trying to produce better test reports.
16:06:27 <anssik> -> Remote Playback API: Implementation report https://w3c.github.io/test-results/remote-playback/all.html
16:06:35 <tidoust> ... Fritz and Louay have been making progress on this space.
16:06:58 <tidoust> ... The implementation report is outdated. I'm looking forward to refreshing it!
16:07:26 <tidoust> Slideset: https://docs.google.com/presentation/d/1PRih6TPCgYjfvfvQ4b5HvEBHGeStuHrwNFmNxlopZsI/edit#slide=id.p
16:08:15 <tidoust> Louay: Fritz did some work on implementation in the last few months. He analyzed missing tests, which he presented during last group meeting.
16:08:25 <tidoust> ... Last time, Fritz focused on the implementation side.
16:09:07 <tidoust> ... I'll let Fritz introduce the work and we can discuss next steps. Currently, we're successful on running Chrome on Android, we didn't manage to run other browsers.
16:09:18 <tidoust> [slide 2]
16:09:53 <tidoust> Fritz: I reviewed the specs to identify test gaps. I implemented 12 new tests. Most of them are manual as the user needs to interact with the document for selecting the remote device.
16:10:06 <tidoust> ... I tested events and side effects that the spec says need to happen.
16:10:17 <tidoust> ... Also exceptions that are thrown when canceling the prompt, etc.
16:10:56 <tidoust> ... Also making sure that the app can cannot with the remote device and effectively seeks in the video.
16:11:19 <tidoust> ... The video shows timestamp so we can ask the user to check actual behavior.
16:11:35 <tidoust> ... The one problem that we had was actually finding a browser that implements the Remote Playback API.
16:11:39 <tidoust> [slide 3]
16:12:22 <tidoust> Fritz: We only managed to run it with Chrome (104) running on Android with a Chromecast Ultra. All the tests pass.
16:12:31 <tidoust> [slide 4]
16:12:43 <tidoust> Fritz: You can see the test results here.
16:12:45 <tidoust> [slide 5]
16:13:07 <tidoust> Fritz: Next step is to get the PR with the new tests reviewed.
16:13:07 <anssik> q?
16:13:12 <anssik> q+
16:13:25 <tidoust> ... Then run the tests with more devices to generate an update implementation report.
16:13:30 <mfoltzgoogle> Q+
16:13:50 <tidoust> anssik: So you're looking for other browsers. I think Safari for Mac OS should implement this API.
16:14:05 <tidoust> Fritz: We tried.
16:14:36 <tidoust> Louay: We didn't manage to run the new tests on Safari connected to an Apple TV using AirPlay. Maybe some advice in the room?
16:15:05 <tidoust> ... We're just done with the implementation, so now need to make more runs.
16:15:21 <tidoust> ... One we have that, we can prepare and publish an updated report.
16:15:35 <tidoust> anssik: Was it Jer who implemented the Remote Playback API?
16:15:46 <tidoust> eric-carlson: I confirm.
16:15:59 <tidoust> anssik: Can we make a connection to check the status of the API in Safari?
16:16:22 <tidoust> eric-carlson: As far as I know, it works with Apple TV. It certainly does not work with Chromecast.
16:16:55 <tidoust> anssik: Louay and Fritz, you should look into it some more, and ping Jer if you run into issues.
16:17:34 <tidoust> [Plan is to make offline connections]
16:17:47 <anssik> q?
16:17:50 <anssik> ack anssik
16:17:52 <tidoust> anssik: Many thanks for the work on this. Progress has been slow until you picked it up!
16:17:53 <anssik> ack mfoltzgoogle
16:18:32 <tidoust> mfoltzgoogle: I would also suggest connecting with someone at Microsoft to see if Chromium-Edge supports this. I don't think anyone from Microsoft is attending today, but that seems worth checking.
16:18:38 <tidoust> anssik: That is a great suggestion.
16:19:15 <tidoust> ... Their implementation could be sufficiently different from Chrome's implementation, so that may be considered a separate implementation. I don't know what is the Windows equivalent stack for casting but good idea to look into it.
16:19:37 <tidoust> mfoltzgoogle: Windows has Miracast support at the OS level.
16:19:52 <anssik> q?
16:20:11 <mfoltzgoogle> Q+
16:20:18 <anssik> ack mfoltzgoogle
16:20:24 <tidoust> mfoltzgoogle:
16:20:28 <tidoust> s/mfoltzgoogle: /
16:21:12 <tidoust> mfoltzgoogle: Over the past year, Mounir moved on from standards work. I'm now the editor of the Remote Playback API. I would welcome other editors. Given that the spec is relatively stable, I don't expect that there will be many edits.
16:21:25 <tidoust> ... A PR went in recently to transition the spec over.
16:21:35 <Louay> q+
16:22:03 <tidoust> anssik: Thanks for picking the editorship for the spec! If someone feels like editing this spec, you're welcome to help Mark!
16:22:29 <tidoust> youenn: If the spec is pretty stable, any plan to publish as Candidate Recommendation soon?
16:22:41 <ben_morss> ben_morss has joined #webscreens
16:22:43 <tidoust> mfoltzgoogle: It's already a Candidate Recommendation
16:23:07 <tidoust> anssik: It's a Candidate Recommendation Draft. Drafts are published whenever a new commit is merged.
16:23:11 <cpn> CR Draft: https://www.w3.org/TR/remote-playback/
16:23:36 <tidoust> mfoltzgoogle: The testing issue for getting the implementation report done was the last issue. Is that still the case?
16:24:09 <tidoust> ... We still need additional implementation report across browsers?
16:24:13 <tidoust> anssik: Yes.
16:24:26 <tidoust> ... That's the only blocker for advancing the spec.
16:24:59 <tidoust> ... Or do you think the Open Screen Protocol would impact this spec?
16:25:12 <cpn> s/Chris_Lemon/Chris_Lemmons/
16:25:38 <tidoust> mfoltzgoogle: Not at this time. The ideas flow the other way. If there are features that we want to add to the Remote Playback API, that would impact the OSP, but currently not the other way around.
16:25:55 <anssik> q?
16:26:00 <anssik> ack Louay
16:26:33 <tidoust> present+ Jason_Waterman
16:26:39 <rakuco> q+
16:27:02 <tidoust> Louay: If we can get help on reviewing the tests PR, that would speed things up.
16:27:10 <anssik> https://github.com/web-platform-tests/wpt/pull/35827
16:27:22 <anssik> ack rakuco
16:28:04 <tidoust> rakuco: I posted some comments on this PR a few minutes ago.
16:28:49 <tidoust> tidoust: assigned to Mounir as editor, will create a PR to update.
16:28:59 <tidoust> anssik: We need to find someone.
16:30:01 <tidoust> tidoust: Would make sense to have Louay as "test lead" for the Working Group. For this PR, we probably need someone else to review the tests.
16:30:49 <tidoust> mfoltzgoogle: I will volunteer someone from Google. Not sure that will be me. We will try to get to it soonish.
16:30:58 <anssik> q?
16:31:27 <anssik> Topic: Multi-Screen Window Placement API
16:31:59 <tidoust> anssik: First topic was what to do after First Public Working Draft.
16:32:11 <jsbell> jsbell has joined #webscreens
16:32:15 <jsbell> present+
16:32:25 <anssik> -> W3C Recommendation Track https://www.w3.org/2021/Process-20211102/#rec-track
16:32:26 <tidoust> ... First of all, congrats for getting the FPWD published. The spec exceeds the expectation for FPWD and keeps improving.
16:33:01 <tidoust> ... The W3C process defines the Recommendation track with a state machine. Now that the spec has been published as FPWD, there will be multiple WD.
16:33:17 <tidoust> ... When you think that the scope is stable, we can request transition to Candidate Recommendation.
16:33:29 <tidoust> ... Then multiple CR drafts. Then Proposed Recommendation and Recommendation.
16:33:49 <tidoust> ... With Louay and Francois, we will help you move forward on this process so that you can focus on the technical work.
16:34:55 <tidoust> ... Francois, can you enable continuous publication to /TR?
16:35:15 <tidoust> tidoust: Sure, I thought that was already done, but indeed just for GitHub Pages for now. I'll work on it
16:35:49 <tidoust> Action: Francois to setup automated publication for Multi-Screen Window Placement API working drafts
16:35:52 <ghurlbot> Created https://github.com/w3c/remote-playback/issues/149 -> action 149 setup automated publication for Multi-Screen Window Placement API working drafts (on ) due 23 Sep 2022
16:36:04 <tidoust> s/(on )//
16:36:33 <tidoust> anssik: Horizontal reviews will be needed. TAG review already done multiple times, but other reviews are needed as well.
16:37:31 <tidoust> ACTION: Anssi/Louay to work with Mike on initiating horizontal review of the Multi-Screen Window Placement API
16:37:32 <ghurlbot> Created https://github.com/w3c/remote-playback/issues/150 -> action 150 work with Mike on initiating horizontal review of the Multi-Screen Window Placement API (on ) due 23 Sep 2022
16:37:49 <anssik> -> How to get horizontal review https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review
16:38:42 <tidoust> anssik: Horizontal review is a subset of wide review. There can be other groups that can be listed as dependencies. Do we have such dependencies?
16:38:50 <tidoust> ... I think CSS WG.
16:39:10 <tidoust> msw: From the W3C, it's just the CSS WG. But there are other dependencies on WHATWG HTML and Fullscreen specs.
16:39:26 <tidoust> anssik: This work proposes changes and clarifications to these specifications, right?
16:39:59 <tidoust> msw: Yes, some algorithmic changes and extensions. Some re-definitions and suggested concepts to describe.
16:40:41 <anssik> q?
16:41:19 <tidoust> anssik: Of course, feedback from other browser vendors is valuable.
16:41:45 <tidoust> msw: We filed an issue on Mozilla standard position repo and reached out to Webkit as well.
16:42:10 <tidoust> anssik: Yes, we had a very good discussion with Martin Thomson last time.
16:42:53 <tidoust> ... Jason, do you know if there are news?
16:42:55 <tidoust> jwaterman: I just reviewed what Martin wrote. I'm not in a position to bring further comments.
16:43:38 <tidoust> anssik: Mike will walk us through that position.
16:43:57 <tidoust> Slideset: https://docs.google.com/presentation/d/1D7Ks1weFmWSmASKKeuMxEM1FW-0c-rdO22KIXh5Tgio/edit
16:44:06 <tidoust> [slide 8]
16:44:59 <tidoust> msw: Latest major concern, from Anne, was around bad actors, and spoofing, in other words using the API to trick the user into going fullscreen on a side display without the user really noticing the change.
16:46:02 <tidoust> ... I merged a PR and added considerations to the explainer, with a potential mitigation: when the user attention returns to a screen that has gone fullscreen, the user agent has the opportunity to show the warning again.
16:46:29 <anssik> q?
16:46:31 <tidoust> ... This could go through the cursor returning to the screen, after a period of inactivity, and certainly after any input event directed at that display.
16:46:46 <tidoust> ... I think that sums up the latest state of affairs on that feedback.
16:47:18 <tidoust> anssik: I would be interested in exploring how various implementations currently make sure that the fullscreen warning gets surfaced to the user.
16:47:23 <tidoust> ... How are you handling it?
16:48:14 <jsbell> Those ACTIONs created above are going into the wrong repo (remote-playback instead of window-placement) - Can someone invoke the magic to tell the RSSAgent the correct repo?
16:48:15 <tidoust> msw: I don't know the exact implementation details for providing an input after a period. Certainly if you bring the cursor towards the top of the display, it would display some indication, be it to tell the user that they can press "Esc" to escape fullscreen.
16:48:34 <tidoust> anssik: Is it correct that there is no sticky UI?
16:48:55 <tidoust> ... Thinking of other implementors, I don't remember how Firefox handles fullscreen API warnings.
16:49:21 <tidoust> ... Do you have consistent UX or does that depend on the OS?
16:50:02 <tidoust> jwaterman: I don't have any background on that. We'll look into that. I'm not exactly sure.
16:50:17 <tidoust> anssik: No worries. I think it's good to understand what implementations are doing.
16:50:47 <tidoust> ... UX on iPad OS?
16:50:56 <tidoust> eric-carlson: We provide a "close" button.
16:51:19 <tidoust> ... Some gestures or keyboard input bring up a dialog asking whether you close it.
16:51:46 <tidoust> ... It's shown when you go to fullscreen. It fades away, and then is shown for touch events.
16:52:08 <tidoust> anssik: It could be useful to reuse this UI as applicable.
16:52:30 <anssik> q?
16:52:43 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
16:52:53 <mfoltzgoogle> Present+ Mark_Foltz
16:53:08 <tidoust> msw: Yes, reuse is good. There are some additional considerations for multi-screen. There aren't, in my view, qualitatively different from single screen.
16:53:42 <tidoust> anssik: Noting that Anne no longer works at Mozilla. Hopefully, someone takes over.
16:53:44 <anssik> RRSAgent, draft minutes
16:53:44 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-webscreens-minutes.html anssik
16:53:51 <ben-morss> ben-morss has joined #webscreens
16:54:00 <tidoust> jwaterman: I'll find someone when I'm back at the office.
16:54:01 <anssik> q?
16:54:47 <tidoust> RRSAgent, draft minutes
16:54:47 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-webscreens-minutes.html tidoust
16:56:22 <anssik> ghurlbot, this is w3c/window-placement
16:56:23 <ghurlbot> anssik, OK
17:10:31 <plh> plh has left #webscreens
17:15:16 <anssik> RRSAgent, draft minutes
17:15:16 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-webscreens-minutes.html anssik
17:16:11 <anssik> RRSAgent, make logs world-visible
17:22:57 <tovep> tovep has joined #webscreens
17:25:52 <jsbell> jsbell has joined #webscreens
17:27:02 <tidoust> msw: Going back to a generic presentation on Multi-Screen Window Placement API
17:27:09 <tidoust> [slide 2]
17:27:56 <mfoltz> mfoltz has joined #webscreens
17:28:10 <tidoust> [Mike goes through speaker notes in the presentation]
17:28:15 <tidoust> [slide 3]
17:28:45 <tidoust> [slide 4]
17:28:48 <tidoust> [slide 5]
17:30:23 <tidoust> [slide 6]
17:32:29 <eric-carlson> eric-carlson has joined #webscreens
17:32:44 <tidoust> [slide 7]
17:33:05 <morssben> morssben has joined #webscreens
17:33:13 <tidoust> [Mike runs the demo]
17:34:00 <tidoust> msw: Two windows labeled ozone x11 that are simulating displays for Chrome OS. Button on the left lets you open a window on the right.
17:34:29 <tidoust> ... The window on the right can delegate its user activation to make the left one fullscreen.
17:35:04 <tidoust> ... The demo shows initiating multi-screen experiences from a single user activation.
17:35:23 <tidoust> ... A second request fullscreen from the fullscreen allows it to change the fullscreen display.
17:35:47 <tidoust> ... I can do the same from the popup window which uses delegating on the fullscreen window, etc.
17:36:02 <tidoust> ... So there's a lot to unpack here for an 18s demo!
17:36:08 <anssik> q?
17:36:35 <tidoust> anssik: All these features are motivated by real user feedback?
17:36:38 <tidoust> msw: Yes.
17:36:49 <tidoust> anssik: Are you able to share more about motivating use cases?
17:37:07 <tidoust> msw: A Google property has expressed public interest in this API.
17:37:21 <tidoust> ... We've been focusing on a number of their specific use cases for this.
17:37:36 <tidoust> ... All of the work we've done solves requirements that they have expressed.
17:37:44 <eric-carlson> q+
17:37:56 <tidoust> anssik: I think the demo is fantastic to showcase what the features do.
17:38:23 <tidoust> ... Is the demo public? There might be useful feedback from developers to gather.
17:38:36 <tidoust> msw: Yes, link at the bottom of the slide takes you to the repo.
17:39:04 <anssik> q?
17:39:10 <tidoust> anssik: If I remember correctly, you published an article on web.dev, that's great.
17:39:19 <anssik> ack eric-carlson
17:39:36 <jsbell> q+
17:39:39 <tidoust> eric-carlson: Have all of these features had privacy review?
17:39:48 <tidoust> msw: through Chrome privacy review process, yes.
17:39:58 <tidoust> eric-carlson: But not from W3C?
17:40:20 <tidoust> msw: Not yet done specifically a privacy horizontal review, but that's definitely one of the next steps.
17:40:29 <anssik> q?
17:40:33 <anssik> ack jsbell
17:41:26 <tidoust> jsbell: I just wanted to jump in. Partners are not just asking for more features, they really highlight gaps that would unlock features in their offering on the web.
17:41:34 <morssben> q+
17:41:49 <anssik> ack morssben
17:41:54 <tidoust> anssik: Note to self and Mike, let's use this demo to feed privacy review
17:42:34 <tidoust> morssben: Chrome privacy review material could be useful input
17:42:50 <tidoust> anssik: Yes, please consider putting that in public space, for example in the repo.
17:43:39 <tidoust> [slide 8]
17:44:15 <tidoust> msw: We covered the feedback slide previously. I did file issue to align and integrate spec content with established specs. But that's premature at this point without second implementer.
17:44:23 <tidoust> [slide 9]
17:44:50 <tidoust> msw: Some requested enhancements and explorations, related to initiating multi-screen experiences.
17:45:18 <tidoust> ... First proposal is maybe incomplete for those who want to show multiple windows in fullscreen from a single user activation.
17:46:11 <tidoust> ... The consumption of transient user activation blocks window.open. It seems that the user agent can be configured to allow a window.open request from a popup to not be blocked.
17:46:22 <tidoust> ... It may not be a departure from the current algorithm.
17:47:02 <tidoust> ... Also a bullet point on opening child windows in fullscreen.
17:47:59 <tidoust> ... My understand from a variety of user feedback on fullscreen need on each display is summarized in the last bullet
17:48:10 <anssik> q?
17:48:27 <mfoltz> Q+
17:48:37 <mfoltz> q-
17:48:48 <tidoust> anssik: Thanks, Mike. As pre-work to privacy review, we should anticipate privacy concerns that reviewers might raise and prepare answers.
17:48:49 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
17:49:05 <mfoltzgoogle> q+
17:49:08 <tidoust> ... I was wondering about privacy issues that could be raised. Fingerprinting could obviously be one.
17:49:56 <tidoust> ... The most popuplar privacy issues are fingerprinting associating with being able to enumerate unique configuration of the system. That's probably something we need to document in the privacy review request.
17:50:07 <tidoust> ... How we mitigate screen enumeration.
17:50:15 <tidoust> msw: A fair amount is already documented.
17:50:21 <anssik> q?
17:50:59 <tidoust> ... The goal for anti-fingerprinting is to make your device look like any other devices. The one bit of information that we propose exposing is whether or not multi-screen may be available.
17:51:20 <tidoust> ... That's whether or not user may display multi-screen features.
17:51:46 <tidoust> ... Goal is to let the user decide when the bit is set.
17:52:00 <tidoust> youenn: If the user agent can lie for the good, why expose it at all?
17:52:18 <tidoust> ... In WebRTC, we had big issues with getUserMedia(). We were exposing the cameras and microphones.
17:52:25 <tidoust> ... It shipped for quite some time.
17:52:59 <tidoust> ... We're now in a situation where we're exposing one bit of information for microphones and one for cameras. It's better. We would be happy to get rid of that, but it's hard.
17:53:11 <tidoust> ... I would strongly encourage you not to do it from the beginning.
17:53:37 <tidoust> eric-carlson: To add a little bit of extra information. Media devices at the time supported two APIs: enumerateDevices and getUserMedia.
17:54:18 <tidoust> ... In theory, the usage of the two should have been the same, but in fact, after shipping for several years, we found that enumerateDevices was used several orders of magnitude higher than getUserMedia.
17:54:24 <anssik> q?
17:54:28 <tidoust> ... So that was being used purely as fingerprinting info.
17:55:24 <tidoust> msw: Absolutely. About that bit that we propose, would it be appropriate to let the user agent initialize as undefined?
17:55:43 <tidoust> ???: undefined then becomes another leaked information that indicates something else.
17:55:47 <tidoust> msw: That's a good point.
17:55:58 <jsbell> ??? = Simeon Vincent
17:56:15 <tidoust> s/???: /Simeon_Vincent:
17:56:31 <anssik> RRSAgent, draft minutes
17:56:32 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-webscreens-minutes.html anssik
17:56:44 <anssik> Present+ Simeon_Vincent
17:56:58 <anssik> q?
17:57:43 <tidoust> msw: From a privacy-first line of thinking, there's a number of existing synchronously available about screen information (screen.x, screen.y, screen.width, screen.height).
17:58:01 <tidoust> ... Currently, the definition of those permits the user agent to constrain them to viewport.
17:59:00 <tidoust> ... The new surface that we're exposing could provide the mechanism to always constrain the values by default, and then go through the gated interfaces for further details.
17:59:15 <tidoust> ... This could be ultimately beneficial for users with privacy
17:59:27 <anssik> ack mfoltzgoogle
17:59:29 <tidoust> ... and still support some of the legacy window placement APIs that we have on the web today.
18:00:19 <tidoust> mfoltzgoogle: Related to the child window proposal. Based on my brief reading of the spec, it seems to be based on window.open. I was wondering how that would scale with opening mulitple child windows at once.
18:01:46 <tidoust> msw: Right now, what the proposal entails is creating an internal slot that is tracked, much like user activation, for multi-screen experiences through the API, and that allows transitioning transient user activation status
18:01:52 <tidoust> ... It was evolved through a rigorous security review process.
18:02:31 <jwaterman> jwaterman has joined #webscreens
18:02:44 <tidoust> ... Ultimately, if you have 3 screens, we may want a game to launch fullscreen on all 3 screens. Trying to come up with a solution that allows that is something that I'm trying to explore.
18:02:47 <anssik> Present+ Shinjiro_Urata
18:03:24 <anssik> q?
18:03:27 <tidoust> ... I want to explore the space and I welcome feedback.
18:04:57 <hyojin> Present+ Hyojin_Song
18:05:28 <tidoust> ??: I would point out that Mike prepared answers to self-review questionnaires on security and privacy. That is good but also good to check things again.
18:06:17 <tidoust> anssik: Thank you for the great presentation, Mike! We will keep on pushing this work forward with wide review and talks to implementers.
18:06:31 <anssik> Topic: Open Screen Protocol
18:10:56 <tidoust> Slideset: https://docs.google.com/presentation/d/e/2PACX-1vRx0vaazkNXk783rEDyUy66AWCh3BHcWHv5o0RcznbVV06k7pZp2F3TPiwIRAecEEZ4w6pZvkvke2n4/pub
18:14:04 <tidoust> [slide 1]
18:15:30 <tidoust> mfoltzgoogle: The Open Screen Protocol is designed to allow independent implementations of some of the APIs developed in the group (Presentation API and Remote Playback API).
18:15:52 <tidoust> ... Suite of protocols to allow two user agents to exchange data that support the implementations of the APIs.
18:16:02 <tidoust> ... Started on the recommendation in 2021.
18:16:24 <tidoust> ... Protocol received reviews, including from security folks within and external to Google.
18:16:46 <tidoust> ... Most of the security feedback have pull requests linked to them.
18:16:53 <tidoust> ... Most of them align with the last time we reviewed them.
18:17:05 <tidoust> [slide 2]
18:17:08 <tidoust> [slide 3]
18:17:27 <tidoust> [slide 4]
18:18:06 <tidoust> msw: TLS 1.3 is used to authenticate agents based on certificates. Not going into details about QUIC, used under the hoods.
18:18:32 <tidoust> ... Just using certificates is not enough to prevent man-in-the-middle. We add a pairing step.
18:19:15 <tidoust> ... It uses a PAKE. Because we use certificates as inputs to this protocol, we can verify that the certificate is linked to the device.
18:19:31 <tidoust> ... Not going to address details on PAKE protocols today.
18:19:42 <tidoust> [slide 5]
18:19:44 <tidoust> [slide 6]
18:20:21 <tidoust> mfoltzgoogle: Key feedback we got was that we were not following usual certificate guidelines.
18:20:47 <tidoust> ... PRs are aimed at aligning with regular guidelines.
18:21:04 <tidoust> [slide 7]
18:21:36 <tidoust> mfoltzgoogle: We were trying to use a certificate that has a circular dependency on itself. That's not possible.
18:22:09 <tidoust> ... Proposal is to use a random seed and a counter. This seems to be sufficient and ok for what we want to do.
18:22:29 <tidoust> ... Linked to PR #293. Other algorithms would be possible but I do believe that's good enough.
18:22:29 <ghurlbot> https://github.com/w3c/window-placement/issues/293 -> Issue 293 [not found]
18:22:35 <tidoust> [slide 8]
18:23:26 <tidoust> mfoltzgoogle: Not all curves are equal. There's a good discussion with multiple participants that basically says that the curve with the most bits in it P-521 is not widely deployed.
18:23:35 <tidoust> ... so considered for removal.
18:23:45 <tidoust> [slide 9]
18:24:04 <anssik> ghurlbot, this is w3c/openscreenprotocol
18:24:04 <ghurlbot> anssik, OK
18:24:30 <tidoust> mfoltzgoogle: Other choice is cipher algorithm. It turns out that if you base things on TLS, that's all good.
18:24:59 <tidoust> ... The issue linked with the PR has some performance measures.
18:25:26 <tidoust> ... The one open issue that deserves further discussion is the remaining curve.
18:25:48 <tidoust> ... The deployment is much less and I don't about the implementation status. Currently, it is in TLS but not mandated.
18:26:39 <tidoust> ... My take is that we should mandate 256. 384 we should recommend for increase comptability. And we want people to switch to better security in the future.
18:26:39 <anssik> q?
18:27:16 <tidoust> ... If you have any objection to removing P-521, let me know!
18:27:33 <tidoust> ... If you have further feedback, that's welcome too.
18:27:48 <tidoust> anssik: Do you have a list of people in mind to review the PRs?
18:28:11 <tidoust> mfoltzgoogle: One of our certificate experts at Google, Ryan Sleevi, reviewed the PRs.
18:28:35 <tidoust> ... I will look into further feedback internally.
18:28:47 <tidoust> ... For other implementers, I don't know.
18:28:53 <tidoust> eric-carlson: I will check.
18:30:10 <tidoust> mfoltzgoogle: I'll switch to Media Capabilities
18:30:24 <tidoust> [slide 14]
18:30:30 <tidoust> [slide 15]
18:30:55 <tidoust> mfoltzgoogle: We define a set of messages that allow agents to describe what kind of audio and video they can receive and are capable of decoding.
18:31:02 <tidoust> [slide 16]
18:31:15 <tidoust> mfoltzgoogle: Details of the messages are in the spec.
18:31:30 <tidoust> ... Main one details the video codec format.
18:32:13 <tidoust> ... We had a long time issue about finding a way to describe codec formats. We jointly resolved with the Media WG that codecs exposed by the WebCodecs registry is a good source of format strings.
18:32:33 <tidoust> ... The Media WG did the work of defining these strings because you need them for WebCodecs to function.
18:32:52 <tidoust> ... The registry lists most of the codecs used on the Web today. But it is not complete.
18:33:13 <tidoust> ... Discussion is then about non-listed codecs. Agents can use RFC 6381
18:33:24 <tidoust> ... PR #299 more or less encodes that in the spec.
18:33:24 <ghurlbot> https://github.com/w3c/openscreenprotocol/issues/299 -> Pull Request 299 Reference WebCodecs registry for codec names. (mfoltzgoogle) F2F, v1-spec
18:34:48 <tidoust> youenn: With Media capabilities, you provide a lot of parameters, and then you get an answer with yes/no/smooth/...
18:35:04 <tidoust> ... I was wondering whether this is good enough or whether you envision more details will be needed.
18:35:32 <tidoust> cpn: There are additional properties such as HDR metadata, transfer function, etc. already in OSP.
18:37:08 <tidoust> eric-carlson: There's an additional issue. Imagine a machine capable of receiving a video stream that it can down-sample for display, there isn't currently a good way to express that. If the sender has multiple streams, one being super high quality. If the receiver needs to down-sample the high quality stream, it would be better to send the lower quality.
18:37:22 <tidoust> ... I don't think that there is a good way to do that.
18:37:47 <tidoust> ... We had a discussion yesterday for a new group scoped to discussing this sort of issues.
18:38:21 <tidoust> ... E.g. extra luminance in the higher quality stream.
18:38:36 <tidoust> ... There isn't a way for you to find out which is the most appropriate stream to send.
18:39:12 <tidoust> mfoltzgoogle: I think the idea is that the agent should only advertise the ones that it wants to receive. So if it doesn't want to receive the higher quality, it should say so.
18:39:58 <tidoust> ... If the receiver prefers the lower quality stream, I don't remember whether there is provision in the spec to address that scenario. I need to check. Feel free to raise an issue otherwise, I'll do it when I review the minutes.
18:40:51 <tidoust> [slide 17]
18:40:54 <tidoust> [slide 18]
18:41:45 <tidoust> mfoltzgoogle: Another open issue around HDR capabilities. color-gamut is not sufficient. Proposal is to add the fields transfer-functions and hdr-metadata as done in Media Capabilities.
18:42:26 <tidoust> ... I'm not an expert on HDR. Assuming these are sufficient for local presentation, I assume that they are sufficient for remote display.
18:43:00 <tidoust> cpn: Yes. HDR metadata is probably going to be refined or completed in Media Capabilities.
18:43:56 <tidoust> mfoltzgoogle: Maybe we can import these by reference instead of copying them. I think that is what PR #300 is doing.
18:43:56 <ghurlbot> https://github.com/w3c/openscreenprotocol/issues/300 -> Pull Request 300 Add transfer-functions and hdr-metadata to video-capabilities. (mfoltzgoogle) F2F, v1-spec
18:44:23 <tidoust> tidoust: Always better not to re-define concepts, so by reference is good!
18:45:04 <tidoust> RRSAgent, draft minutes
18:45:04 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-webscreens-minutes.html tidoust
18:46:09 <tidoust> [45mn lunch break]
18:48:45 <reillyeon> reillyeon has joined #webscreens
18:51:08 <reillyeon> reillyeon has left #webscreens
19:39:44 <tovep> tovep has joined #webscreens
19:55:57 <takumif> takumif has joined #webscreens
19:59:50 <tidoust> mfoltzgoogle: Back to security issues. P-521, I think there is consensus to drop.
20:00:14 <tidoust> [slide 10]
20:00:59 <tidoust> mfoltzgoogle: Re. #278, we don't have an authority that generates the certificates, so it makes sense to use a randomly generated SRV-ID.
20:01:00 <ghurlbot> https://github.com/w3c/openscreenprotocol/issues/278 -> Issue 278 Do not use Distinguished Name to convey protocol details (sleevi) security-tracker, F2F
20:01:47 <tidoust> ... Second part of the feedback is that there is an RFC describing how to include the DNS-SF in the SRV-ID and we should do that.
20:02:10 <tidoust> ... However, I discovered that there are a couple of things that would not work well for our case.
20:02:45 <tidoust> ... I need some clarification from the RFC or from its author about how this might be used for our use case, e.g. in cases of DNS-SD instance name changes.
20:04:51 <tidoust> ... I wonder about exchanging with IETF group. Should this go through the liaison or can I just reach out to the author?
20:05:08 <tidoust> tidoust: I recommend going the informal way for clarifications.
20:06:01 <tidoust> anssik: Wondering about security reviews for the protocol
20:06:27 <tidoust> tidoust: We don't usually develop protocols, so not sure what to recommend on top of the usual process.
20:06:45 <tidoust> anssik: A possible example is WebSockets.
20:07:09 <anssik> https://www.rfc-editor.org/rfc/rfc6455
20:07:29 <tidoust> mfoltzgoogle: The security of the underlying technical details such as SPAKE2, certificates, etc. should probably be reviewed by IETF experts.
20:08:34 <tidoust> ... I wasn't planning on bringing wide review in this particular meeting but something to keep in mind.
20:08:55 <tidoust> anssik: Your slides are perfect at conveying the background and rationale for choices.
20:09:35 <tidoust> mfoltzgoogle: Yes, we have a history of slides, minutes and GitHub discussions. Hopefully we can come up with a good history to explain our choices..
20:09:45 <tidoust> [slide 11]
20:09:56 <tidoust> mfoltzgoogle: #279 and #280
20:09:56 <ghurlbot> https://github.com/w3c/openscreenprotocol/issues/279 -> Issue 279 The keyUsage name is digitalSignature, not signing (sleevi) security-tracker, F2F
20:09:56 <ghurlbot> https://github.com/w3c/openscreenprotocol/issues/280 -> Issue 280 Clarify the supported signature algorithms for certificates (sleevi) security-tracker, F2F
20:10:58 <tidoust> ... The clearest way to make sure that you have the right constants for the certificates is to write them in binary format as there have been mistakes in the past.
20:11:31 <tidoust> ... Constants are based on object IDs
20:11:39 <tidoust> ... Francois reviewed and provided feedback here.
20:11:46 <tidoust> [slide 12]
20:12:11 <tidoust> mfoltzgoogle: On 2.0 version of agent certificates, some changes on the fields.
20:12:36 <tidoust> [slide 13]
20:12:59 <tidoust> mfoltzgoogle: Final issue is on the certificate's maximum lifetime: #282
20:13:00 <ghurlbot> https://github.com/w3c/openscreenprotocol/issues/282 -> Issue 282 Certificates should have a maximum lifetime, and SPAKE2 identities should be SPKI not cert fingerprint (estark37) security-tracker, F2F, v1-spec
20:13:07 <tidoust> ... We did not set a maximum lifetime.
20:13:18 <tidoust> ... Having some protocol around key rotation could be useful.
20:13:35 <tidoust> ... That is more complicated so not willing to pick it up right now, but that is useful.
20:13:45 <tidoust> ... Maybe aligning it with what WebTransport does.
20:14:04 <tidoust> ... Ways to get updated key fingerprints when the keys are updated.
20:15:26 <tidoust> ... The other change suggested was to use the certificate fingerprint as SPKI to be able to smoothly transition to new certificates. That seems like a good idea. PR#301 attempts to do this.
20:15:26 <ghurlbot> https://github.com/w3c/PR/issues/301 -> Issue 301 [not found]
20:15:48 <tidoust> [slide 20]
20:16:36 <tidoust> mfoltzgoogle: SPAKE2, which we use as part of the pairing protocol. Underlying spec changed, I attempted to better align our specs with SPAKE2. Variable names have notably changed.
20:16:45 <tidoust> ... See PR #294
20:16:45 <ghurlbot> https://github.com/w3c/openscreenprotocol/issues/294 -> Pull Request 294 Update for SPAKE2 (mfoltzgoogle) F2F
20:16:53 <anssik> RRSAgent, draft minutes
20:16:53 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-webscreens-minutes.html anssik
20:17:27 <tidoust> ... I used this opportunity to simplify the protocol. That makes it easier to digest. I welcome reviewers on this.
20:17:55 <tidoust> ... Security aspects have not changed.
20:18:02 <tidoust> [slide 21]
20:18:29 <tidoust> mfoltzgoogle: My goal was to resolve most security issues before taking a deeper dive at Mattr.
20:18:47 <anssik> s/Mattr/Matter
20:18:52 <tidoust> ... There are a few remaining issues for which I didn't have time to prepare proposed updates.
20:19:33 <tidoust> ... Some possible changes around TLS SNI.
20:19:57 <tidoust> ... A few other issues that we'll need to address, but that should be the end of the list for v1 of the Open Screen Protocol.
20:21:46 <takumif> Slides: https://docs.google.com/presentation/d/1CLTmCP1J3_DXW0Wza7f9KqDrvv-o-D6lfr11dxQCeJs/edit#slide=id.p
20:21:54 <tidoust> Topic: Site-initiated mirroring
20:22:03 <tidoust> s/Slides:/Slideset:
20:22:43 <tidoust> [slide 1]
20:22:48 <tidoust> [slide 2]
20:23:04 <tidoust> takumif: Allows a website to mirror its content to another device
20:23:19 <tidoust> ... Same content on sender side and receiver side.
20:23:38 <tidoust> ... We have a private API in Chrome to achieve this. Some products use this already, we would like to bring this to the wider web.
20:23:46 <tidoust> [slide 3]
20:24:04 <tidoust> takumif: We conducted a TAG review a couple of months ago. No major concerns raised.
20:24:24 <tidoust> ... Since the June meeting, there was a bit of feedback there, and internal feedback. We tweaked the API a little bit.
20:24:51 <tidoust> ... The explainer is available on GitHub. I believe it is slightly outdated compared to these slides, I will refresh it.
20:25:05 <tidoust> ... The feature is behind a runtime flag in Chromium.
20:25:31 <tidoust> ... I have local patches to make things work and I hope to land these soon, you can track progress through the bug tracker.
20:25:37 <tidoust> [slide 4]
20:25:54 <tidoust> takumif: Showing what the API looks like.
20:26:15 <tidoust> ... Web site can specify "mirroring" in the request to initiate a Presentation.
20:26:37 <tidoust> ... All the rest exists in PresentationRequest, we leverage that.
20:27:22 <tidoust> ... Last time, we envisioned passing a specific URL scheme. We now feel a "type" struct would be more explicit and preferrable.
20:27:34 <tidoust> msw: What would be another "type"?
20:28:00 <tidoust> takumif: We could envision a "type": "url".
20:28:14 <tidoust> ... There was a suggestion to drop the "type" field entirely.
20:28:28 <tidoust> ... But I think that would allow to let the web site use all default settings.
20:28:33 <Zakim> Zakim has left #webscreens
20:28:40 <tidoust> ... Secondly, it allows us to add other types in the future.
20:29:37 <tidoust> mfoltzgoogle: One of the issues that has been raised in the past was possibility to provide different URLs for different content (e.g. audio and video)
20:30:05 <tidoust> takumif: We could add additional settings such as "requireVideo".
20:30:31 <tidoust> mfoltzgoogle: So you do suggest to have a "url" "type" that would be the default for strings.
20:30:36 <tidoust> takumif: Yes.
20:30:55 <tidoust> [slide 5]
20:31:45 <tidoust> takumif: Additional parameters so far are "captureLatency" and "audioPlayback" (do you want audio playback on the receiver side or sender side).
20:31:55 <tidoust> [slide 6]
20:32:28 <tidoust> takumif: A web site would be able to list different URLs in the order of preference. The UA will pick up the firt one that is supported by the receiver chosen by the user.
20:33:01 <anssik> RRSAgent, draft minutes
20:33:01 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-webscreens-minutes.html anssik
20:33:11 <tidoust> ... The Web site would be able to tell which one was chosen through `connection.source.type` and `connection.source.url`
20:33:18 <tidoust> [slide 7]
20:33:38 <tidoust> takumif: This is not part of the current proposal but an idea for a possible future extension.
20:34:13 <tidoust> ... We could add a type to remote media streams.
20:34:31 <tidoust> ... We had looked at this but had not found a way to hide the captured stream from the web site itself.
20:34:57 <tidoust> ... But there may be other scenarios where we want to pass media streams. The current design would be extensible.
20:35:05 <tidoust> [slide 8]
20:35:12 <tidoust> takumif: That is essentially what I have.
20:35:47 <tidoust> msw: Would you say that mirroring a shortcut to getUserMedia that allows user not to select the tab to mirror?
20:36:23 <tidoust> takumif: It is similar, but in the case of getUserMedia, the Web site has access to the stream whereas it cannot access the stream here, which seems a good thing in many scenarios.
20:36:59 <tidoust> anssik: I was wondering whether TAG raised something similar about getUserMedia
20:37:08 <tidoust> takumif: No.
20:37:20 <tidoust> anssik: What was the gist of their feedback?
20:37:29 <tidoust> takumif: No significant feedback.
20:37:32 <anssik> s/getUserMedia/getDisplayMedia
20:38:15 <tidoust> ... [going through TAG feedback]
20:39:13 <tidoust> mfoltzgoogle: About the API shape, I'm wondering if there is a use case for the web developer wanting to feature detect whether site mirroring is available?
20:40:10 <tidoust> ... It seems a little hostile to throw an exception if browser does not support mirroring vs. no source that are compatible.
20:40:27 <tidoust> msw: In that case, would a site want to use getDisplayMedia instead?
20:41:07 <tidoust> ... If you want mirroring and mirroring does not work, you may want to switch to getDisplayMedia. If you provide the fallback URLs, you won't get the mirroring.
20:41:45 <tidoust> takumif: If it does not support mirroring, the site can supply fallback URLs if that provides the right features for them.
20:42:03 <tidoust> ... I'm not sure how getDisplayMedia would work here.
20:42:43 <tidoust> msw: The fallback URL means the user chose a device.
20:42:58 <tidoust> ... In that case case, you don't necessarily want the presentation to go through.
20:43:26 <tidoust> mfoltzgoogle: The page knows the fallback is chosen. It can then call getDisplayMedia or something else.
20:43:47 <tidoust> ... But we haven't built a way of passing a media stream through the Presentation API for now.
20:44:16 <tidoust> ... Right now, the web site can provide the URL of a web app that would be the recipient of that stream.
20:44:51 <tidoust> mfoltzgoogle: One comment about the media-stream idea at the end. Breakout session earlier this week on element capture.
20:45:05 <tidoust> ... Capture just an element as input to create a media stream.
20:45:16 <tidoust> ... That could a complement to this. The two can work together.
20:46:22 <tidoust> -> https://docs.google.com/presentation/d/e/2PACX-1vSBwa1kvYKY14-nh3Wd523X7Nzy-fi-sBoplE4pBLGkOGBkTpR1u5hA5s2UDg4D1ICip6lYXA9bfKYl/pub?start=false&loop=false&delayms=3000 Slides Element Capture
20:46:24 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
20:46:35 <tidoust> -> https://www.w3.org/2022/09/14-element-capture-minutes.html Minutes from breakout session on Element Capture
20:46:58 <tidoust> msw: The privacy concerns brought there are interesting.
20:47:29 <tidoust> mfoltzgoogle: Some of the concerns is generic, some specific to element capture, which I think we addressed but we'll iterate on it.
20:47:58 <tidoust> Topic: Wrap up
20:48:42 <tidoust> anssik: For multi-screen window placement, we decided to seek wider review, including privacy review.
20:49:33 <tidoust> ... Some interest to expose virtual displays for testing purpose. Implementation on Mac, and looking for support on Windows and Linux.
20:50:23 <tidoust> msw: The virtual display approach we use on Mac uses APIs that are not guaranteed to be supported by Apple. Feedback is that we should document our use of these APIs to illustrate the need to expose them officially.
20:51:02 <tidoust> anssik: For Remote Playback API, we want to get the implementation report out. Some confusion about Safari implementation status.
20:51:27 <tidoust> ... Eric wanted to talk with Louay and Fritz about implementation status.
20:51:46 <tidoust> ... For the Open Screen Protocol, fantastic slideset from Mark as usual.
20:52:12 <tidoust> ... In some near future, we will probably proceed with wide review for OSP.
20:52:38 <tidoust> ... In connection with OSP, we defered Matter/CSA coordination to a further meeting since they have not yet published the spec publicly.
20:53:31 <tidoust> ... For site-initiated mirroring in the Presentation API, what are the next immediate steps?
20:53:48 <tidoust> takumif: Trying to have the implementation up and running under a flag.
20:54:18 <tidoust> mfoltzgoogle: At a subsequent meeting, we should discuss how to bring site-initiated mirroring to the standards track.
20:54:34 <tidoust> anssik: Yes, that's a good next step for us to look into that.
20:56:45 <tidoust> anssik: It was very great to see you around. Hybrid system works great.
20:57:10 <tidoust> mfoltzgoogle: Next virtual meeting could be near January 2023. That probably depends on the CSA publishing their spec.
20:58:38 <anssik> RRSAgent, draft minutes
20:58:38 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-webscreens-minutes.html anssik
20:58:42 <tidoust> anssik: Also important to see multi-implementer support in the room.
20:58:44 <tidoust> RRSAgent, draft minutes
20:58:44 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-webscreens-minutes.html tidoust
21:05:43 <tovep> tovep has joined #webscreens
21:05:55 <tovep> tovep has left #webscreens
22:33:10 <msw> msw has joined #webscreens