Date: Sun, 4 Oct 2009 08:33:03 -0700 (PDT) From: James Phillips <anti_spam256@yahoo.ca> To: freebsd-questions@freebsd.org Subject: Re: Voting for a native i386/amd64 flash player Message-ID: <553217.31319.qm@web65506.mail.ac4.yahoo.com> In-Reply-To: <20091004120022.6765210657A0@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=0A=0A=0A> =0A> Message: 29=0A> Date: Sat, 3 Oct 2009 23:45:18 -0600=0A> Fr= om: Chad Perrin <perrin@apotheon.com>=0A> Subject: Re: Voting for a native = i386/amd64 flash player=0A> To: freebsd-questions@freebsd.org=0A> Message-I= D: <20091004054518.GD37100@guilt.hydra>=0A> Content-Type: text/plain; chars= et=3D"us-ascii"=0A> =0A> On Sat, Oct 03, 2009 at 08:01:07AM -0700, James Ph= illips=0A> wrote:=0A> > =0A> > I have this fantasy that if I design and bui= ld a=0A> better streaming video=0A> > format, "They" (broadcasters) will us= e it, if properly=0A> marketed.=0A> =0A> It may be a fantasy, but as fantas= ies go, it's not a bad=0A> one.=0A> =0A> =0A> > =0A> > This would be despit= e the lack of "strong" DRM or=0A> license terms (GPL v3=0A> > is OK, right?= ).=0A> =0A> No, it isn't okay, really.=0A=0AThat's ok: I've thought of an "= out" for the licensing issue:=0AI can write up an RFC. That way the BSD peo= ple can boast about their "reference implementation," while the GNU zealots= can be assured that their "pure" implementation won't be leveraged against= them.=0A=0A> =0A> >=A0 4. Publishers are authenticated with a=0A> Public-k= ey infrastructure=0A> =0A> That caught my attention.=A0 I don't think we=0A= > necessarily need a mainstream=0A> style implementation of PKI, though.=A0= I'd say either=0A> go with simple=0A> public key digital signatures in the= style of OpenPGP or=0A> take cues from=0A> the Perspectives plugin for Fir= efox and do distributed "web=0A> of trust"=0A> style verification.=A0 Certi= fying Authorities are=0A> basically just a social=0A> engineering trick; no= w, instead of trusting one party, you=0A> have to trust=0A> two.=0A=0AI thi= nk I fell into the trap of using buzzwords. I *know* Certifying Authorities= are an interm scam needed until the general population understands how pub= lic keys work.=0A=0AI think PGP style (but binary) signatures on every ~32k= B packet solves the problem of authentication in the event of of missing pa= ckets.=0A=0AI was envisioning that the CNN's and BBC's of the world would h= ave a series of public keys (one for each bureau), while Joe down the stree= t would have 1 or 2 (one public, one for darknets). =0A=0A=0A=0A> > =0A> > = 2. For interoperability, I need to stabilize key=0A> points of the spec=0A>= > before publication. Currently struggling with date=0A> stamps (taking in= to=0A> > account leap seconds) (mostly resolved), and a=0A> transform to al= low the=0A> > publisher to be authenticated even if some data is=0A> missin= g.=0A> =0A> There are copyfree licensed implementations of date=0A> managem= ent that take=0A> leap seconds into account out there already.=A0 Is there= =0A> some reason you=0A> can't borrow liberally from them?=0A=0AProbably be= cause I don't know about them :)=0A=0AActually, I was planning to borrow fr= om Unix Time, increasing the resolution, and making the number signed (for = old recordings).=0A=0ABut, Unix time doesn't do leap seconds, so they have = to be added back in.=0A=0AJust recently, (reading cal(1)) I realized anothe= r problem: not everyone uses the Gregorian Calendar. Now I have to decide h= ow to take that into account sufficiently.=0A=0A> > 4. A dual-license may q= uickly result in a fork that=0A> implements=0A> > "features" I really don't= want to see. (Read: anything=0A> deliberately=0A> > incompatible.)=0A> =0A= > That's just another reason to go with a copyfree license=0A> instead of t= he=0A> GPL.=0A> =0A=0AA copyfree license wouldn't have a "stick" preventing= the implementation of an "effective technological measure" as described in= Article 11 the 1996 WIPO treaty (GPL v3 does).=0A=0AIf the (hypothetical) = RFC explicitly says that copy-protection won't work (in the "security consi= derations" section), MAYBE a judge will decide any incompatible implementat= ion is also ineffective at "copy protection." =0A=0A=0ARegards,=0A=0AJames = Phillips=0A=0A=0A=0A=0A=0A ___________________________________________= _______________________=0AYahoo! Canada Toolbar: Search from anywhere on th= e web, and bookmark your favourite sites. Download it now=0Ahttp://ca.toolb= ar.yahoo.com.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?553217.31319.qm>