- From: Henri Sivonen <hsivonen@hsivonen.fi>
- Date: Mon, 19 May 2014 15:04:03 +0300
- To: "public-restrictedmedia@w3.org" <public-restrictedmedia@w3.org>
- Cc: cobaco <cobaco@freemen.be>, Deivi Kuhn <deivilk@gmail.com>, brashley46@tfnet.ca
On Thu, May 15, 2014 at 4:09 PM, cobaco <cobaco@freemen.be> wrote: > On 2014-05-15 14:10 Henri Sivonen wrote: >> https://twitter.com/hsivonen/status/466845056310075392 (Apologies to >> the FSF for "no one" in the latter tweet in order to fit the memetic >> pattern.) > > in that tweet you ask the question: > "Prompt to download DRM wrapped in a proprietary platform and no one bats an > eye. Remove the platform wrapper and everyone loses their minds." It's not a question. It's an observation. > we've been over the answer time and again on this list... > > There's a major difference between: > - supporting a legacy api that has been abused to provide drm and that's on > the way out anyway, and > - supporting a brand new api that is going to be used for nothing but DRM As your word "legacy" implies, the NPAPI argument is fundamentally path-dependent. That is, if EME had been here first, no one opposed to DRM would argue that the way Adobe Access DRM is available to Firefox would become better by dropping the Mozilla-controlled sandbox and by adding the Flash platform in between. As for the "nothing but DRM" argument relative to NPAPI enabling DRM and also other things, I think the argument is weak on two counts: 1) Generally, the argument that general-purpose things that enable both things that you approve of and things you disapprove of are more acceptable than special-purpose things that only enable the things you disapprove of depends on a substantial part of the uses of the general-purpose thing being those that you approve of. The NPAPI has always been predominantly about injecting proprietary code to the side of the Web platform, but proprietary code isn't necessarily DRM. Without EME, the proportion of DRM use of the NPAPI would increase, asymptotically converging towards 100%, since the non-DRM uses of NPAPI are more and more addressed by the Open Web Platform. Is a general-purpose thing still justified when it is (almost) only put to uses you disapprove of? 2) When someone who makes a supposedly general-purpose product makes the argument that they are not complicit in the disapproved uses of their general-purpose product, those making the accusation of complicity in disapproved uses generally view e.g. a direct support contract between the maker of the product and the disapproved user as an aggravating matter. Mozilla has put engineering effort not only in keeping the NPAPI around in the abstract but to fix issues with specific plug-ins, including ones that are DRMy, so Mozilla has already specifically supported plug-ins that are about DRM (most notably Silverlight, whose non-DRM uses ended up being neglibible). On Thu, May 15, 2014 at 4:51 PM, Deivi Kuhn <deivilk@gmail.com> wrote: > As Executive Secretary of Free Software Brazilian Government Committee I > could say that is a real deception. Do you find prompting to download an Adobe Access DRM-only component more deceptive than prompting to download Flash Player, which includes Adobe Access? As noted before, the DRM component will be an optional (at the cost of studios denying you movies if you decline; like today) third-party component and Firefox itself will remain Free Software. > I think the need to phrase things that apologetically makes abundantly clear > how widespread the support for DRM isn't, at least on the end-user side Ask a user "Do you want DRM?" and the answer is "Of course not!" But when the user has paid for a movie service, the same user likely wants movies to actually play or else the browser "doesn't work". :-( > Mozilla caving now, instead of *if* and when it turns out they loose market > share because of it, is not doing the 'best they can', not in my book We might have reacted differently had we not had the H.264 experience. In that case, we refused to support H.264 via <video> while letting it be supported via <object>/<embed> while Chrome, IE and Safari supported H.264 via <video>. We failed to turn the tide. We capitulated more than two years ago, but we still, over two years later, haven't managed to fully execute on the capitulation and support H.264 in *release builds* on all platform that provide an H.264 decoder. We are still hurting from our attempt to go against H.264: especially on Mac, which a lot of Web designers use. (Our opposition to H.264 did yield some positive results, though: OpenH264.) Now, Firefox already supports DRM via <object>/<embed> and Microsoft, Google and Apple have shipped EME (each with their own CDM) in the context of <video>. You'd have us wait instead of recognizing the similarities between these situations? > e.g you can press skip forward all you want in Firefox, which will duly pass > it on to the CDM, but if the CDM decides to ignore that and send firefox back a > non-skipped decrypted stream (potentially while lying about the timestamp) > there's nothing you can do about that You are correct that in the planned sandboxing arrangement, it would be technically possible for a CDM to enforce the unskippability of advertising by refusing to decode subsequent non-advertising video unless the same CDM session has decoded the ads and the duration of the ads has passed since decoding previous non-ad content. I don't know whether Adobe Access supports this sort of restriction. On Fri, May 16, 2014 at 8:14 PM, B. Ross Ashley <brashley46@tfnet.ca> wrote: > As a consumer, as well as a quondam webmaster, I'd rather have a > SECURE browser that gave no external agency any control of my computer > in any fashion whatsoever. Do you currently have any NPAPI plug-ins installed in Firefox? (You are a current Firefox user, right?) If you do, those have more agency on your computer than the CDM will have. If you don't, you'll be able decline the CDM, too. (At the cost of not being able to use some services--probably a smaller set of services than the set of services that don't work if you refuse to install Flash Player.) -- Henri Sivonen hsivonen@hsivonen.fi https://hsivonen.fi/
Received on Monday, 19 May 2014 12:04:31 UTC