07:49:12 RRSAgent has joined #webscreens 07:49:12 logging to http://www.w3.org/2015/05/19-webscreens-irc 07:49:19 RRSAgent, make logs public 07:50:00 Meeting: Second Screen Presentation WG F2F - Berlin - Day 1 07:50:04 Chair: Anssi 07:50:20 mfoltzgoogle has joined #webscreens 07:50:34 Agenda: https://www.w3.org/wiki/Second_Screen/Meetings/May_2015_F2F#Day_1_-_Tue_19_May_2015 07:52:47 whywhat has joined #webscreens 07:53:23 markw has joined #webscreens 07:54:16 Present: Mark_Watson, Anton_Vayvod, Mark_Foltz, Shih-Chiang_Chien, Hongki_Cha, Anssi_Kostiainen, Francois_Daoust, Louay_Bassbouss, Stephan_Steglich, Christian_Furhop, Matt_Hammond, Michael_Kang_(observer), Mohammed_Dadas 07:55:10 michael_Kang_LGE has joined #webscreens 07:55:36 Louay has joined #webscreens 07:55:45 mh-away has joined #webscreens 07:56:14 RRSAgent, draft minutes 07:56:14 I have made the request to generate http://www.w3.org/2015/05/19-webscreens-minutes.html tidoust 07:57:55 Present+ Oleg_Beletski 07:57:59 schien has joined #webscreens 07:58:32 s/Furhop/Fuhrhop/ 07:59:23 Present+ Soonbo_Han 07:59:57 soonbo has joined #webscreens 08:01:38 hyojin has joined #webscreens 08:01:58 scribe: tidoust 08:02:17 Topic: Kick Off 08:03:10 Anssi welcomes participants, thanks host, starts round of introductions. 08:03:12 mdadas has joined #webscreens 08:03:52 Anssi: I'm editing different specs in other W3C groups. Excited by this group, it's focused, very good group! 08:04:41 ... Looking forward to a productive discussion today. Goal is to reach so-called consensus. F2F can help resolve most critical issues that could perhaps go on and on on the mailing-list 08:04:53 ... We can adjust the agenda as needed. 08:06:42 ?_Song: Working for LG, editor of CSS spec. 08:06:57 Soonbo_Han: From LG, as well 08:07:07 Hyojin Song :) 08:07:18 Mark_Watson: from Netflix, would like our web site to be able to connect to TV sets. 08:07:31 soonbo_ has joined #webscreens 08:07:41 Anton_Vayvod: from Google, London office. Extending Chrome for Android to support second screens 08:07:54 Mark_Foltz: From Google, editor of the spec 08:08:15 Hongki: From ETRI, Korea 08:08:45 Oleg_Beletski: Samsung Electronics, Finland. Working with Samsung technologies for mobile in particular 08:09:12 Schien: Mozilla, working in TV in particular, interested to connect devices there 08:09:38 Mohammed_Dadas: from Orange, evolving IPTV services for the future. Interested by this group in that regard. 08:09:44 s/?_Song/Hyojin_Song/ 08:10:36 Francois: staff contact 08:11:01 obeletski has joined #webscreens 08:11:04 Louay_Bassbouss: from Fraunhofer FOKUS, was involved in Presentation API since the work in the Community Group. 08:11:45 Michael_Kong: from LG Electronics, in charge of broadcasting standards for Europe, DVB and HbbTV. Interested in companion screens for TV. Coming here as an observer this time. 08:12:08 Stephan_Steglich: from Fraunhofer FOKUS, I would like to welcome you to our offices here 08:12:27 ... Feel free to ask questions during breaks and free evenings! 08:13:27 ... [Stephan reviewing meeting logistics] 08:14:40 ... Some room reserved in a nearby restaurant (on your own expenses) for this evening. Social dinner tomorrow, part of MWS. 08:15:34 ... Room tomorrow won't be the same one, more security involved, there should be some sign at the entrance to guide you to the 6th floor. Louay and myself won't be around tomorrow morning but Christian will be there. 08:17:45 Matt_Hammond: from BBC, we make programs for TV and radio, doing a lot of R&D. I've been working a lot on DVB and HbbTV, companion screens and synchronization in particular. Interesting for us to see that work here. First time in W3C groups. 08:17:47 Christian Fuhrhop, Fraunhofer FOKUS - proxy for Louay 08:18:28 Chritian_Fuhrhop: from Fraunhofer FOKUS, I'm essentially proxying other colleagues here as they will be busy with the Media Web Symposium 08:18:57 Yougyun_Song: from LG Electronics, observing the meeting 08:19:38 I think Younghun Song is right 08:19:50 Topic: Agenda review 08:20:22 Anssi: The agenda has been online for a month or so. I propose to look at it and see if there are things that we want to shuffle around, drop, or add. 08:20:44 -> https://www.w3.org/wiki/Second_Screen/Meetings/May_2015_F2F#Day_1_-_Tue_19_May_2015 Agenda for day 1 08:21:05 Anssi: I'd like Mark to walk us through the spec 08:21:54 ... Then a Warm up session, to discuss use cases and requirements and see whether they still match the reality. From time to time, new features come in. 08:22:10 q+ would like to ask about agenda 08:22:11 s/Michael_Kong/Michael_Kang/ 08:22:18 q? 08:22:30 Zakim has joined #webscreens 08:22:46 q+ would like to ask about agenda 08:22:58 q+ to ask about agenda 08:23:00 q? 08:23:06 ack anssik 08:23:06 anssik, you wanted to ask about agenda 08:23:14 Anssi: [demoing Zakim's queue] 08:23:22 q+ suggest addition to "warm up" part of the agenda 08:23:38 q+ propose change to warm up 08:23:53 q+ to ask what does it mean to be an observer at the F2F meeting? 08:23:59 q+ to propose change to warm up on agenda 08:24:07 whywhat: thanks! 08:24:33 Anssi: After use cases and requirements, Francois should take us through the evaluation of security and privacy that he made against the Presentation API. 08:24:51 s/Yougyun_Song/Younghun_Song/ 08:25:21 ... Matt would like to jump in the warm up session to introduce the discussion on the alignment between HbbTV and the Presentation API. 08:25:50 stepsteg has joined #webscreens 08:26:04 Matt: Yes, I have a short set of slides to present. 10 minutes should be enough to get up to speed. Then we can discuss during the relevant parts of the agenda and get back to it at the end. 08:26:31 Anssi: Any concern to fit that in the warm up session? 08:26:49 Anton: Shouldn't we do that for other technologies as well? 08:27:14 Anssi: That's a good point. We could do a session about the different technologies, indeed. 08:27:29 Louay: We may also do demos in that session, e.g. with Miracast. 08:27:40 Anssi: OK, my only concern is preserving time. 08:28:23 ... I'm hearing Matt could introduce HbbTV, Mark or Anton for Google, Chien for Mozilla and Oleg for Samsung. 08:28:46 ... Goal is to extract the main issues. 08:29:01 Oleg: I also raised several use cases that could fit here. 08:29:13 Anssi: Let's use the use cases session for that. 08:29:54 ... Then warm up becomes: use cases and requirements, security and privacy, review of different technologies 08:31:16 Anssi: After warm up session, we enter the core of the discussions. I was happily surprised that we're using GitHub issues so well. For each issue, I would like someone who is familiar with the issue to present it, then proposals to be made. 08:32:09 ... We may resolve on some proposal, but note that resolutions are provisional until after 10 days after the meeting to allow people who are not in the F2F to react. We will pass around calls for consensus on the mailing-list. 08:32:11 q? 08:32:16 q- 08:32:20 q+ 08:32:22 q? 08:32:33 ack whywhat 08:32:34 whywhat, you wanted to ask what does it mean to be an observer at the F2F meeting? 08:33:09 Anton: Some people mention that they're observing the meeting. What does that mean? 08:34:52 ack mfoltzgoogle 08:35:23 Anssi: Great question. Meetings are restricted to group participants usually. Chair can invite other people provided they request observer status in advance. I approved requests I received for this meeting. 08:35:51 jcdufourd has joined #webscreens 08:37:20 Mark: Question on GitHub issues and possibility to edit the spec before resolutions are taken 08:37:24 q+ 08:38:22 Anssi: W3C Process is not meant to block you. Let's be flexible. With Git, it's easy to revert things. Proposals can be integrated unless concerns are raised. 08:39:05 Francois: Right, W3C process is not meant to block you, so feel free to work the way you prefer as long as people in the group are fine with it 08:39:12 q? 08:39:21 Anssi: The editor is the one that manages the spec, so whatever works for you 08:39:25 ack hongki 08:39:45 Hongki: For curiosity, our document is an editor's draft, right? 08:40:51 +1 to tidoust proposal 08:40:54 Anssi: Editor's draft is the latest version, published from time to time in TR space 08:41:17 q? 08:41:23 needs to define the "time to time" 08:41:26 Francois: Right, one possibility that I encourage is to automatically publish editor's drafts in TR space. That's easily doable nowadays. 08:41:43 Anssi: Good point. Noting this for later discussion. 08:42:58 Anssi: Back to the agenda and the list of priorities. Any need to shuffle things around? [going through the rest of the agenda]. 08:43:31 ... Focus for day 2 is on new features. In the morning, if we have issues left out from day 1, we should address them on day 2. 08:43:59 ... Then new features. Then lunch and after lunch, we have the open session with the 5th Media Web Symposium. 08:44:30 ... This gives us an opportunity to engage with the community. 08:44:56 ... [reviewing the MWS second screen agenda] 08:45:37 -> https://www.fokus.fraunhofer.de/go/mwsworkshops#Content-5b1390b6 Media Web Symposium - Multiscreen 08:45:46 q? 08:46:09 Anssi: After the open session, we'll wrap things up and get to the social dinner. 08:46:25 Stephan: There will be a bus to go to the social dinner. 08:46:40 Anssi: Any question on the agenda? 08:46:46 [none heard] 08:47:37 Topic: Walkthrough of the Presentation API 08:48:59 RRSAgent, draft minutes 08:48:59 I have made the request to generate http://www.w3.org/2015/05/19-webscreens-minutes.html tidoust 08:49:30 Present+ Jean-Claude_Dufourd 08:50:00 -> http://w3c.github.io/presentation-api/ Presentation API 08:50:17 Mark: [introducing the Presentation API] 08:50:29 ... The Status of This Work is mostly boilerplate 08:50:34 q? 08:51:27 Mark: Then we list use cases and requirements that we would like to cover, conformance, terminology and examples, and finally we go into technical details about the API, interface definitions and algorithms. 08:51:53 ... The security and privacy section is currently a placeholder 08:52:25 ... The introduction explains that we want to make sure that we cover a wide range of technologies, using wired and wireless technologies. 08:53:10 ... At the core, the page wants to give the browser a URL to some content to present, and then get some way to communicate between the controlling and presenting page. 08:54:01 ... We use the terms 1UA and 2UA to reference two different scenarios: in the 1UA case, the user agent streams audio/video content to the remote display. Technologies such as Cast or Miracast are the main target. 08:54:31 ... The second use case is when you are talking to another agent. The first UA just gives the URL to the second one. 08:55:09 ... This can provide a higher quality in the video experience because you can use the local hardware resources to render the video, which is good, especially if the first device is a mobile phone. 08:55:49 Mark_Watson: I would mention support for native apps on the second device in the introduction. That's in scope but not mentioned right now. The target device may not support HTML5. 08:56:47 ... I'm not sure there's anything else needed in the spec to address this use case, but it would be good to see that in the introduction. 08:57:02 Mark: ok. 08:57:58 Mark: Moving on to use cases. We want to support presentations, multiplayer gaming and multiple screens to render multiple content to multiple screens. 08:58:18 ... One additional detail I did not mention is reconnection to existing sessions. 08:59:31 ... Skipping over conformance and terminology sections. Examples show how the API can be used in practice, to start sessions, exchange messages, and also what the presenting page code could look like. 09:00:18 Anssi: We should not underestimate the power of examples. Developers will look at that section first and copy the code that appears there. Please let's maintain this to ensure that the content in that section matches the current API. Think about examples in your pull requests! 09:00:54 Mark: [quickly going through the API definition]. 09:01:24 mdadas_ has joined #webscreens 09:01:24 ... Two main interfaces: the PresentationSession is an object that looks like an RTCDataChannel. That's on purpose. 09:01:48 ... It contains the state of that connection, an ID to attach an identifier to that presentation session. 09:02:24 ... The other interface is NavigatorPresentation defines the entry points to the Presentation API, to start and resume presentation sessions. 09:02:50 ... One important event is onavailablechange that alerts you when a display is available. 09:03:23 Anssi: I note that the stability of "onavailablechange" is under discussion 09:03:49 Mark: We need to do a bit of work to define the algorithm for starting the presenting page on the presenting side. 09:04:14 q? 09:04:19 Mark: We started the process of identifying the security and privacy considerations for this API. To be discussed. 09:04:26 s/Mark:/Mark_Foltz:/g 09:05:13 Mark_Foltz: A logistical note, we try to cross-reference GitHub issues from within the spec 09:05:28 Anssi: Not perfect but pretty useful 09:06:00 Topic: Use cases and requirements 09:06:18 -> https://github.com/w3c/presentation-api/issues/68 Use case and requirements issue 09:06:50 Anssi: When we add something to the spec, it should be motivated by use cases, otherwise people will want to inject their own ideas which could lead to scope creep. 09:06:59 +q 09:07:02 q+ 09:07:09 q+ 09:07:15 ... Is the list we have still valid? Should we add some? Should we drop some? What about the list of requirements? 09:07:16 q? 09:07:20 ack hongki 09:08:11 Hongki: For the multiplayer gaming use case, there's a good and illustrated definition on GitHub. Why is that not reflected in the editor's draft? 09:08:38 Louay: This use case is multiplayer gaming in general, and this is a more concrete example with a Poker game. 09:08:41 q+ 09:08:52 Mark_Foltz: It elaborates on the existing use case. 09:09:17 +q 09:09:23 Anssi: Some groups have a separate use cases and requirements document. We may consider doing the same thing. I think that could fit here. 09:09:27 q+ 09:09:29 q+ 09:10:05 Anssi: Are there people in the room interested in contributing to that spec? 09:10:36 ... We can put it in a Wiki to start with, and people can contribute there. 09:11:20 ACTION: Louay to initiate the Use cases and Requirements document (probably on a Wiki page) 09:11:33 q? 09:12:01 ack obeletski 09:12:44 Oleg: We were also thinking about use cases. I posted the example of Pictionary game on the mailing-list. I don't think that it adds a lot of requirements. I agree that it makes sense to create a separate document. 09:12:56 Anssi: So maybe you can work with Louay. 09:13:22 q? 09:13:22 Oleg: Another note, I do not see how joinSession maps to existing use cases right now. 09:13:49 ack whywhat 09:14:18 Anton: We may want to refactor the use cases as there is some overlap between audio/video sharing and media flinging 09:14:43 ACTION: Anton to refactor use cases to avoid overlap 09:14:55 q? 09:15:04 ack mfoltzgoogle 09:16:31 Mark_Foltz: I have two potential use cases to fold in the document. One that does not add new requirements but is useful: working on a shared document. The second use case is about companion screens that can accept input. It could be useful to have that in the list. 09:17:04 ... How does a touch-sensitive or input-sensitive display relate to the API. 09:17:05 q? 09:17:10 Anssi: That's interesting. 09:17:11 ack mh 09:18:27 Matt: Reading the Media flinging, I'm also thinking about the application lifecycle. You have some model when you initiate the session from a device, then close that session, resume it. Other people in the room may want to continue to interact with the TV as I'm presenting video with it. 09:18:34 Anssi: Is it many-to-one mapping? 09:18:54 Matt: It could be but my primary thought was around the application lifecycle. It would be good to capture that. 09:19:09 q? 09:19:12 Anssi: We have a specific session as part of the multi-screen session. 09:19:41 Oleg: Having clarifications around lifecycle would make the life of developers way easier as well. 09:20:16 Mark_Foltz: Right, if we have a use case, we should have some code example as well and some sort of state diagram that explains the lifecycle. 09:20:23 Anssi: Right. 09:20:35 q? 09:20:40 Anssi: Let's move to requirements. 09:21:20 Mark_Foltz: [going through requirements] 09:21:22 song has joined #webscreens 09:21:46 q+ 09:22:06 q+ 09:22:08 Mark_Foltz: For launching the presentation, it may be up to the Web app, or the UA may provide a menu to launch the presentation. 09:23:00 q? 09:23:03 ... Controlling page and presenting page may or may not be on the same user agent, the API abstracts that away and the pages should not know anything about it 09:23:15 ack schien 09:23:38 Schien: We have use cases for multiple users but the functional requirements kind of miss that part 09:24:32 ACTION: Schien to complete the list of requirements with multiple users ones 09:25:14 q+ 09:25:15 q? 09:25:20 ack jcdufourd 09:26:08 Jean-Claude: My question is about the note on multi-screen enumeration and named identification requirements being removed. The user agent still lists the screens to the user while the Web page only has "present or not", right? 09:26:22 ... The user still gets to choose the target screen? 09:26:51 Anssi: Yes, it's similar to the file picker. Same abstraction to address security issues. 09:27:41 Jean-Claude: You mentioned the ability to delegate rendering but also sensing, user inputs. 09:27:51 Anssi: That could be future extensions. 09:28:26 Jean-Claude: probably you can already do it today over the bi-directional communication channel. I'm just wondering whether mentioning it here could be a good idea. 09:28:50 Anssi: I think we have one issue for that. 09:28:56 Mark_Foltz: Yes, we have 09:29:05 q? 09:29:08 Anssi: I agree that's something missing from the spec. We're not really clear on that yet. 09:29:10 ack obeletski 09:30:00 Oleg: Another potentially missing requirement. I understand that you may want to support multiple screens. If that's the case, it may impact the API and should appear in the list of requirements in any case. 09:30:00 Mark_Foltz: Yes. 09:30:44 q? 09:33:04 scribe: anssik 09:33:17 Topic: Security and privacy evaluation and considerations 09:34:37 -> https://github.com/w3c/presentation-api/issues/45 Security and privacy evaluation and considerations 09:34:48 jcduford: Adding better support for remote sensors could be a good topic to discuss in the webscreens community group. https://www.w3.org/community/webscreens/ 09:35:16 tidoust: do not expect us to do resolutions in this specific slot 09:35:34 ... it is important to review the spec from privacy and security perspective as early as possible 09:35:51 ... we may hit these at later stages along the Rec Track 09:36:07 ... there's no yes or no answers in this, finding the right balance is the key 09:36:34 ... there are bunch of people from WebAppSec who've produced a questionnaire other groups can use to evaluate their specs 09:36:44 ... this questionnaire is not complete, but is useful nevertheless 09:37:06 ... I'll go through the observations I've made while completing the questionnaire 09:37:19 ... secure context, I'll get back to it at the end 09:37:37 ... Does this specification deal with personally-identifiable information? 09:37:52 ... does not expose the list of devices 09:38:12 ... only whether there are one or more displays available 09:38:28 ... can disclose user's location, e.g. at home vs. in a hotel 09:38:38 ... implications on filtering 09:39:24 ... if the API conveys information that it is able to render specific content that'd be a bigger privacy issue 09:40:11 ... Does this specification deal with high-value data? 09:40:13 ... no 09:40:21 ... Does this specification introduce new state for an origin that persists across browsing sessions? 09:40:39 ... there may be things we should address related to this 09:41:03 ... if you know the URL and id, you can attach to a session running regardless of where you (physically) are 09:41:40 q? 09:41:53 q+ 09:42:21 ack jcdufourd 09:42:54 jcdufourd: you said something about filtering, and related risks 09:43:56 tidoust: the idea is to allow the web site to show the "display on a second screen" button only if the action could succeed 09:44:25 whywhat: proposes to focus on browser initiated presentations 09:44:31 ... to solve the issue 09:46:39 q? 09:46:51 mh: no position on the proposal 09:47:07 ... can see the advantages though from the privacy and security perspective 09:47:26 ... may work with a relative static web content 09:47:38 ... we're talking of a wide range of use cases 09:47:51 +q 09:48:11 ... if we have control over the UI widgets then we can customize the UX more 09:49:16 q+ 09:51:06 q+ 09:51:57 q? 09:52:01 ack mfoltzgoogle 09:52:28 mfoltzgoogle: in cast, can initiate from the browser or the page 09:53:17 ACTION: I can see if there is any data we can share about user behavior around that. 09:53:22 q- 09:53:33 ACTION anton to explore browser initiated presentation via declarative approach 09:53:48 ACTION: anton to explore browser initiated presentation via declarative approach 09:54:01 q? 09:54:05 ack markw 09:54:24 markw: Netflix's UX people would prefer to have control over the UX 09:54:44 ... they like the current state where they can render the icon at least 09:55:08 ... makes it possible to implement consist UX across browsers 09:56:51 anssik: 09:58:18 ... another related, but tangential, issue is how devices that the page knows how to reach via a cloud service, say, can be exposed to the user 09:58:22 tidoust: Secure Contexts 09:58:37 ... in a uniform way with devices on the local network that are discovered and managed by the UA 09:58:40 ... WebRTC WG is doing a bunch of specs that have some overlap 09:59:00 ... Media Capture and Stream and Output Devices allow enumerating output devices 09:59:32 ... we may want to reuse that pattern 09:59:51 ... currently restricted to audio only, but would be extended to video 10:00:09 ... we want to cover the presenting video and audio content 10:00:35 ... not the right abstraction to present video control directly 10:01:02 ... Audio Output API proposes a sinkId on an HTMLMediaElement 10:01:14 ... that associated the HTMLMediaElement with a device 10:01:20 ... something we may want to look at too 10:01:29 ... perhaps interact with the WebRTC WG 10:02:17 ... to filter devices, by splitting the work to 1) present HTML content 2) dedecated to media 10:02:51 s/dedecated/dedicated/ 10:03:40 markw: we do not necessarily mean HTMLMediaElement only 10:03:51 ... there's a bit more than just render media content 10:05:30 ACTION: tidoust to look into WebRTC WG's Audio Output API and its reuse in the context of the Presentation API 10:06:53 [breaking out for lunch, back at 1 PM] 10:44:09 mfoltzgoogle has joined #webscreens 10:56:58 tidoust has joined #webscreens 10:57:04 RRSAgent, draft minutes 10:57:04 I have made the request to generate http://www.w3.org/2015/05/19-webscreens-minutes.html tidoust 10:57:22 bigscreen has joined #webscreens 11:00:54 [starting now] 11:01:44 tidoust: wrapping up the discussion on security and privacy 11:01:48 Louay has joined #webscreens 11:01:59 ... the network service discovery spec attempted to solve discovery 11:02:10 ... had issues with security 11:02:11 schien has joined #webscreens 11:02:13 whywhat has joined #webscreens 11:02:17 ... now the spec requires CORS support 11:02:21 hongki has joined #webscreens 11:02:28 ... which mean legacy device cannot be supported 11:02:38 ... we should see if CORS is required for the Presentation API 11:02:51 ... the API is means for devices that are already able to access the Web 11:03:08 ... if we allowe specific URL schemes we're open to new class of devices 11:03:13 s/allowe/allow/ 11:03:47 ... a minor point: "Does this specification allow an origin some measure of control over a user agent’s native UI?" 11:04:10 ... Does this specification expose temporary identifiers to the web? 11:04:17 ... that'd be URL and id 11:04:28 ... How should this specification work in the context of a user agent’s "incognito" mode? 11:04:48 ... implication of the incognito mode on the Presentation API 11:04:58 schien has joined #webscreens 11:05:07 q+ 11:05:10 Michael_Kang has joined #webscreens 11:05:12 anssik: what do other specs say about "incognito"? 11:05:52 tidoust: yes, some specs impose extra requirements for "incognito" 11:06:14 ACTION: tidoust to look into "incognito" requirements on the spec 11:06:34 mdadas has joined #webscreens 11:06:44 ... this ties into the app lifecycle too, the web developer should understand that 11:07:18 ... security requirements on the messaging channel 11:07:49 ... While the spec will not mandate communication protocols, it should set some guarantees of message confidentiality and authenticity. 11:08:07 ... same problem as with the WebRTC 11:08:13 ... can learn or adapt from it 11:08:43 ... mark has a nice summary at https://github.com/w3c/presentation-api/issues/45#issuecomment-103376106 11:09:22 ... no good answer to security and privacy, we must have the right acumen 11:10:48 ... in the Rec Track, at Last Call maturity we are expected to seek review from accessibility, internationalization, security and privacy groups 11:11:06 ... of course we can initiate discussion with there group already now 11:11:21 ... suggest to initiate the discussion with internationalization soon 11:11:22 q? 11:11:26 ack anssik 11:13:43 ACTION: tidoust to seek review from PING and Web Security IG when the spec has adapted F2F changes 11:13:50 q? 11:14:25 mfoltzgoogle: do you want to incorporate feedback to the spec's security and privacy section 11:14:39 tidoust: low hanging fruits could be baked in already 11:15:34 ACTION: mfoltzgoogle to prime the Security and Privacy Considerations section with content from https://github.com/w3c/presentation-api/issues/45 11:15:41 q? 11:17:34 scribe: cf 11:18:03 Topic: HbbTV 2.0 and the Presentation API 11:18:10 Subset of Application lifecycle in HbbTV 2.9 slides to be presented 11:18:25 Short description of HbbTV 2.0 11:19:07 HbbTV - essentially web content on a television 11:19:15 s/2.9/2.0/ 11:19:32 Signalling usually in broadcast stream, content in most cases on a server 11:20:20 Broadcast related content can only be presented if boradcaster allows it 11:20:48 Other aplications can be broadcast independend. No access to broadcast stream, but can play IP streams. 11:21:25 soonbo has joined #webscreens 11:21:43 HbbTV devices can be discovered with DIAL protocol 11:22:21 DIAL can launch apps on TVs (with addressing of specific security concerns) 11:22:57 Devices get paired, communication is via websocket message passing. 11:24:23 Pairing requires URLs with mazching string 11:24:57 Relation to Presentation API - 11:25:18 parameters would be useful to pass HbbTV specific information 11:25:50 Do applications need to be aware that the device it is paired with is HbbTV? 11:26:32 Lifecycle problems may occur if a presentation starts, but does not connect on web socket. Or an app is 11:26:48 still running when communication disconnects. 11:27:01 Processes can't be remotely controlled/stopped. 11:27:44 Re-connection can not be guaranteed. Would likely require a restart of application. 11:30:31 Multiple connections can be made with same URL suffixes, but communication would likely fail on websocket communication establishment. 11:31:42 q? 11:31:45 Slides are attached to github issue, contain more information... 11:32:57 stepsteg has joined #webscreens 11:35:04 slides are here: https://myshare.app.box.com/s/rl2joltd6pyu6hx7flbpc1zu91pbptvu 11:35:14 also attached to: https://github.com/w3c/presentation-api/issues/67 11:36:01 Mark Foltz: Presentation on Cast in Chrome 11:36:26 Second screen functionality by browser extension 11:38:17 Three basic use cases - web page controls video, web page controls slide show, web page mirrored externaly 11:39:31 Chrome architecture - renders generally separated from browser. Media router component allows rendering on external devices. 11:40:29 Handles PresentationAPIs and UI for controlling/linking them. 11:40:50 Communication done with "Mojo IPC" protocol. 11:41:40 If site for presentation gets available they register to media router. 11:42:15 App can detect change and then start presentation session on presentation device. 11:43:25 If device can render content directly or use cast sharing or webRTC to render on another device 11:43:56 ProviderManager provides common interface to cast/dial/hangout 11:46:58 q? 11:48:30 Schien: How do you perform the webRTC conections? 11:49:07 Mark: Basically using the underlying services (in this case Hangout), i.e. some server on the network, not locally, 11:49:45 Schien: Two presentation modes 11:50:24 Presents architecture. 11:52:38 Lifecycle stages: Dicovery, control channel establishment,presenting page launching, app-to-app transport channel establishment 11:53:05 control channel closure - on session closure app-to-app channel closure 11:54:50 Built-in protocols for Firefox-Firefox connection - presenter broadcasts info on port 9876 11:55:10 requester determines which end point it can talk to ans establishes RTC channeö 11:59:00 security model reduces footprint on presentation device - no access to device storage, indexDB or cookie 11:59:15 Web pages are launched in a sandbox 12:02:26 mdadas has joined #webscreens 12:02:55 Future work - support for Firefox browsers, resume/join facility, binary messaging, HDMI and WiFI Display support, 12:03:05 possibly one to many sessions 12:03:25 s/one to many/one-to-many/ 12:04:32 q? 12:06:23 (Staying in agenda order, not re-sorting the order of issues to be discussed) 12:07:25 (Actually we are changing the order of issues right now - see updated wiki page) 12:10:24 scribe: mh 12:10:54 Anssi: To scribe, prefix the line with the name of the one who speaks 12:11:13 ... then use continuation dots followed by a space not to repeat the name of the speaker 12:11:26 Topic: Define a bi-directional data channel between opening and presenting browsing contexts 12:11:49 -> https://github.com/w3c/presentation-api/issues/46 Bi-directional data channel issue on GitHub 12:13:15 Anssi: The group has been exploring options such as WebRTC. Have been converging. 12:14:29 mfoltzgoogle: need to clarify this is message oriented ... generating events. no fragmentation. 12:14:43 obeletski has joined #webscreens 12:15:25 ... Do we need to specify message size limits? Or a minimum supported size? 12:17:43 anssik: only specify if an issue emerges. 12:19:08 mfoltzgoogle: Make explicit that the message channel is reliable and in-order 12:19:42 schien: Agree this is reasonable. 12:21:14 hyojin has joined #webscreens 12:23:04 PROPOSED RESOLUTION: adopt the "send"-like interface and clarify in the spec that the data channel is an in-order reliable message-based communication channel. 12:25:16 whywhat: Chrome silently doesn't send empty mesages in WebRTC. Could this be expected to work as a "ping" mechanism? 12:28:28 markw: WebSockets spec says nothing about this. Doesn't indicate that empty messages are a special case. 12:29:45 ACTION: tidoust to look at how WebSockets and how WebRTC data channels deal with empty messages 12:30:17 topic: Define (cross) origin relationship between opener and presenting page 12:30:22 RRSAgent, draft minutes 12:30:22 I have made the request to generate http://www.w3.org/2015/05/19-webscreens-minutes.html tidoust 12:30:49 -> https://github.com/w3c/presentation-api/issues/63 Define (cross) origin relationship between opener and presenting page 12:32:21 schien: Propose we define the origin relationship. Webpages can be easily inspected, so security authentication judgement woudl have to be deferred to a separate (e.g. server side) security agent. 12:32:26 But for the Presentation API we might there may not be access to cloud services. Need to define security guarantees. 12:32:43 Propose to learn from window.postMessage design 12:34:03 ... For example: If JS inside embedded iframes only wants to talk to outer frame with same origin, it can specify this. 12:34:16 ... The browser makes the check 12:35:45 jcdufourd: If I start a Netflix native app from my app, my domain will not match netflix.com domain. 12:36:21 markw: haven't assumed origin associated with two separate UAs 12:36:41 ... the two UAs are isolated/independent 12:37:36 mfoltzgoogle: this is an app to app authentication problem ... both sides should use a 3rd party to help with that. 12:39:20 ... CORS? Probably doesn't make sense though ... doesn't protect the server 12:40:48 ... same origin requirement probably too restrictive and creates obstacle to reusing presentations. Can't see how it can be enforced. 12:41:45 tidoust: window can determine origin of its content. 2nd screen (UA2) cannot reliably check the origin of UA1 12:42:42 markw: app cannot trust UA (or the UAs trust in each other) ... app developers must implement this kind of authentication check for themselves 12:46:36 anssik: what are the risks? app on UA1 would have to choose to launch malicious presentation on UA2 12:47:58 schien: Concern is how does the app launched on UA2 know if it can trust the app that launched it on UA1 12:49:57 schien: UA1 passes origin information to UA2. Will not prevent attacks if UA1 is compromised; but will work if UA1 is uncompromised 12:52:06 ... could be done by authenticating a token with a cloud service and passing that across. But does not work if there is a local network but no internet access 12:53:36 jcdufourd: in this situation, the devices on the home network are traditionally considered trusted (e.g. how UPnP works) 12:55:18 Louay: We must also consider sitautions where one of the two parties is an app without origin (because it is not a UA) 12:56:07 ... or because it is a packaged web app 12:57:43 http://www.w3.org/TR/app-uri/ 12:58:05 mfoltzgoogle: proposed approach sounds Firefox OS specific ... is there scope for defining an extension to the basic spec for this, to avoid impacting other use cases? 12:58:52 anssik: We are targetting browsers. Packaged web apps are perhaps appropriate to consider as an extension. 13:00:44 markw: summary: UA2 and UA1 cannot practically agree to exchange info about target origins without mandating something (new) at the protocol level, which is out of scope. Does not give effective trust information. 13:01:31 anssik: but is possible for certain use cases / implementations as described by schien 13:02:47 schien: will go away and consider proposals from mfoltzgoogle 13:05:48 ACTION: schien to look to see if there is a chance to apply CORS origin check approaches to Firefox OS specific packaged app 13:07:00 PROPOSED RESOLUTION: drop step 3 in 6.3.2 Receiving a message through PresentationSession, the message origin will not be conveyed. 13:08:45 RRSAgent, draft minutes 13:08:45 I have made the request to generate http://www.w3.org/2015/05/19-webscreens-minutes.html tidoust 13:08:45 topic: Define security requirements for messaging channel between secure origins 13:09:09 -> https://github.com/w3c/presentation-api/issues/80 Define security requirements for messaging channel between secure origins 13:10:42 mfoltzgoogle: If web apps on both UA1 and UA2 are running in a secure context, can they expect this of the channel? 13:11:07 ... But difficult to do between two devices at the browser level. 13:11:48 ... Either: encourage web developers to do their own encryption (e.g. using WebCrypto) ... Or we try to provide stronger guarantees. 13:12:41 ... suspect it is better to leave it up to the application for now, but leave open to change in the future. 13:13:38 ... attacks will be likely within the LAN, so perhaps more limited. This is qualitatively different to the open internet. 13:13:42 What do other people think? 13:15:24 tidoust: currently, a web app from a secure origin cannot open an unsecure WebSocket ... this feels analogous 13:16:26 ... but we must address this issue in the spec in some way 13:19:51 markw: If you cannot open an unsecure WebSocket connection then it is not possible to communicate with another device on the local network. We need to allow it (but mediated via the Presentation API, not by using the WebSocket API) ... but is this acceptable to the security teams? (Green padlock still showing despite an unencrypted communication channel being present) 13:20:20 s/teams/people/ 13:21:03 tidoust: we should raise this issue with other groups 13:21:46 markw: app on UA1 could provide fingerprint of self signed cert provided by app on UA2 (for validation by UA1). Thoughts? 13:22:06 markw: One option to consider would be for the secure page requesting a presentation session to provide the fingerprint of a self-signed cert at the target device that will be used to secure the point-to-point communication between the devices 13:22:52 markw: One option to consider would be for the secure page requesting a presentation session to provide the fingerprint of a self-signed cert at the target device that will be used to secure the point-to-point communication between the devices 13:23:16 mfoltzgoogle: at minimum, some implementation guidance is needed. 13:24:20 anssi: messaging channel security currently out of scope 13:25:35 ... but does at some level need addressing 13:26:16 PROPOSED RESOLUTION: keep issue 80 open while we gather more implementation experience. Highlight issue asking for feedback when getting in touch with PING / Web security IG 13:28:33 markw: Another direction would be for the Presentation API to provide a way for the UA to request the site to help transport key exchange messages, with the resultant keys being used to secure the direct local network communication 13:29:04 RRSAgent, draft minutes 13:29:04 I have made the request to generate http://www.w3.org/2015/05/19-webscreens-minutes.html tidoust 13:30:06 [breaking for coffee for 10 minutes, resuming at 3.40 PM] 13:30:36 one of the issues in the above discussion is: in the 2 UA case, with separate implementations on the two sides, there is a need for spec text to have interoperable communication (with or without security) 13:46:56 scribe: tidoust 13:47:18 Topic: Refine how to do session teardown/disconnect/closing 13:47:42 -> https://github.com/w3c/presentation-api/issues/35 Issue #35 13:48:47 Mark_Foltz: 2 scenarios. One where the user requests that the presentation be stopped through the browser in the 1-UA case. That's pretty straightforward. 13:49:18 ... The other scenario is when the user agent closes the presenting session. 13:49:55 ... [going through bullet points in issue #35] 13:51:54 ... choice between adding a disconnectReason to the statechange event or an error event to PresentationSession. Do not feel strongly one way or the other. 13:52:14 Schien: Only two states right now, there should be more. 13:52:37 Anssi: The list of states is indeed open for revision. 13:53:23 Schien: for entering the "terminated", it must be an explicit app call. Successful close from an application perspective. 13:53:34 s/"terminated"/"terminated" state/ 13:53:58 Schien: Otherwise the connection is disconnected but still alive. 13:55:04 Matt: Also useful while initializing the connection as I understand the connection starts in a "disconnected" state and it would be useful to distinguish that from the end of the application lifecycle. 13:58:52 tidoust_ has joined #webscreens 13:58:58 scribe: tidoust_ 13:59:08 Matt: It would be interesting to understand what "disconnected" mean in practice. 13:59:15 Mark_Foltz: It is going to be difficult to distinguish between various situations. You don't know in most cases. 13:59:19 ... Using joinSession is a way to reconnect to re-establish current session in case of temporary failure. 13:59:26 bigscreen_ has joined #webscreens 14:01:44 Mark_Foltz: I think we're agreeing to add the "terminated" state. 14:02:44 Francois: what does "disconnected" mean for the application developer? Does it mean that he has to call joinSession to resume the session, or will the user agent continue to try to re-establish the session in the background? 14:02:53 mdadas has joined #webscreens 14:04:04 Mark_Foltz: "disconnect" really means the UA surrendered. Then the app can implement whatever logic is needed 14:05:54 Oleg: In Samsung Multiscreens tech, quite close to HbbTV, you may pass a boolean flag to "close" that keeps the presenting side open. 14:06:14 ... If you close the session from the originating page, what is happening to the presenting page? 14:07:58 Mark_Foltz: Right now, the behavior is really defined for one connecting session and so "close" will request the presenting side to close as well. When we consider multi-screens scenarios, we should revisit that. 14:08:13 hongki has joined #webscreens 14:08:16 ... Good topic for the multiple screens session! 14:09:42 Anton: the spec does not say anything about what happens to the presenting page and should say something. 14:09:44 mfoltzgoogle has joined #webscreens 14:11:20 mdadas has joined #webscreens 14:11:50 PROPOSED RESOLUTION: for #35, add a "terminated" state to the list of connection state and clarify in the spec what happens on the presenting side when "close" is called 14:12:17 obeletski_ has joined #webscreens 14:14:04 Bigscreen has joined #webscreens 14:14:59 RRSAgent, draft minutes 14:14:59 I have made the request to generate http://www.w3.org/2015/05/19-webscreens-minutes.html tidoust_ 14:16:51 TOPIC; Specify the presentation initialization algorithm 14:17:18 TOPIC: Specify the presentation initialization algorithm 14:17:36 s/TOPIC; Specify the presentation initialization algorithm// 14:18:14 -> https://github.com/w3c/presentation-api/issues/34 Issue #34 14:22:54 mfoltzgoogle: Need to make sure presentation session is able to know when it's connected. 14:24:34 anssik: From a webdev perspective, better to set session before onload. 14:25:13 obeletski_: Single time async operation calls for Promise. 14:26:24 PROPOSAL: Promise NavigatorPresentation.getSession() 14:29:58 Zakim has left #webscreens 14:32:42 whywhat has joined #webscreens 14:33:04 Zakim has joined #webscreens 14:34:11 mh: Do we need a "connecting" state while the presentation connection is established? 14:34:15 markw has joined #webscreens 14:34:48 tidoust_: If we leave the Promise unresolved while the connection is established, then it can serve the same purpose. 14:42:15 obelestki_: What about leaving Promises unresolved for joinSession()? 14:42:51 mwatson: Concerns about programming model. Developers expect them to resolve in a reasonable amt of time. 14:42:52 soonbo has joined #webscreens 14:43:12 jcduford,mfoltzgoogle: Concern about garbage collection and implementation complexit. 14:43:31 mfoltzgoogle: PROPOSAL: Strike unresolved Promises proposal from joinSession() algorithm. 14:43:37 PROPOSED RESOLUTION: For #34, keep the "joinSession" algorithm in 6.4.2 deterministic and strike the issue note 14:43:54 PROPOSED RESOLUTION: For #34, keep the "joinSession" algorithm in 6.4.2 deterministic and strike the issue note about unresolved Promises 14:44:42 PROPOSED RESOLUTION: Promise NavigatorPresentation.getSession() 14:45:25 RRSAgent, draft minutes 14:45:25 I have made the request to generate http://www.w3.org/2015/05/19-webscreens-minutes.html tidoust 14:47:37 PROPOSED RESOLUTION: Promise NavigatorPresentation.getSession() which resolves when the communication channel is established and rejects if the communication channel cannot be established 14:49:26 i/mfoltzgoogle: Need to make sure/scribe: mfoltzgoogle/ 14:49:29 RRSAgent, draft minutes 14:49:29 I have made the request to generate http://www.w3.org/2015/05/19-webscreens-minutes.html tidoust 14:49:51 scribe: mfoltzgoogle 14:52:37 TOPIC: Specify behavior when multiple controlling pages are connected to the session 14:52:49 https://github.com/w3c/presentation-api/issues/19 14:57:22 mfoltzgoogle: Added joinSession, need to define behavior when there are multiple connected session to the presentations. 14:58:07 schien: PROPOSAL: Promise NavigatorPresentation.getSessions(), onsessionavailable would fire when the list had changed. 14:58:29 markw_ has joined #webscreens 14:58:48 tidoust_: Do we need to return a Promise to return the list? 14:59:22 mh: I don't want to know that there are two sessions, don't want to do a diff on the list. 15:01:13 q+ 15:01:14 eschien: add an onnewsession handler for additional connected sessions. 15:02:47 mh: What if you call getSession() after there are multiple sessions available? Don't you want to know about all sessions? 15:03:36 https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#navigator-service-worker-getRegistration 15:03:45 https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#navigator-service-worker-getRegistrations 15:03:57 anssik: ServiceWorker returns Promises for getRegistration and getRegistrations 15:04:42 q? 15:04:47 ack Louay 15:06:19 Louay: In CG we had onpresent. Why did we reject that proposal? 15:06:42 https://www.w3.org/community/webscreens/wiki/API_Discussion#Usage_on_Remote_Screen 15:08:17 mdadas_ has joined #webscreens 15:13:30 blassey has joined #webscreens 15:13:59 mfoltzgoogle PROPOSAL: NavigatorPresentation.sessions[] initialized with a single PresentationSession for the opening page. NavigatorPresentation.onsessionavailable when array changes. 15:14:39 echein: Don't use array attributes, Web developers can modify prototype 15:16:04 eschien: Replace array with PresentationSession[] NavbigatorPresentation,getSessions() 15:17:32 jcduford: Not compatible 15:18:25 jcduford: Not incompatible. For simple case use a Promuse, for advanced cases use getSessions()/onsessionavailable. 15:19:30 s/jcduford: Not compatible// 15:19:37 jcduford: Promise NP.getSession(), PresentationSession[] NP.getSessions(), NP.onsessionavailable event when set of sessions changes. 15:19:54 q+ 15:21:13 jcdufourd has joined #webscreens 15:21:48 s/jcduford:/jcdufourd:/g 15:23:33 song has joined #webscreens 15:23:53 q? 15:23:57 ack mh 15:25:02 discussion in the CG on multiple sessions/channels https://lists.w3.org/Archives/Public/public-secondscreen/2014Nov/0052.html 15:29:07 [Discussion on terminology and the fact that it is confusing to have "session" used on both sides. Mark_Foltz proposes to look at naming alternatives] 15:30:54 ACTION: Mark_Foltz to look at renaming "sessions" for controlling and presenting sides. 15:32:22 PROPOSAL: Possible renaming: getSession() --> isPresentation() | startSession() --> startPresentation() | joinSession() --> joinPresentation() 15:37:51 PROPOSED RESOLUTION: starting point for #19 is Promise NP.getSession(), PresentationSession[] NP.getSessions(), NP.onsessionavailable event when set of sessions changes (with possible naming changes) 15:38:34 http://w3c.github.io/presentation-api/#common-idioms 15:38:45 A presentation is an active connection between a user agent and a presentation display for displaying web content on the latter at the request of the former. 15:38:53 A presentation session is an object relating an opening browsing context to its presentation display and enabling two-way-messaging between them. Each such object has a presentation session state and a presentation session identifier to distinguish it from other presentation sessions. 15:39:19 RRSAgent, draft minutes 15:39:19 I have made the request to generate http://www.w3.org/2015/05/19-webscreens-minutes.html tidoust 15:44:21 https://github.com/w3c/presentation-api/pull/90 15:45:54 ACTION: mfoltzgoogle to fix spec to refer to updated Presentation idiom 15:47:32 Topic: Define user agent context for rendering the presentation 15:47:47 -> https://github.com/w3c/presentation-api/issues/14 Issue #14 15:47:57 scribe: tidoust 15:48:36 Mark_Foltz: Basically, what we've done on the presenting side is rendering things in "incognito" mode so everything such as local storage, cookies and so on is separate. 15:49:15 ... We have questions about some sensor APIs, whether they will be available. We haven't disabled any API right now. 15:49:41 ... Permission-granting APIs should probably be discouraged since they would require the user to interact with the presenting screen. 15:49:53 Anssi: Good point, what about touch? 15:50:04 Mark_Foltz: Not a real problem. 15:50:24 Schien: At Mozilla, pretty similar to what Google does, using "private browsing" mode. 15:50:35 ... Separate cache as well. Completely isolated. 15:51:56 ... In my opinion, because the Web developer wants symmetry on both sides between the 1UA and the 2UA mode, I would propose to disable the APIs that we don't want them to use. 15:52:44 Jean-Claude: Is the 1UA case with multiple connections possible? Does it make sense? 15:53:03 Mark_Foltz: It is possible but we haven't really thought about that for now. 15:54:00 Mark_Foltz: The way I would summarize the issue at stake is that the presenting user agent should not persist data, disable the APIs that require user permission. 15:54:43 Anssi: The more problematic APIs are the legacy APIs such as geolocation. You could do feature detection but nothing would really happen such as listening to deviceOrientation changes but nothing would happen. 15:54:56 wonsuk has joined #webscreens 15:55:58 Schien: For packaged application, we only grant permissions to APIs listed in the manifest 15:56:46 mozilla private browsing: https://wiki.mozilla.org/PrivateBrowsing 15:58:24 Francois: I note initial work on defining "Private Browsing" mode in the TAG 15:58:43 -> http://w3ctag.github.io/private-mode/ Private Mode Browsing 15:59:08 ACTION: Define browsing context in terms of the upcoming spec for private browsing, perhaps using the Mozilla link as an interim reference. 16:00:23 Two key points: 1. There should not be persistent data kept across presentations for any origin 2. APIs that require user permission should act as if the user canceled/rejected the request 16:01:46 Mark_Foltz: There are things that we may want to address, e.g. what happens when the presenting page calls "window.open". 16:02:04 Jean-Claude: Anything that pops up will be a pain 16:02:47 Mark_Foltz: there should be some informative guidance for implementers, typically. 16:03:44 q? 16:03:54 RRSAgent, draft minutes 16:03:54 I have made the request to generate http://www.w3.org/2015/05/19-webscreens-minutes.html tidoust 16:05:48 [closing Day 1] 16:06:24 RRSAgent, draft minutes 16:06:24 I have made the request to generate http://www.w3.org/2015/05/19-webscreens-minutes.html tidoust 17:20:17 wonsuk has joined #webscreens 18:32:32 Zakim has left #webscreens