W3C home > Mailing lists > Public > public-webpayments@w3.org > October 2013

Re: Standards Making 101 (was: Re: Tradehill Bitcoin exchange shut down for 2nd time in 2 years)

From: Joseph Potvin <jpotvin@opman.ca>
Date: Mon, 7 Oct 2013 11:09:31 -0400
Message-ID: <CAKcXiSqqpbZ6Df2rvbbiJThx4Wp-648Yy1eoR4TdA8EwJM3Z3Q@mail.gmail.com>
To: Web Payments CG <public-webpayments@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:24 UTC