- From: Mark Watson <watsonm@netflix.com>
- Date: Thu, 16 Jan 2014 12:16:30 -0800
- To: Markus Demmel <az@zankapfel.org>
- Cc: "public-restrictedmedia@w3.org" <public-restrictedmedia@w3.org>
- Message-ID: <CAEnTvdDbit6Bpsa1Q+dJR5mQ8LHB5j-_6S1gGO+0vKR2qLJ4yg@mail.gmail.com>
On Thu, Jan 16, 2014 at 12:03 PM, Markus Demmel <az@zankapfel.org> wrote: > On 15.01.2014 18:41, Mark Watson wrote: > > Since EME is proposed to be a separate "Extension specification", isn't > what you are looking for just the existing HTML5 and HTML5.1 specifications > ? > > ...Mark > > i was thinking more in a "bottom-up"-approch, meaning that it should be > transparent to the viewer of a webpage if there is a risk of running closed > source-code binaries. > I would expect that, where that concern exists, there would need to be a more granular approach. We have text in the security and privacy sections of the document for this, and suggestions for improvement are welcome. If a browser offers users security or privacy promises that are based - at least in part - on the open source nature of the browser code, then I would expect such a browser to either refuse to execute unknown code or at least provide granular and timely user control over that. For example, the user could be asked or at least informed on a per-origin basis that the origin wishes to make use of the proprietary code. The browser could at this point provide information about what is or is not known about this code. For example, if nothing is known, or if specific information about the use of identifiers is known etc. As a service provider, I am going to choose the CDM which results in the least aggressive approach by the browser implementor. So, there is at least some mechanism to apply pressure on CDM implementors to provide browsers implementors which as much information as possible here. The more ope they are, the less aggressive the browser warnings / controls and the happier the service provider. ...Mark > > The Approval of the W3C (like http://www.w3.org/Icons/valid-xhtml10 ) has > become somehow flawed, since the validator won't complain, if one uses the > extensions as specified. If you are concerned what code runs on your > platform, a simple way to reassure it, would be a profile that tells you > exactly that. And from my current knowledge, a W3C logo won't tell me that > in the future. > > > > > On Wed, Jan 15, 2014 at 9:38 AM, Norbert Bollow <nb@bollow.ch> wrote: > >> Am Wed, 15 Jan 2014 08:45:26 -0800 >> schrieb David Singer <singer@apple.com>: >> >> > People effectively profile HTML all the time — there are ‘rolling >> > edges’ of what is implemented and used, and what is falling out of >> > use and being removed from implementations. >> >> I'm not talking about that kind of thing, but about a more formal kind >> of profile specification drafted by a public interest oriented community >> process. >> >> There is, IMO at least, a strong need to have an answer (which is as >> precise and authoritative as possible) to the question about the >> markup language format and features that are appropriate to use in >> websites that are intended to be part of the “open web” (understood in >> a way that in particular does not discriminate against FOSS). >> >> I had expected the W3C process to be providing this answer, but since >> this seems to be not the case (if W3C continues on the path on which it >> seems to be, it will provide a superset of this answer, but not the >> answer itself), it appears that it is necessary to formalize a profile >> spec elsewhere. >> >> > If DRM is not used by content owners, not implemented by browsers, or >> > not supported by customers, it will die. Having a formal spec that >> > differs from the w3c one only in that it doesn’t include EME doesn’t >> > seem to change the balance at all. >> >> I agree that by itself, a formal profile spec (or any other kind of >> formal spec that addresses the problem) will achieve little. >> >> However if EME (and/or a follow-up further step downwards on the >> slippery slope of increasing proprietarization of the web >> platform) turns out to be dangerously successful in the marketplace, >> and it becomes evident that political efforts are necessary and >> appropriate to safeguard the public interest, it will be incredibly >> important to already have a precise spec that can be referenced >> in the context of such political efforts. >> >> Greetings, >> Norbert >> >> >> > On Jan 15, 2014, at 8:41 , Norbert Bollow <nb@bollow.ch> wrote: >> > >> > > Olivier Thereaux <olivier.thereaux@bbc.co.uk> wrote: >> > > >> > >>> Accordingly, a subset of the OWP which removes EME would more >> > >>> accurately be characterized as a "profile" of the OWP, rather than >> > >>> a fork of the OWP. >> > >> >> > >> Agreed, profiling is a different beast. That might have been what >> > >> the OP actually had in mind. >> > > >> > > There's an effort to develop a profile spec, and promote it, >> > > underway already at http://FreedomHTML.org/ >> > > >> > > Greetings, >> > > Norbert >> > > >> > > >> > > >> > > >> > >> > David Singer >> > Multimedia and Software Standards, Apple Inc. >> > >> > >> >> >> > >
Received on Thursday, 16 January 2014 20:16:58 UTC