- From: Joe Steele <steele@adobe.com>
- Date: Tue, 2 Dec 2014 17:11:46 +0000
- To: "<public-html-media@w3.org>" <public-html-media@w3.org>
- Message-ID: <D9EE180A-1491-4953-AC5B-3DBA7C48F6D3@adobe.com>
http://www.w3.org/2014/12/02-html-media-minutes.html <http://www.w3.org/2014/12/02-html-media-minutes.html> Joe Steele <http://www.w3.org/> HTML Media Task Force Teleconference 02 Dec 2014 See also: IRC log <http://www.w3.org/2014/12/02-html-media-irc> Attendees <> Present BobLund, ddorwin, jdsmith, joesteele, markw, pal, twirl Regrets paulc Chair joesteele Scribe joesteele Contents Topics <http://www.w3.org/2014/12/02-html-media-minutes.html#agenda> Bug 27055: Surfacing License to the User <http://www.w3.org/2014/12/02-html-media-minutes.html#item01> Summary of Action Items <http://www.w3.org/2014/12/02-html-media-minutes.html#ActionSummary> <trackbot> Date: 02 December 2014 <scribe> scribe: joesteele <scribe> agenda: discussion with Sergei re: 27055 Bug 27055: Surfacing License to the User https://www.w3.org/Bugs/Public/show_bug.cgi?id=27055 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27055> Surfacing License to the User twirl: someone times the license is not exposed to the end user ... many times this is about caching ... many possible states of the cache ... other topics like that -- ... changing aspect ratio of screen might cause a problem -- CDM might prohibit ... There is a Kinect patent: count a number of people in a room and could prohibit based on that ... an ability to read and verify the license would be useful to let the user know what restrictions there are ... and what they can do with this content ... e.g. caching is prohibited, can't store encrypted frames ... can imagine an attack against the user because they can't play this content ... in our opinion -- profitable for all terms to somehow be standardized and presented to the user and UA ... we don't want to provide the solution, see our role as asking questions markw: ... reiterate the points I made in the thread ... there are technical restrictions in the license that are not the same as what the user expects ... may be more restrictive than what the product does overall ... for example to allow you to have preview licenses ... example to allow short amounts of content to be viewed before license is acquired ... not sure how this could be displayed usefully twirl: yes we discussed that in the bug ... there are product and technical restrictions ... they could be different ... but things that annoy the user the most are things hardware could do but are prohibited from doing so ... this needs some solution ... e.g. you have one hour life ... for example what the user can do to extend the content ... as a consumer it is worst thing to be done ... e.g. when terms changed and leds to misunderstatdning ... those restrictions must be presented to user markw: as an example if the page provided 100 preview license, what would be the behavior? twirl: we could present that to the user markw: what about 100? twirl: that seems like a weird example ... could be solved by correct UI markw: that is an actual example ... I think the problem of the services telling the users what restrictions are applied is a real problem, but not sure how it could be technically enforced ... don't think that would fly as a technical solution twirl: I think would be up to the user agent how deal with that ... the history of DRM is very concrete here joesteele: I think one issue being raised is that for this to be enforced it would require the UA to understand all the same restrictions as the CDM ... essentially working in parallel pal: today there is a lot of commercially protected content for which vendors provide information about the restrictions on the content ... no merchant wants the user to be disappointed e.g. by not being able to watch content on a plane ... merchant is driven commercially to want to display the right information to the user ... not sure why the standard should include this mechanism twirl: we are bringing DRM into the web where everyone can use it. we will have many more implementations, many of which will not follow the regular commercial pattern ... don't think the example of the existing large providers works for this pal: a system that does display that information to the user would not be successful so why would they do it twirl: I don't agree with that pal: HTML std does not prevent folks from putting all page content in the H1 header, but folks don't do it becuase it is a bad experience ... strong incentive to commuicate to the user twirl: fraud is a possible use case and concern pal: I don't see a big change from what is possible today twirl: that is partly true, there is no means to control content other than plugins ... this would be a big change ... the history of DRM has many examples of where customers are deceived by companies ... trying to find a way to solve that problem ... users devices being controlled, users licenses being removed <markw> s/perceicved/deceived/ joesteele: is your concern mainly about fraud? or the possibility of a company making a choice which is not apparent to the user? twirl: both actually -- this is being opened dramatically so that everyone can protect content, this will mean this will happen a lot more ... might just be a misunderstanding, but the result is still that a large number of people being disappointed ... the problem is generally that the content provider has a very large scope of rights, but people never thought that content providers has these rights -- e.g. purge content from cache ... if they had realized, this would have caused an issue markw: I just wanted to refute the idea that this is new functionality, this is just a new way of exposing this functionality just making it more standarized via the video tag twirl: that is our greatest concern, we don't want another <object> tag ... we don't like DRM but we want it to be "webby" markw: I think what a number of the browsers are doing makes this more clear and the object tag is less related to this bug twirl: any step forward is good but could step farther ... joesteele: I don't think that this will get worse because folks will still need to have business relationships with companies providing the DRM engines twirl: you said in the bug that anyone could make their own MediaKeys -- so we will have this. ... that is one of our greatest concerns that there will be a closed market https://www.w3.org/Bugs/Public/show_bug.cgi?id=27166 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27166> joesteele: this is an example of what I am talking about ... would text like this be useful? markw: wanted to correct the point about anyone creating their own CDM, it is the intention that each browser integrates with its own CDM. None of the browsers are designing a system where the site can provide its own CDM. ... don't think that a site-downloadable CDM could be in compliance ... so it is not the case that there will be arbitrary CDMs twirl: in that bug everyone is saying that nothing in the spec prevents that ... if nothing prevents creating new MediaKeys systems I am expecting that there will be joesteele: any opinions on how we should proceed? twirl: I can provide a list of use cases that are problematic in the bug -- most have been discussed already joesteele: two options for moving forward I see: ... 1) text restricting how the CDM can behave ... 2) A standard set of restrictions on the license and a way to provide those to the UA ... twirl will provide the list of use cases he is concerned about to address #2 jdsmith: if I understandand the conversation correctly this is about the transparency of the transaction ... the license is opaque and the user does not know what they are getting ... much like many transactions on the web ... I am a little concerned that the license would be very complex and difficult ... example of privacy standards P3P being something not useful in the end ... there will be a collection of licenses, maybe many, and some browser UI to present them ... this feels like a very difficult solution to this problem ... think I understand the transparency concern. think I agree with Mark that this is on the site to provide before the purchase ... but where you really want to solve this is on the site itself ... before the purchase, not after twirl: this is true, but there is a difference between DRM content and others, the blackbox on the users device prevents them from seeing this ... 1?? don't think this could be fair if you present it that way ... this is already done by every CDM <markw> +1 to Jerry's comments twirl: task is just to make it open nothing more pal: just trying to level expectations here, don't think there is a problem to solve here ... the task of providing the range of possible rights is an enormous problem ... don't think the next step should be just document one or two cases ... if the next step is to document all the possible rights this is a problem twirl: this is not all, just the existing CDMs pal: that can't just be summarized by two parameters twirl: don't feel that it is infinite ... expect it is really just a few pal: there does not seem to be any action this group can take till this is in wide use ... don't want to prevetn people from doing business <ddorwin> EME and DRM add another way to restrict access, but websites also have many other ways, including just no longer providing the content. Codifying the policies of the license can’t explain all that the user can do. <ddorwin> In contrast, DRM may be entirely responsible for enforcing user capabilities when, for example, the user has a physical disc. ddorwin: wanted to make the point that EME is only part of the restrictions that the website can place, such as restricting the set of titles you can see ... even without DRM ... in the past with offline content, the disk was preventing you from doing things, now we are moving to the server model where the server can prevent you from doing things twirl: we have a new model, not entirely clear but the CDM is on the device and needs standardization ... if we have a just client and server, then why have a CDM at all? but it is for something, so lets say for what joesteele: any other points to raise? any actions we can take? twirl: putting text in the spec would be better than nothing jdsmith: do you think language in the spec that constrained the CDM to practices that are ethical and do not deceive the end user would be a possible resolution? twirl: would prefer a guarantee, but is up to the HTML WG to decide whether it can be resolved ... I am not trying to do your job, just raising concerns joesteele: when is next scheudled meeting? jdsmith: meetings scheduled for the 9th and 16th, but Paul is out joesteele: I will be available for the 9th but not after Summary of Action Items <>[End of minutes] Minutes formatted by David Booth's scribe.perl <http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.140 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>) $Date: 2014-12-02 17:08:52 $
Received on Tuesday, 2 December 2014 17:12:16 UTC