TV Control API

01 Sep 2015


See also: IRC log


Bin_Hu, Chris, Kaz, Paul_Higgs, Sean_Lin, Sung_Hei_Kim
Bin Hu


<kaz> scribenick: cpn

<kaz> scribe: Chris

Summary of action items

<kaz> actions

<kaz> action-36?

<trackbot> action-36 -- Chris Needham to Look at the requirements from the media pipeline tf -- due 2015-09-01 -- OPEN

<trackbot> http://www.w3.org/community/tvapi/track/actions/36

<inserted> scribenick: kaz

cpn: security and privacy portion
... W3C published some guideline or recommendation
... fingerprinting, etc., for browser usage
... TV and interaction services
... visibility of entire channel list, etc., would be related to privacy issues
... also regarding recording APIs
... scheduled recordings would be related security and privacy restriction
... those kind of issue should be considered

bin: right

cpn: any comments so far?

bin: great and really appreciate your hard work
... good to see the MPTF requirements
... but not necessarily connected to our gap analysis
... their target was indicating gaps for HTML5
... which might be addressed by the future version of HTML5
... security&privacy might be handled by the applications themselves
... we need to look into the MPTF requirements based on that kind of big picture
... might want to have more fundamental method to solve the issues
... before TPAC there will be not much time
... that is my view

paul: understand what you're saying
... higher level of functionality we'd like to expose is the priority
... (paul explains some usability issue)
... recording schedule from one domain to another domain would be difficult just using cookie mechanism

bin: don't think that would be an API issue

paul: we should make a note

<scribe> scribenick: cpn

UNKNOWN_SPEAKER: we'd need to think about our security model, e.g., the OIPF has one

Bin: Is it appropriate for us to address these issues, or are they a much bigger thing for the web platform as a whole?
... Also regulatory issues

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
... This isn't a good user experience
... We could say it's not in scope of our work, but then which group should look at this?

Bin: it could be the HTML5 group, possibly
... Could Kaz or Daniel suggest where this should be considered in terms of overall security?
... Another group may have more expertise and more resourse to help solve this
... This is separate to us achieving a spec in our timescale, and we're only a CG at this stage

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

Bin: I think we shuold look at this from the point of view of overall web security

Kaz: There is a separate WG - the Web Apps Security WG - discussing security
... There's also an automotive WG and an automotive business group, also looking at security and privacy issues, they give a good example
... We could work with these groups, e.g., at TPAC Sapporo, get their advice

Bin: I don't know how we can achieve our goal by the end of this year

Kaz: The automotive groups have a joint TF looking at security+privacy
... From a timescale point of view, we can just record that we have identified these issues, but not change the API at this stage
... In the automotive case, they've just started discussing security, having become a WG

Bin: I see a time to market issue here for us
... 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
... 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
... Does this sound reasonable?

Kaz: I think so, we could create a task force for the next generation spec

Bin: ... And the scope of that TF would be broader than just security/privacy

<ddavis> scribenick: ddavis

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.
... That's where the future of the spec lies - implementations. Maybe TPAC is a good opportunity to get feedback.
... 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.

<scribe> scribenick: cpn

Bin: Maybe Chris or Paul could lead this work in the future?

<kaz> close action-36

<trackbot> Closed action-36.

Bin: Next topic is conditional access (CAS)

<kaz> action-38?

<trackbot> action-38 -- Sung Hei Kim to Propose an api spec for conditional access systems -- due 2015-09-01 -- OPEN

<trackbot> http://www.w3.org/community/tvapi/track/actions/38

<kaz> SungHei's writeup

Sung Hei: I sent an email while ago. I've looked at the ATSC and MPEG-2 specs, which define a conditional access descriptor

scribe: The CA card meta information is provided by the CA descriptor
... The ATSC CAS spec has a CA system ID, which normally identifies the vendor of the CAS system
... There isn't other meta information in the ATSC spec
... The ISO spec is similar to ATSC, but it has a CA PID, with ECM or EMM information
... Also, the PES also has a flag to indicate of the content is scrambled
... I think we can define meta information for CA cards, and I defined a TVCICardInformation dictionary, with CAS system ID and PID
... The TVChannel has an isFree attribute, which should correspond to the isScrambled
... I wasn't sure where to put this information, maybe in TVChannel or TVSource - or maybe a new interface?

Paul: I don't think it should go into TVChannel, as the same card can be used to decrypt multiple channels
... I think there two things: the per-channel CA system ID, but is different to the cards that are installed in the system

Sung Hei: So, we can have information in the TVChannel, and also under TVManager?

Paul: If the entitlement to a channel changes, e.g., going from free to paid, these would go under TVManager
... I'm not sure why the content would need to know where the ECM and EMM are

Sung Hei: We could remove the CAS PID if we don't need it

Bin: I suggest we pick this up on the mailing list

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?

scribe: It's difficult for the webapp to choose which CA card to apply to which content

Bin: Next is parental control, Paul has summarised this on the mailing list

Paul: There are things still to address, e.g., how subtitle information is transferred from the video source to the video element

Bin: Is how to do this an implementation issue?

Paul: I would think we'd use the various video/audio/text track elements to do this

Chris: I agree with this approach

Paul: The existing spec, based on the WebRTC MediaStream, we have doesn't allow text or data channels

Bin: I suggest Sean work with Paul on the interface
... Regarding TPAC, I don't have an update from the Web & TV chairs

Kaz: We need to ask them again, also Glen, GGIE moderator
... Let's discuss on the chairs/moderators mailing list
... Maybe have a session in the morning, leave the afternoon for GGIE

Chris: should we organise a break-out session?

Daniel: It would be good to bring to the IG as a whole, so it should be fine to include during the day

Kaz: After the meeting on Oct 26, if there are things to discuss we could have a break-out on the Wednesday to continue

Bin: Thank you everybody

<kaz> [ adjourned ]

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/09/01 14:09:50 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/cpn:/paul:/
Succeeded: i/security and privacy portion/scribenick: kaz
Succeeded: s/there's/they/
Succeeded: s/thing/think/
Succeeded: s/MediaStrea/MediaStream/
WARNING: No scribe lines found matching ScribeNick pattern: <Chris> ...
Found ScribeNick: cpn
Found Scribe: Chris
Found ScribeNick: kaz
Found ScribeNick: cpn
Found ScribeNick: ddavis
Found ScribeNick: cpn
ScribeNicks: cpn, kaz, ddavis
Present: Bin_Hu Chris Kaz Paul_Higgs Sean_Lin Sung_Hei_Kim
Agenda: https://lists.w3.org/Archives/Public/public-tvapi/2015Aug/0017.html
Got date from IRC log name: 01 Sep 2015
Guessing minutes URL: http://www.w3.org/2015/09/01-tvapi-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]