Re: Proprietary Data Formats




"Jeroen Wenting" <jwenting at hornet dot demon dot nl> wrote in message
news:11k2o4gmgvcc649@xxxxxxxxxxxxxxxxxxxxx
>
>> US law makes it difficult to write-open source software to interface
>> with proprietary formats.
>>
> Wrong. It makes it hard if your sole purpose is to use that interface for
> illegal purposes like copyright infringement.

There's a difference between copyright infringement and, for example,
license agreements. The copyright laws themselves say you are allowed to
make copies of text/music/video/etc. you purchase for personal use. The
licensing agreement may say otherwise. If you decide to copy the
text/music/video/etc. for personal use anyway, then you haven't commited
copyright infringement, you've broken the licensing agreement.

Therefore, if someone invites a protection scheme for encrypting data on
a movie DVD, and I write a decryptor for it so that I can archive the movie
data onto my computer because I want to have all my movies accessible in my
home theatre without bothering to change DVDs, I haven't commited copyright
infringement. And yet the US laws (namely DMCA) criminalize me for writing
this decryption algorithm.

So your statement is factually false, assuming that by "if", you mean
"if and only if".

> Of course every single data format is proprietary to someone or some
> organisation. Someone always controls it, all the OS zealots want is to
> take control over the world's data for their own.

There are "open" formats, e.g. PNG, ASCII, Unicode, UTF-8, XViD, XML,
HTML, etc. in which the translation between semantic information and
bitstreams is made freely available to the public. People are encourage to
write encoders and decoders for this format, and there is no licensing fee
to pay or any restrictions on the usage of that format, or files written in
that format. That is what is meant by "non-proprietary" formats.

When someone says "proprietary format", they usually mean a format for
which the translation between bitstream and semantic information is not
publically known (e.g. Microsoft Word format), so that only a select few can
write encoders and decoders for the format.

Given these new definitions, do you still feel the same way that you do?

>> So the maker of a device or software that can suck you into encoding
>> your data in a proprietary format, has you hostage. You have to buy
>> ONLY his software to analyse it. You can't even hire somebody to write
>> a tool to extract YOUR data. You have effectively given handed over
>> possession of your data to the tool maker.
>>
> Hardly. Noone can prevent you from accessing your own data.

Yes, someone can. It currently exists in a limited form called DRM,
which stands for Digital Rights Management. DRM is an umbrella term for any
technology which restricts access to data, including access to your own
data. If you use a music-composition software to write your own song, for
example, but that software only saves the songs to formats which include
DRM, then you will have limited access to your own data. In particular, if
the makes of the music-composition software decide to revoke your license to
listen to your own song, you will no longer have access to your own data.

So all we have to do is not run those kinds of software, right? This is
where Trusted Computing comes in. Trusted Computing is an umbrella term in
which access to the hardware is restricted by the hardware vendors. For
example, Intel might control what software is allowed to run on their Intel
processors. It is possible that if you buy a system with Trusted Computing
hardware, that you will not be allowed to use any software except those that
encode into DRMed formats.

> As to stealing the data the tool manufacturer provides in their templates
> and models, that's a whole different story.

Yes, that is a whole different story; one that no one brought up earlier
and is off topic, so I don't know why you brought it up.

>
>> It is amazing how crooked and stupid a law can be when you are lax
>> about allowing corporations to bribe politicians.
>>
> Better than allowing zealots to determine law.

I don't nescessarily agree with this. At least, with a zealot, you at
least know what cause (s)he is going to support. When you have a politician
determining the law, and that politician can be bribed, then you never know
what causes the politician will support; in fact, the cause may change from
day to day, depending on who is bribing.

In both cases, you might not end up with laws you like. But in the case
of the zealot, at least you know what kind of laws to expect.

>
>> The practical solution may be similar to the solution to the silly
>> laws against encryption. Buy your software and have your services run
>> outside the USA.
>
> Those "silly" laws are quite necessary for security purposes. If anyone
> can have your algorithm and keys anyone can crack your encryption.

The statement "if anyone can have your algorithm and keys, anyone can
crack your encryption" is true (if we're lenient about the definition of
"crack" here). However, the following statement is NOT true: "if anyone can
have your algorithm, anyone can crack your encryption." In fact, the reverse
statement happens to be true: "even if everyone happens to have your
algorithm, no one yet has managed to crack it" for many encryption
algorithms.

Therefore, "silly laws" which say "you must not export your algorithms
outside of the USA" are NOT nescessary for security purposes. In fact, those
laws were made because certain algorithms are TOO secure, and the government
doesn't like the idea of not being able to crack its enemies' messages.

This might seem like a "good thing" at first, but when you have
politicians being bribed, then *YOU* might turn out to be the enemy of the
government, and you DON'T want the government to be able to crack your
encryption.

> I'd rather have export restrictions on encryption than the French system
> where only the government is allowed to use encryption at all.

I'm assuming you're referring to the fact that in France, the government
wants a backdoor in all encryption algorithms so that they can decrypt any
messages. So to be precise, everybody (not just the government) can use
encryption, but the government has a special skeleton key that can decrypt
all messages.

Given that that's what you're referring to, you should be against
proprietary encryption algorithms. Unless you know how the algorithm works,
how can you be sure there isn't a backdoor that allows the government to
decrypt all your messages easily?

- Oliver


.



Relevant Pages

  • Re: CryptAPI(encryption/decryption)
    ... I'm decoding the base64 encoded data before trying to decrypt. ... I misspelled the Private Key as Primary Key. ... and the priavte key in PEM format. ... Is there any variation in the encryption format in openssl compared to ...
    (microsoft.public.pocketpc.developer)
  • Re: CryptAPI(encryption/decryption)
    ... The openssl encrypted data format is in bigendian ... Why there is so many compatibility difference between MS Crypt and openssl? ... I misspelled the Private Key as Primary Key. ... Is there any variation in the encryption format in openssl compared to ...
    (microsoft.public.pocketpc.developer)
  • Re: CryptAPI(encryption/decryption)
    ... The openssl encrypted data format is in bigendian ... Is there any way I can import the PEM formated private key to the MS CSP ... I'm decoding the base64 encoded data before trying to decrypt. ... Is there any variation in the encryption format in openssl compared ...
    (microsoft.public.pocketpc.developer)
  • Re: Representing futuristic English
    ... >> Kristopher wrote: ... ASCII encoding isn't all that different from, say, Morse Code, and I'll ... it's so hard to come up with safe encryption algorithms). ... with some new bin/cue-like file-container format, ...
    (rec.arts.sf.composition)
  • [OT] Re: Requiring a date be entered as mm/dd/yy on a form field.
    ... like setting a legal date format and the government can spend billions ... writing CIFS documents and revising government software to implement the ... Note that the US has recommended metric units since around the same time ... when they enact laws which nobody follows and nobody enforces. ...
    (microsoft.public.scripting.jscript)