- From: Joseph Potvin <jpotvin@opman.ca>
- Date: Mon, 7 Oct 2013 11:09:31 -0400
- To: Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CAKcXiSqqpbZ6Df2rvbbiJThx4Wp-648Yy1eoR4TdA8EwJM3Z3Q@mail.gmail.com>
A follow-up on this topic, in relation to HTML5 and it's handling of DRM. I'm sharing a post below from another list because, In general, I think the web payments community should tread cautiously in relation to DRM, as it has tentacles that reach far beyond software, to limit what can and can't be done with devices. Any web payments standard can find itself boxed in by the dominant device OEMs. Joseph Potvin ---------- Forwarded message ---------- From: Russell McOrmond <russell@flora.org> Date: Mon, Oct 7, 2013 at 10:39 AM Subject: Re: [OTT-GOSLING] Mozilla bug 923590: Pledge never to implement HTML5 DRM To: GOSLING members in Ottawa <ottawa-gosling@list.goslingcommunity.org> I don't understand the pledge. Transparent software can't implement DRM. I know that the XPDF folks document how they have a flag to "honour" the cut-and-paste settings in a PDF file, but that isn't DRM in the way envisioned here. That is metadata which software can choose to ignore and which users are always free to ignore as well by installing a differently compiled version. DRM involves encrypting content, and only giving out decryption keys to vendors who contractually agree to disallow the users/owners of computers from having any control. The law is then changed such that unauthorized access to decryption keys is illegal. FLOSS licensing disallows such agreements (NOTE: I'm not talking about non-FLOSS derivatives of non-Copyleft licenses which can, as they are no longer FLOSS), so FLOSS can't implement DRM. This could easily have been handled within the existing HTML standards and had content types that indicated the specifics of the encrypted content. Essentially a player capable of playing AAC files and AAC-DRM-AGREEMENT-3423412341 (note: 1) files aren't the same thing. As the DRM agreements (and thus key management) expands, so do the various deliberately incompatible file types. Having extensions to HTML to pretend to simplify this incompatibility doesn't seem to me to provide any technical advantage -- seems only to be politics to me. Is there anything for Mozilla to do? Sure, they can not implement part of the content negotiation which would communicate what file types a browser supports. If the IT property rights infringers decided to do this within the existing standard and treated these appropriately as different file types, then there would have been nothing that Mozilla could or needed to do. If a user had a plug-in that supported AAC-DRM-AGREEMENT-3423412341 then the browser would announce that and the website and plug-in could talk directly. BTW: HTML5-DRM-AGREEMENT-234234 is different than HTML5, and cannot be legally implemented in Mozilla so must be handled by a plug-in. Whether any such plug-in will ever exist is unknown, but I suspect unlikely given that plug-in is called a non-FLOSS browser. The lack of such a plug-in will drive people who don't understand the issue to non-FLOSS browsers, and there is really nothing Mozilla can do about that -- the pledge means nothing, but will mean that people blame Mozilla rather than the right people for the upcoming incompatibilities. I wouldn't be surprised to find that it was an IT property rights infringer that started the pledge in the first place. Note 1: I give long numbers to the agreements given DRM is not a yes/no question, but which particular cartel's key management and anti-IT-owner contracts are being honoured. There won't be a single key for any given plaintext file type, but as many as there are untrusting/untrustworthy cartels who have demonstrated to not only mistrust computer owners but other content companies as well. While we may start with only a few key cartels, it is inevitable that this number will grow over time given the DRM concept exists as a form of mistrust. I still believe that the correct response is to pressure governments apply competition/anti-trust laws to wipe out these cartels, and to remove any legal protection for these direct and/or indirect infringement of our IT property rights. That isn't a Mozilla question, though, but a public policy question that requires geeks to get past believing that organizations like Mozilla should be targeted with pledges rather than getting more politically active and solve the legal issues at the root of all this. ______________________________ _________________ Ottawa-gosling mailing list Ottawa-gosling@list.goslingcommunity.org http://list.goslingcommunity.org/mailman/listinfo/ottawa-gosling ---------- Forwarded message ---------- From: Glen Newton <glen.newton@gmail.com> Date: Fri, Oct 4, 2013 at 12:16 PM Subject: [OTT-GOSLING] Mozilla bug 923590: Pledge never to implement HTML5 DRM To: GOSLING members in Ottawa <ottawa-gosling@list.goslingcommunity.org> https://bugzilla.mozilla.org/show_bug.cgi?id=923590 Related: EFF: Lowering Your Standards: DRM and the Future of the W3C https://www.eff.org/deeplinks/2013/10/lowering-your-standards -Glen ______________________________ _________________ Ottawa-gosling mailing list Ottawa-gosling@list.goslingcommunity.org http://list.goslingcommunity.org/mailman/listinfo/ottawa-gosling On Tue, Sep 10, 2013 at 9:37 AM, Joseph Potvin <jpotvin@opman.ca> wrote: > Manu, I shared your list of good practices for standards development & > maintenance with a colleague who's long been active with the IETF > "Michael Richardson" <mcr+ietf at sandelman.ca>. He adds... > > "I will add another important thing: the 1.0 has to anticipate the > upgrade to 2.0 and beyond." > > On Mon, Sep 9, 2013 at 10:52 PM, Manu Sporny <msporny@digitalbazaar.com> > wrote: > > On 09/09/2013 09:48 AM, Ricardo Varela wrote: > >> Some of the existing regulations are there to contemplate "use cases" > >> that some projects may not have had to face yet and I think its not > >> so wise to quickly disregard them all as "no longer relevant" > > > > +1 > > > >> On that note: I think it's important to separate the different areas > >> in WebPayments that have to do with payment technologies, regulation, > >> and virtual currencies. > > > > +1 > > > >> I don't see why we have such a zeal in linking all of those together. > >> Are we saying that there will be no WebPayments standard until we > >> have fully operational virtual currencies? > > > > Definitely not. I don't think anyone is saying that all of this stuff is > > linked together such that we can't make reasonable progress based on the > > practicalities of the regulatory environment today. > > > >> In the meantime, my opinion is that it would be good that at least > >> some parts of those web payments find their way to real users out > >> there, even if they have to be built over the "old" payment > >> infrastructures > > > > Yes, absolutely. As we've seen, even most of the virtual/alt currencies > > layer over the old payment infrastructure. That's going to be the way it > > is for decades to come. > > > > For those of you that are not familiar with the process of creating > > world standards, what Ricardo is getting at is very important to > > internalize. > > > > To make progress toward something that will be a world standard takes a > > tremendous amount of focused effort. You have to be practical about it, > > which means that only a handful of the things we're trying to address > > are going to be addressed in the 1.0 specifications. In general: > > > > Troubled standards: > > > > 1. Place design purity over practicality (XHTML2) > > 2. Don't have an active community behind them (GRDDL) > > 3. Are more complex than the task requires (SOAP) > > 4. Misunderstand the target audience (RDF/XML) > > 5. Try to do too much (WSDL) > > 6. Are created in the Working Group, w/ no industry feedback loop (P3P) > > 7. Has a timeline that is not restricted (XHTML2) > > > > Successful standards: > > > > 1. Are messy, but solve real problems in a pragmatic way (HTML5) > > 2. Have active communities behind them (CSS3) > > 3. Are simple, elegant, and reuse what works (JSON) > > 4. Understand the target audience (HTML5) > > 5. Are focused (PNG) > > 6. Are largely done by industry before a Working Group starts (JSON-LD) > > 7. Has a restricted timeline (less than 4 years) to hit 1.0 (JSON-LD) > > > > If what Ricardo is saying is that we should focus on the latter 6 items > > if we want the work that this group is doing to succeed, I couldn't > > agree more. > > > > -- manu > > > > -- > > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) > > Founder/CEO - Digital Bazaar, Inc. > > blog: Meritora - Web payments commercial launch > > http://blog.meritora.com/launch/ > > > > > > -- > Joseph Potvin > Operations Manager | Gestionnaire des opérations > The Opman Company | La compagnie Opman > http://www.projectmanagementhotel.com/projects/opman-portfolio > jpotvin@opman.ca > Mobile: 819-593-5983 > LinkedIn (Google short URL): http://goo.gl/Ssp56 > -- Joseph Potvin Operations Manager | Gestionnaire des opérations The Opman Company | La compagnie Opman http://www.projectmanagementhotel.com/projects/opman-portfolio jpotvin@opman.ca Mobile: 819-593-5983 LinkedIn (Google short URL): http://goo.gl/Ssp56
Received on Monday, 7 October 2013 15:10:21 UTC