Re: Encrypted Media proposal

On Mar 5, 2012, at 4:59 AM, Smylers wrote:

> Mark Watson writes:
> 
>> I was referring to common customer expectations. When a customer
>> chooses between a new TV with a Netflix badge and one without they
>> don't expect to be able to watch Netflix on the one without the badge.
> 
> That may be true but I don't see how it's relevant to the open web
> platform.
> 
> If a TV has a web browser (and implements all the relevant open web
> standards) then I'd expect it to be able to display content from all
> websites, not just sites that are in cahoots with the TV's manufacturer.

That's a choice for each website. "The Web" is not "The set of all content accessible with W3C standards alone". Plugins prove that the delta is non-empty.

> In particular, I would expect it to work with sites that don't exist at
> the time the TV was manufactured.

Sure, so long as those sites target the W3C platform. i.e. don't use capabilities not part of that platform.

You're not saying that it is somehow 'wrong' for websites to choose to target devices with additional capabilities are you ?

> 
> I would not expect the TV to require a badge on it for every website I
> may wish to visit.

Right, it's to everyone's advantage if the capabilities that sites need can be made part of the "web platform" so that as few as possible such badges are needed.

> So yes, I might expect a TV without a Netflix badge
> to be able to use the Netflix website.

Ok, so add the capabilities we need to the web platform then.

> 
> However, if a TV doesn't advertise general open web capabilities but
> instead has specific software installed to view walled-garden content
> from particular suppliers, then it isn't part of the open web. Anybody
> buying such a TV runs the risk of those particular content suppliers
> ceasing to trade, or changing their formats, or no longer providing as
> wide a range of content.

Those risks exist with any website.

> 
> In that case the device manufacturer and the content provider
> necessarily have a commercial relationship (possibly indirectly) and as
> such can arrange for appropriate software for playing the content to be
> installed on the device. So it isn't necessary there for the technology
> used to deliver the content to follow open web standards.

But it would obviously be better if it did - reducing the need for those n-m commercial relationships and letting both service providers and TV manufacturers invest their time in more interesting things instead.

> 
> If the content can't be viewed solely by implementing open web standards
> then I don't see why it's interesting for it to be 'mostly' implemented
> using open web standards; whether the 'missing piece' is a CDN or a
> codec or plug-in -- or indeed whether the entire software is a
> completely closed source application written from scratch using bare
> ones and zeroes

That's a good question. At least from our point of view, if our service could be supported in HTML5 it could make it much easier to get the service onto more devices (and eventually all devices). This would be to be benefit of both Netflix (lower costs) and our users (more devices) - or just our users if we passed the cost savings on to them in some form (lower price or more content).

If the service can be supported 'mostly' in HTML5 as you put it, then the same advantages apply. Asking TV manufacturers to integrate a CDM is much simpler both for us and them than asking them to integrate a custom SDK (TV's tend not to support plugins).

On the desktop, an HTML5 solution (compared to plugins) would enable greater code sharing across desktop and non-desktop devices - again with the advantages described above. Obviously we'd be incentivized to help solve the CDM-availability problem for browsers.


> -- doesn't affect the fact that it's not the open web
> but a service only available to those who enter into certain contractual
> relationships.
> 
> So I don't see why the 'requires a badge' scenario is relevant to HTML5.

Because I sincerely hope there will remain a delta between "The Web" and "The set of all content accessible with W3C standards alone". Closing off a space which has previously supported vibrant innovation is not a good thing.

> 
>> At Netflix we don't have customers telling us that we 'don't get it'.
>> It's often argued that all customers want is easy, convenient,
>> reasonably-priced and legal access to content and they become
>> frustrated with industries that refuse to offer them that. But that is
>> exactly what we are offering and what we want to make possible with
>> HTML5.
> 
> For what it's worth I'm not a Netflix customer. You operate in my country
> (the UK), but as I understand it your service is not available on the
> operating system I run (Linux, with Firefox as my browser), and
> obviously there's no point in my becoming a customer unless my system is
> supported.

Fair point.

> 
> Given that Linux and Firefox are both software libre, I would like for
> you to use technology which is entirely openly specified and can be
> entirely implemented in open source software.

Yep, me too. Unfortunately, the authors of that kind of software have explicitly prohibited in their licenses that it be used to implement the content protection capabilities that our content provider partners require. I don't judge either party.

> 
> In particular, I'd like to sign up with a service which doesn't limit
> the devices, operating systems, and browsers on which I may view its
> content, including allowing hardware and software doesn't yet exist.

And when someone offers that service you can sign up for it. But we can't right now offer that service (for the reasons above), and even if we could it would be up to us whether to offer it.

We all have services we would like to sign up for which are not available. We can all say "wouldn't it be great if there was a service which did X". But that doesn't mean it makes sense to get annoyed at the provider of a similar service because it doesn't work the way you want it to. Maybe it feels frustrating that it is "so close". But it is up to the people who start companies and create services to decide what they do.

> 
> At the moment the Netflix service is harming its customers by
> restricting their ability to freely switch to a different operating
> system. If a Netflix customer who currently runs Windows realizes that
> in general she would be better off running Linux instead on her
> computer, she can't switch because she'd lose Netflix functionality.

I don't see how that "harms" the customer. It's not possible to "harm" someone by not offering them a service that you are under no obligation to offer. "restriction" implies that we take actions to prevent something which would otherwise 'just work'. This is not the case. Adding Linux support would be a project requiring investment and resources.

The lack of Linux support certainly makes our service less attractive to some people (although the majority of viewing is not on desktop or laptop platforms).

Linux support would certainly improve our service and make it attractive to more people.

Those are different things from "harm".

> 
> Or if you provide Linux support but as a secret binary blob, that may
> give me access at the moment but restrict me from later deciding I'd
> rather switch to, say, FreeBSD instead. Whereas if you provide support
> in a truly open way, customers have no such restrictions imposed on
> them.

This is answered by the points above.

> 
> Similarly, I did not download any music from major record companies
> until they started making it available to buy in MP3 format. 
> 
>> Our use of content protection _vastly_ increases the range of content
>> we can offer to our customers,
> 
> But it limits your customers to those who use particular software which
> has signed the appropriate contracts; it isn't available to anybody who
> uses a web browser implementing open web technologies.

So which business plan should we choose: offering almost no content on every device, or offering a vast range of content on 100s of different devices ? 

> 
>> so I fail to see how it harms them.
> 
> It appears to be harming me right now.

No it's not. We're just not offering you exactly what you want. That's not harm.

Some customers would like to watch last weekend's new releases on Netflix. We don't offer those. That's not harm either.

> 
> As a customer the thing I would most appreciate would be for Netflix to
> use its strong position in the market to pressure content owners to
> allow adopting a format which is entirely opening implementable.

I understand many people would like us to do that. That would be a pretty high level business strategy move. As I explained earlier, we work closely with our content provider partners to agree on acceptable levels of risk. Sometimes reducing the technical requirements, whilst increasing risk, has some other benefit such as time-to-market for a given platform. When we do that, we get better empirical evidence about the real risks, which we of course share with the content providers in our discussions. You can't expect that people will just jump into a perceived abyss without evidence.

> 
> That's effectively what happened with the music download industry:
> certain large players insisted that they wished to provide music files
> without CRM, and eventually the content owners complied.

The video industry is very different in many ways. Most video is still distributed over traditional broadcast/CableTV. There is no equivalent of iTunes.

> 
> As a customer I am grateful for the music download sites which did this,
> as it has improved what is available to me.
> 
>> It's just not an issue that we get any number of Customer Service
>> calls about (either from customers or would-be customers).
> 
> I don't think Netflix has ever sought my opinion as to why I'm not a
> customer.

No, but we do market research and the objective there is to have large enough samples to understand consumer opinions.

> 
> John Simmons writes:
> 
>> ... the Amazon Video on Demand service is supported from my Samsung
>> Blu-Ray player. Now that surprised even me, and I am in this industry.
> 
> That it is surprising is evidence that at the moment there isn't an
> expectation for content to be available across different devices that
> aren't in cahoots with content providers.

Right.

> 
> HTML is surely about making content available to all who implement open
> web standards, so this surprise is something we wish to replace with a
> general expectation that everything will work everywhere.

With one caveat, that is the point of the proposal.

[The caveat is just what I mentioned above: that everything working everywhere as a hard-and-fast rule would be a terrible barrier to innovation].

> 
>> I bring this up because it illustrates what I believe is at the heart
>> of the dispute about this proposal- a lack of clarity regarding the
>> future significance of broadband-broadcast convergence - brought about
>> because each industry is caught in its own 'paradigm paralysis' - its
>> own tunnel vision reinforced by the decisions of the past.
> 
> I agree.
> 
>> I am convinced that if we get this right, clearly understanding the
>> requirements for commercial video distribution on the web and the
>> needs of an open web we can bring about a broadband-broadcast,
>> multi-screen revolution that will be one of the most significant web
>> developments since 1993. 
>> 
>> That is my belief, and I know others on this thread agree with me.
> 
> That sounds fair enough.
> 
>> That is why I am so supportive of this effort.
> 
> Curiously, it's similar thinking that has led me to come to the opposite
> conclusion, not wishing to support a proposal which leaves a crucial
> part of the solution only available to certain parties.

As I've said, its clear that for the solution to be successful CDMs need to be available to everyone. But that's clearly in the interest of browser makers, CDM providers and service providers, so its hard to imagine why that would not come to pass. Some evidence/progress towards this goal would be valuable but will take some time.

...Mark

> 
> Cheers
> 
> Smylers
> 
>

Received on Monday, 5 March 2012 19:04:28 UTC