Ummm, strange. Look at it this way, you...don't have access to modify the registry files directly, the OS has a lock on the registry HIVES, so you can't modify them without going through the API's. If you go through the API's you can't do anything strange to muck them up because the interface rules are enforced. The only way the registry can become "corrupted" is if the file system becomes corrupted. If your file system has become corrupted you are having a much larger issue to deal with.
Okay, the real story is modifying boot related keys. Very frusterating if you're trying to work on Windows guts.
Screw up my Linux boot sequence? No problem...I ask lilo at the boot prompt to load my kernel with init=/bin/sash or some other statically linked shell. With e3, I can repair or edit any of those text files, even if ld.so is fubared (don't laugh, I've managed it).
Try mucking around with Windows guts and you pretty much are stuck with making a backup of the registry, grabbing an install CD to get to Rescue Console (a rather lengthy process), and hoping hard that nothing breaks.
If you manage to change an important registry value using the API's correctly so that "system cannot boot" well that is no different than using any text editor under *nix to change your config file values. And...
Ah, but I can still boot my Linux box and fix what I did. I'm just screwed under Windows.:-(
I can already mount a bad machine's registry by removing its hard disk, and popping it into another working machine.
That's true, if you have another one handy. Does MS put out any editors to handle dead registry files, though (i.e. not the active one, and not the active registry on another machine somewhere in your domain)?
"...*should* have an embedded format number..."
Another strange one. The registry is chock full of typed values and format numbers for applications.
I meant that prefs files should have a format version number for the prefs file at the front of the file, at least if they're binary. UNIX programs can usually get away without that because the vast majority of config files are simple perl-style associative hashes (string -> value).
Yea, I know about the MAC, and how Apple stores their application data using alternate file streams. You can do the same thing under Windows but very few programmers use that feature. Alternate file streams are standard under NTFS 5.0...go to google and search on...
"NTFS alternate streams"
Actually, bizarrely enough, I have run into these before, but they *really* are not used much, and support for them is basically nonexistant.
In theory, a Windows application could simply store a sub-registry hive for its config settings into the alternate data stream, then mount the thing into the OS registry, and whooosh, you've got an app where it's config settings follow the EXE around. I've never seen this done, but the principle is sound.
Urk...I don't think this would work well. Few administrators would let EXEs in the Programs File dir modify themselves. My issue isn't really prefs traveling around with the app, but the fact that there's this mass of fragile software that breaks if you remove the installed registry entries from the equation. I'd kind of like to see apps able to regenerate their registry settings, and users able to move apps around.
"...vastly more sophisticated in format than the simple three datatypes that the registry can handle."
What? You just a casual Windows user then? Not a programmer eh? Yea, I know your type, you probably just run regedit and think that is all there is to the registry. No, there are many more datatypes unseen. Microsoft only provides three in the simple regedit tool. Applications have access to many more through the real registry API. See...
This I did not know.:-) However, it pales in comparison to the Mac OS's template-based resource formats...where's my packed boolean set value type?
I won't even comment on ascii text config files being "sophisticated"
While they're frequently just mappings from strings to values, sometimes an application requires more than that. Some of these formats would be very difficult to replicate with the Windows registry, but are quite easy to edit as a text file. The registry is not very well suited for lists. Anything with subsections is often not that well suited to the registry -- I can search and cut and paste regions very easily in, say, XF86Config. You might find another registry editor, but unlike my text editor, regedit does not support undo. Finally, linearly searching through the registry is a time-consuming task -- I can grep through/etc much faster (and using regexes, etc, to find what I want).
"...software thinking it can modify other software's registry entries, and thereby causing all sorts of problems."
This is no different than any other OS that uses file system based config files. Again, look at a *nix user's home directory! I did say that the registry was ACL enforced.
I'm not claiming this is a technical limitation of the registry, but it's how it's used. Somehow, UNIX software manages to go around without poking at each others settings.
Heck, there are a lot of policy things I don't like about the registry. Who at MS decided to root the file association keys in one massive place in the registry, along with a ton of other stuff, has made it quite irritating to skim through a list that already is long enough.
"You ever seen an XPM?"
Yea, X Window pixmap format...lol!;)
I meant really looked at one, opened it up in a text editor...compared to that, text format numbers don't worry too many people.
Using text format is also a lot more legitimate for UNIX/Linux folks, who have to worry about endian issues. Exchanging binary config files between a PPC and an x86 could be quite frusterating...
What I'd like, under Linux, is a standard way of storing configuration information.
~/. for users.
For systemwide settings, like daemons,/etc/.
To the point where I could pick an arbitrary application, such as Mozilla, and run a single command to back-up both systemwide configuration and all user configurations.
Yup. Copies above listed files.
This isn't like the Windows registry, but it does provide a lot of the benefits - standardised, OS-wide format, ability to easily locate all system configuration files - without the disadvantages (single big easily-damaged file).
It is even possible to backup the HIVEs without being in the OS. Just boot to another OS and copy the files off the disk (assuming you can read and write to NTFS).
Okay, let me put it this way. If I corrupt my registry, or alter a key in such a way that the system cannot boot (and boy, are there a *hell* of a lot of those), recovering the system is pretty much a lost cause unless (a) I have a backup of the actual hives, which I made earlier *and* I'm willing to suffer whatever problems will happen if I remove all the entries made to the registry since I made the backup or (b) I have some third party tool that can check the registry for consistency and edit it.
It's downright reprehensible that MS doesn't include a console-based editor for *dead registries* -- not the active one -- with their Recovery Console tool with every copy of Windows.
The argument that I might want to have a file with only an int in it is kind of silly. Any normal app is going to have a decent number of said values, plus *should* have an embedded format number for upwards compatibility. The MacOS has preferences files *with* (optionally) a structured format (resources). You can even define templates to say what the format of a resource should be *in* the file. That's significantly nicer.
Linux would do well to adapt to some kind of OS database for its configuration settings and local accounts even if it isn't regsitry like.
Why? It uses config files that are vastly more sophisticated in format than the simple three datatypes that the registry can handle.
There's some benefit to having an easy-to-use hierarchical editor that can handle basic data types, but it's not *that* mindblowing. It also leads to software thinking it can modify other software's registry entries, and thereby causing all sorts of problems.
But if you want to continue to store a 64 BIT value in a text file as "0xFFFFFFFFFFFFFFFF" be my guest. (BTW, this is the same problem I have with HTTP, inefficient as hell!)
I have to say that while I'm not a tremendous fan of monitoring, and the RIAA/MPAA have definitely been pulling dirty stunts before, EPIC's claim about them damaging "critical thinking" is kind of bogus. The "chilling effect" bit is kind of silly, as is the attempt to squeeze in fair use (which is quite important, and is even relevant to some of the things the RIAA/MPAA has done, but has nothing to do with Britney Spears music bootlegging on a campus connection).
Also, I suspect that most univ. administrators couldn't care less about potential "security" or "privacy" issues that EPIC is calling "purported risks of P2P". They care about massive bandwidth usage, though.
Frankly, EPIC would be better off going after legislation (which *is* an issue) that our *AA friends are trying to push through.
Bandwidth is what matters, when in fact it's the the latency which kills applications
Surely you're talking about something different from the article poster, who was referring to the causes of an entirely different (and uncommon) metric: "bandwidth latency".;-)
Why, *every* self-respecting contituient downloads WINE, installs it, downloads IE, installs that in WINE (doing whatever hacking is necessary to get it to work), and then uses that to contact their representative. They aren't forcing you to buy the products of the (by far) largest donor of government funds from the tech industry at all! They certainly aren't trying to quell the voices of the people that oppose it.
Yup. Raskin was probably royally peeved when _The Mac is Not a Typewriter_ was published. There have been "information appliances" for some time now. Dedicated word processors. All manner of propriatary PDAs. They didn't catch on particularly well, despite Raskin talking about how they were going to dominate the field. People hate being limited from something that they could once do. Maybe if the personal computer had never existed and only information appliances had been running around, IAs woudl have caught on.
The rising dominance of Windows CE in the PDA market is a good argument that even on PDAs people want a relatively full-blown environment.
Your arguments hold true for, say, the Japanese market.
And it's not like this hasn't been done before. OpenDoc. It was the logical evolution of OLE (though frankly I think OLE ended up being more confusing than helpful to most users). There was an attempt at a "unified work environment" in Lotus Notes and other heavyweight groupware (if you've ever used something like this, you'll notice that it's not massively popular with users). It's been discussed over and over and *over*, and it isn't new by a long, long shot. The predicted grand evolution of the all-encompassing container app has pretty much come down to IE's file browser supporting previews, and then Konqueror cloning said previews.
The Registry is a horrid implementation of an *awful* idea.
You want to make a centralized database *cache* a la the MacOS desktop file, go for it. I don't like the idea of having a single, nontransferable crucial chunk of data that's a single point of failure. It's idiotic that you can't simply copy an installed application on Windows to another computer.
:-) I haven't purchased any Apple products since their killing of the clones, a fair number of years back -- I swore I'd leave my much-loved Mac after that incident, and now I've been using x86 Linux for years. No iDisk available...
Hmm...my Marathon 1 CD is unfortunately at home, not at college with me. Post an email address where I can get in touch with you.
because your horizon only goes out to a horizon of two
The horizon of two isn't a hard limit -- it might be extended to, say, three, or even be adaptive. However, I strongly suspect that trying to maintain any sort of local cache of an entire P2P network is a losing cause, unless distribution of the thing was a bit smarter (come to think of it, since there are public keys involved, this data can be signed...hmm, interesting, though it still might eat a lot of storage space).
the trust values fade very fast
How about a nonlinear trust degradation?
Here's an url with most of the links
I'll certainly read this (though because of two projects that I'm getting swamped with, it'll probably be a few days until I can properly give the stuff the attention it deserves). Still, thank you very much. This looks like exactly what I like poking around with.
BTW, TA had some excellent Star Wars-esque music. I purchased it, lost the CD, and then downloaded oggs of their music. Love it.
Re:A *real* anti-leech/anti attacker system propos
on
Gnutella2?
·
· Score: 2
What technical problems are you concerned with?
I have one major advantage -- I suspect that most people doing decentralized trust care about whether someone can be trusted absolutely or not. I'm willing to say "this person is a little trusted" even if there's not a lot of ground to go on (because someone you trust trusts them) or "this person is not trusted" even if they could be (the db doesn't have to be complete at each node). It's okay to have a certain error margin, because this is just used to assist the primary program. That would, I imagine, free me from the nastiest constraint involved...
Re:A *real* anti-leech/anti attacker system propos
on
Gnutella2?
·
· Score: 2
In a real p2p net you constantly interact with people you have not communicated with before.
But if you have a 200 entry trust list, and all the people on there have a 200 entry trust list, that's a pretty sizeable chunk of data. It isn't just those that you have to interact with.
The traffic required to gather the information needed to keep track of individual users is more of a burden than leeches.
Take the above scheme...200 lists, refreshed on at most a weekly basis...that isn't *that* much. A gnutella client generates more than that with search broadcasts in a short period of time.
When user A uploads to user B only they know that it happened, if user A says he uploaded but user B says he didn't then who do you trust?
Using files was just an idea, one of the many sources of deriving trust automatically. Originally my idea was to manually grant trust -- "Wow, this guy's serving me this great file! I'm giving him some points!". However, I suspect that people are more likely to be willing to do active negative moderation ("These files are fakes -- I'm stripping the guy of all the trust I gave him") and let the client slowly increase trust. It also makes it difficult for someone *cough* MPAA to serve deliberately corrupted files, since their goal is to serve tiny corrupted slices and damage large files -- to gain trust, they have to serve large chunks of data. There is no required, direct link between files downloaded and trust gained. Furthermore, the only person listened to is the person *granting* the trust. He is under no onus to grant trust if he downloads a file -- this isn't "credit" or "money", it's "trust". He could have a client that doesn't trust anyone except those he manually marks.
There is also the privacy/incrimination issue of tracking individual issue of tracking individual users uploads and downloads.
Yes, I mentioned that. It was some of some concern, but the fact that trust can derive from other sources helps obscure it. There's no log of transferred files ever moved around. The best you know is that Person A knows of Person B, and likely engaged in some transaction with them. Hell, they could have chatted with them and liked them and jacked their trust.
I thought about this a lot and tried to create algorithms for working out how much to trust someone
Same here, though my interest lies more in the field of improving resistance of P2P networks to organized outside attack, as the RIAA/MPAA have been hiring firms to do. The robust antileech stuff is a bonus that I suspect some people will be interested in.
The only solution that seems workable to me is for the users to form groups. The group members trust each other. People who want the same sort of files will group together, groups of pr0nsters, electronica fans, ebook people etc. When people in group X have sent you more bytes than you have sent to them, you give people from group X priority in your upload queue.
Actually, rather similar to what I'm doing in essence. My approach is a bit more fuzzy (outward spreading weakening webs of trust), since I'd like to automate as much as possible, which I feel is important for scalability reasons. People tend to interact with those that hae similar interests.
You need some crypto so that group members can prove their membership and people can't falsly claim to be a member of a group that uploads a lot.
[Nods] similar to my conclusions, and my design follows yours here. Note: one drawback of any auth system that I have a small amount of concern over is that suddenly, people are storing a standardized piece of data that has lots of value to crackers on their computer -- their keypair. I could see nasty worms erupting aimed at grabbing keypairs.
The implementation details will need tweaking after some actual s/w is written. My current vision is that a group grows from a single member who holds the group private key. The founder grants membership to people who upload to him. Group members send reccomendations to the founder for new members. When the group grows large it may be necessary to spread the private key to several members.
Again we're similar. A few differences -- I tried to avoid discrete trust level issues -- "I trust you" or "I don't", but no middle ground. You may not trust everyone that gets into the group -- an issue with PGP, for instance. Second, there is no single private key in what I'm proposing -- no person has rights to anything other than their own trust list. Third (this may in particular be interesting, since it could be better either way), with your system trust is transitive. If User A is in Group B, and User C is in Group B, then A and C both trust each other. I allow one way trust -- I can trust Bob the Enormous Fileserver Admin, though he may not trust me.
Your idea sounds almost like a distributed version of Direct Connect. If you can get a userlist, it's like a distributed server...
Thanks for the feedback and posting the ideas. There are precious few people interested in security issues on P2P (despite the fact that P2P needs security more than most areas), and it's really good to talk to someone else interested in the area. Most P2P types like "quick patch" solutions.:-(
Assuming that there will be no additional reduction of strength from attacks, it's another 54 bits.
Assuming Moore's Law roughly holds, that's about lg(54) * 1.5 = 11.5 years before systems can break this thing in four years.
Now, that's actually a little shorter than one might like, and more importantly, it doesn't leave as much breathing room as one might like if more holes are found, but...
Err...no. If something is a few days old...well, knowing old information about where submarines were planning to rendezvous in WWII made quite a difference, hearkening to Cryptonomicon.
Re:A *real* anti-leech/anti attacker system propos
on
Gnutella2?
·
· Score: 2
True (I wasn't aware of this, and I'm not sure that there's actually *support* for this in any actual implementation), but not useful for what I'm talking about. It's still much too rough-grained.
Slashdot Mirror
bird-like *and* dinosaur
I can already see trademark infringement suits from a host of Finnish companies...
That's stupid. Eventually almost *all* companies will be "in the tech market".
Ummm, strange. Look at it this way, you...don't have access to modify the registry files directly, the OS has a lock on the registry HIVES, so you can't modify them without going through the API's. If you go through the API's you can't do anything strange to muck them up because the interface rules are enforced. The only way the registry can become "corrupted" is if the file system becomes corrupted. If your file system has become corrupted you are having a much larger issue to deal with.
:-(
:-) However, it pales in comparison to the Mac OS's template-based resource formats...where's my packed boolean set value type?
/etc much faster (and using regexes, etc, to find what I want).
;)
Okay, the real story is modifying boot related keys. Very frusterating if you're trying to work on Windows guts.
Screw up my Linux boot sequence? No problem...I ask lilo at the boot prompt to load my kernel with init=/bin/sash or some other statically linked shell. With e3, I can repair or edit any of those text files, even if ld.so is fubared (don't laugh, I've managed it).
Try mucking around with Windows guts and you pretty much are stuck with making a backup of the registry, grabbing an install CD to get to Rescue Console (a rather lengthy process), and hoping hard that nothing breaks.
If you manage to change an important registry value using the API's correctly so that "system cannot boot" well that is no different than using any text editor under *nix to change your config file values. And...
Ah, but I can still boot my Linux box and fix what I did. I'm just screwed under Windows.
I can already mount a bad machine's registry by removing its hard disk, and popping it into another working machine.
That's true, if you have another one handy. Does MS put out any editors to handle dead registry files, though (i.e. not the active one, and not the active registry on another machine somewhere in your domain)?
"...*should* have an embedded format number..."
Another strange one. The registry is chock full of typed values and format numbers for applications.
I meant that prefs files should have a format version number for the prefs file at the front of the file, at least if they're binary. UNIX programs can usually get away without that because the vast majority of config files are simple perl-style associative hashes (string -> value).
Yea, I know about the MAC, and how Apple stores their application data using alternate file streams. You can do the same thing under Windows but very few programmers use that feature. Alternate file streams are standard under NTFS 5.0...go to google and search on...
"NTFS alternate streams"
Actually, bizarrely enough, I have run into these before, but they *really* are not used much, and support for them is basically nonexistant.
In theory, a Windows application could simply store a sub-registry hive for its config settings into the alternate data stream, then mount the thing into the OS registry, and whooosh, you've got an app where it's config settings follow the EXE around. I've never seen this done, but the principle is sound.
Urk...I don't think this would work well. Few administrators would let EXEs in the Programs File dir modify themselves. My issue isn't really prefs traveling around with the app, but the fact that there's this mass of fragile software that breaks if you remove the installed registry entries from the equation. I'd kind of like to see apps able to regenerate their registry settings, and users able to move apps around.
"...vastly more sophisticated in format than the simple three datatypes that the registry can handle."
What? You just a casual Windows user then? Not a programmer eh? Yea, I know your type, you probably just run regedit and think that is all there is to the registry. No, there are many more datatypes unseen. Microsoft only provides three in the simple regedit tool. Applications have access to many more through the real registry API. See...
This I did not know.
I won't even comment on ascii text config files being "sophisticated"
While they're frequently just mappings from strings to values, sometimes an application requires more than that. Some of these formats would be very difficult to replicate with the Windows registry, but are quite easy to edit as a text file. The registry is not very well suited for lists. Anything with subsections is often not that well suited to the registry -- I can search and cut and paste regions very easily in, say, XF86Config. You might find another registry editor, but unlike my text editor, regedit does not support undo. Finally, linearly searching through the registry is a time-consuming task -- I can grep through
"...software thinking it can modify other software's registry entries, and thereby causing all sorts of problems."
This is no different than any other OS that uses file system based config files. Again, look at a *nix user's home directory! I did say that the registry was ACL enforced.
I'm not claiming this is a technical limitation of the registry, but it's how it's used. Somehow, UNIX software manages to go around without poking at each others settings.
Heck, there are a lot of policy things I don't like about the registry. Who at MS decided to root the file association keys in one massive place in the registry, along with a ton of other stuff, has made it quite irritating to skim through a list that already is long enough.
"You ever seen an XPM?"
Yea, X Window pixmap format...lol!
I meant really looked at one, opened it up in a text editor...compared to that, text format numbers don't worry too many people.
Using text format is also a lot more legitimate for UNIX/Linux folks, who have to worry about endian issues. Exchanging binary config files between a PPC and an x86 could be quite frusterating...
What I'd like, under Linux, is a standard way of storing configuration information.
/etc/.
~/. for users.
For systemwide settings, like daemons,
To the point where I could pick an arbitrary application, such as Mozilla, and run a single command to back-up both systemwide configuration and all user configurations.
Yup. Copies above listed files.
This isn't like the Windows registry, but it does provide a lot of the benefits - standardised, OS-wide format, ability to easily locate all system configuration files - without the disadvantages (single big easily-damaged file).
Yup.
It is even possible to backup the HIVEs without being in the OS. Just boot to another OS and copy the files off the disk (assuming you can read and write to NTFS).
Okay, let me put it this way. If I corrupt my registry, or alter a key in such a way that the system cannot boot (and boy, are there a *hell* of a lot of those), recovering the system is pretty much a lost cause unless (a) I have a backup of the actual hives, which I made earlier *and* I'm willing to suffer whatever problems will happen if I remove all the entries made to the registry since I made the backup or (b) I have some third party tool that can check the registry for consistency and edit it.
It's downright reprehensible that MS doesn't include a console-based editor for *dead registries* -- not the active one -- with their Recovery Console tool with every copy of Windows.
The argument that I might want to have a file with only an int in it is kind of silly. Any normal app is going to have a decent number of said values, plus *should* have an embedded format number for upwards compatibility. The MacOS has preferences files *with* (optionally) a structured format (resources). You can even define templates to say what the format of a resource should be *in* the file. That's significantly nicer.
Linux would do well to adapt to some kind of OS database for its configuration settings and local accounts even if it isn't regsitry like.
Why? It uses config files that are vastly more sophisticated in format than the simple three datatypes that the registry can handle.
There's some benefit to having an easy-to-use hierarchical editor that can handle basic data types, but it's not *that* mindblowing. It also leads to software thinking it can modify other software's registry entries, and thereby causing all sorts of problems.
But if you want to continue to store a 64 BIT value in a text file as "0xFFFFFFFFFFFFFFFF" be my guest. (BTW, this is the same problem I have with HTTP, inefficient as hell!)
You ever seen an XPM?
I have to say that while I'm not a tremendous fan of monitoring, and the RIAA/MPAA have definitely been pulling dirty stunts before, EPIC's claim about them damaging "critical thinking" is kind of bogus. The "chilling effect" bit is kind of silly, as is the attempt to squeeze in fair use (which is quite important, and is even relevant to some of the things the RIAA/MPAA has done, but has nothing to do with Britney Spears music bootlegging on a campus connection).
Also, I suspect that most univ. administrators couldn't care less about potential "security" or "privacy" issues that EPIC is calling "purported risks of P2P". They care about massive bandwidth usage, though.
Frankly, EPIC would be better off going after legislation (which *is* an issue) that our *AA friends are trying to push through.
Bandwidth is what matters, when in fact it's the the latency which kills applications
;-)
Surely you're talking about something different from the article poster, who was referring to the causes of an entirely different (and uncommon) metric: "bandwidth latency".
Why, *every* self-respecting contituient downloads WINE, installs it, downloads IE, installs that in WINE (doing whatever hacking is necessary to get it to work), and then uses that to contact their representative. They aren't forcing you to buy the products of the (by far) largest donor of government funds from the tech industry at all! They certainly aren't trying to quell the voices of the people that oppose it.
And MS gives most of their money to Republicans, too...
Yup. Raskin was probably royally peeved when _The Mac is Not a Typewriter_ was published. There have been "information appliances" for some time now. Dedicated word processors. All manner of propriatary PDAs. They didn't catch on particularly well, despite Raskin talking about how they were going to dominate the field. People hate being limited from something that they could once do. Maybe if the personal computer had never existed and only information appliances had been running around, IAs woudl have caught on.
The rising dominance of Windows CE in the PDA market is a good argument that even on PDAs people want a relatively full-blown environment.
Your arguments hold true for, say, the Japanese market.
And it's not like this hasn't been done before. OpenDoc. It was the logical evolution of OLE (though frankly I think OLE ended up being more confusing than helpful to most users). There was an attempt at a "unified work environment" in Lotus Notes and other heavyweight groupware (if you've ever used something like this, you'll notice that it's not massively popular with users). It's been discussed over and over and *over*, and it isn't new by a long, long shot. The predicted grand evolution of the all-encompassing container app has pretty much come down to IE's file browser supporting previews, and then Konqueror cloning said previews.
Current systems don't try hard at all to download files from locations on the local network, which is pretty bad.
One of the coolest things about P2P is the ability to have closer servers with the same file.
Freenet doesn't have the pretty GUI, but it does a better job.
The Registry is a horrid implementation of an *awful* idea.
You want to make a centralized database *cache* a la the MacOS desktop file, go for it. I don't like the idea of having a single, nontransferable crucial chunk of data that's a single point of failure. It's idiotic that you can't simply copy an installed application on Windows to another computer.
Reiser needs to stop making his filesystems so enormous and complex and worry more about stability and reliability.
Reiser is getting excessively ambitious.
You know, I *tried* to look at the website, but half the links on it are dead...
This guy is just trying to make money the easiest way he can
Yup. Lets look at the story submission text:
* Yale Professor of Computer Science
Yup, Yale sure is CS central
* Unabomber target
This is his selling point for himself?
* Operating systems are relics of the past
subtext: No, I didn't just rip off Gosling's old speeches that failed to come true...
* We should be able to access data anytime/anywhere
This is such a fricking overused and pointless buzzphrase in the tech world that it's ridiculous. It's like a politician's "what about the children".
* seeing a stream of 3D documents
Yeah, everything gets better when it's 3d. Uh, huh. Very 90s.
The man is obviously an ass. Given the "irrelevant OS" and "3D documents" crap, it sounds like he harvested a bunch of random mid 90s research papers.
:-) I haven't purchased any Apple products since their killing of the clones, a fair number of years back -- I swore I'd leave my much-loved Mac after that incident, and now I've been using x86 Linux for years. No iDisk available...
Hmm...my Marathon 1 CD is unfortunately at home, not at college with me. Post an email address where I can get in touch with you.
Wow. Thanks for your time reviewing this.
because your horizon only goes out to a horizon of two
The horizon of two isn't a hard limit -- it might be extended to, say, three, or even be adaptive. However, I strongly suspect that trying to maintain any sort of local cache of an entire P2P network is a losing cause, unless distribution of the thing was a bit smarter (come to think of it, since there are public keys involved, this data can be signed...hmm, interesting, though it still might eat a lot of storage space).
the trust values fade very fast
How about a nonlinear trust degradation?
Here's an url with most of the links
I'll certainly read this (though because of two projects that I'm getting swamped with, it'll probably be a few days until I can properly give the stuff the attention it deserves). Still, thank you very much. This looks like exactly what I like poking around with.
It used MIDI (which I believe was used in-game). It also had Red Book audio for listening in your CD player.
Take a glance at the ridiculously in-depth Marathon Story Site's Music Page, which has some good background and coverage.
BTW, TA had some excellent Star Wars-esque music. I purchased it, lost the CD, and then downloaded oggs of their music. Love it.
What technical problems are you concerned with?
I have one major advantage -- I suspect that most people doing decentralized trust care about whether someone can be trusted absolutely or not. I'm willing to say "this person is a little trusted" even if there's not a lot of ground to go on (because someone you trust trusts them) or "this person is not trusted" even if they could be (the db doesn't have to be complete at each node). It's okay to have a certain error margin, because this is just used to assist the primary program. That would, I imagine, free me from the nastiest constraint involved...
In a real p2p net you constantly interact with people you have not communicated with before.
:-(
But if you have a 200 entry trust list, and all the people on there have a 200 entry trust list, that's a pretty sizeable chunk of data. It isn't just those that you have to interact with.
The traffic required to gather the information needed to keep track of individual users is more of a burden than leeches.
Take the above scheme...200 lists, refreshed on at most a weekly basis...that isn't *that* much. A gnutella client generates more than that with search broadcasts in a short period of time.
When user A uploads to user B only they know that it happened, if user A says he uploaded but user B says he didn't then who do you trust?
Using files was just an idea, one of the many sources of deriving trust automatically. Originally my idea was to manually grant trust -- "Wow, this guy's serving me this great file! I'm giving him some points!". However, I suspect that people are more likely to be willing to do active negative moderation ("These files are fakes -- I'm stripping the guy of all the trust I gave him") and let the client slowly increase trust. It also makes it difficult for someone *cough* MPAA to serve deliberately corrupted files, since their goal is to serve tiny corrupted slices and damage large files -- to gain trust, they have to serve large chunks of data. There is no required, direct link between files downloaded and trust gained. Furthermore, the only person listened to is the person *granting* the trust. He is under no onus to grant trust if he downloads a file -- this isn't "credit" or "money", it's "trust". He could have a client that doesn't trust anyone except those he manually marks.
There is also the privacy/incrimination issue of tracking individual issue of tracking individual users uploads and downloads.
Yes, I mentioned that. It was some of some concern, but the fact that trust can derive from other sources helps obscure it. There's no log of transferred files ever moved around. The best you know is that Person A knows of Person B, and likely engaged in some transaction with them. Hell, they could have chatted with them and liked them and jacked their trust.
I thought about this a lot and tried to create algorithms for working out how much to trust someone
Same here, though my interest lies more in the field of improving resistance of P2P networks to organized outside attack, as the RIAA/MPAA have been hiring firms to do. The robust antileech stuff is a bonus that I suspect some people will be interested in.
The only solution that seems workable to me is for the users to form groups. The group members trust each other. People who want the same sort of files will group together, groups of pr0nsters, electronica fans, ebook people etc. When people in group X have sent you more bytes than you have sent to them, you give people from group X priority in your upload queue.
Actually, rather similar to what I'm doing in essence. My approach is a bit more fuzzy (outward spreading weakening webs of trust), since I'd like to automate as much as possible, which I feel is important for scalability reasons. People tend to interact with those that hae similar interests.
You need some crypto so that group members can prove their membership and people can't falsly claim to be a member of a group that uploads a lot.
[Nods] similar to my conclusions, and my design follows yours here. Note: one drawback of any auth system that I have a small amount of concern over is that suddenly, people are storing a standardized piece of data that has lots of value to crackers on their computer -- their keypair. I could see nasty worms erupting aimed at grabbing keypairs.
The implementation details will need tweaking after some actual s/w is written. My current vision is that a group grows from a single member who holds the group private key. The founder grants membership to people who upload to him. Group members send reccomendations to the founder for new members. When the group grows large it may be necessary to spread the private key to several members.
Again we're similar. A few differences -- I tried to avoid discrete trust level issues -- "I trust you" or "I don't", but no middle ground. You may not trust everyone that gets into the group -- an issue with PGP, for instance. Second, there is no single private key in what I'm proposing -- no person has rights to anything other than their own trust list. Third (this may in particular be interesting, since it could be better either way), with your system trust is transitive. If User A is in Group B, and User C is in Group B, then A and C both trust each other. I allow one way trust -- I can trust Bob the Enormous Fileserver Admin, though he may not trust me.
Your idea sounds almost like a distributed version of Direct Connect. If you can get a userlist, it's like a distributed server...
Thanks for the feedback and posting the ideas. There are precious few people interested in security issues on P2P (despite the fact that P2P needs security more than most areas), and it's really good to talk to someone else interested in the area. Most P2P types like "quick patch" solutions.
Hehe...someone send this to the Debian mailing list. I wanna see the feathers fly...
Assuming that there will be no additional reduction of strength from attacks, it's another 54 bits.
Assuming Moore's Law roughly holds, that's about lg(54) * 1.5 = 11.5 years before systems can break this thing in four years.
Now, that's actually a little shorter than one might like, and more importantly, it doesn't leave as much breathing room as one might like if more holes are found, but...
Err...no. If something is a few days old...well, knowing old information about where submarines were planning to rendezvous in WWII made quite a difference, hearkening to Cryptonomicon.
True (I wasn't aware of this, and I'm not sure that there's actually *support* for this in any actual implementation), but not useful for what I'm talking about. It's still much too rough-grained.