From josh@mercuryfs.net Thu Aug 2 02:46:44 2001 From: josh@mercuryfs.net (Josh) Date: Wed, 1 Aug 2001 18:46:44 -0700 Subject: what is managed source Message-ID: <000001c11af4$fc94b0f0$35512304@koi> Here's my definition of managed source http://www.mercuryfs.net/managed_source.htm It will change. From josh@mercuryfs.net Thu Aug 2 23:28:05 2001 From: josh@mercuryfs.net (Josh) Date: Thu, 2 Aug 2001 15:28:05 -0700 Subject: MFS compared to SFS Message-ID: <000001c11ba2$66aadc50$35512304@koi> I've briefly read thru SFS's web site, and emailed them. From what I see, it's a superior security add on for NFS. I like their ideas, UNI ID and the S0 network will provide similar features (once up and running). You guys may want to checkout the Direct Access FS. They have taken NFS and extended it in a very cool way. www.dafscollaborative.org As for a summary of MFS, its available at www.mercuryfs.net/summary.pdf The presentations are at www.mercuryfs.net/presentations A set of scenarios which explain what MFS will try to do is a www.mercuryfs.net/scenarios.pdf. In the scenarios are some footnotes which reference the design and specific features which accomplish what the scenario says it will. Our philosophy, license, a non competition pledge, and other misc items are there too. A brief comparison to CODA and AFS are also there. www.mercuryfs.net Let me know if you guys have any questions, and any other similar projects. - josh From josh@mercuryfs.net Fri Aug 3 01:19:25 2001 From: josh@mercuryfs.net (Josh) Date: Thu, 2 Aug 2001 17:19:25 -0700 Subject: talked to ESR Message-ID: <000401c11bb1$f41c9600$35512304@koi> I spoke to Eric Raymond about my managed source idea. He has about the same thing to say about it as I do. You open source zealots will at least respect what your own god has to say!!! HA! Heres the emails http://www.mercuryfs.net/esr_email.htm - josh (I'm not a member, you must email me direct) From ian@hawk.freenetproject.org Fri Aug 3 01:35:53 2001 From: ian@hawk.freenetproject.org (Ian Clarke) Date: Thu, 2 Aug 2001 17:35:53 -0700 Subject: talked to ESR In-Reply-To: ; from josh@mercuryfs.net on Thu, Aug 02, 2001 at 05:19:25PM -0700 References: Message-ID: <20010802173553.A15372@freenetproject.org> --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Aug 02, 2001 at 05:19:25PM -0700, Josh wrote: > I spoke to Eric Raymond about my managed source idea. He has about the same > thing to say about it as I do. You open source zealots will at least respect > what your own god has to say!!! HA! ESR isn't my god, I worship the one true God, RMS. Ian. --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD4DBQE7afHpQtgxRWSmsqwRAgnIAJiV3fTomzJJfjPDv4rEo9EjEjKjAJ9R1cUh BvfXqdfDxDKZN/Vwe4jzvA== =sP27 -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From bram@gawth.com Fri Aug 3 01:54:16 2001 From: bram@gawth.com (Bram Cohen) Date: Thu, 2 Aug 2001 17:54:16 -0700 (PDT) Subject: talked to ESR In-Reply-To: Message-ID: On Thu, 2 Aug 2001, Ian Clarke wrote: > ESR isn't my god, I worship the one true God, RMS. I don't trust or respect either of those guys any farther than I can throw them. And boy, they're hard to throw. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From bram@gawth.com Fri Aug 3 02:02:28 2001 From: bram@gawth.com (Bram Cohen) Date: Thu, 2 Aug 2001 18:02:28 -0700 (PDT) Subject: talked to ESR In-Reply-To: Message-ID: On Thu, 2 Aug 2001, Josh wrote: > Heres the emails http://www.mercuryfs.net/esr_email.htm > Apparently Josh is incapable of reading, because esr sure doesn't sound impressed in that mail. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From josh@mercuryfs.net Fri Aug 3 02:06:04 2001 From: josh@mercuryfs.net (Josh) Date: Thu, 2 Aug 2001 18:06:04 -0700 Subject: talked to ESR In-Reply-To: Message-ID: <000001c11bb8$78c9fb80$35512304@koi> He doesn't seem to really care, and recognizes that I'm essentially an open source method, but I assume he accepts that my goal warrants an exception to the current method. He's just pointing out that a successful open source project must have an element of management, and just as each group of people have their own leaders, be it implied, elected, hired, or declared king, it's the democratic approach that works. Democratic being an executive and congress. I just don't want to enhance NFS and all the others, when they can adopt MFS for next to free. If UNI ID is a hit, then it can go non profit. But we all need to remember that the internet has its own executive(s). The DNS root servers, ICANN, TCP/IP, etc. Just because I have the patent, doesn't mean I'm excluding people from implementing it. I'm only requiring global interoperability, and that will be one hell of a challenge into itself. If Microsoft or Novell invented MFS, you can bet they would patent it too. Probably the same with Sun. Because they would recognize that one basic design should be the global file system. And MFS is the first viable candidate, in my opinion. Yeah, its an incomplete design, but whats left is cake, in my opinion. I can even switch over to PGP and slam dunk the security issues. Which are already slam dunked. Nobody has thought of hashing a credit card number and PIN number to create a psuedo-anonymous form of identification. UNI ID beats the political challenges. - josh -----Original Message----- From: Bram Cohen [mailto:bram@gawth.com] Sent: Thursday, August 02, 2001 6:02 PM To: Global-Scale Distributed Storage Systems Subject: Re: talked to ESR On Thu, 2 Aug 2001, Josh wrote: > Heres the emails http://www.mercuryfs.net/esr_email.htm > Apparently Josh is incapable of reading, because esr sure doesn't sound impressed in that mail. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From orasis@acm.cs.umn.edu Fri Aug 3 02:16:45 2001 From: orasis@acm.cs.umn.edu (Justin Chapweske) Date: Thu, 2 Aug 2001 20:16:45 -0500 Subject: talked to ESR In-Reply-To: ; from josh@mercuryfs.net on Thu, Aug 02, 2001 at 06:06:04PM -0700 References: Message-ID: <20010802201645.D36212@sorry.cs.umn.edu> Can we please get some moderation on this list? Thanks, -- Justin Chapweske, Lead Swarmcast Developer, OpenCola Inc. http://www.swarmcast.com/ From richard@highwayman.com Fri Aug 3 02:59:43 2001 From: richard@highwayman.com (Richard Clayton) Date: Fri, 3 Aug 2001 02:59:43 +0100 Subject: talked to ESR In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <>, Josh writes >He doesn't seem to really care, I have a lot of sympathy with him >Just because I have the patent, Exactly what do you have a patent on ?? I've read a certain amount of the text on your website and have seen a lot of buzzwords, a deep misunderstanding of the business models of ISPs, an assumption that web content is static (and served independently of accessing IP address), a US-centric approach to the law and a cavalier disregard of user's rights when approached by policemen who persuade you that a life is at risk! What I haven't seen is a patent number (apart from Apple's) or even an indication of exactly which part of your Grand Design you have persuaded the US Patent Office is innovative. >Nobody has thought of hashing a credit card number and PIN number to create >a psuedo-anonymous form of identification. Perhaps that's because it won't work :( * partners often share a single credit card number so it isn't as unique as would be desirable * in order for a third party to validate a UNI ID they must be given your credit card number.... one of the lessons we are learning in the ECommerce world is that individuals are very reluctant to hand over this information * your charging model is completely backwards : you have no provision to prevent the third party from running up any number of $0.02 charges [$0.05 in some documents!] once you have released the credit card number to them * if you think the credit card companies are going to take only a few percent from $0.02 transactions you clearly haven't negotiated with them... * it's bad system design to wave your hands about someone else's credentials system ("no two people have the same card number") and then build into the heart of your schemes I would write more (you've written enough detail amongst the hype for it to be taken apart), but I see others are already bored with the topic. - -- 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/AwUBO2oFjxfnRQV/feRLEQISeACg/3gYGuC9Ypns39gfCMXcFp3nqMkAn1C/ N9LdE4ukKtUL99dhxT1FzrSk =gexa -----END PGP SIGNATURE----- From josh@mercuryfs.net Fri Aug 3 03:09:23 2001 From: josh@mercuryfs.net (Josh) Date: Thu, 2 Aug 2001 19:09:23 -0700 Subject: talked to ESR In-Reply-To: Message-ID: <000001c11bc1$51444030$35512304@koi> The patent is www.mercuryfs.net/patent.zip, 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, 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 Only universal-id.net is to charge the credit card to prove its 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. 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? Once again: MFS is the first to separate a file into 2 fundamental units: information and data. 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? -----Original Message----- From: Richard Clayton [mailto:richard@highwayman.com] Sent: Thursday, August 02, 2001 7:00 PM To: Global-Scale Distributed Storage Systems Subject: Re: talked to ESR -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <>, Josh writes >He doesn't seem to really care, I have a lot of sympathy with him >Just because I have the patent, Exactly what do you have a patent on ?? I've read a certain amount of the text on your website and have seen a lot of buzzwords, a deep misunderstanding of the business models of ISPs, an assumption that web content is static (and served independently of accessing IP address), a US-centric approach to the law and a cavalier disregard of user's rights when approached by policemen who persuade you that a life is at risk! What I haven't seen is a patent number (apart from Apple's) or even an indication of exactly which part of your Grand Design you have persuaded the US Patent Office is innovative. >Nobody has thought of hashing a credit card number and PIN number to create >a psuedo-anonymous form of identification. Perhaps that's because it won't work :( * partners often share a single credit card number so it isn't as unique as would be desirable * in order for a third party to validate a UNI ID they must be given your credit card number.... one of the lessons we are learning in the ECommerce world is that individuals are very reluctant to hand over this information * your charging model is completely backwards : you have no provision to prevent the third party from running up any number of $0.02 charges [$0.05 in some documents!] once you have released the credit card number to them * if you think the credit card companies are going to take only a few percent from $0.02 transactions you clearly haven't negotiated with them... * it's bad system design to wave your hands about someone else's credentials system ("no two people have the same card number") and then build into the heart of your schemes I would write more (you've written enough detail amongst the hype for it to be taken apart), but I see others are already bored with the topic. - -- 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/AwUBO2oFjxfnRQV/feRLEQISeACg/3gYGuC9Ypns39gfCMXcFp3nqMkAn1C/ N9LdE4ukKtUL99dhxT1FzrSk =gexa -----END PGP SIGNATURE----- --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From josh@mercuryfs.net Fri Aug 3 03:15:30 2001 From: josh@mercuryfs.net (Josh) Date: Thu, 2 Aug 2001 19:15:30 -0700 Subject: the mercury file system and UNI ID In-Reply-To: Message-ID: <000101c11bc2$2b8c60b0$35512304@koi> Your questions: "'Exactly what do you have a patent on ?? I've read a certain amount of the text on your website and have seen a lot of buzzwords, a deep misunderstanding of the business models of ISPs, an assumption that web content is static (and served independently of accessing IP address), a US-centric approach to the law and a cavalier disregard of user's rights when approached by policemen who persuade you that a life is at risk!"' My answers: The business models of ISPs are not that far off, MFS does not apply to all internet files, and the Synchronization groups will go a long way. . ISP's are motivated by new features, faster performance, better security, and things that their end users will like. The dynamic content issues can be beaten, I'm certain of it. See this link for a small discussion on that topic. www.mercuryfs.net/essence3.htm As for the issues of when a life is at risk, I'm only going to cite existing case law, and I'm waiting for an attorney to step forward and help me on it. It will be the same laws the apply to federal express and UPS. Until then, everything is a situation. But this will be ironed out far before its up and running. But remember this, UNI ID does not store a complete credit card number, and only an email address. Just because that info is given to the cops doesn't mean they've identified anybody. And whats wrong if I actually trust my government? I'm not saying they are perfect, but I fear foreign problems more than domestic. I'm going to deny the Chinese, for example. That will be a headache. -----Original Message----- From: Richard Clayton [mailto:richard@highwayman.com] Sent: Thursday, August 02, 2001 7:00 PM To: Global-Scale Distributed Storage Systems Subject: Re: talked to ESR -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <>, Josh writes >He doesn't seem to really care, I have a lot of sympathy with him >Just because I have the patent, Exactly what do you have a patent on ?? I've read a certain amount of the text on your website and have seen a lot of buzzwords, a deep misunderstanding of the business models of ISPs, an assumption that web content is static (and served independently of accessing IP address), a US-centric approach to the law and a cavalier disregard of user's rights when approached by policemen who persuade you that a life is at risk! What I haven't seen is a patent number (apart from Apple's) or even an indication of exactly which part of your Grand Design you have persuaded the US Patent Office is innovative. >Nobody has thought of hashing a credit card number and PIN number to create >a psuedo-anonymous form of identification. Perhaps that's because it won't work :( * partners often share a single credit card number so it isn't as unique as would be desirable * in order for a third party to validate a UNI ID they must be given your credit card number.... one of the lessons we are learning in the ECommerce world is that individuals are very reluctant to hand over this information * your charging model is completely backwards : you have no provision to prevent the third party from running up any number of $0.02 charges [$0.05 in some documents!] once you have released the credit card number to them * if you think the credit card companies are going to take only a few percent from $0.02 transactions you clearly haven't negotiated with them... * it's bad system design to wave your hands about someone else's credentials system ("no two people have the same card number") and then build into the heart of your schemes I would write more (you've written enough detail amongst the hype for it to be taken apart), but I see others are already bored with the topic. - -- 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/AwUBO2oFjxfnRQV/feRLEQISeACg/3gYGuC9Ypns39gfCMXcFp3nqMkAn1C/ N9LdE4ukKtUL99dhxT1FzrSk =gexa -----END PGP SIGNATURE----- --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From josh@mercuryfs.net Fri Aug 3 03:37:09 2001 From: josh@mercuryfs.net (Josh) Date: Thu, 2 Aug 2001 19:37:09 -0700 Subject: uni id In-Reply-To: Message-ID: <000201c11bc5$32593960$35512304@koi> As for the validator having your credit card number, you would have to trust the location where you are entering your card number. But remember that the number is not to be xferred across the internet. Because of the use of OSR's file system kit (www.osr.com), the NT version will not likely be an open source client. My approach is this: get a separate credit card, just for uni ids, it need only be a 100 dollar card. It will make your card bill easier. UNI ID utilizes the worldwide visa and mastercard network, and will not require the end user to remember a new ID (only the PIN number). Just as fake ATM's can get your card's, so can fake computer terminals using UNI ID. The laws will be specific to each country, but I'm convinced that any credit card laws regarding the xfer of credit cards will app. Also, part 4 of my license has been altered, since there are many people out there that hate cops. I'll just cite the existing federal laws that allow the SS to operate, because I'd have to follow the law like anybody else. That way I can get past this thing about the cops. Thing is, if the SS finds a pound of cocaine, from what I understand, their rules don't let them do a damn thing about it. That's assuming they got into your house because of a protection issue, not financial... at least that's how their warrants are written from what I've been told. Guys, get past the patent, this is basically a royalty free license. Its going to be running according to the internets rules once its established. The rules in place now apply to the startup nature of this. Once globally deployed, its going all standards based. IE the design will be written in RFC style, the patents more or less a non issue because everybody wants a single global file system standard (hopefully). Why do I get crucified for seeking a patent? If I'm going for funding, they will ask "why don't you have a patent"' This is s business decision, I'm not pissing on the open source initiative, I'm just saying that Microsoft has some valid criticisms of it, so do a lot of other for profit entities. I want to be almost open source. I'm getting the feeling that I'm expected to give away MFS, to be chopped into bits by everybody else? Maybe the world isn't ready for a global file system yet. If not, then ?FS will be the next big thing. But I really don't want to see it go as "yeah, it's a form of MFS" Why should I purposely try to be a Visicalc? Why cant I be allowed to pay my bills by making a bit of money from MFS? This is supposed to be a technical discussion group, but so far its all about ideals. The design is online. What should I do, retype it all in email? Also, as for the other email about the ratio of his words to mine, my response is: Sounds to me like he could care less about the license issues, as do I. -----Original Message----- From: Richard Clayton [mailto:richard@highwayman.com] Sent: Thursday, August 02, 2001 7:00 PM To: Global-Scale Distributed Storage Systems Subject: Re: talked to ESR -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <>, Josh writes >He doesn't seem to really care, I have a lot of sympathy with him >Just because I have the patent, Exactly what do you have a patent on ?? I've read a certain amount of the text on your website and have seen a lot of buzzwords, a deep misunderstanding of the business models of ISPs, an assumption that web content is static (and served independently of accessing IP address), a US-centric approach to the law and a cavalier disregard of user's rights when approached by policemen who persuade you that a life is at risk! What I haven't seen is a patent number (apart from Apple's) or even an indication of exactly which part of your Grand Design you have persuaded the US Patent Office is innovative. >Nobody has thought of hashing a credit card number and PIN number to create >a psuedo-anonymous form of identification. Perhaps that's because it won't work :( * partners often share a single credit card number so it isn't as unique as would be desirable * in order for a third party to validate a UNI ID they must be given your credit card number.... one of the lessons we are learning in the ECommerce world is that individuals are very reluctant to hand over this information * your charging model is completely backwards : you have no provision to prevent the third party from running up any number of $0.02 charges [$0.05 in some documents!] once you have released the credit card number to them * if you think the credit card companies are going to take only a few percent from $0.02 transactions you clearly haven't negotiated with them... * it's bad system design to wave your hands about someone else's credentials system ("no two people have the same card number") and then build into the heart of your schemes I would write more (you've written enough detail amongst the hype for it to be taken apart), but I see others are already bored with the topic. - -- 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/AwUBO2oFjxfnRQV/feRLEQISeACg/3gYGuC9Ypns39gfCMXcFp3nqMkAn1C/ N9LdE4ukKtUL99dhxT1FzrSk =gexa -----END PGP SIGNATURE----- --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From richard@highwayman.com Fri Aug 3 04:08:15 2001 From: richard@highwayman.com (Richard Clayton) Date: Fri, 3 Aug 2001 04:08:15 +0100 Subject: talked to ESR In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <>, Josh 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----- From josh@mercuryfs.net Fri Aug 3 04:02:31 2001 From: josh@mercuryfs.net (Josh) Date: Thu, 2 Aug 2001 20:02:31 -0700 Subject: disassociation of a file from an IP address Message-ID: <000101c11bc8$bd67cc30$35512304@koi> In answer to the previous email, heres how the disassociation works. Basic permanent caching: IP address = file file = math value set A file distributed world wide node 1 verifies from source IP address that file still equals math value set A. node 1 broadcasts this updated Information record to its network, and all nodes on it can continue to use file, because it has not changed. All nodes within node 1's network will know to use their existing copy. If file has changed, the math values will be different, and all nodes will need another copy. Once its downloaded once, it can be distributed in a peer to peer manner. Now, take this a step further. Imagine that you receive a file from a different source, and it generates a set of math values A. You can transparently associate that file as being the file, because of an identity function achieved by the math values and symmetric property of equality (if a=b then b=a). that's location independence. So long as you access the file by its math values, the source need not be the owner of the file. That's the key to disassociating a file from an IP address, while keeping it in sync. That's the key to distributed cache concurrency. See Figure 9 of the design. Its nothing special, but the MFS handle formula is special. Its can be made to apply to any file with a URL. Figure 8 is the key to the whole design. Basically, a file and its URL can create all of figure 8. once a file is separated into those 3 records, that's when all the features become possible. Such as downloading Microsoft office via a modem, and its slow the first time. The URLs for your copy, or works copy of office may be different, but that's an Information record issue. There are simply 2 information records, but it's the same data records. If you have office installed locally, you can still run the version from work, thru the modem like, but simply use your local data records. But so long as those information records are current, you have a cached copy of the Microsoft office files from work. In this regard, MFS is a network file system that will be fast enough to be a replacement local file system. Because the anywhere pc goal says that your pc is the provider of your files, which are at users.isp.net/john.doe. at first glance, you think your ISP has to approve of every file change, but that's not the case. Your home PC is simply granted the access to modify user.isp.net/john.doe files as it pleases. When your home pc logs onto the internet, it also connects to the ISP. so you are running a network file system locally. When disconnected operation gets added, the permanent caching will make it a very simple thing to do. Its not a persistent cache, it's a permanent cache. The only reason caching implies being temporary is because nobody knew how to make it permanent. I think I did it. If I didn't, please point out why. From josh@mercuryfs.net Fri Aug 3 04:28:06 2001 From: josh@mercuryfs.net (Josh) Date: Thu, 2 Aug 2001 20:28:06 -0700 Subject: talked to ESR In-Reply-To: Message-ID: <000201c11bcc$5072be60$35512304@koi> If you want the patent figures, I'll email them to you. For legal reasons, I'm not putting the entire patent online. If you want to see the details of the design, read the design, not the patent. Sorry. This is just provisional, and I'm simply following orders. I thought I put the claims in it. Thanks for pointing that out. I just scanned them, and can email to you directly. But first I ask what your intention is. Why don't you read the design, then get back to me? If you have no interest in my project, then I'd rather not give you the patent claims at this point in time. First I want to know if you are interested or not. No, it's a read/write file system with integrated caching, which should be able to transparently emulate other technologies such as CIFS and NFS. As for the mac FS, the resource fork is not linked via cryptology, and its not a very successful file system, nor is it a distributed file system. It's a different way of doing a file allocation table. Novell calls it a name space. Completely different comparison. As for the IPsec issues, end point authentication is implied by the fact that only the validator and uni id have the first part of the credit card number, which is used to key the IPsec communication. Because the credit card number isn't xferred in its normal form. Its assumed that your credit card is kept confidential, that you use a paper shredder, and basic knowledge. Remember, my argument is that a determined thief can break anything. As for UNI ID's security, the idea is to keep your PIN number secret. I believe many of your arguments are based on the assumption that something like this can be accomplished while being hack proof. I disagree. I believe that any usable system can be hacked. Once combined with PGP, it will be both central and distributed. Those together should make for the most usable secure system. The idea is that if the credit card is valid, and the provided PIN number and stored (incomplete) credit card number hash to the ID which is claimed, then assuming only the holder of the card has the pin number, they have been authenticated and identified, in a basic sense. UNI ID will support the changing of a pin number. Whats important is that UNI ID doesn't store your private key, so authenticating to be yourself and accessing your files are 2 different a passwords. In my opinion, the security of such a design is acceptable, and if anything can be improved. Your cryptographic link that you refer to requires brute force to compute. Remember, nothing is unbreakable. Also, there is nothing in the design to keep the split point of the credit card number to be moved to the left, thus UNI ID stores less of the credit card number, and the PIN number grows in size. This would only serve to increase security. Whats also important is that UNI ID is tied to MFS in a modular way, where a local are network can emulate the UNI ID scheme, or ideally combine the two together. This would be useful for telecommuters who whish to work from home using MFS, but their work doesn't trust UNI ID. MFS can be successful without UNI ID. Also, the central service does not get involved in online e-commerce purchases, UNI ID simply refers to your chosen online payment method. That way, we don't get involved in anything but UNI ID charges. If a pin number and credit card have been obtained, then by shutting off the credit card and ordering a new one, you solve it. Because they wont be able to authenticate using your UNI ID, because UNI ID cant do successful 5 cent charges. This is when you login using your 3rd uni id password, your most secret one. You're supposed to print a copy of your passwords when you setup a new uni id account, and remember the first 2. the pin and private key. The third is used to log into UNI ID and change over to a new credit card number. At which point UNI ID (and therefore MFS) would update the ID's group memberships to use the new ID. -----Original Message----- From: Richard Clayton [mailto:richard@highwayman.com] Sent: Thursday, August 02, 2001 8:08 PM To: Global-Scale Distributed Storage Systems Subject: Re: talked to ESR -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <>, Josh 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----- --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From josh@mercuryfs.net Fri Aug 3 04:43:19 2001 From: josh@mercuryfs.net (Josh) Date: Thu, 2 Aug 2001 20:43:19 -0700 Subject: talked to ESR In-Reply-To: Message-ID: <000301c11bce$708d0eb0$35512304@koi> Also, with IP ver 6, there will be much better geographical mapping of IP addresses. This will help when you are in California and authenticate, then 5 minutes later you authenticate in new york. In that case, UNI ID can be programmed to step in becaue you've been ripped off, just like visa and MasterCard's automatic software does. Computers login with Server accounts, so a different set of rules apply. People will get their UNI ID's ripped off, because it will happen with any successful technology. I think that the basic design is sound, and we can make it usable. Especially since there are 3 uni id passwords total. Also, the groups feature can be replaced or enhanced. Having uni id store the random private key for groups is something that can be updated. For example, it can be delegated to a directory service via LDAP... so that part of the design is not fixed in stone. -----Original Message----- From: Josh [mailto:josh@mercuryfs.net] Sent: Thursday, August 02, 2001 8:28 PM To: Global-Scale Distributed Storage Systems Subject: RE: talked to ESR If you want the patent figures, I'll email them to you. For legal reasons, I'm not putting the entire patent online. If you want to see the details of the design, read the design, not the patent. Sorry. This is just provisional, and I'm simply following orders. I thought I put the claims in it. Thanks for pointing that out. I just scanned them, and can email to you directly. But first I ask what your intention is. Why don't you read the design, then get back to me? If you have no interest in my project, then I'd rather not give you the patent claims at this point in time. First I want to know if you are interested or not. No, it's a read/write file system with integrated caching, which should be able to transparently emulate other technologies such as CIFS and NFS. As for the mac FS, the resource fork is not linked via cryptology, and its not a very successful file system, nor is it a distributed file system. It's a different way of doing a file allocation table. Novell calls it a name space. Completely different comparison. As for the IPsec issues, end point authentication is implied by the fact that only the validator and uni id have the first part of the credit card number, which is used to key the IPsec communication. Because the credit card number isn't xferred in its normal form. Its assumed that your credit card is kept confidential, that you use a paper shredder, and basic knowledge. Remember, my argument is that a determined thief can break anything. As for UNI ID's security, the idea is to keep your PIN number secret. I believe many of your arguments are based on the assumption that something like this can be accomplished while being hack proof. I disagree. I believe that any usable system can be hacked. Once combined with PGP, it will be both central and distributed. Those together should make for the most usable secure system. The idea is that if the credit card is valid, and the provided PIN number and stored (incomplete) credit card number hash to the ID which is claimed, then assuming only the holder of the card has the pin number, they have been authenticated and identified, in a basic sense. UNI ID will support the changing of a pin number. Whats important is that UNI ID doesn't store your private key, so authenticating to be yourself and accessing your files are 2 different a passwords. In my opinion, the security of such a design is acceptable, and if anything can be improved. Your cryptographic link that you refer to requires brute force to compute. Remember, nothing is unbreakable. Also, there is nothing in the design to keep the split point of the credit card number to be moved to the left, thus UNI ID stores less of the credit card number, and the PIN number grows in size. This would only serve to increase security. Whats also important is that UNI ID is tied to MFS in a modular way, where a local are network can emulate the UNI ID scheme, or ideally combine the two together. This would be useful for telecommuters who whish to work from home using MFS, but their work doesn't trust UNI ID. MFS can be successful without UNI ID. Also, the central service does not get involved in online e-commerce purchases, UNI ID simply refers to your chosen online payment method. That way, we don't get involved in anything but UNI ID charges. If a pin number and credit card have been obtained, then by shutting off the credit card and ordering a new one, you solve it. Because they wont be able to authenticate using your UNI ID, because UNI ID cant do successful 5 cent charges. This is when you login using your 3rd uni id password, your most secret one. You're supposed to print a copy of your passwords when you setup a new uni id account, and remember the first 2. the pin and private key. The third is used to log into UNI ID and change over to a new credit card number. At which point UNI ID (and therefore MFS) would update the ID's group memberships to use the new ID. -----Original Message----- From: Richard Clayton [mailto:richard@highwayman.com] Sent: Thursday, August 02, 2001 8:08 PM To: Global-Scale Distributed Storage Systems Subject: Re: talked to ESR -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <>, Josh 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----- --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From josh@mercuryfs.net Fri Aug 3 05:55:56 2001 From: josh@mercuryfs.net (Josh) Date: Thu, 2 Aug 2001 21:55:56 -0700 Subject: uni id Message-ID: <000001c11bd8$9585bbe0$35512304@koi> One last note about UNI ID. If the validator is a public use PC, such as in a library or an airport terminal, then it will always be logged into UNI ID via its own server id. Although I don't have it in the design yet, having the validator and UNI ID maintain a permanent IPsec connection, keyed via unshared info (from a man in the middle perspective), then the scenarios of the validator being faked out by a man in the middle pretending to be universal-id.net, are overcome. In that sense, when the public use PC boots up, it logs into either UNI ID, or MFS... ? This logged in method may or may not be the same as an end users pc logging into their ISP, with async mirroring, in order to make the anywhere PC work. I haven't addressed the anywhere pc details fully yet, I'm focusing on coding the basic stored procedures for the sync groups at the moment. Also, this week I'm working on the other uni id figures to use FIG 96's method of xferring the PIN number securely. So for now, focus on FIG 96. From oren@hishome.net Fri Aug 3 07:05:40 2001 From: oren@hishome.net (Oren Tirosh) Date: Fri, 3 Aug 2001 09:05:40 +0300 Subject: creationism Message-ID: <20010803090540.A3514@hishome.net> creationism n. The (false) belief that large, innovative software designs can be completely specified in advance and then painlessly magicked out of the void by the normal efforts of a team of normally talented programmers. In fact, experience has shown repeatedly that good designs arise only from evolutionary, exploratory interaction between one (or at most a small handful of) exceptionally able designer(s) and an active user population -- and that the first try at a big new idea is always wrong. Unfortunately, because these truths don't fit the planning models beloved of management, they are generally ignored. http://www.tuxedo.org/~esr/jargon/html/entry/creationism.html From ian@hawk.freenetproject.org Fri Aug 3 07:48:57 2001 From: ian@hawk.freenetproject.org (Ian Clarke) Date: Thu, 2 Aug 2001 23:48:57 -0700 Subject: talked to ESR In-Reply-To: ; from richard@highwayman.com on Fri, Aug 03, 2001 at 02:59:43AM +0100 References: Message-ID: <20010802234857.A18805@freenetproject.org> --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 03, 2001 at 02:59:43AM +0100, Richard Clayton wrote: > Exactly what do you have a patent on ?? I've read a certain amount of > the text on your website and have seen a lot of buzzwords, a deep > misunderstanding of the business models of ISPs, an assumption that web > content is static (and served independently of accessing IP address), a > US-centric approach to the law and a cavalier disregard of user's rights > when approached by policemen who persuade you that a life is at risk! I think even in that analysis you have given him too much credit. It would be a great shame if anyone smart wasted any more time on this guy, he is essentially a troll, one who has just enough ability to provoke people to waste their time in responding to his crazy "ideas", but no more than that. Ian. --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7aklZQtgxRWSmsqwRAlK0AKCAR+pzvU8KO2twHCv93krWsI0F0gCbBKn6 HHAxa3SLamkdzibUEBkMYDA= =aHTW -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From josh@mercuryfs.net Fri Aug 3 08:32:41 2001 From: josh@mercuryfs.net (Josh) Date: Fri, 3 Aug 2001 00:32:41 -0700 Subject: MFS compared to ocean store In-Reply-To: Message-ID: <000001c11bee$7af72c30$35512304@koi> The reason we don't need to fight with the cops is because the info we have doesn't identify our end users. They must get the credit card companies and/or ISPs to ID them. So I need not defend our end users, because the Cops will just run into somebody else's system. UNI ID is an intermediary. It will take the cops resources to do this, which means they are most likely to chase child porn and nuclear warhead designs. This wont be a type of thing where we address 100 issues a day. You cant send email with UNI ID, only receive, so you cant threaten people, so the cops wont have to come to us to demand to know who people are. Its simply not necessary for us to put up the fight, because they will need a court order anyhow! For Visa and the ISP! So my views are irrelevant. If I'm a conservative or liberal, the procedures would be the same. Now, a separate issue. I've had a chance to read over ocean stores method of a global identifier (the MFS handle is the comparison). They are quite different in design. The MFS handle is built for an identity function. It's completely extracted from the data, and the ocean store GUID is only partially extracted; part of its identifier is assigned. The MFS handle is created from the URL and its data. In this respect, 2 identical files will create the same MFS handle. That's the identity function. The MFS handle is a globally unique identifier. Since MFS requests data via MFS handle, all routes that the request follows can eavesdrop on the request and/or the data that flows thru it. Imagine that I'm in California, and I request something from Japan. Hawaii eavesdrops on the request as it passes by. Now, Hawaii may have the file, but it doesn't need to do a search, figure out it doesn't have it, then pass the request on, thus incurring the delay of the search. Instead, it immediately passes the request, then as the data starts to flow from Japan thru Hawaii, Hawaii can THEN figure out it has a copy, and TRANSPARENTLY continue the data stream instead of Japan, thus saving the traffic between Hawaii and Japan. To see the figure for this, go to www.mercuryfs.net/design/fig_39.pdf As low priority, hawaii can begin the search when the request first flows thru it, and can have it completed after japan has started sending its data. If a large movie is being watched in new york, from japan, over time all the links transporting the movie will have searched if they have it, in a group effort to conserve bandwidth. Remember that the MFS handle is a function of the url and data, therefore its NOT assigned by the file system. Instead, its assigned TO the file system, by the file. THAT is a very important distinction between MFS and all the others. I expect it to be a much bigger hit outside of the US before inside the US. I predict that New Zealand will be a big fan of it. The design is online. My ideas are documented. I know that all software begins with blueprints, that's why I'm working on the design, not the code. If anybody has a technical question with my ideas, let me know, I'll happily respond. -----Original Message----- From: Ian Clarke [mailto:ian@hawk.freenetproject.org] Sent: Thursday, August 02, 2001 11:49 PM To: Global-Scale Distributed Storage Systems Subject: Re: talked to ESR << File: ATT00013.dat >> << File: footer.txt >> On Fri, Aug 03, 2001 at 02:59:43AM +0100, Richard Clayton wrote: > Exactly what do you have a patent on ?? I've read a certain amount of > the text on your website and have seen a lot of buzzwords, a deep > misunderstanding of the business models of ISPs, an assumption that web > content is static (and served independently of accessing IP address), a > US-centric approach to the law and a cavalier disregard of user's rights > when approached by policemen who persuade you that a life is at risk! I think even in that analysis you have given him too much credit. It would be a great shame if anyone smart wasted any more time on this guy, he is essentially a troll, one who has just enough ability to provoke people to waste their time in responding to his crazy "ideas", but no more than that. Ian. From josh@mercuryfs.net Fri Aug 3 22:25:50 2001 From: josh@mercuryfs.net (Josh) Date: Fri, 3 Aug 2001 14:25:50 -0700 Subject: MFS stored procedures Message-ID: <000001c11c62$df6f9890$35512304@koi> The MFS design references the stored procedures, they are located here: http://www.mercuryfs.net/design/mfs_stored_procedures.pdf From josh@mercuryfs.net Sun Aug 5 22:12:48 2001 From: josh@mercuryfs.net (Josh) Date: Sun, 5 Aug 2001 14:12:48 -0700 Subject: other projects like ocean store Message-ID: <000001c11df3$663b1110$35512304@koi> If any of you know of other projects like Ocean Store or CODA, please let me know. I need to learn of the others that are aiming for the same thing. Those 2 appear to the best comparisons so far. Oh yeah, my summary has been re written, the last one sucked and only focused on bandwidth. From josh@mercuryfs.net Thu Aug 9 00:14:00 2001 From: josh@mercuryfs.net (Josh) Date: Wed, 8 Aug 2001 16:14:00 -0700 Subject: technical feedback Message-ID: <000001c1205f$cf711080$35512304@koi> Since you all have taken such a keen interest in my license, patent, and political opinions, I wanted to let you all know that the business plan summary is now put together. www.mercuryfs.net/business_plan.htm Like most of my stuff, it's a rough draft. If you all thought my engineering was full of hot air, wait 'till you see the business plan. Oh, it's my best yet. - josh PS. I'll bother you guys again when I've got some code (1-2 years). From gohnesorge@lh-computertechnik.de Thu Aug 9 02:34:37 2001 From: gohnesorge@lh-computertechnik.de (g'o'tz ohnesorge) Date: Thu, 09 Aug 2001 03:34:37 +0200 Subject: technical feedback References: Message-ID: <3B71E8AD.6448D2F2@lh-computertechnik.de> Josh wrote: > Since you all have taken such a keen interest in my license, patent, and > political opinions, I wanted to let you all know that the business plan > summary is now put together. www.mercuryfs.net/business_plan.htm Like most > of my stuff, it's a rough draft. > > If you all thought my engineering was full of hot air, wait 'till you see > the business plan. Oh, it's my best yet. > > - josh > > PS. I'll bother you guys again when I've got some code (1-2 years). If you're trying to code clients and servers, take a look at http://www.rebol.com . It's a 200 kByte scripting language that has most web protocols already built in (like listening and talking to ports, http and ftp, email, parsing, lists of objects handling, a compression format, binary and text data files, security levels, and bin hex and b64 encoding), and the basic variants are free. Might save you some time and brain waste in the prototyping phase. Hoping this didn't sound too much like spam or a programming language religion flame war invitation. From bram@gawth.com Thu Aug 9 04:10:17 2001 From: bram@gawth.com (Bram Cohen) Date: Wed, 8 Aug 2001 20:10:17 -0700 (PDT) Subject: technical feedback In-Reply-To: Message-ID: On Wed, 8 Aug 2001, Josh wrote: > PS. I'll bother you guys again when I've got some code (1-2 years). I find the suggestion that you could ever get code working quite humorous. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From josh@mercuryfs.net Thu Aug 9 21:20:13 2001 From: josh@mercuryfs.net (Josh) Date: Thu, 9 Aug 2001 13:20:13 -0700 Subject: technical feedback In-Reply-To: Message-ID: <000401c12110$b24eb320$35512304@koi> I find your lack of technical criticism to be a waste of time. -----Original Message----- From: Bram Cohen [mailto:bram@gawth.com] Sent: Wednesday, August 08, 2001 8:10 PM To: Global-Scale Distributed Storage Systems Subject: Re: technical feedback On Wed, 8 Aug 2001, Josh wrote: > PS. I'll bother you guys again when I've got some code (1-2 years). I find the suggestion that you could ever get code working quite humorous. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From josh@mercuryfs.net Fri Aug 10 09:29:36 2001 From: josh@mercuryfs.net (Josh) Date: Fri, 10 Aug 2001 01:29:36 -0700 Subject: a global fs Message-ID: <000201c12176$97580470$35512304@koi> In an attempt to jumpstart this dead email list, I put forth the following statement: The essence of a global file system is a globally unique file identifier (file handle), and a globally unique user identification/authentication method. Nail those 2, and the rest is easy. I'm not interested in anything other than technical responses. From richard@highwayman.com Fri Aug 10 12:11:05 2001 From: richard@highwayman.com (Richard Clayton) Date: Fri, 10 Aug 2001 12:11:05 +0100 Subject: a global fs In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <>, Josh writes >In an attempt to jumpstart this dead email list, I put forth the following >statement: > >The essence of a global file system is a globally unique file identifier >(file handle), not always ... I can say "I'd like a copy of the PGP source please" then, when a system (or a friend with email) delivers me a copy then I will check that what I have received is acceptable by checking a signature on the source. If I trust the signature then I will accept the source as being valid. There may be many files with such a signature on, and I may be happy to accept any of them. >and a globally unique user identification/authentication >method. I can see no obvious requirement for this in a simple file system. Many people think they want this for other reasons (political control or money collection), but it doesn't have much to do with file handling. >Nail those 2, and the rest is easy. there's no evidence for this >I'm not interested in anything other than technical responses. the list is run for other reasons than just your benefit. Wait and see whether a fruitful discussion comes along rather than just stirring. - -- 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/AwUBO3PBSRfnRQV/feRLEQKN0ACfasvsbpU2NbePXFIu0Ym50BDD3Z4AoN/1 rZub7k02t0XpdU0adG397/b7 =OUIX -----END PGP SIGNATURE----- From blanu@bozonics.com Fri Aug 10 13:03:36 2001 From: blanu@bozonics.com (Brandon Wiley) Date: Fri, 10 Aug 2001 07:03:36 -0500 (CDT) Subject: a global fs In-Reply-To: Message-ID: > The essence of a global file system is a globally unique file identifier > (file handle), and a globally unique user identification/authentication > method. > > Nail those 2, and the rest is easy. Yep. Freenet has that. CHKs and SVKs. From josh@mercuryfs.net Fri Aug 10 23:40:08 2001 From: josh@mercuryfs.net (Josh) Date: Fri, 10 Aug 2001 15:40:08 -0700 Subject: a global fs In-Reply-To: Message-ID: <000101c121ed$68fa3b80$35512304@koi> Thanks for the reply. Accessing data is a bit of a challenge, I agree. Your PGP example is a good example a fundamental security issue. Here's what I've done about it. I've broken the file access method into 2 main steps. The first step is resolving the URL to the file handle. This is done with a somewhat client/server approach, in that its hierarchical, and security applies. PGP-like signatures are used, to ensure the authenticity of the information records (used for the resolve step). Essentially, you must use a trusted source to resolve the URL to file handle. But the file handle is a function of the data. It's basically the size, crypto hash, dns domain (exception, this value is assigned) and file extension. Because of this design, the next half of file access is much easier. Once you access it via its math values, the provider is irrelevant because security is a non issue. This is because only the data you're requesting will have those values. To put it another way, at this step in the process there is only the concept of a corrupt file, not a false file. Since this method allows anybody to provide the data, the task becomes getting it via the fastest method. The PGP signature example you stated would apply to the first part of the file access, when the URL is being resolved to a file handle, but not to the second part. Another byproduct of using this method is caching. If you have a file with the same handle locally, then you need not request it from the network. As for the globally unique user identifier, it's used for encryption and authentication. Basically, if I want to encrypt a file so only X can decrypt it, I need to use X's public key. Hence the need for the identifier. In order to make the encryption features work, the central system which is the key authority, must keep a record of all the users. Now for a local area network file system, this wouldn't be a political challenge. But for a global file system, this central authority would be looked upon as being the achilles heel, especially if it stored its end users names, addresses, etc. I believe if the central authority was to be able to function while only storing an incomplete credit card number and email address, it would be politically feasible. Separately, I don't expect this list to exist only for my benefit, however that is the reason I'm here. Instead, I don't waste time with irrelevant philosophical / political issues, only technical/business issues. I do hope for a fruitful technical discussion, otherwise I'm wasting my time. I laugh at those that see email groups as their social livelihood (not you personally). I prefer to focus on billable hours, and go online for tech support and news, not the email groups. But now that I'm working on this project full time, I'm back online. Last time I was online this much was 8th grade...... Funny how the psychology hasn't changed. There's a few good people, the rest are either naysayers who poke, but have nothing useful to say, or remain silent. Like most things in life, you have to wade thru the majority of crap to find the gold nuggets. I remember this one client who had a great network administrator/engineer in house. But the guy couldn't communicate, be assertive, etc. He sat in the computer room (probably in newsgroups) while his managers hired me to do what he was capable of. Funny thing was, based on how his network was setup, this guy knew exactly what he was doing. But he lacked the business skills to be successful. He didn't like me, and felt I was a threat to him (maybe he wasent that dumb afterall). For moral reasons, I specifically said "I think you're capable of doing this, assuming you have the time", to him, in front of his supervisor (who hired me). After a few months, and about 40 billable hours, his supervisor (who was new to the job), asked me if I felt he should replace his administrator. I said "only if you can find somebody better". Then for the next 3 weeks, I helped him interview people. The administrator was replaced, and I didn't loose any sleep over it. For those same reasons, I don't spend my days typing emails. This is business. That's how I see things. I'm not a manager (am a project manager), and I'm not an in house network administrator. I've worked with enough startup companies, and have observed useless idiots scoring funding. If they can do it, so can I. - josh -----Original Message----- From: Richard Clayton [mailto:Richard.Clayton@cl.cam.ac.uk] On Behalf Of Richard Clayton Sent: Friday, August 10, 2001 4:11 AM To: Global-Scale Distributed Storage Systems Subject: Re: a global fs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <>, Josh writes >In an attempt to jumpstart this dead email list, I put forth the following >statement: > >The essence of a global file system is a globally unique file identifier >(file handle), not always ... I can say "I'd like a copy of the PGP source please" then, when a system (or a friend with email) delivers me a copy then I will check that what I have received is acceptable by checking a signature on the source. If I trust the signature then I will accept the source as being valid. There may be many files with such a signature on, and I may be happy to accept any of them. >and a globally unique user identification/authentication >method. I can see no obvious requirement for this in a simple file system. Many people think they want this for other reasons (political control or money collection), but it doesn't have much to do with file handling. >Nail those 2, and the rest is easy. there's no evidence for this >I'm not interested in anything other than technical responses. the list is run for other reasons than just your benefit. Wait and see whether a fruitful discussion comes along rather than just stirring. - -- 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/AwUBO3PBSRfnRQV/feRLEQKN0ACfasvsbpU2NbePXFIu0Ym50BDD3Z4AoN/1 rZub7k02t0XpdU0adG397/b7 =OUIX -----END PGP SIGNATURE----- --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From josh@mercuryfs.net Sat Aug 11 01:33:45 2001 From: josh@mercuryfs.net (Josh) Date: Fri, 10 Aug 2001 17:33:45 -0700 Subject: freenet Message-ID: <000701c121fd$4824d360$35512304@koi> In response to the comparison with freenet, I'm aware that they are using a hash (and more) as a key type. But I haven't read deep into the technical stuff, because it will only complicate things. Ted Anderson (who I believe maintains this list) responded to an email of mine, and pointed out that he played a major role in a freenet key type. I responded with the MFS handle formula, and if it was identical to freenet, I assume he would of pointed it out. From what I read from the freenet web site (in May), the file name and hash are used in the key, but the extension and size are not (they are with the mfs handle). However, if you guys could tell me if they are using a credit card for a form of identification, I'd appreciate it. I doubt it, because one of them would of pointed it out by now. Also, doesn't freenet only encrypt data from point to point? From what I know (and it aint much), it doesn't permanent store data in encrypted format. Its funny how I hold back from reading about freenet, because of legal reasons. You guys do have a point when you say that intellectual property issues are a pain in the ass. However, because we are computer specialists, this is an area of the law that impacts us. Personally, I feel there would be headaches to deal with regardless what your profession is. I know freenet is aiming for similar goals, but their approach is different. Unfortunately the freenet philosophy wont allow us to work together. Before I got the design to where it is, it was just a hobby, most of the time spent as thinking about how to overcome the duplication problem. Since it was a hobby, I never read the engineering details of AFS, or others. I only learned enough about NFS to maintain it. So now I'm learning of all the others. Oh yeah, MFS is also aiming to be a replacement for ICP, but there is no ICP interface yet in the design (along with may other missing pieces). From bram@gawth.com Sat Aug 11 01:55:27 2001 From: bram@gawth.com (Bram Cohen) Date: Fri, 10 Aug 2001 17:55:27 -0700 (PDT) Subject: freenet In-Reply-To: Message-ID: On Fri, 10 Aug 2001, Josh wrote: > However, if you guys could tell me if they are using a credit card for a > form of identification, I'd appreciate it. Am I the only one who fell over laughing when they read this? -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From josh@mercuryfs.net Sat Aug 11 01:58:08 2001 From: josh@mercuryfs.net (Josh) Date: Fri, 10 Aug 2001 17:58:08 -0700 Subject: freenet In-Reply-To: Message-ID: <000a01c12200$b06380e0$35512304@koi> That was very helpful. We made a lot of progress... Thank you -----Original Message----- From: Bram Cohen [mailto:bram@gawth.com] Sent: Friday, August 10, 2001 5:55 PM To: Global-Scale Distributed Storage Systems Subject: Re: freenet On Fri, 10 Aug 2001, Josh wrote: > However, if you guys could tell me if they are using a credit card for a > form of identification, I'd appreciate it. Am I the only one who fell over laughing when they read this? -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From blanu@bozonics.com Sat Aug 11 02:14:14 2001 From: blanu@bozonics.com (Brandon Wiley) Date: Fri, 10 Aug 2001 20:14:14 -0500 (CDT) Subject: freenet In-Reply-To: Message-ID: > Ted Anderson (who I believe > maintains this list) responded to an email of mine, and pointed out that he > played a major role in a freenet key type. No, not really. Although he certainly was on the list for a while and was on the side of content hashes. The major role played in the development of the Freenet key types were Oskar Sandberg and myself, pulling in opposite directions. > >From what I read from the freenet web site (in May), the file name and hash > are used in the key, but the extension and size are not (they are with the > mfs handle). An extension is, by definition, part of the filename. Keys don't contain the exact size of the file, but do contain a maximum size for the file expressed in a fixed length logarithmic scale. > would of pointed it out by now. Also, doesn't freenet only encrypt data from > point to point? From what I know (and it aint much), it doesn't permanent > store data in encrypted format. It does both. From josh@mercuryfs.net Sat Aug 11 02:29:26 2001 From: josh@mercuryfs.net (Josh) Date: Fri, 10 Aug 2001 18:29:26 -0700 Subject: freenet In-Reply-To: Message-ID: <000f01c12205$0fafb9c0$35512304@koi> Thank you, I appreciate the info. Ted didn't claim to be the main guy, rather a contributing member who's been involved in content based file handles for a long time. Also, regarding intellectual property issues, I do not intend to try to block freenet from evolving. My desire for the patent is to deal with Microsoft. I have no problem with you guys. Check out this link, Microsoft is trying for the third time on their file system goal. The first was called OFS, in the early-mid 90's. If I get my way, I will be them to it. I've made the decision to focus on the NT marketplace first, because of their lack of distributed file systems. Funny, I intend to hire oracle to design the Microsoft SQL server version first !? (I love it) http://www.zdnet.com/anchordesk/stories/story/0,10738,2802585,00.html This is going to be interesting... -----Original Message----- From: Brandon Wiley [mailto:blanu@bozonics.com] Sent: Friday, August 10, 2001 6:14 PM To: Global-Scale Distributed Storage Systems Subject: Re: freenet > Ted Anderson (who I believe > maintains this list) responded to an email of mine, and pointed out that he > played a major role in a freenet key type. No, not really. Although he certainly was on the list for a while and was on the side of content hashes. The major role played in the development of the Freenet key types were Oskar Sandberg and myself, pulling in opposite directions. > >From what I read from the freenet web site (in May), the file name and hash > are used in the key, but the extension and size are not (they are with the > mfs handle). An extension is, by definition, part of the filename. Keys don't contain the exact size of the file, but do contain a maximum size for the file expressed in a fixed length logarithmic scale. > would of pointed it out by now. Also, doesn't freenet only encrypt data from > point to point? From what I know (and it aint much), it doesn't permanent > store data in encrypted format. It does both. --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From gohnesorge@lh-computertechnik.de Sat Aug 11 10:41:22 2001 From: gohnesorge@lh-computertechnik.de (g'o'tz ohnesorge) Date: Sat, 11 Aug 2001 11:41:22 +0200 Subject: freenet References: Message-ID: <3B74FDC2.EA4EC3A@amiga.com> Josh wrote: > That was very helpful. We made a lot of progress... > > Thank you > > -----Original Message----- > From: Bram Cohen [mailto:bram@gawth.com] > Sent: Friday, August 10, 2001 5:55 PM > To: Global-Scale Distributed Storage Systems > Subject: Re: freenet > > On Fri, 10 Aug 2001, Josh wrote: > > > However, if you guys could tell me if they are using a credit card for a > > form of identification, I'd appreciate it. > > Am I the only one who fell over laughing when they read this? > > -Bram Cohen > > "Markets can remain irrational longer than you can remain solvent" > -- John Maynard Keynes Maybe I can help out with a few hints: a) Credit card fraud makes several times more money change owners than do bank raids. b) There's credit card number generator programs available (on the net, on BBSs, among the h4><0r community, wherever ..) that make a seemingly valid CC number for you - mostly used to get free access to pr0n sites, I'd guess. The reason that this is at all possible is that CC numbers are really not even remotely secure identification numbers, but random numbers with an identity problem (the teacher will draw a smily in my homework book for this clever expression). A CC number is a hash of the owners name (or even only length of that), the expiration date, and a serial number. That they're able to get away with that and most other thin gs that are referred to as security measures in the world of American business, roots in the widely lamented fact that mathematics is the best kept secret in the American educational system, even more than how to avoid pregnancies. (Sorry for the bashing, nearly all Americans I got to know on the net a really well educated and also very smart people, but as a whole the opposite seems to be available widely enough to allow for commercial mining.) c) If one of your main goals, as in Freenet and a bunch of other distributed systems, is to prevent censorship, and for that reason also ensure that access is as anonymous as humanly or mathematically possible, then using a CC number that you have to acquire by means of showing your ID card to a commercial venture known for making their customer information database available for free to the governement and for cash to everyone else, can only be perceived as a hideous attempt at standup comedy. And there's another story that came to my mind regarding the attitude to need to leave your CC number around everywhere, and treat everything as someone else's property that you have to pay for over and over at every corner. It's a poem which most kids in Germany over the past decades had to learn some time, about a guy named Mr. Ribbeck of Ribbeck in Havelland: In short, he had a fruit tree (birnbaum) in his garden, and given the age of the poem, those very sweet fruits were newly introduced to the area in what now is, I think, northern Poland, and thus probably still quite expensive. This guy had a habit of giving those fruits away to kids who came by his house. Some time he got old, and knew what would soon happen. He also knew that his son to inherit the house and garden would not go on to give fruits away to kids. So he demanded that upon his burial, one such fruit was to be placed upon his grave. Some years later, a new fruit tree had grown in the grave yard, where everyone could go and pick a fruit for free. Not sure what the message in tha t could be .. From josh@mercuryfs.net Sat Aug 11 22:22:49 2001 From: josh@mercuryfs.net (Josh) Date: Sat, 11 Aug 2001 14:22:49 -0700 Subject: freenet In-Reply-To: Message-ID: <000001c122ab$c6e198b0$35512304@koi> It is true that credit card fraud does make a lot of money. My goal is a global method whereby a person does not need to be assigned another ID to remember. I figured that since credit cards are global, I can utilize them. Visa and Mastercard currently are not deployed in China, but they are virtually everywhere else. Since our charges will be 25 cents or less, any abuse should show up easily. Even though its going to be a virtually open source design, we will probably keep the credit card module closed source, so people cant modify it and redistribute it in order to steal credit card numbers. This should help with that issue. We believe that the business model of charging an end user an insignificant amount in order to authenticate them, is a valid model. An added byproduct of using a credit card is that the bill is an audit log. Technically, the credit card number is not ever stored locally, and its not transferred across the internet in an unprotected form. Basically, a UNI ID is a hash of a credit card number and password. To see this, click here www.mercuryfs.net/design/uni_id.pdf and here www.mercuryfs.net/design/fig_96.pdf. A very useful American law is that a person is only liable for up to $50 (usually they pay nothing) when their credit card has been stolen. I figure this is an advantage. I remember years ago, back in the BBS days, some guy stole or deduced a formula that could turn any credit card that ended in a 6 or a 9 into another valid credit card number. At least that's what he claimed. Our goal will be to engineer the system to a near foolproof and automated level. Either the credit card is full, shut off, its UNI ID disabled by the owner, or the pin number is invalid. Oh yeah, the credit card is not necessary to browse files via MFS, its only used for file writes and encryption features. As for your points about Americans, I wholly agree, and I'm an American. To quote Chris Rock? Kid Rock? (I forget who).. "the only reason the cities are full of black niggers, is because the rest of the countryside is full of white niggers" To put it another way: people are people. I remember going to France, and being told by a bunch of Americans that the French are pricks. I soon realized that the rudest people there were Americans (and British). Its funny, the Europeans look upon the British as the Texan's of Europe. In my opinion, if you can handle the attitudes of Los Angeles, you can go anywhere in the world, because it doesn't get much worse than here. I even consider New Yorker's to be more honest and direct, and less full of crap, than people in LA. Personally, I blame Hollywood. I think they turned most of the women around here into stuck-up bitches. They don't seem to be as bad in central and northern California, or in New York, or anywhere else I've been. ...?!?! -----Original Message----- From: g'o'tz ohnesorge [mailto:gohnesorge@lh-computertechnik.de] Sent: Saturday, August 11, 2001 2:41 AM To: Global-Scale Distributed Storage Systems Subject: Re: freenet Josh wrote: > That was very helpful. We made a lot of progress... > > Thank you > > -----Original Message----- > From: Bram Cohen [mailto:bram@gawth.com] > Sent: Friday, August 10, 2001 5:55 PM > To: Global-Scale Distributed Storage Systems > Subject: Re: freenet > > On Fri, 10 Aug 2001, Josh wrote: > > > However, if you guys could tell me if they are using a credit card for a > > form of identification, I'd appreciate it. > > Am I the only one who fell over laughing when they read this? > > -Bram Cohen > > "Markets can remain irrational longer than you can remain solvent" > -- John Maynard Keynes Maybe I can help out with a few hints: a) Credit card fraud makes several times more money change owners than do bank raids. b) There's credit card number generator programs available (on the net, on BBSs, among the h4><0r community, wherever ..) that make a seemingly valid CC number for you - mostly used to get free access to pr0n sites, I'd guess. The reason that this is at all possible is that CC numbers are really not even remotely secure identification numbers, but random numbers with an identity problem (the teacher will draw a smily in my homework book for this clever expression). A CC number is a hash of the owners name (or even only length of that), the expiration date, and a serial number. That they're able to get away with that and most other thin gs that are referred to as security measures in the world of American business, roots in the widely lamented fact that mathematics is the best kept secret in the American educational system, even more than how to avoid pregnancies. (Sorry for the bashing, nearly all Americans I got to know on the net a really well educated and also very smart people, but as a whole the opposite seems to be available widely enough to allow for commercial mining.) c) If one of your main goals, as in Freenet and a bunch of other distributed systems, is to prevent censorship, and for that reason also ensure that access is as anonymous as humanly or mathematically possible, then using a CC number that you have to acquire by means of showing your ID card to a commercial venture known for making their customer information database available for free to the governement and for cash to everyone else, can only be perceived as a hideous attempt at standup comedy. And there's another story that came to my mind regarding the attitude to need to leave your CC number around everywhere, and treat everything as someone else's property that you have to pay for over and over at every corner. It's a poem which most kids in Germany over the past decades had to learn some time, about a guy named Mr. Ribbeck of Ribbeck in Havelland: In short, he had a fruit tree (birnbaum) in his garden, and given the age of the poem, those very sweet fruits were newly introduced to the area in what now is, I think, northern Poland, and thus probably still quite expensive. This guy had a habit of giving those fruits away to kids who came by his house. Some time he got old, and knew what would soon happen. He also knew that his son to inherit the house and garden would not go on to give fruits away to kids. So he demanded that upon his burial, one such fruit was to be placed upon his grave. Some years later, a new fruit tree had grown in the grave yard, where everyone could go and pick a fruit for free. Not sure what the message in tha t could be .. --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From stevej@sieve.net Sat Aug 11 23:26:36 2001 From: stevej@sieve.net (steve jenson) Date: Sat, 11 Aug 2001 15:26:36 -0700 Subject: freenet In-Reply-To: ; from josh@mercuryfs.net on Sat, Aug 11, 2001 at 02:22:49PM -0700 References: Message-ID: <20010811152636.A3314@sieve.net> Quoting Josh (josh@mercuryfs.net): > It is true that credit card fraud does make a lot of money. My goal is a > global method whereby a person does not need to be assigned another ID to > remember. I figured that since credit cards are global, I can utilize them. > Visa and Mastercard currently are not deployed in China, but they are > virtually everywhere else. Since our charges will be 25 cents or less, any > abuse should show up easily. > > Even though its going to be a virtually open source design, we will probably > keep the credit card module closed source, so people cant modify it and > redistribute it in order to steal credit card numbers. This should help with > that issue. For about 5 minutes until somebody reverse engineers your code. If keeping your source closed on this is your measure of protection then you're in deep trouble. There's no security through obscurity. > We believe that the business model of charging an end user an > insignificant amount in order to authenticate them, is a valid model. An > added byproduct of using a credit card is that the bill is an audit log. > > Technically, the credit card number is not ever stored locally, and its not > transferred across the internet in an unprotected form. Basically, a UNI ID > is a hash of a credit card number and password. To see this, click here > www.mercuryfs.net/design/uni_id.pdf First, why are you making people download PDF's and shockwave files when regulare HTML and animated gif's would suffice? From uni_id.pdf >A UNI ID is a globally unique identification, in the form of an >email address. Example: bigassunreadblestring@universal-id.net I thought you just said that you weren't going to be giving people another ID number to remember? "no two people have the same card number" I think this was already pointed out to be not true. "When a credit card is invalidated, its UNI IDs no longer test valid" I would appreciate you going into depth regarding exactly how you generate the ID from the Credit Card number and Pin in such a way as to make it easily provable to be invalid without central ID repository lookups. Banks already know that central lookups for every transaction will not scale. (Refer to Ross Anderson's excellent 'Security Engineering' chapter 9) "When a user sets up a UNID ID account, 3 passwords are given." You get an F- in usability, son. "4. The party wishing to validate your ID will have just received either VALID or INVALID." ooh!! I get all sorts of excited when I read about authentication schemes that never hand back a token that can be guaranteed to prove the end state of the transaction. If you don't know why, that doesn't surprise me. (skipping ahead.. getting bored with techno-babble): "User and Server types operate the same, but Groups rely on universal-id.net to be the trusted source of the private key When a member requests a groups private key..." huh? Do you know anything at all about public key cryptography? "When you login to a PC connected to the Internet and slide your credit card thru (sic) your keyboad (will soon be a standard)" This is just stupid. Nobody will do this. Well, I could do this all day long but I think I'd rather go work on a useful project. > Our goal will be to engineer the system to a near foolproof and automated > level. Ah yes, who doesn't have this goal? > ... ... ...Personally, I blame Hollywood. I think they turned > most of the women around here into stuck-up bitches. This sentece tells me that you should work more on your lady skills and less on thinking up vapourware. cheers, steve -- steve jenson http://sieve.net/ PGP fingerprint: 79D0 4836 11E4 A43A 0179 FC97 3AE2 008E 1E57 6138 From josh@mercuryfs.net Sun Aug 12 00:23:49 2001 From: josh@mercuryfs.net (Josh) Date: Sat, 11 Aug 2001 16:23:49 -0700 Subject: uni id In-Reply-To: Message-ID: <000201c122bc$ad8eaf90$35512304@koi> Is this where I'm supposed to feel like I've been shot down? Oh yeah, here's where I feel humiliated. Now... I'm going to reply, step by step, and lets see if you stay engaged, or go back to the sidelines.... And yes, I do appreciate you giving this conversation some life. Otherwise I wouldn't be able to justify filling up everybodys inbox with this huge message. As for the separate module plan, it will not eliminate anything, only make it more of a hassle. My plan is to rely on NT's native credit card reader that will eventually be made. That way, its Microsoft's problem, not mine. Yeah, it don't yet exist, but I do believe card readers in keyboards will become standard. I think by simply monitoring the underground, and offering $50,000 rewards to the very people that crack the system, to create something better, I can simply turn this problem onto itself. See, the Adobe people screwed up by having the Russian arrested. They should have offered his company a contract to improve the security. I don't you about you guys, but I'm convinced this is the very best way to approach the problem. Especially with a nearly open source design. All I know is that if I have a budget to work with, I can greatly reduce this problem. Also, we could tie it into NT's driver authentication routine, where a hash/crc (whatever) is stored of the driver, and anything else but that wont be allowed to load. God, why didn't they have that in windows 3.0, back in 1990? For Christ sakes, to first validate what is to be loaded into the kernel has been a part of mainframe operating systems forever (hasn't it?). Separately, the fact is that hackers go after vulnerable credit card databases, not the individual cards that fly thru the Internet. Ideally, you get a separate credit card just for UNI ID, so the bill is just an audit log, nothing else. Heck, make it a 100 dollar card. Plus, if you shut it off, it doesn't effect your regular credit cards. As for the animated files, I suck at web authoring. If you want to re do them, once I get funding, I'll pay you for it.. As for the "no two people have the same credit card number" statement, I also previously pointed out that it was an error. It should be "no two people have the same credit card number and pin number". Once an account is setup, it checks for a collision (an existing identical ID), and if there is one, the end user must choose a different password (the "completion password'). Therefore the issue is solved. If not, show me why. Also, note the sub account # (value 63050). It exists to identify different accounts using the same card. As for the 3 passwords, it's a necessity. As stated earlier, the first is your pin number that's used for authentication. Its low security because its used often. The next is your private key, used for decryption, its high security. The last is your account login password, when you need to change your other passwords, or ID, and/or credit card number. As for the usability, I'm not going to put everything into 1 password. That would be a poor tradeoff. As for uni-id being the private key keeper for groups, that is temporary. What I'm really aiming for is something that can be emulated in NT's active directory, or novell's NDS. That way, MFS can run on those platforms and hopefully end up providing uni-id and pgp based security for accesses coming from the Internet. This would achieve a level of transparency, where it all appears to be the same from the outside, but you're running your native O/S on the inside. That's the ultimate goal. When I said I wasn't going to give people a long ID to remember, I was referring to the method of appending your pin number to your credit card, then hashing it. That's your ID. So your id is essentially a formula, you need not memorize it. But you do need to remember what credit card you used. As for vaporware, my stuff is NOT vaporware. Rather, its napkin ware. When you have a design on a napkin, you have thus elevated yourself to a higher level than vaporware. Especially if you got a 2" binder, soon to be 3", full of stuff that looks like blueprints. As for do I know anything about public key cryprography: I'm not an expert, nor do I intend to be. But I have a good chance of talking my way into funding, then hiring an expert. I claim to be a business man, who's engineering is good enough to fool the venture capitalists. Hell, I'm going to toss the uni id design to my attorneys within a few weeks (after I fill it in)), and let them figure out if it will work or not. I love it, they gotta research it, shit, let them deal with it!!! See, they don't want to be embarrassed in their own field by patenting something that wont work! That's a very very handy fact that I learned for an old client of mine. See, in a way, its 2 birds with 1 stone... As for using a bank for every transaction, authentications only occur at login, or when a server is establishing a security trust with another server. For all file system events other than this, the banks are not involved. As for how it works, and how it keeps your info confidential, here's the details, and you need to reference figures 63 and 96. go to www.mercuryfs.net/design/figures_index.htm. You also need to reference the uni-id design (what exists of it at the moment). Definitions: The validator: is either your home PC, your work PC, somebody else's PC, or a public use PC. For public use PCs, you must trust the place your at just as you trust an ATM machine that you walk up to. Just as fake ATM's can suck out your info, a fake validator can suck your credit card and pin number, and private key. My rationale: Any public use PC will be a security risk, forever. This does not apply to my design, but to everything. The goal is to be practical, not theoretically unbreakable. End user: that's you. universal-id.net: the central authentication network. When you setup an account, a figure 63 record is created. Your first account has a sub id # of 00 (value 63050). Your next one will be 01. It stops at 99. So you can have 100 accounts per credit card. Note that your credit card # is stored in an incomplete manner (value 63005). The expiration date is not stored. To compute the rest of the credit card, a brute force method is needed. The fact that the completion password (reference unid id design) is not fixed in length works to your advantage. Note that nothing keeps the incomplete credit card number from being shorter, thus storing less of it. When this happens, the beginning of the UNI ID pin grows in length. How it works: Note from the design, the UNI ID pin # (the 1st of the 3 passwords) begins with 4 numbers, which are assigned to you. Only the last part of the pin number is your chosen "completion" password. Thus, if the last 2 digits of my credit card number are 34, and this is my first UNI ID (sub account number is 00), and my chosen completion password is "ok", then my pin number is "3400ok" Ideally, a person will use a longer password than ok. The fact that the completion password is not fixed in length, but the ID is, helps to hide the info behind the hash function, and utilize its 1-way property to make computation of the info a pain in the ass. At this point in time, only you have your uni id pin number. The central system has your incomplete credit card number and uni id on file. (and your RSA public key, but not private key) Here's how the authentication steps go. Follow fig 96. You either manually enter your credit card number and expiration date, or swipe the card thru the keyboard. You manually enter your pin number. Think of this step as your login name and password, for a global file system login. The validator computes your uni id by hashing your full credit card number and your uni id password (less the first 2 digits, since the credit card number is complete). The validator sends to universal-id.net "I'm validating uni id X" along with a timestamp. universal-id.net receives this request, looks up the ID's dbase record by searching value 63003 (fig 63). It then prepares an IPsec tunnel (IPsec could be substituted for encryption, I suppose) using a hash of the first 8 digits of the credit card number & time stamp as the key. This is done by referencing value 63005 to get the (incomplete) credit card number. During this time, the validator will have also prepared an IPsec channel, using the same info. Note that the only info that has crossed the internet is the ID (the biglongrandomstring@universal-id.net). Because both sides prepare the IPsec channel identically, and key it with the same password (hash of credit card and timestamp), they will communicate. Universal-id.net then sends an ok message, via the IPsec. The validator sends the uni id pin number to universal-id.net via IPsec. The incomplete credit card number (value 63005) is appended with the newly received pin number. It is then hashed, and compared to value 63003. If it matches, the credit card is charged 15 cents (or whatever), and the item on the credit card is the uni id, and the timestamp. Thus they will have an audit log for their authentication. This step is what identifies the person as being that dbase record. Assuming the pin number is kept secret, and the credit card charge goes thru, they are considered authenticated. Now, a number of things can go wrong. The IPsec can be keyed differently, the pin number and credit card may hash to a different or non existent id, the credit card charge may fail. All of these events represent a failed authentication. That's the essence of it. Note that fig 96 is the only figure that represents the xfer of the pin number via IPsec, I have yet to update the other uni id figures. Now, I haven't answered everything, but give me issues that you want more detail on, and I'll gladly elaborate. I think this is unique because either nobody has thought of it before, or it wont work because there's something that I'm missing. Either way, that's why I'm here. -----Original Message----- From: steve jenson [mailto:stevej@sieve.net] Sent: Saturday, August 11, 2001 3:27 PM To: Global-Scale Distributed Storage Systems Subject: Re: freenet Quoting Josh (josh@mercuryfs.net): > It is true that credit card fraud does make a lot of money. My goal is a > global method whereby a person does not need to be assigned another ID to > remember. I figured that since credit cards are global, I can utilize them. > Visa and Mastercard currently are not deployed in China, but they are > virtually everywhere else. Since our charges will be 25 cents or less, any > abuse should show up easily. > > Even though its going to be a virtually open source design, we will probably > keep the credit card module closed source, so people cant modify it and > redistribute it in order to steal credit card numbers. This should help with > that issue. For about 5 minutes until somebody reverse engineers your code. If keeping your source closed on this is your measure of protection then you're in deep trouble. There's no security through obscurity. > We believe that the business model of charging an end user an > insignificant amount in order to authenticate them, is a valid model. An > added byproduct of using a credit card is that the bill is an audit log. > > Technically, the credit card number is not ever stored locally, and its not > transferred across the internet in an unprotected form. Basically, a UNI ID > is a hash of a credit card number and password. To see this, click here > www.mercuryfs.net/design/uni_id.pdf First, why are you making people download PDF's and shockwave files when regulare HTML and animated gif's would suffice? >From uni_id.pdf >A UNI ID is a globally unique identification, in the form of an >email address. Example: bigassunreadblestring@universal-id.net I thought you just said that you weren't going to be giving people another ID number to remember? "no two people have the same card number" I think this was already pointed out to be not true. "When a credit card is invalidated, its UNI IDs no longer test valid" I would appreciate you going into depth regarding exactly how you generate the ID from the Credit Card number and Pin in such a way as to make it easily provable to be invalid without central ID repository lookups. Banks already know that central lookups for every transaction will not scale. (Refer to Ross Anderson's excellent 'Security Engineering' chapter 9) "When a user sets up a UNID ID account, 3 passwords are given." You get an F- in usability, son. "4. The party wishing to validate your ID will have just received either VALID or INVALID." ooh!! I get all sorts of excited when I read about authentication schemes that never hand back a token that can be guaranteed to prove the end state of the transaction. If you don't know why, that doesn't surprise me. (skipping ahead.. getting bored with techno-babble): "User and Server types operate the same, but Groups rely on universal-id.net to be the trusted source of the private key When a member requests a groups private key..." huh? Do you know anything at all about public key cryptography? "When you login to a PC connected to the Internet and slide your credit card thru (sic) your keyboad (will soon be a standard)" This is just stupid. Nobody will do this. Well, I could do this all day long but I think I'd rather go work on a useful project. > Our goal will be to engineer the system to a near foolproof and automated > level. Ah yes, who doesn't have this goal? > ... ... ...Personally, I blame Hollywood. I think they turned > most of the women around here into stuck-up bitches. This sentece tells me that you should work more on your lady skills and less on thinking up vapourware. cheers, steve -- steve jenson http://sieve.net/ PGP fingerprint: 79D0 4836 11E4 A43A 0179 FC97 3AE2 008E 1E57 6138 --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From josh@mercuryfs.net Sun Aug 12 00:31:04 2001 From: josh@mercuryfs.net (Josh) Date: Sat, 11 Aug 2001 16:31:04 -0700 Subject: the british In-Reply-To: Message-ID: <000301c122bd$b02c2150$35512304@koi> Ooops, his email ended in "cheers, - steve"... Perhaps he's a Brit....??? No wonder I pissed him off. You guys are more than the Texans of Europe, Britain is the best example of a worldwide failure to date! And to think, you Brits still bow before the queen. Oh, I love it. America beat your ass, with one of your own officers (Washington), then we saved it twice (WW 1 and 2). Oh, and the best part of the history books: when Washington rowed across the Delaware, it was an act of desperation. But you Brits were passed out drunk, after throwing a victory party..... and that's how we won our Independence! Because of the drunken Brits! Hell, I'd trust those Aussie convicts, drunken Kiwi's, worthless Canadians, and poor Indians, before a Brit! The only thing Britain has going for them is the fact they speak English (incorrectly, I might add)... I cant wait for the next 4th of July, I'm going to celebrate it in Britain! Cheers mate :) - josh (meant in good humor) -----Original Message----- From: steve jenson [mailto:stevej@sieve.net] Sent: Saturday, August 11, 2001 3:27 PM To: Global-Scale Distributed Storage Systems Subject: Re: freenet Quoting Josh (josh@mercuryfs.net): > It is true that credit card fraud does make a lot of money. My goal is a > global method whereby a person does not need to be assigned another ID to > remember. I figured that since credit cards are global, I can utilize them. > Visa and Mastercard currently are not deployed in China, but they are > virtually everywhere else. Since our charges will be 25 cents or less, any > abuse should show up easily. > > Even though its going to be a virtually open source design, we will probably > keep the credit card module closed source, so people cant modify it and > redistribute it in order to steal credit card numbers. This should help with > that issue. For about 5 minutes until somebody reverse engineers your code. If keeping your source closed on this is your measure of protection then you're in deep trouble. There's no security through obscurity. > We believe that the business model of charging an end user an > insignificant amount in order to authenticate them, is a valid model. An > added byproduct of using a credit card is that the bill is an audit log. > > Technically, the credit card number is not ever stored locally, and its not > transferred across the internet in an unprotected form. Basically, a UNI ID > is a hash of a credit card number and password. To see this, click here > www.mercuryfs.net/design/uni_id.pdf First, why are you making people download PDF's and shockwave files when regulare HTML and animated gif's would suffice? >From uni_id.pdf >A UNI ID is a globally unique identification, in the form of an >email address. Example: bigassunreadblestring@universal-id.net I thought you just said that you weren't going to be giving people another ID number to remember? "no two people have the same card number" I think this was already pointed out to be not true. "When a credit card is invalidated, its UNI IDs no longer test valid" I would appreciate you going into depth regarding exactly how you generate the ID from the Credit Card number and Pin in such a way as to make it easily provable to be invalid without central ID repository lookups. Banks already know that central lookups for every transaction will not scale. (Refer to Ross Anderson's excellent 'Security Engineering' chapter 9) "When a user sets up a UNID ID account, 3 passwords are given." You get an F- in usability, son. "4. The party wishing to validate your ID will have just received either VALID or INVALID." ooh!! I get all sorts of excited when I read about authentication schemes that never hand back a token that can be guaranteed to prove the end state of the transaction. If you don't know why, that doesn't surprise me. (skipping ahead.. getting bored with techno-babble): "User and Server types operate the same, but Groups rely on universal-id.net to be the trusted source of the private key When a member requests a groups private key..." huh? Do you know anything at all about public key cryptography? "When you login to a PC connected to the Internet and slide your credit card thru (sic) your keyboad (will soon be a standard)" This is just stupid. Nobody will do this. Well, I could do this all day long but I think I'd rather go work on a useful project. > Our goal will be to engineer the system to a near foolproof and automated > level. Ah yes, who doesn't have this goal? > ... ... ...Personally, I blame Hollywood. I think they turned > most of the women around here into stuck-up bitches. This sentece tells me that you should work more on your lady skills and less on thinking up vapourware. cheers, steve -- steve jenson http://sieve.net/ PGP fingerprint: 79D0 4836 11E4 A43A 0179 FC97 3AE2 008E 1E57 6138 --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From josh@mercuryfs.net Sun Aug 12 01:36:49 2001 From: josh@mercuryfs.net (Josh) Date: Sat, 11 Aug 2001 17:36:49 -0700 Subject: uni id loopback weakness Message-ID: <000501c122c6$e06810f0$35512304@koi> Oh, one thing I forgot to point out. I see a basic weakness in that a false loopback which would act like an authentication server, and take the information from the validator, and just feed it right back to it, and give an approval. I intend to overcome this by using standard methods of authentication of an IP address, such as digital certificates and something else. Once way to address this vulnerability is to have the central authentication service remember something about the last authentication that happened from that IP address, and use it as a method of proof for the current method. In theory, a fully automated method ought to correctly pass data forever, and only a failure or hack attempt would cause a disruption in this endless loop (or should I say chain). But this would be separate from the user's ID, rather it would be an issue between the validator and universal-id.net, to help insure the authenticity of the validator. A home PC and a public use PC such as in an airport have different security requirements in this respect. There is much more to be added to UNI ID, maybe plugging it into PGP. There is no reason why RSA must be used in MFS. From dnm@pobox.com Sun Aug 12 07:58:07 2001 From: dnm@pobox.com (Dan Moniz) Date: Sun, 12 Aug 2001 02:58:07 -0400 Subject: the british In-Reply-To: References: Message-ID: >Ooops, his email ended in "cheers, - steve"... Perhaps he's a Brit....??? No >wonder I pissed him off. > >You guys are more than the Texans of Europe, Britain is the best example of >a worldwide failure to date! > >And to think, you Brits still bow before the queen. > >Oh, I love it. America beat your ass, with one of your own officers >(Washington), then we saved it twice (WW 1 and 2). > >Oh, and the best part of the history books: when Washington rowed across the >Delaware, it was an act of desperation. But you Brits were passed out drunk, >after throwing a victory party..... and that's how we won our Independence! >Because of the drunken Brits! > >Hell, I'd trust those Aussie convicts, drunken Kiwi's, worthless Canadians, >and poor Indians, before a Brit! The only thing Britain has going for them >is the fact they speak English (incorrectly, I might add)... > >I cant wait for the next 4th of July, I'm going to celebrate it in Britain! > >Cheers mate This is simultaneously laughable and appalling. Not only is Steve not British, he's probably as American as anyone I know. Furthermore, I do recall a number of messages back you making the statement: At 6:45 PM -0700 7/30/01, Josh wrote: >Besides, the freenet community seems to hide behind the 1st amendment too >much, and I just don't agree with that philosophy. I respect patents and >intellectual property. Besides, any computer hack with half a brain can >bypass any copy protection scheme. Luckily, this email list says to keep >philosophy and law out of it, so this will be my last submission on that >topic. And _now_ you're trying to channel Washington into some hair-brained sense of self-righteous nationalism to rail against someone who isn't even British? Furthermore, you sit there and reply to criticism with useless retorts like: At 1:20 PM -0700 8/9/01, Josh wrote: >I find your lack of technical criticism to be a waste of time. but decide it's fine for you to plague the list with this bullshit? I'm not even going to get into the ridiculous bits of the whole anti-British sentiment. It's immature and shortsighted, and I'm being generous. This is not the way to either gain the respectful consideration of people you consider to be colleagues or to try to attract business partners. Ian was right when he identified you as a troll, and I assumed as much previous to that. I've mostly been watching, somewhat amused. This last bit was just too over the top, but I'll go back to ignoring you now. -- Dan Moniz [http://www.pobox.com/~dnm/] From josh@mercuryfs.net Sun Aug 12 07:56:23 2001 From: josh@mercuryfs.net (Josh) Date: Sat, 11 Aug 2001 23:56:23 -0700 Subject: the british In-Reply-To: Message-ID: <000001c122fb$e6d21d70$35512304@koi> Hey, he ripped me, so why not. At least I kept my message short, cant say the same about yours. I don't ever hear Americans say 'cheers'. If I'm a troll, so be it. At least you said it was laughable. -----Original Message----- From: Dan Moniz [mailto:dnm@pobox.com] Sent: Saturday, August 11, 2001 11:58 PM To: Global-Scale Distributed Storage Systems Subject: Re: the british >Ooops, his email ended in "cheers, - steve"... Perhaps he's a Brit....??? No >wonder I pissed him off. > >You guys are more than the Texans of Europe, Britain is the best example of >a worldwide failure to date! > >And to think, you Brits still bow before the queen. > >Oh, I love it. America beat your ass, with one of your own officers >(Washington), then we saved it twice (WW 1 and 2). > >Oh, and the best part of the history books: when Washington rowed across the >Delaware, it was an act of desperation. But you Brits were passed out drunk, >after throwing a victory party..... and that's how we won our Independence! >Because of the drunken Brits! > >Hell, I'd trust those Aussie convicts, drunken Kiwi's, worthless Canadians, >and poor Indians, before a Brit! The only thing Britain has going for them >is the fact they speak English (incorrectly, I might add)... > >I cant wait for the next 4th of July, I'm going to celebrate it in Britain! > >Cheers mate This is simultaneously laughable and appalling. Not only is Steve not British, he's probably as American as anyone I know. Furthermore, I do recall a number of messages back you making the statement: At 6:45 PM -0700 7/30/01, Josh wrote: >Besides, the freenet community seems to hide behind the 1st amendment too >much, and I just don't agree with that philosophy. I respect patents and >intellectual property. Besides, any computer hack with half a brain can >bypass any copy protection scheme. Luckily, this email list says to keep >philosophy and law out of it, so this will be my last submission on that >topic. And _now_ you're trying to channel Washington into some hair-brained sense of self-righteous nationalism to rail against someone who isn't even British? Furthermore, you sit there and reply to criticism with useless retorts like: At 1:20 PM -0700 8/9/01, Josh wrote: >I find your lack of technical criticism to be a waste of time. but decide it's fine for you to plague the list with this bullshit? I'm not even going to get into the ridiculous bits of the whole anti-British sentiment. It's immature and shortsighted, and I'm being generous. This is not the way to either gain the respectful consideration of people you consider to be colleagues or to try to attract business partners. Ian was right when he identified you as a troll, and I assumed as much previous to that. I've mostly been watching, somewhat amused. This last bit was just too over the top, but I'll go back to ignoring you now. -- Dan Moniz [http://www.pobox.com/~dnm/] --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From gohnesorge@lh-computertechnik.de Sun Aug 12 09:53:58 2001 From: gohnesorge@lh-computertechnik.de (g'o'tz ohnesorge) Date: Sun, 12 Aug 2001 10:53:58 +0200 Subject: freenet References: Message-ID: <3B764425.D8FFDB6C@amiga.com> steve jenson wrote: > > www.mercuryfs.net/design/uni_id.pdf > > First, why are you making people download PDF's and shockwave files when > regulare HTML and animated gif's would suffice? (grin ..) google.com converts .PDF to text, but you'll have to hand the URL of the file to it, and then wait for it to check up on it, and then fish it out of the google .PDF cache again. In a pinch .. From josh@mercuryfs.net Mon Aug 13 03:46:30 2001 From: josh@mercuryfs.net (Josh) Date: Sun, 12 Aug 2001 19:46:30 -0700 Subject: oops Message-ID: <000001c123a2$28816f90$35512304@koi> X-AntiAbuse: Sender Address Domain - mercuryfs.net Turns out the older version of the uni id design was online. No wonder you quoted what was quoted before. Sorry. The file system has different requirements than email, mainly to keep the author psuedo-anonymous. That's why the pgp stuff is going to be done differently. (this message was CC'd to the group) From ian@hawk.freenetproject.org Mon Aug 13 07:15:08 2001 From: ian@hawk.freenetproject.org (Ian Clarke) Date: Sun, 12 Aug 2001 23:15:08 -0700 Subject: the british In-Reply-To: ; from josh@mercuryfs.net on Sat, Aug 11, 2001 at 04:31:04PM -0700 References: Message-ID: <20010812231508.D17329@freenetproject.org> --AbQceqfdZEv+FvjW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Aug 11, 2001 at 04:31:04PM -0700, Josh wrote: > Ooops, his email ended in "cheers, - steve"... Perhaps he's a Brit....??? No > wonder I pissed him off. Your ill-informed anti-British bigotry, your substance-free ideas, and laughably overblown ego, combine to make you one of the first people I have seriously considered making my mail server block all emails from automatically. I waste my time on this one occasion to ask those on this list to please not waste any more of their time on you, since I am sure that every response, regardless of its content, only serves to inflate your ego further. If anyone ever proposed the perfect design for a person to irritate me, you would definitely constitute prior art. Ian. --AbQceqfdZEv+FvjW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7d3BsQtgxRWSmsqwRAo5fAJ4hEJtX3/7oxaaqqYG6xfi9NfyTSACfe7rJ S/fcr/611ewPkC6HcaX+JUo= =/dJZ -----END PGP SIGNATURE----- --AbQceqfdZEv+FvjW-- From dnm@pobox.com Mon Aug 13 07:37:49 2001 From: dnm@pobox.com (Dan Moniz) Date: Mon, 13 Aug 2001 02:37:49 -0400 Subject: SDSI 2.0 movement Message-ID: Anyone know what the status is on SDSI 2.0 (the merging of previous SDSI efforts and work from the SPKI IETF WG, which I noticed, is concluded)? -- Dan Moniz [http://www.pobox.com/~dnm/] From josh@mercuryfs.net Mon Aug 13 09:00:45 2001 From: josh@mercuryfs.net (Josh) Date: Mon, 13 Aug 2001 01:00:45 -0700 Subject: the british In-Reply-To: <20010812231508.D17329@freenetproject.org> Message-ID: <000601c123ce$0edaf3f0$35512304@koi> But I'm typing with a smile. And trying to keep to the points. So I'm not politically correct. Big deal. Overall, I consider myself as being pragmatic. In that I don't get caught up on ideals. Besides, I was easy on the British. -----Original Message----- From: Ian Clarke [mailto:ian@hawk.freenetproject.org] Sent: Sunday, August 12, 2001 11:15 PM To: Josh Cc: Global-Scale Distributed Storage Systems Subject: Re: the british << File: ATT00023.dat >> On Sat, Aug 11, 2001 at 04:31:04PM -0700, Josh wrote: > Ooops, his email ended in "cheers, - steve"... Perhaps he's a Brit....??? No > wonder I pissed him off. Your ill-informed anti-British bigotry, your substance-free ideas, and laughably overblown ego, combine to make you one of the first people I have seriously considered making my mail server block all emails from automatically. I waste my time on this one occasion to ask those on this list to please not waste any more of their time on you, since I am sure that every response, regardless of its content, only serves to inflate your ego further. If anyone ever proposed the perfect design for a person to irritate me, you would definitely constitute prior art. Ian.