W3C home > Mailing lists > Public > public-restrictedmedia@w3.org > January 2014

Re: Watermarking [Re: Campaign for position of chair and mandate to close this community group]

From: Mark Watson <watsonm@netflix.com>
Date: Tue, 14 Jan 2014 09:18:59 -0800
Message-ID: <CAEnTvdC0eN=zLciKTzgNyDKvCbkt93=9TO9869mKd_e5id7TOQ@mail.gmail.com>
To: Duncan Bayne <dhgbayne@fastmail.fm>
Cc: "public-restrictedmedia@w3.org" <public-restrictedmedia@w3.org>
On Mon, Jan 13, 2014 at 6:22 PM, Duncan Bayne <dhgbayne@fastmail.fm> wrote:

> > > I understand that.  What I'm saying is that EME is simply not an
> > > acceptable addition to the Open Web, for reasons that have been
> > > explained in detail, and with some repetition, on this list already.
> >
> > Ok, but also I and others have explained with a similar level of
> > repetition and detail why we think it appropriate and valuable for W3C
> > to work on this.
>
> Sure.
>
> > It would be great if you could find one. What I am missing is what
> > help you realistically expect in that task ? Certainly, if I was aware
> > of such an alternative I would have no hesitation in proposing it or
> > helping to develop it, but I am not.
>
> Well, as I say, the actual requirements that lead to the proposal of EME
> would be a start.  This is how it looks to those who don't agree that
> EME is a good fit with the Open Web:
>
>  - 'big content' has certain requirements relating to preventing users
>  copying data streams
>
>  - they won't make those requirements public (as you've said, the
>  agreements are confidential)
>
>  - their licensees propose a technical solution that is unacceptable to
>  many others because it necessitates the use of non-user-modifiable
>  client components
>
>  - all proposed alternatives (e.g. FOSS DRM, server-side watermarking,
>  client-side watermarking, no DRM at all) are shot down as being either
>  too expensive or inadequate to the (secret) requirements
>
> In a normal software project, I'd take an apparently insoluble conflict
> (the requirement for non-user-modifiable client components) to mean that
> we have done a poor job of determining requirements.
>
> Hence my request for either a real user to talk to (e.g. an MPAA rep) or
> the actual requirements docs, which you've told me are confidential.
>
> And *that* sets off my spidey-senses ... something is not quite right
> here.
>

As I said, multiple companies have built businesses by providing solutions
to the problem of satisfying the studio requirements. So it is clearly
possible to develop solutions but also clearly difficult enough that people
think there is real value in it. I haven't proposed that we develop such a
solution in W3C, in part because it's very difficult and I don't see any
path towards doing that in public.

The requirements for EME are to provide an API to those existing solutions.
There's no secret there.

I'm confused about why you think I should provide requirements for a
problem that I have not proposed we address,

...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.
>
Received on Tuesday, 14 January 2014 17:19:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:42 UTC