[plug] MS Curriculum at schools and TAFEs ...

[Christian]

On Mon, Apr 23, 2001 at 01:56:08PM +0800, The Thought Assassin wrote:
 
> I wasn't sure of the situation, I just knew that there was nothing
> stopping people from using it IRL, but that there was definitely no
> guarantee that a truly free version couldn't be challenged legally.
> Yes, as long as the information was obtained through legal means. (IANAL,
> but I'm fairly sure I'm right about this) Patents were introduced to
> prevent people keeping things like this secret, but they introduce
> insurmountable legal barriers to Free alternatives. I had assumed that the
> algorithm in question was patented, as RSA likes to do.

Actually, I don't think it was ever patented.  Just made a trade
secret.  Of course, then someone posted it to USENET in 1994...

My understanding is that if you patent something then you must
describe how it works even though you then retain control over its use.
By keeping it a trade secret I think they couldn't actually patent it.

> I don't really think that's the stance, either, I just worry that if start
> to offer inches, miles will be taken - or that the greater populous will
> think "even the Free Software people accept quasi-open proprietary
> standards, obviously there's no benefit in pushing for complete freedom."
> In short, I'm paranoid, but perhaps with good cause.

Very possibly. :)

> file format buys you nothing. It is just a pain in the arc4.

*rotfl*

> As you so astutely point out, the only benefit is if it is designed to
> prevent the person viewing the document from getting at the plaintext
> version of it. This obviously depends on trusted client software, which is
> incompatible with freedom. The only way to trust your client software is
> not to license the appropriate parts to those who won't make their clients
> behave as specified, and then you're using legal protection, not
> technological protection, so why bother making such a nuisance of yourself
> with the encryption side of things?

Exactly.  Since the PDF standard has been properly documented, there can
be no "trusted software".

> > >From what I've seen it appears that the security/cryptography community
> > is somewhat split by this general issue of content protection through
> > cryptography.
> 
> Yes, some think it is futile, the others wonder how it could ever be a
> desirable thing in the first place. :)

I was actually thinking between those who believe it to be futile and
those who are getting paid to pretend that it isn't.

> All of them no doubt relying on legislative protection at a fundamental
> level, not presenting an effective technological solution. Except for the
> ones relying on secrecy and Oh-god-I-hope-noone-reverse-engineers this.
> Or am I wrong?

Actually, some of them sounded like they really believed they had found
a way of protecting their content.  In particular, one group who were
working on protecting Java applets so they couldn't be reverse
engineered and/or stolen.  I wasn't entirely convinced but the paper was
generally well-received.

> At which point in time you are out-competed by those willing to offer your
> customers more, even if the extra feature is just copying functionality.
> This competition can only be avoided by legalistic or secretive means.

Let's hope.

> > (i.e., more restricted) which appears to be basically what Microsoft is
> > planning on doing with Windows XP.  Doesn't really bother me though -- I
> > can't see Linus accepting a kernel patch to only allow certain digitally
> > signed MP3's being played...
> 
> ...and when CDs are obsolete and all music is sold in formats decryptable
> only under Windows, what will you do then? We should all care about this.

How do you propose to make a file only "decryptable" under Windows?  If
possible this would violate Kerchhoff's assumption that security reside
only in the key.  At which stage someone (anyone) reverse engineers
Windows, posts the recovered key (or algorithm) to USENET and suddenly
it's all down the tubes.

-- 
DSA 0x0EC1D28C: BBCB 0D79 4EBB 078A A066  7267 8BED E9D6 0EC1 D28C