13:05:10 RRSAgent has joined #tvapi 13:05:10 logging to http://www.w3.org/2015/09/01-tvapi-irc 13:05:19 Zakim has joined #tvapi 13:06:50 scribenick: cpn 13:06:55 Meeting: TV Control API 13:06:56 scribe: Chris 13:07:14 Agenda: https://lists.w3.org/Archives/Public/public-tvapi/2015Aug/0017.html 13:07:23 Present: Bin Hu, Chris, Kaz, Paul Higgs, Sean Lin, Sung Hei Kim 13:07:34 Topic: Summary of action items 13:07:47 -> http://www.w3.org/community/tvapi/track/actions/open actions 13:08:03 action-36? 13:08:03 action-36 -- Chris Needham to Look at the requirements from the media pipeline tf -- due 2015-09-01 -- OPEN 13:08:03 http://www.w3.org/community/tvapi/track/actions/36 13:08:15 nigel has joined #tvapi 13:09:24 cpn: security and privacy portion 13:09:47 ... W3C published some guideline or recommendation 13:10:06 ... fingerprinting, etc., for browser usage 13:10:17 ... TV and interaction services 13:10:40 ... visibility of entire channel list, etc., would be related to privacy issues 13:10:55 ... also regarding recording APIs 13:11:21 ... scheduled recordings would be related security and privacy restriction 13:11:46 ... those kind of issue should be considered 13:11:58 bin: right 13:12:05 cpn: any comments so far? 13:12:21 bin: great and really appreciate your hard work 13:12:45 ... good to see the MPTF requirements 13:13:16 ... but not necessarily connected to our gap analysis 13:13:45 ... their target was indicating gaps for HTML5 13:14:17 ... which might be addressed by the future version of HTML5 13:14:45 ... security&privacy might be handled by the applications themselves 13:15:26 ... we need to look into the MPTF requirements based on that kind of big picture 13:15:59 ... might want to have more fundamental method to solve the issues 13:16:22 ... before TPAC there will be not much time 13:16:37 ... that is my view 13:17:48 cpn: understand what you're saying 13:18:02 ... higher level of functionality we'd like to expose is the priority 13:18:27 s/cpn:/paul:/ 13:18:57 ... (paul explains some usability issue) 13:19:40 ... recording schedule from one domain to another domain would be difficult just using cookie mechanism 13:20:18 bin: don't think that would be an API issue 13:20:35 paul: we should make a note 13:20:47 scribenick: cpn 13:21:09 i/security and privacy portion/scribenick: kaz/ 13:21:15 ... we'd need to think about our security model, e.g., the OIPF has one 13:22:36 Bin: Is it appropriate for us to address these issues, or are they a much bigger thing for the web platform as a whole? 13:22:53 ... Also regulatory issues 13:23:50 jcverdie has joined #tvapi 13:24:04 Paul: But not everyone will write 'nice' web-apps, and given the openness of the web, if there's no sandboxing then we run the risk of devices being vulnerable to bad activity 13:24:13 ... This isn't a good user experience 13:24:36 ... We could say it's not in scope of our work, but then which group should look at this? 13:24:48 Bin: it could be the HTML5 group, possibly 13:25:32 ... Could Kaz or Daniel suggest where this should be considered in terms of overall security? 13:25:35 q+ 13:25:51 ... Another group may have more expertise and more resourse to help solve this 13:28:09 ... This is separate to us achieving a spec in our timescale, and we're only a CG at this stage 13:29:02 Paul: Each W3C spec has security considerations in place, but it's not in our current requirements, but we risk creating a spec that's not usable 13:29:47 Bin: I think we shuold look at this from the point of view of overall web security 13:30:06 Kaz: There is a separate WG - the Web Apps Security WG - discussing security 13:30:42 ... There's also an automotive WG and an automotive business group, also looking at security and privacy issues, there's give a good example 13:31:03 s/there's/they/ 13:31:33 ... We could work with these groups, e.g., at TPAC Sapporo, get their advice 13:32:03 Bin: I don't know how we can achieve our goal by the end of this year 13:32:26 Kaz: The automotive groups have a joint TF looking at security+privacy 13:33:00 ... From a timescale point of view, we can just record that we have identified these issues, but not change the API at this stage 13:33:29 ... In the automotive case, they've just started discussing security, having become a WG 13:34:11 Bin: I see a time to market issue here for us 13:35:35 ... I suggest having two work-streams: one to complete the API spec based on the gap analysis, another to discuss with these other groups and to prioritise what's needed for a second version of the spec 13:37:11 ... If we don't have solutions for the current gaps, which are driven by the industry participants, we'll finish the first version with those remaining, and defer those also to a second version 13:37:33 ... Does this sound reasonable? 13:38:05 Kaz: I think so, we could create a task force for the next generation spec 13:38:43 Bin: ... And the scope of that TF would be broader than just security/privacy 13:39:13 scribenick: ddavis 13:39:42 cpn: Forgive me if this is too soon but we've spent a long time on this issue on this call. What I'd like to hear is feedback form other implementers. 13:40:00 cpn: That's where the future of the spec lies - implementations. Maybe TPAC is a good opportunity to get feedback. 13:40:36 cpn: At this stage, I'm uncertain but I hope in the next generation we get a broader amount of participation in the group. Maybe that's the time to start addressing these other issues. 13:40:54 scribenick: cpn 13:41:52 Bin: Maybe Chris or Paul could lead this work in the future? 13:41:59 close action-36 13:41:59 Closed action-36. 13:42:19 Bin: Next topic is conditional access (CAS) 13:42:23 action-38? 13:42:23 action-38 -- Sung Hei Kim to Propose an api spec for conditional access systems -- due 2015-09-01 -- OPEN 13:42:23 http://www.w3.org/community/tvapi/track/actions/38 13:43:12 -> https://lists.w3.org/Archives/Public/public-tvapi/2015Sep/0000.html SungHei's writeup 13:43:13 Sung Hei: I sent an email while ago. I've looked at the ATSC and MPEG-2 specs, which define a conditional access descriptor 13:43:29 ... The CA card meta information is provided by the CA descriptor 13:44:06 ... The ATSC CAS spec has a CA system ID, which normally identifies the vendor of the CAS system 13:44:52 ... There isn't other meta information in the ATSC spec 13:46:08 ... The ISO spec is similar to ATSC, but it has a CA PID, with ECM or EMM information 13:46:47 ... Also, the PES also has a flag to indicate of the content is scrambled 13:47:55 ... I think we can define meta information for CA cards, and I defined a TVCICardInformation dictionary, with CAS system ID and PID 13:48:34 ... The TVChannel has an isFree attribute, which should correspond to the isScrambled 13:49:25 ... I wasn't sure where to put this information, maybe in TVChannel or TVSource - or maybe a new interface? 13:49:49 Paul: I don't think it should go into TVChannel, as the same card can be used to decrypt multiple channels 13:50:36 ... I think there two things: the per-channel CA system ID, but is different to the cards that are installed in the system 13:50:58 Sung Hei: So, we can have information in the TVChannel, and also under TVManager? 13:51:38 Paul: If the entitlement to a channel changes, e.g., going from free to paid, these would go under TVManager 13:52:41 ... I'm not sure why the content would need to know where the ECM and EMM are 13:53:43 Sung Hei: We could remove the CAS PID if we don't need it 13:54:01 Bin: I suggest we pick this up on the mailing list 13:55:20 Sung Hei: Another question: the content already knows what kind of CA card is needed to decode, so I don't think the application needs to choose, so maybe we should remove this requirement? 13:55:41 ... It's difficult for the webapp to choose which CA card to apply to which content 13:56:02 Bin: Next is parental control, Paul has summarised this on the mailing list 13:56:54 Paul: There are things still to address, e.g., how subtitle information is transferred from the video source to the video element 13:57:20 Bin: Is how to do this an implementation issue? 13:57:54 Paul: I would thing we'd use the various video/audio/text track elements to do this 13:58:49 s/thing/think/ 13:59:00 Chris: I agree with this approach 13:59:36 Paul: The existing spec, based on the WebRTC MediaStrea, we have doesn't allow text or data channels 13:59:46 s/MediaStrea/MediaStream/ 14:00:52 jcverdie has joined #tvapi 14:01:57 Bin: I suggest Sean work with Paul on the interface 14:02:38 Bin: Regarding TPAC, I don't have an update from the Web & TV chairs 14:03:03 Kaz: We need to ask them again, also Glen, GGIE moderator 14:03:30 ... Let's discuss on the chairs/moderators mailing list 14:03:56 ... Maybe have a session in the morning, leave the afternoon for GGIE 14:04:28 Chris: should we organise a break-out session? 14:04:53 Daniel: It would be good to bring to the IG as a whole, so it should be fine to include during the day 14:05:51 Kaz: After the meeting on Oct 26, if there are things to discuss we could have a break-out on the Wednesday to continue 14:06:31 Bin: Thank you everybody 14:07:45 [ adjourned ] 14:07:47 skim13 has left #tvapi 14:07:49 rrsagent, make log public 14:07:49 seanlin has left #tvapi 14:07:53 rrsagent, draft minutes 14:07:53 I have made the request to generate http://www.w3.org/2015/09/01-tvapi-minutes.html kaz 14:09:20 Chair: Bin Hu 14:09:40 rrsagent, draft minues 14:09:40 I'm logging. I don't understand 'draft minues', cpn. Try /msg RRSAgent help 14:09:44 rrsagent, draft minutes 14:09:44 I have made the request to generate http://www.w3.org/2015/09/01-tvapi-minutes.html cpn 14:10:00 jcverdie has joined #tvapi 14:14:59 jcverdie has joined #tvapi 15:11:29 jcverdie has joined #tvapi 15:26:08 jcverdie has joined #tvapi 15:40:57 Zakim has left #tvapi 16:12:20 nigel has joined #tvapi