bluesky AT lists.ibiblio.org
Subject: Global-Scale Distributed Storage Systems
List archive
- 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-----
-
talked to ESR,
Josh, 08/02/2001
- <Possible follow-up(s)>
- Re: talked to ESR, Ian Clarke, 08/02/2001
- Re: talked to ESR, Bram Cohen, 08/02/2001
- Re: talked to ESR, Bram Cohen, 08/02/2001
- RE: talked to ESR, Josh, 08/02/2001
- Re: talked to ESR, Justin Chapweske, 08/02/2001
- Re: talked to ESR, Richard Clayton, 08/02/2001
- RE: talked to ESR, Josh, 08/02/2001
- Re: talked to ESR, Richard Clayton, 08/02/2001
- RE: talked to ESR, Josh, 08/02/2001
- RE: talked to ESR, Josh, 08/02/2001
- Re: talked to ESR, Ian Clarke, 08/03/2001
Archive powered by MHonArc 2.6.24.