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 <per...@apotheon.com>
Subject: Re: Voting for a native i386/amd64 flash player
To: freebsd-questions@freebsd.org
Message-ID: <20091004054518.gd37...@guilt.hydra>
Content-Type: text/plain; charset="us-ascii"
On Sat, Oct 03, 2009 at 08:01:07AM -0700, James Phillips
wrote:
I have this fantasy that if I design and build a
better streaming video
format, "They" (broadcasters) will use it, if properly
marketed.
It may be a fantasy, but as fantasies go, it's not a bad
one.
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
two.
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
missing.
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
implements
"features" I really don't want to see. (Read: anything
deliberately
incompatible.)
That's just another reason to go with a copyfree license
instead of the
GPL.
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."
Regards,
James Phillips
__________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your
favourite sites. Download it now
http://ca.toolbar.yahoo.com.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@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 |
+----------------------------------------------------%}
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
