Thanks very much for reminding us of that page.
I'll include those suggestions in
www.kegel.com/remedy.html
before I submit it as a comment to the DOJ.
I (and I'm sure some of you) have been studying the
Proposed Final Judgment. I'm putting together a critique which tries to show how the PFJ fails to meet the criteria set by the Court of Appeals, and how it needs to change to meet
those criteria. It's at
www.kegel.com/remedy.html.
Please have a look at it, and let me know if you think I'm on the right track.
Also, I've set up a mailing list on this topic; to subscribe,
go to http://groups.yahoo.com/group/ms-remedy/
or send a message to ms-remedy-subscribe@yahoogroups.com
Looking forward to your feedback. I'm hoping that I can
come up with a document that a significant number of Free Software
supporters can sign on to, which will get the attention
of the States' attournys-general, and which has a good chance
of influencing the judge to impose a settlement which won't
leave the Free Software community out in the cold.
Sam developed SDL *before* Loki existed.
That's one of the reasons I recommended him
to Scott back when Scott was forming Loki and
looking to hire his first programmer.
-- Dan Kegel
I've also been tracking the Linux-Kernel mailing list for notes about bottlenecks that probably affected the original benchmarks, and their resolution; see
http://www.kegel.com/mindcraft_redux.html.
Finally, for server programmers, I've been collecting a page of tips on how to write high performance server software for Linux/Unix; see
http://www.kegel.com/c10k.html.
I'm a programmer with about 20 years experience, ten or so with Unix and Linux, and I employ one or two interns constantly, each for three to six months. I've found that monster.com is not a good place to find interns; I have much better luck advertising on jobtrak.com. So don't forget about them.
Our product is for use between cooperating parties who know it's not in their interest to subvert the system.
It won't help you if you're sending mail to hostile people.
If both sender and recipient refrain from making unsecure copies of the mail, our product does in fact reduce the number of readable copies of a message to zero when the expiration date arrives.
http://www.kegel.com/nt-linux-benchmarks.html has a summary of the recent SPECweb99 benchmarks comparing Linux and Windows 2000. I should have database benchmarks for Win2k there soon, too.
I think this might be the way companies decide
to go. For extra protection, the companies can
choose an encryption product that shreds the
email after, say, 90 days (and lets them turn off
shredding if they get subpoenaed). Only one
I know of like that at the moment is the Outlook
plugin from www.disappearing.com.
I have a little writeup on the history of the wake-one fix (and others) at http://www.kegel.com/mindcraft_redux.html . Looking at Andrea's patch, one important change was
Offhand, it looks like that particular change isn't in Red Hat 6.1 or 6.2. I don't know whether this would affect ServerBench performance, though. It's hard to tell without looking at the source.
If the NT and Unix versions of ServerBench are very different, it's possible that the NT one is just better written.
One way to use ServerBench even if that's true would be to compare ServerBench scores only between different flavors of Unix.
I just checked the ZD site, and couldn't find any published ServerBench results for Unix. They don't have a central repository of results, it seems, but a search for "ServerBench" in all of zdnet showed very few hits.
Microsoft's general strategy is to bind all users to Windows. To some extent, this happens even without any evil intent. Microsoft products will tend to have that property naturally because Microsoft has no incentive to perform the kind of interoperability testing that would prevent it, and does not make true interoperability a requirement. This is one reason Microsoft needs to be broken up -- to keep the negative effects of that tendency under control.
Disclaimer: I write code for Disappearing Inc., but I'm not an official spokesman.
Aaron, you're on the right track. The tricky part is making this work conveniently, so that users don't absolutely have to have a separate email client to read or write this kind of email.
Disappearing Inc. will certainly educate its customers; the system only helps its users implement retention policies, it can't enforce them. The education will start before customers start using the Disappearing Inc. service, so I don't think DI will be engendering a false sense of security.
You ask "How shredded are the keys". We are trying to reduce the number of copies of the keys and decrypted messages made during the course of normal operation. Most of the time, there will be only one copy of the key, in one file on a RAID filesystem. When the key is erased, we will write over the region of disk where it is stored. At some point, we'll probably audit our software and sniff the entire physical disks for traces of old keys, just to make sure none are escaping deletion.
I designed the Disappearing, Inc. key server protocol and wrote the first implementation of it.
I don't think it's a marketing gimmick. It's a genuine effort to minimize the number of copies (on disk, in RAM, on the network) of decrypted email messages and the keys used to decrypt them; in principle, most of the time there's only one copy of the key, and if you delete that one copy, the message is unreadable. There are many ways people could subvert the system, just as there are many ways to spread secrets using the phone or paper. The point of this system is that you have to *try* to subvert it to cause plaintext copies to proliferate, as opposed to normal email, where they proliferate by default.
Nothing is perfect, but the Disappearing Inc. stuff probably doesn't suffer from the problems you suspect.
The Disappearing Inc. software is for people who share a common interest in having email go away after a while. It doesn't keep people from making plaintext copies, but it will probably remind people that making plaintext copies goes against their common interest.
That's right. The Disappearing Inc. stuff is simply an aid for groups that want to arrange for internal email to go away after, say, a year. There are many ways around it; its value lies in the fact that groups using it have a common interest in having the mail go away after a while.
Amusing that Microsoft had to go outside to buy Posix compatibility for NT. I guess they're finally admitting their own Posix subsystem was designed solely as a featurelist checkbox item, and was not intended to actually be used. Heck, it didn't even support sockets! I think it was more like a Posix Ghetto- they made sure programs using it couldn't communicate with the outside world.
I was one of the invitees, and as of 3pm EST, ETrade is still saying "hang in there... we haven't allocated the shares yet..." even though it's been trading for 3 hours now. I'm not cut out for this suspense...
Slashdot Mirror
Thanks very much for reminding us of that page. I'll include those suggestions in www.kegel.com/remedy.html before I submit it as a comment to the DOJ.
Please have a look at it, and let me know if you think I'm on the right track.
Also, I've set up a mailing list on this topic; to subscribe, go to http://groups.yahoo.com/group/ms-remedy/ or send a message to ms-remedy-subscribe@yahoogroups.com
Looking forward to your feedback. I'm hoping that I can come up with a document that a significant number of Free Software supporters can sign on to, which will get the attention of the States' attournys-general, and which has a good chance of influencing the judge to impose a settlement which won't leave the Free Software community out in the cold.
- Dan
Sam developed SDL *before* Loki existed. That's one of the reasons I recommended him to Scott back when Scott was forming Loki and looking to hire his first programmer.
-- Dan Kegel
I've also been tracking the Linux-Kernel mailing list for notes about bottlenecks that probably affected the original benchmarks, and their resolution; see http://www.kegel.com/mindcraft_redux.html.
Finally, for server programmers, I've been collecting a page of tips on how to write high performance server software for Linux/Unix; see http://www.kegel.com/c10k.html.
For info about my internship program, see http://www.kegel.com/academy/
I work for Disappearing, Inc. too.
Our product is for use between cooperating parties who know it's not in their interest to subvert the system.
It won't help you if you're sending mail to hostile people.
If both sender and recipient refrain from making unsecure copies of the mail, our product does in fact reduce the number of readable copies of a message to zero when the expiration date arrives.
http://www.kegel.com/nt-linux-benchmarks.html has a summary of the recent SPECweb99 benchmarks comparing Linux and Windows 2000. I should have database benchmarks for Win2k there soon, too.
Disclaimer: I helped write their keyserver.
You can find an unbiased summary of NT-versus-Linux benchmark results at
http://www.kegel.com/nt-linux-benchma rks.html
diff -u linux/net/ipv4/tcp.c:1.1.1.6
@@ -1575,7 +1575,7 @@
add_wait_queue(sk->sleep, &wait);
for (;;) {
- current->state = TASK_INTERRUPTIBLE;
+ current->state = TASK_INTERRUPTIBLE | TASK_WAKE_ONE;
Offhand, it looks like that particular change isn't in Red Hat 6.1 or 6.2. I don't know whether this would affect ServerBench performance, though. It's hard to tell without looking at the source.
If the NT and Unix versions of ServerBench are very different, it's possible that the NT one is just better written.
One way to use ServerBench even if that's true would be to compare ServerBench scores only between different flavors of Unix.
I just checked the ZD site, and couldn't find any published ServerBench results for Unix. They don't have a central repository of results, it seems, but a search for "ServerBench" in all of zdnet showed very few hits.
This book had the best explanation of relativity
I've ever seen. Time dilation makes sense now!
Microsoft's general strategy is to bind all users to Windows. To some extent, this happens even without any evil intent. Microsoft products will tend to have that property naturally because Microsoft has no incentive to perform the kind of interoperability testing that would prevent it, and does not make true interoperability a requirement. This is one reason Microsoft needs to be broken up -- to keep the negative effects of that tendency under control.
I'm working on an FTP benchmark; see www.kegel.com/dkftpbench
Don't forget The Elegant Universe: Superstrings, Hidden Dimensions, and the Quest for the Ultimate Theory" by Brian Greene. It's amazing.
Disclaimer: I write code for Disappearing Inc., but I'm not an official spokesman.
Aaron, you're on the right track. The tricky part is making this work conveniently, so that users don't absolutely have to have a separate email client to read or write this kind of email.
Disclaimer: I write code for Disappearing Inc.
Disappearing Inc. will certainly educate its customers; the system only helps its users implement retention policies, it can't enforce them. The education will start before customers start using the Disappearing Inc. service, so I don't think DI will be engendering a false sense of security.
You ask "How shredded are the keys". We are trying to reduce the number of copies of the keys and decrypted messages made during the course of normal operation. Most of the time, there will be only one copy of the key, in one file on a RAID filesystem. When the key is erased, we will write over the region of disk where it is stored. At some point, we'll probably audit our software and sniff the entire physical disks for traces of old keys, just to make sure none are escaping deletion.
So they should be fairly well shredded.
I designed the Disappearing, Inc. key server protocol and wrote the first implementation of it.
I don't think it's a marketing gimmick. It's a genuine effort to minimize the number of copies (on disk, in RAM, on the network) of decrypted email messages and the keys used to decrypt them; in principle, most of the time there's only one copy of the key, and if you delete that one copy, the message is unreadable. There are many ways people could subvert the system, just as there are many ways to spread secrets using the phone or paper. The point of this system is that you have to *try* to subvert it to cause plaintext copies to proliferate, as opposed to normal email, where they proliferate by default.
Nothing is perfect, but the Disappearing Inc. stuff probably doesn't suffer from the problems you suspect.
The Disappearing Inc. software is for people who share a common interest in having email go away after a while. It doesn't keep people from making plaintext copies, but it will probably remind people that making plaintext copies goes against their common interest.
That's right. The Disappearing Inc. stuff is simply an aid for groups that want to arrange for internal email to go away after, say, a year. There are many ways around it; its value lies in the fact that groups using it have a common interest in having the mail go away after a while.
I'm the guy who designed the Disappearing Inc. keyserving protocol and wrote the first couple implementations, by the way.
(see Microsoft Admits to Secretly Paying for "Independent" Ads).
Caveat lector.
http://alumnus.caltech.edu/~dank/rsi.htm
Amusing that Microsoft had to go outside to buy Posix compatibility for NT.
I guess they're finally admitting their own Posix subsystem was designed solely as a featurelist checkbox item, and was not intended to actually be used.
Heck, it didn't even support sockets!
I think it was more like a Posix Ghetto- they made sure programs using it couldn't communicate with the outside world.
I was one of the invitees, and as of 3pm EST,
ETrade is still saying "hang in there... we
haven't allocated the shares yet..." even though
it's been trading for 3 hours now.
I'm not cut out for this suspense...