It's Like Déjà Vu All Over Again
"You could probably waste an entire day on the preceding links alone. But why take chances? We also give you Paul Snively..." — John Wiseman, lemonodor
Something has been bothering me in all of the reporting about the Morpheus/FastTrack broughaha, but it hasn't been until today that I could put my finger on it. Finally, it occurred to me that there are really two issues: first, people had assumed that Morpheus was fully distributed, including, presumably, in how it does authentication. Secondly, people had assumed for some reason that Morpheus was impervious to having some of its core code changed out from under it.
The current state of the art, as far as I have seen, tends to fall into one of two traps.
First trap:
Assume that you need arbitrary keys including non-self-authenticating ones.
Think about the problem of crossing trust boundaries, and solve by delegating to a "trusted third party".
Forever after you will be vulnerable to MicrosoftNSIVerisignICANNUSGovInc. and anyone who can subvert one of their servers (including their employees). When this bloated monopoly screws something up, your system will pay the price for their incompetence. You will not be able to choose a different name authority, because everyone else will also be tied to the central monopoly and you will need their service in order to interoperate with the wider world. (Does this scenario sound familiar to any sysadmins out there?) In addition, they will charge you a tax on every packet for the privilege of continued service.
Morpheus didn't pay the "tax" to FastTrack, so FastTrack was able to shut Morpheus down by leveraging the fact that their naming system was centralized. Oops. Straight into the first trap.
As Zooko points out, all effective human UIs to secure distributed naming systems end up being implementations of the Pet Names Markup Language, a mechanism for associating (local) human-readable names with self-authenticating tokens in a distributed system. I hope Morpheus is paying attention.
11:34:33 PM
Move along. Spotted randomly on Slashdot: "Emacs religion: control excess, and all shall be saved." The intelligent, sophisticated, wordplay-loving, kicked-out-of-some-of-the-finest-institutions-in-the-country Emacs users in the crowd are groaning now; the rest of you heathens can just go scratch your underdeveloped heads and move along, nothing to see here. [diveintomark]
Ahhh. I've been a disciple of this religion for over 20 years. The same essential editor on the following platforms...
TOPS 20
VAX
Data General AOS/VS
Tektronix 440x
Symbolics, LMI, and TI Lisp Machines
Apollo Domain OS
Mac OS
Various Unixes
Windows
Probably some other one I forgot
There is a significant start-up cost to get the true religion. You've attained Nirvana when your reading your email, executing your shells, reading news, editing your code, running your debugger, editing your web pages, reading application help files, manipulating your file system, grepping large files, etc. all in Emacs.
One significant feature of Emacs that beats everything else... all the dialogs, directory listings, shell output, info documents, etc. are all editable text. You can copy and paste information from the most unusual places to save time.
In the GUI Windows world, dialog boxes, etc. dictate just what they want you to copy and paste and how big they want the window to be, even when the list of information is eight miles long. If you cannot copy it, you are out of luck. If it scrolls for hours, you are out of luck.
EMACS: Escape Meta Alt Control Shift.
EMACS: Eventually Mallocs All Computer Storage.
EMACS: Eight Megabytes And Constantly Swapping
I, too, have been using EMACS since my Lisp Machine days. I use it daily on my Windows box at work. I still occassionally get "What the hell is that?" from coworkers. It tends to stop the first time I show them an incremental regular-expression search. Then they start asking how they can learn EMACS.
11:10:18 PM
Somethings to dig your security teeth into: ACL support for the Linux kernel.
Access Control Lists allow fine grained access control to filesystem objects, by attaching a list of permissions to grant or deny specific capabilities to users or groups.
Too bad ACL's demonstrably don't work. And what they grant or deny are not "capabilities," a technical term of art in secure computing that has a specific, well-defined meaning that is being corrupted in this context.
10:43:05 PM
The more time I spend thinking about P2P architectures, the more I think that IM is the solution. Here is how they stack up:
1) Proven scalability. Compare the ~3 m simultaneous users online at AIM and ICQ with the ~1.5 m Napster and Morpheus (at their peaks).
2) The ability to connect to specific individuals on an IM system vs. the fractional network approach on the current P2P systems.
3) Authorization and buddy lists. IM has it. P2P systems offer the ability to ban only.
4) QoS (Quality of Service) is much higher on IM than the current P2P systems. [John Robb's Radio Weblog]
IM would indeed make an excellent P2P application, but let's remember that that's what it is—an application—and you can tell practically nothing about the underlying architecture of any given IM system from using it. Some points about the comments above:
First, going from ~1.5m to ~3m users (who in neither case were actually simultaneous) isn't a scalability accomplishment. Going from ~1.5m to ~15m (that is, an order of magnitude) would be. And it's important to understand that the chosen examples, AIM and ICQ, are both owned and operated by AOL on—you guessed it—mind-bogglingly enormous server farms. Nary a whiff of P2P in the house.
It's a good thing John said "current." I get the impression that what John is really contrasting are two different categories of applications, either of which may or may not be P2P-based: file-sharing vs. IM. If your app is file-sharing, chances are you're interested in getting a file, not connecting directly to someone named X. By contrast, if you want to send someone an IM, then by definition you're interested in connecting to them! Once again, this has nothing whatsoever to do with P2P.
There are several P2P infrastructure pieces that deal with authorization ([sic]; John almost certainly means "authentication" here, although good P2P systems treat both). These same systems typically have some notion of "trusted users," i.e. buddies. Check out JXTA, MNet, Spread, Ensemble, Spinglass, OpenPrivacy, and E.
Another blanket statement that overlooks that the problem being solved in one case (sending truly tiny snippets of text and/or a little audio point-to-point) is utterly trivial in terms of bandwidth consumption compared to the other (distributed large-file-sharing across an arbitrary number of peers). It's not hard to have high QoS when you aren't providing much service.
Don't get me wrong; IM can definitely be an excellent example of a P2P application. It's just extremely dangerous to think of IM's application characteristics as defining anything about a P2P architecture.
10:39:35 PM
The more time I spend thinking about P2P architectures, the more I think that IM is the solution. Here is how they stack up:
