- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 4 Mar 2012 16:41:37 -0800
- To: Mark Watson <watsonm@netflix.com>
- Cc: Ian Hickson <ian@hixie.ch>, "<public-html@w3.org>" <public-html@w3.org>
On Sun, Mar 4, 2012 at 11:02 AM, Mark Watson <watsonm@netflix.com> wrote: > On Mar 4, 2012, at 8:11 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: >> A customer >> with an internet-capable TV but no game console or other box that >> Netflix has explicitly been ported to wouldn't be able to use it >> either. > > I believe Netflix is supported on most Internet-capable TVs. We'd obviously like it to be all. Hence the proposal. I'll note once again that it's not the technology that's holding you back, its your contracts with the movie distributors. The technology that Netflix needs has been available for some time, and is in active and growing use. One of the active questions here is why we should be adding troublesome-in-multiple-ways tech to the web platform solely to help you honor the contractual obligations you voluntarily agreed to, when from a technical perspective you're completely covered. (I'm aware that the movie studios more or less act like stubborn leeches in these kinds of contracts, so you have my sympathy. But sympathy doesn't extend far in a technical debate.) >> For streaming services that aren't on-demand, like some >> television streams, DRM prevents them from time-shifting to a time >> they wish to watch. > > And so those services should be less attractive to consumers than services that do support time-shifting. The point is that DRM prevents me from using a *secondary* service to do time-shifting on my own, if my primary source either doesn't offer it or does a bad job. The fact that you're locked in to using the original media distributor for *everything* is a disservice to customers who should have more competition. >> It's quite normal and relevant for the W3C to demand that the open web >> stay open. Many browser vendors in the discussion so far believe that >> adopting this proposal would do exactly the opposite. Since it's >> attempting to solve a problem that will disappear in a few years >> anyway, it's appropriate for the group to push back on this. >> >> Finally, policy issues are completely appropriate for this forum. >> We're not a hivemind of problem-solvers, solely focused on solving the >> tasks placed in front of us. We're a community of people interested >> in developing the web, who have come together for the purpose of >> making it easier to interoperate. We decide *not* to solve certain >> problems all the time; in fact, that's the *majority* outcome for >> problems brought to the group. If we gave up our prerogative to judge >> problems and decide whether or not to solve them, the output of this >> group would be markedly worse. > > Yes, but it's the basis of those decisions that differs. Most are based on whether there is a sufficient body of interest in solving the problem and sufficient real-world experience to expect that it can be solved in a way that will stand the test of time. This is a very practical basis for decision-making. The character of the arguments in this case are completely different. With all due respect to the members of this group, our expertise is primarily in engineering - at least this is what we all have in common - and the concerns that have been raised are not at all engineering issues. This is incorrect - several engineering issues have been raised by Henri Sivonen, Boris Zbarsky, and others, such as the fact that the tech for current in-use CDMs is closed-source and almost certainly will continue to be. This means that browsers can't fix security bugs they find in the CDMs (and a long track record of interacting with plugin creators shows that vital security bugs are both common and given distressingly little attention). Because it's DRM, they also can't even legally reverse-engineer the CDM to port it to platforms the CDM producer chose not to care about. Alongside the pure engineering concerns, there have been multiple concerns raised about the effect this has on the platform, such as the fact that current CDMs generally require licensing, which excludes niche browsers and OSes. As well, a proliferation of incompatible CDMs being used to encode/decode different content is bad for the platform in the same way that a proliferation of video codecs is - it means that simplest path of just picking one and using it probably excludes a significant fraction of users. Alongside both of those, we must worry about our own users and their rights. This is quite normal and common. For example, there's nothing wrong, technically, with assigning every user a unique ID and making this accessible to ads, and in fact this would be tremendously useful for ad providers. Our users appreciate us protecting their privacy as much as possible, though, so we refuse to implement functionality of this nature. Similarly, DRM negatively impacts our users in multiple ways, restricting the ways they can use their computer and their media. It is our right and duty to weigh this in our appraisal. And finally, alongside all of those concerns, we get to the value judgements. Many of us feel that DRM, particularly in its common current incarnations, is morally wrong to inflict on people. Contrary to your statements, value judgements are *completely* appropriate for a technical discussion. We are people, and we have to live with the consequences of our actions, including the technology we develop and distribute to our users. Attempting to argue that we should lay our personal feelings aside and solve your problems regardless of our opinions of them isn't going to go very far. Note that I'm not trying to convince *you*, Mark. Your company is currently tied down in contracts with the media distributors that require things I find immoral. You've gotta do what you gotta do. My goal is to help ensure that the other stakeholders who aren't directly financially benefitting from inconveniencing their users and damaging the long-term health of the platform get good, complete information about all the drawbacks of your proposal, so that hopefully they decide along with me to reject it. ~TJ
Received on Monday, 5 March 2012 00:42:25 UTC