- From: Matt Ivie <matt.ivie@gmail.com>
- Date: Fri, 14 Jun 2013 01:02:51 -0600
- To: Mark Watson <watsonm@netflix.com>,Duncan Bayne <dhgbayne@fastmail.fm>
- CC: public-restrictedmedia@w3.org
"I don't follow the logic in that statement. Just because W3C can do >>nothing >>to reconcile the incompatible licensing choices of copyleft software >>authors and Hollywood content authors we should do nothing to improve >>the >>technology situation for everyone else ?" Are you saying that the software licenses chosen by the two parties are incompatible or that copyleft software is incompatible with the copyrights of Hollywood films? I'm assuming you mean the former but I just wanted to clarify. Mark Watson <watsonm@netflix.com> wrote: >>On Thu, Jun 13, 2013 at 3:26 PM, Duncan Bayne <dhgbayne@fastmail.fm> >>wrote: >> >>> > It's >>> > not >>> > an argument against a capability to say that there exists hardware >>or >>> > software than cannot support it. I can point to such >>hardware/software >>> > for >>> > any given aspect of the web. >>> >>> "One of W3C's primary goals is to make these benefits available to >>all >>> people, whatever their hardware, software, network infrastructure, >>..." >>> >>> EME is not a step towards this. It is specifically designed to >>restrict >>> certain media to the subset of people who have a particular >>combination >>> of hardware, software and network infrastructure that is blessed by >>the >>> CDM vendors. >>> >> >>The media in question is already restricted to those people. EME >>doesn't do >>that. If anything, EME will increase the set of people able to access >>the >>media. Think about it: those people are the potential customer base >>for >>services like ours, why would we want to reduce the size of that set ? >> >> >>> >>> > It is progress towards the goal if such software can be made more >>widely >>> > available (more platforms). >>> >>> You keep saying that, as though there is something about the EME >>> proposal that makes this more likely. What evidence have you to >>support >>> that assertion? >>> >> >>Admittedly I don't have empirical evidence at this stage. It's very >>early. >>But it's certainly a goal. A reason to believe it's likely is that >>porting >>Flash and Silverlight to more platforms is unlikely to happen, since >>that >>are substantial pieces of software (complete presentation/execution >>environments) with - in the case of Silverlight - an announced >>end-of-life. >>By contrast, CDMs will be much smaller in scope and therefore easier >>to >>port. Both the vendors and the customers of CDMs have an incentive to >>support as many platforms as possible in order to maximize their >>revenue >>and potential customer base respectively. >> >> >>> >>> > As for languages, there is nothing in EME that restricts the >>number or >>> > kind >>> > of languages supported and I can say that at least for our service >>DRM in >>> > no way restricts the languages we offer with our content. You seem >>to >>> > have >>> > accepted John F's arguments on accessibility. >>> >>> And note my weaker language on those points initially; "probably" >>rather >>> than "most assuredly not". My understanding of the intended >>> implementation of CDMs is that they will be closed-source, >>proprietary >>> blobs. The content they 'protect' will not be available in the >>clear. >>> This means that users cannot extend the system to support languages >>> other than those supported by the CDM vendor, and can't use machine >>> translation on the content either. >>> >> >>Why do you think CDMs will have any language-specific functionality at >>all >>? >> >> >>> >>> > Regarding geographic location, to my knowledge the DRM products >>that are >>> > likely to be made into CDMs don't support that. The CDM would need >>> > some privileged access to an accurate geo-location service, >>something >>> > which >>> > I think would be technically difficult. That's not to say Internet >>video >>> > services don't have geo-restrictions, just that they aren't >>enforced >>> > using >>> > DRM, to my knowledge. >>> >>> I don't think it'd be any more difficult than the IP-based geocoding >>> that's currently used to restrict website content based on location? >>> >> >>That's a restriction applied by the server, not by a client component. >>Using DRM to "enforce" geo-restrictions implies to me that you are >>somehow >>making use of the robustness of the client component to more >>accurately >>identity the location and then either report this securely to the >>server or >>apply the restrictions at the client based on allowed locations >>returned in >>the license. I don't see how you would do that. >> >> >>> >>> > It's a fact that there is content which comes with restricted >>licensing >>> > terms. If we can make that content available on the web to more >>people, >>> > on >>> > more platforms, with better consideration of security, privacy and >>> > accessibility, >>> >>> Privacy? I'm curious as to how you expect inscrutable closed-source >>> proprietary blobs to enhance the security of those who use them. >>> >> >>Compared to plugins today, since CDMs are integrated with browsers, we >>can >>expect the browser implementors to pay attention to their security and >>privacy properties. For example, if the CDM vendor refuses to explain >>to >>the browser implementor exactly what the CDM does, the browser >>implementor >>may choose to throw a scary dialog before the CDM is invoked, warning >>the >>user that they are about to executed unknown, untrusted code and >>giving >>them a choice not to (or more likely, the browser would choose not to >>ship >>that CDM at all). >> >>Likewise, if the CDM will communicate some kind of identifying >>information >>to the server, the user may be warned of this (and given the choice to >>disable the CDM). Such a CDM would not operate when in "anonymous" >>browsing >>mode. >> >>I think these are improvements over the status quo. >> >> >>> >>> > then this is progress towards the goal you quoted. >>> >>> But - and note that I'm only agreeing with accessibility amongst the >>> points you raised - is such progress worth sacrificing the goal of >>an >>> Open Web? I argue that it's not. >>> >> >>Hmm, I feel caught in some circular logic. Weren't the goals you >>quoted the >>goals of the W3C ? What do you consider the "goal of an open web" that >>would be sacrificed ? >> >>Nevertheless, I understand the argument: the improvements expected by >>EME >>proponents are too small to be worth this other cost. I'd like to >>understand better what this other cost really is. Specifically, what >>is the >>practical benefit to users that you believe would be sacrificed by >>having >>this work done in W3C rather than elsewhere. >> >> >>> >>> > Yes, >>> > there will be people whose choice of hardware/software is >>incompatible >>> > with >>> > the licensing terms. That's not something that can be fixed by >>W3C. >>> >>> No, it's not something that can be fixed by the W3C, which is one of >>the >>> many reasons why they shouldn't be recommending EME. >>> >> >>I don't follow the logic in that statement. Just because W3C can do >>nothing >>to reconcile the incompatible licensing choices of copyleft software >>authors and Hollywood content authors we should do nothing to improve >>the >>technology situation for everyone else ? >> >>...Mark >> >> >>> >>> -- >>> Duncan Bayne >>> ph: +61 420817082 | web: http://duncan-bayne.github.com/ | skype: >>> duncan_bayne >>> >>> I usually check my mail every 24 - 48 hours. If there's something >>> urgent going on, please send me an SMS or call me at the above >>number. >>> >>> -- Sent from my Replicant phone with K-9 Mail. Please excuse my brevity. Visit replicant.us
Received on Friday, 14 June 2013 07:03:37 UTC