See also: IRC log
<trackbot> Date: 22 September 2015
<slightlyoff> I only have 30-ish minutes
First topic: https://github.com/w3c/encrypted-media/issues/85
davide has briefed TAG last week on topic.
<ddorwin> not me jdsmith
markw: Don't believe this is an architectural issue, but implementation options. Takes place entirely within the UA.
<slightlyoff> is this something that's going to be an interop hazard?
markw: Can understand some browsers may not want to implement, and it's optional for that reason.
Travis: The choice to do some extra cleanup outside the browser session seems strange to TAG.
<slightlyoff> Travis: <a ping>
markw: It's understood that there
will be cases where messages are lost. Experience has shown
with current implementations that it can be reliable
enough.
... Closed systems like TVs can write as they go and there's no
issue with writing data as they go.
... On PCs, some implementations may not be able to
sufficiently protect stored data and for them writing data on
session close may be more appropriate.
<slightlyoff> I'd like to understand what % of failure is being experienced and is seen as acceptable
ddorwin: Two options: Have secure storage, can write periodically. If not, write the data at the end of session.
slightlyoff: Would like to know more about what level of robustness is secure enough?
markw: Robustness is distinct from frequency of success. If you have protections against alteration, but not rollback, then write as you go isn't robust enough.
Travis: Is there a way the user agent can regularly ping the server to report that playback is ongoing?
markw: That's been a topic of
discussion, and license renewal is one way to implement
that.
... Have for a long time had a goal that playback will continue
with loss of server connectivity.
... Secure release is designed to do that.
Travis: I was asking about a heartbeat that would indicate ongoing playback, but would still work with loss of connectivity.
markw: Use those now.
slightlyoff It seems that ping suppression could be detected, if it was commonly detected from specific accounts.
markw: We don't believe that pattern would be significantly different from normal users playing content for short duration.
slightlyoff: What's the enforcement mechanism you would use on accounts that show mis-use?
Travis: I'd like to ask about
client robustness requirements again.
... Secure tamper proof storage for keys seems necessary in
some scenarios.
<ddorwin> I was dropped
<ddorwin> dialing back in
markw: We don't have offline
scenarios that might require this. Robustness requirements
depend greatly on the features provided by the particular
DRM.
... If licenses are stored, then it needs to be protected.
<slightlyoff> I have to go, but I'd like to understand why this feature would be "optional"?
markw: Rollback protection could be important for limited duration licenses.
<slightlyoff> thanks BobLund
<Zakim> ddorwin, you wanted to answer offline question
BobLund: There are cable companies that also want this features.
slightlyoff: This feature was mentioned earlier as optional. Why would it be optional?
<slightlyoff> thanks markw
markw: There are some members
that believe implementation is difficult.
... Circumstances would determine what we might do in response,
and license renewal would perhaps be considered.
ddorwin: There is an offline option that requires key and state storage. Secure release also requires secure storarge that should be tamperproof or tamper evident.
plh: If the feature is optional, you might consider other means. Are these other means inadequate?
markw: There are no other means
that we feel are sufficient.
... There are insecure alternatives (e.g. page JS reporting
activity). What we are interested in here is having a solution
that brings some of the robustness from the DRM component to
the problem.
Travis: It sounds like you want
secure release to be spec'd and available on implementations
somewhere.
... I'm a little dubious of optional features based on past
descriptions.
jdsmith: Would prefer not optional, but we've not resolved implementation issues.
Travis: Is the ask of TAG to make architectural decision on the secure release feature?
ddorwin: Yes.
Travis: If the spec requires data storage on shutdown, that would be a stretch. That may not be decisive here, since there are options for implementation.
markw: If writing data on session close is an issue, we should probably spend some more time discussing it. Clearly code is executed when browsers are closed today, and it's not clear how this is different.
Travis: Some native app models have no guarantees about shutdown, and are required to incrementally save state. It is correct that some app models run code on shutdown.
<joesteele> +1
jdsmith: Want to confirm that we want to publish on every commit (auto publish).
+1
<ddorwin> +1
plh: A PR is ready that will turn this on.
jdsmith: I will approve it today.
<plh> https://github.com/w3c/encrypted-media/pull/88
<plh> https://github.com/w3c/encrypted-media/pull/92
jdsmith: I'd like to review these today.
plh: ddorwin, if you don't hear from jdsmith today, consider it approved.
<plh> https://github.com/w3c/encrypted-media/pull/87
<plh> https://github.com/w3c/encrypted-media/pull/66
<plh> https://github.com/w3c/encrypted-media/issues/17
<joesteele> Looks good to me
jdsmith: I'll proceed with implementation.
<plh> https://github.com/w3c/encrypted-media/issues/71#issuecomment-136507577
<joesteele> s/slightlyoff It seems/slightlyoff: It seems/
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/davide/ddorwin/ FAILED: s/slightlyoff It seems/slightlyoff: It seems/ No ScribeNick specified. Guessing ScribeNick: jdsmith Inferring Scribes: jdsmith WARNING: Replacing previous Present list. (Old list: joesteele) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ BobLund, jdsmith, davide, ddorwin, mawatson, jdsmith, plh WARNING: Replacing previous Present list. (Old list: BobLund, jdsmith, davide, ddorwin, mawatson, jdsmith, plh) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ joesteele, BobLund, jdsmith, davide, ddorwin, markw, jdsmith, plh, slightlyoff, cwilso, robink, Travis, adrianba Present: joesteele BobLund jdsmith davide ddorwin markw jdsmith plh slightlyoff cwilso robink Travis adrianba Agenda: https://lists.w3.org/Archives/Public/public-html-media/2015Sep/0021.html Found Date: 22 Sep 2015 Guessing minutes URL: http://www.w3.org/2015/09/22-html-media-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]