See also: IRC log
<kaz> scribenick: cpn
<kaz> scribe: Chris
<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 ]
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]