Voting for a native i386/amd64 flash player
anti_spam256 at yahoo.ca
Sun Oct 4 15:33:04 UTC 2009
> Message: 29
> Date: Sat, 3 Oct 2009 23:45:18 -0600
> From: Chad Perrin <perrin at apotheon.com>
> Subject: Re: Voting for a native i386/amd64 flash player
> To: freebsd-questions at freebsd.org
> Message-ID: <20091004054518.GD37100 at guilt.hydra>
> Content-Type: text/plain; charset="us-ascii"
> On Sat, Oct 03, 2009 at 08:01:07AM -0700, James Phillips
> > I have this fantasy that if I design and build a
> better streaming video
> > format, "They" (broadcasters) will use it, if properly
> It may be a fantasy, but as fantasies go, it's not a bad
> > This would be despite the lack of "strong" DRM or
> license terms (GPL v3
> > is OK, right?).
> No, it isn't okay, really.
That's ok: I've thought of an "out" for the licensing issue:
I can write up an RFC. That way the BSD people can boast about their "reference implementation," while the GNU zealots can be assured that their "pure" implementation won't be leveraged against them.
> > 4. Publishers are authenticated with a
> Public-key infrastructure
> That caught my attention. I don't think we
> necessarily need a mainstream
> style implementation of PKI, though. I'd say either
> go with simple
> public key digital signatures in the style of OpenPGP or
> take cues from
> the Perspectives plugin for Firefox and do distributed "web
> of trust"
> style verification. Certifying Authorities are
> basically just a social
> engineering trick; now, instead of trusting one party, you
> have to trust
I think I fell into the trap of using buzzwords. I *know* Certifying Authorities are an interm scam needed until the general population understands how public keys work.
I think PGP style (but binary) signatures on every ~32kB packet solves the problem of authentication in the event of of missing packets.
I was envisioning that the CNN's and BBC's of the world would have a series of public keys (one for each bureau), while Joe down the street would have 1 or 2 (one public, one for darknets).
> > 2. For interoperability, I need to stabilize key
> points of the spec
> > before publication. Currently struggling with date
> stamps (taking into
> > account leap seconds) (mostly resolved), and a
> transform to allow the
> > publisher to be authenticated even if some data is
> There are copyfree licensed implementations of date
> management that take
> leap seconds into account out there already. Is there
> some reason you
> can't borrow liberally from them?
Probably because I don't know about them :)
Actually, I was planning to borrow from Unix Time, increasing the resolution, and making the number signed (for old recordings).
But, Unix time doesn't do leap seconds, so they have to be added back in.
Just recently, (reading cal(1)) I realized another problem: not everyone uses the Gregorian Calendar. Now I have to decide how to take that into account sufficiently.
> > 4. A dual-license may quickly result in a fork that
> > "features" I really don't want to see. (Read: anything
> > incompatible.)
> That's just another reason to go with a copyfree license
> instead of the
A 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).
If the (hypothetical) RFC explicitly says that copy-protection won't work (in the "security considerations" section), MAYBE a judge will decide any incompatible implementation is also ineffective at "copy protection."
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
More information about the freebsd-questions