Voting for a native i386/amd64 flash player
jhell at DataIX.net
Sun Oct 4 17:07:11 UTC 2009
On Sun, 4 Oct 2009 08:33 -0700, anti_spam256@ wrote:
>> 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
>> 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."
> James Phillips
> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
So how many different subjects are in here that don't thread ?
With all due respect: wheres Waldo ?
| dataix.net!jhell 2048R/89D8547E 2009-09-30 |
| BSD since FreeBSD 4.2 Linux since Slackware 2.1 |
| 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E |
More information about the freebsd-questions