Skip to Content.
Sympa Menu

bluesky - Re: talked to ESR

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: Richard Clayton <richard AT highwayman.com>
  • To: Global-Scale Distributed Storage Systems <bluesky AT franklin.oit.unc.edu>
  • Subject: Re: talked to ESR
  • Date: Fri, 3 Aug 2001 04:08:15 +0100


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <>, Josh <josh AT mercuryfs.net> writes

>The patent is www.mercuryfs.net/patent.zip,

erm... the file I've just fetched and skip read only has pages 1..32 and
stops when it was about to get interesting by enumerating the claims

I'm not a patent expert, but I know that bit matters :-(

>and it exists to thwart
>Microsoft.
>
>The UNI ID design URL you already have. When setting up a new ID, it first
>scans for a collision, if there is one, it requires you to change your
>completion password (see the design). When multiple people use the same
>card, they each use a different PIN number (as does every individual). An
>example PIN is "3400ok", 34 is the last 2 digits of the credit card, 00 is
>from 0-99, because multiple people can use the same card, and OK is the used
>chosen "completion" password. The first 4 digits of all UNI ID passwords are
>assigned. UNI ID stores the credit card in an incomplete manner, only
>reassembling the full card number when the pin number is (securely)
>transferred. Just as ATM machines would have to remember your password,

actually they don't ... there is a cryptographic link between your
account number and your PIN ((and when you "change your PIN" all you
actually do is to change an offset value)).

>so
>would a thief for UNI ID, but this applies to all password based
>technologies. You cannot do a man in the middle attack between the validator
>and uni-id. To see why, go here: http://www.mercuryfs.net/design/fig_96.pdf

which shows that you're assuming that IPSec will prevent the man in the
middle from existing ... you're doing no end point authentication (that
I can detect) at your level

>Only universal-id.net is to charge the credit card to prove its
>authenticity.

that merely demonstrates that it is a valid credit card number; it does
nothing to link that number to an individual (which the true owner might
see as a reasonable test of "authenticity")

>The validator does not make money by doing this, they merely
>accept your id and password, and turn to universal-id to authenticate it. If
>somebody is using your UNI ID , that authentication charge is a timestamped
>record in the credit card log.

without further details (such as IP address) this will be useless in
tracking down an abuser - so that would predicate the central service
becoming involved in every disputed transaction.

This involvement in traceability has proved problematic for ISPs already
- -- and it seems unwise to build that in from day one (mind you, for this
amount of money it's unclear to me that anyone would try to chase things
up -- leaving a nice little earner for someone who can skim from many
many accounts -- bad system design again, to have such a possibility).

>If the credit card companies don't like 5
>cents, then I can make it 10 cents, or 25 cents, and instead of refunding it
>all at the end of the year (less 10 dollars), it can be quarterly. If we
>get volume, we can throw it into a money market account and get a bit of
>interest of it for a few months, thus reducing our total rate, since UNI ID
>isn't out to be the next Microsoft, or verisign, etc. UNI ID will become a
>non profit foundation, ideally.
>
>The MFS design is at my site, www.mercuryfs.net. If you all want me to, and
>I'll gladly cut and paste from it, but I don't think I should fill up
>everybody's inbox. In fact, I already tried to send attachments to all of
>you, but the email list wont allow it. So you have to visit the site I
>guess?

I think what people are looking for is not replication of the same
material but expansion of the bits that confuse them - plus some
indication of the answers to the complicated questions.

>Once again: MFS is the first to separate a file into 2 fundamental units:
>information and data.

I thought the Mac filing system did that :)

>This applies to all files, and can be implemented as a
>transparent caching mechanism on all the other technologies (but that's not
>my intention). It allows true location independence that appears to beat all
>the others, including coda.
>
>Any other questions?

this looks like a cache design to me (with some "push" as well as "pull"
features) - rather than a filing system per se. Would that be a fair
description ?

- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBO2oVnxfnRQV/feRLEQKdxACglS3A+tQC+wuzEgBjoz3ZKK3o31AAn0Lf
zsIaUSlfUuUCIaK6u+Z03wyu
=emie
-----END PGP SIGNATURE-----




Archive powered by MHonArc 2.6.24.

Top of Page