[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Arch]Re: [Auth]a list of what we need the personal Data system to

From: John
Subject: Re: [Arch]Re: [Auth]a list of what we need the personal Data system to do.
Date: Mon, 16 Jul 2001 08:46:57 -0500

--- Begin Message --- Subject: Re: [Arch]Re: [Auth]a list of what we need the personal Data system to do. Date: Mon, 16 Jul 2001 08:44:08 -0500
Norbert Sendetzky wrote:
> > Am I to read you correctly: the data is encrypted by the Customer,
> > placed in the DataBank, retrieved at the Customer request, and decrypted
> > locally to be sent to the Service via SHTTP? Is the purpose of this to
> > make the data as stored inaccessible to the DataBank?
> Of course!
> I am not willing to give any unencrypted private information to anybody just
> for storing. This solution is as bad as Microsofts one!

Well, that would definitely make multiple providers unnecessary. No-one
can mine the data, because no-one except the user can access it. Of
course, that storage scenario creates an economic freedom problem.

What if a person says "I don't care if company X knows a great deal of
information about me, if they provide something in exchange." Your
scheme takes away that choice, by requiring the customer to explicitely
release information on a case-by-case basis to the provider each and
every time the provider wishes to mine. You and I might say "fine" or "I
don't want anyone mining my data" and that is *our* choice! How died and
made us into Dieties?

Individual freedom isn't only the freedom to choose this group's
morality (yours, mine, and many here); freedom is also freedom to make a
choice that offends us (you, me, and many here) personally.

I agree that the data should be stored encrypted as that would reduce
successful cracks. However, I believe that who holds the key(s) should
be a negotiation between the user and the provider. Agree or disagree,
there's more flexibility in allowing that decision to be configurable.
It allows more variability, and thus more competition among providers,
which will tend to drag down prices.

The idea is that if a customer wants to be the complete owner of his
data, he will seek a provider that provides that option under DotGNU. If
there's a sufficient number of customers, the completely private service
will be available. They will compete against those DotGNU providers who
insist on holding the keys. All of them collectively will compete
against Microsoft.

What prevents the provider from becoming "as bad as Microsoft"; ie from
becoming an information monopolist? The trick is to make switching
providers simple for the customer, no matter what degree of key-holding
the customer chooses. Then a customer can say "I don't like your
policies. I'm switching, and there's nothing Mr Provider that you can do
about it."

Sort of like GNU/Linux. One kernal. Multiple providers. Many options.
With minimal common standards the customer can easily switch providers.

Let's not be Henry Ford, and paraphrase, "You can have any DotGNU, as
long as it's black."

John Le'Brecage

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]