Netscape 4.7 adds yet another button to the navigation toolbar, which is annoying because it further increases the amount of screen real estate required for me to be able to see the "Stop" button on the right. Right now, the "Shop", "My Netscape", and "Search" buttons are all candidates for removal -- if I could figure out how.
Does anyone know how to remove buttons from the toolbar? Is there some hack to the preferences.js file that would do it?
If I understand the concept, weather futures are a useful form of insurance for businesses.
Suppose I'm the CFO of UmbrellaCorp, and my company's income is proportional to the average annual rainfall in my state. If we have a dry year, the company gets minimal income and might go bankrupt. So, I go to BigBank, Inc. and buy a derivative whose value is inversely proportional to annual rainfall. The bank agrees to buy back the derivative at the end of the year. If we have a dry year, I make some money on my derivative to offset the loss of income; if we have a wet year, I lose some money on the derivative, but that's OK because I made beaucoup bucks selling umbrellas.
In effect, I pay BigBank to assume some of the weather-related risk to my business. The bank has a more diverse investment pool than UmbrellaCorp, so they can better manage the risk. They've also got a pile of weather analysts who can determine a fair price for the derivative, then charge me a bit more than that price so the bank makes money in the long run.
Commoditizing weather derivatives through an active exchange keeps them liquid (UmbrellaCorp can sell its instrument for instant cash in an emergency) and maintains their price near what everyone thinks is fair.
Of course, if Joe DayTrader with his 8192-node Beowulf cluster thinks he can predict the weather better than the average analyst, he's welcome to lose his shirt trying to outfox the market.
One of the biggest problems in online voting is that one must be able to verify that no-one has voted twice without tying a person's identity to her vote in any way.
Guaranteed voter anonymity is required to prevent effective reprisal or bribery for votes cast. It must be impossible for me either to coerce you ("vote for Bob or I'll fire you/arrest you/break your legs") or to bribe you ("vote for Bob and I'll give you $50"). Today, I could try either of these approaches to fix the outcome of an election, but there would be no point in doing so because J. Random Voter could just say "I'll vote for Bob, please don't hurt me (and thanks for the bribe!)" and then go vote his conscience anyway. I'd have no way to prove that he did otherwise.
The requirement of anonymity forbids assigning public/private keys to each voter to sign her vote -- if the signature is nonrepudiable, you would have a provable record of who voted for whom. One could argue that the Elections Commission could prevent improper release of voter/vote pairs by imposing heavy legal penalties on the violators, but this argument should be just as distasteful to/. readers as the claim that we could prevent improper release of escrowed encryption keys in the same way.
Today, our election systems are heavily weighted in favor of voter anonymity, with relatively weak protection against multiple voting. This compromise made sense in late-19th-century America, when corporate robber barons frequently tried to coerce/cajole their employees into voting for pro-big-business candidates. It makes just as much sense today, for the same reasons.
The easy options for online voting today either move the current system online -- which makes multiple voting very much easier -- or guarantee no multiple votes through digital signatures -- which suffers from the aforementioned vote-tying problem. I believe there are known cryptographic solutions to the online voting dilemma, but they are too computationally expensive to deploy for more than a handful of voters.
I scanned Unisys's page, and it appears they are claiming their licensing fees from everyone who uses any LZW-using formats. That includes PDF and PostScript files with compressed bitmaps.
I could care less if GIF bites the dust, but I'm more than a little perturbed about PDF. Does the PDF format define any alternate compression schemes?
I can't believe someone could actually write prose like that. My best guess right now is that the author wanted to post an encrypted message and used a high-order Markov model to encode the ciphertext as a plausible English document.
The training set for the model might be real RFC's, or possibly the U.S. Congressional Record;-).
Someone on BugTraq speculated, quite correctly IMHO, that one reason LinuxPPC may be holding up so well is that nobody has yet ported existing buffer overflow exploits for Linux apps to the PPC architecture. Thus, a large class of potential holes is less likely to be exploited than if the machine were running x86 Linux (any flavor).
Can someone who has experience writing exploits evaluate whether this hypothesis is reasonable? Are buffer overflows sufficiently easy to exploit that known holes would have been used by now?
To: postmaster@earth.sol.com From: zork@gmaps.beta.lyrae.net Subject: GRBH advisory
Dear Earthlings:
We have received numerous reports that your planet has been broadcasting unsolicited commercial email (commonly referred to as "spam"). Please be advised that your planet is now a candidate for Galactic Real-time Black Hole (GRBH) listing.
We understand that, as a young and technologically backward species, you may not be familiar with the rules of Galactic Etiquette. However, ignorance is no excuse for your present behavior. We have also heard that your planetary network maintains a so-called "black-hole list." Please note that your penchant for colorful metaphors is unique among sentient species; we of the galactic community are rather more literal-minded.
We personally doubt that you wish to see your planet torn apart by a gravitational vortex, so we urge you to cease transmitting spam immediately. Please inform us by interocitor of your intent to comply within the next 100 centons.
I just got a new Dell system with Phoenix BIOS, and it displays the Dell logo and "www.dell.com" in the top-right corner of the screen every time I boot. In fact, the shipped configuration displays a full-screen Dell logo instead of the usual self-test and hardware detection information. Fortunately, there's an option to turn that off.
Anyone know how to replace that logo with the bitmap of my choice? The BIOS is flashable, so I imagine that it's not too hard.
I've seen a lot of suggestions here about "baiting" email with phrases designed to attract Echelon sniffers. However, it's annoying to have to read the bait words (not to mention explaining their presence to your friend, your boss, your mom, &c) in every message.
Many mail user agents will let you add arbitrary headers to your message. Hence, one can get maximum spookage with minimum annoyance by adding an X-NSA header, e.g.
X-NSA: POTUS nerve agent militia encryption
In my experience, anyone who is clueful enough to display all message headers is also clueful enough to get the joke (HHOS).
Everyone is busy deconstructing the new jargon file entries, but nobody has noted the six casualties (see the ChangeLog). Let us respectfully intone the names of the deceased:
"DEChead" "Open DeathTrap" "Share and Enjoy!" "double DECkers" "microtape" "pig, run like a"
Now I was never into DEC culture, but I *was* once a frequent user of "Share and Enjoy!". Sniff sniff...
Now seems a good time to mention that David Brin isn't the only SF author who has considered the implications of a total surveillance society. Check out David Drake's short story collection Lacey and his Friends for an alternative viewpoint. I read it years ago, but a quick check reveals that it's still for sale cheap on amazon.com.
I think your view of the "Star Trek surveillance society" is biased by the fact that ST:TOS, ST:TNG, ST:DS9, and ST:V all are intimately connected with Star Fleet, the military arm of the Federation. I don't recall pervasive surveillance in any of snapshots of "normal" civilian life.
Moreover, all the cameras in the galaxy didn't prevent numerous and massive screwups by Star Fleet which required the exertions of its most famous captains to uncover. See, for example, the most recent Star Trek movie.
The trouble is, there are never enough Jean-Luc Picards to go around.
If you suspect that the hardware RNG produces a bitstream with known correlations that an attacker could exploit, then scramble the bits further in software. For instance, instead of using the raw bitstream, pass it through your favorite stream cipher seeded with a key composed from a trusted random source like/dev/random. Or, for a lower-bandwidth application, read a random number of bits into a buffer, then compute the buffer's SHA-1 hash and use that as the next few bits of your stream.
Someone who knows more about crypto than I do can probably suggest a stronger scheme than the above. The goal is to make it computationally infeasible for an attacker to exploit his knowledge of the RNG's hidden weaknesses, while requiring many fewer trusted random bits than would be needed if the hardware RNG were not used at all.
Slashdot Mirror
Netscape 4.7 adds yet another button to the navigation toolbar, which is annoying because it further increases the amount of screen real estate required for me to be able to see the "Stop" button on the right. Right now, the "Shop", "My Netscape", and "Search" buttons are all candidates for removal -- if I could figure out how.
Does anyone know how to remove buttons from the toolbar? Is there some hack to the preferences.js file that would do it?
If I understand the concept, weather futures are a useful form of insurance for businesses.
Suppose I'm the CFO of UmbrellaCorp, and my company's income is proportional to the average annual rainfall in my state. If we have a dry year, the company gets minimal income and might go bankrupt. So, I go to BigBank, Inc. and buy a derivative whose value is inversely proportional to annual rainfall. The bank agrees to buy back the derivative at the end of the year. If we have a dry year, I make some money on my derivative to offset the loss of income; if we have a wet year, I lose some money on the derivative, but that's OK because I made beaucoup bucks selling umbrellas.
In effect, I pay BigBank to assume some of the weather-related risk to my business. The bank has a more diverse investment pool than UmbrellaCorp, so they can better manage the risk. They've also got a pile of weather analysts who can determine a fair price for the derivative, then charge me a bit more than that price so the bank makes money in the long run.
Commoditizing weather derivatives through an active exchange keeps them liquid (UmbrellaCorp can sell its instrument for instant cash in an emergency) and maintains their price near what everyone thinks is fair.
Of course, if Joe DayTrader with his 8192-node Beowulf cluster thinks he can predict the weather better than the average analyst, he's welcome to lose his shirt trying to outfox the market.
One of the biggest problems in online voting is that one must be able to verify that no-one has voted twice without tying a person's identity to her vote in any way.
/. readers as the claim that we could prevent improper release of escrowed encryption keys in the same way.
Guaranteed voter anonymity is required to prevent effective reprisal or bribery for votes cast. It must be impossible for me either to coerce you ("vote for Bob or I'll fire you/arrest you/break your legs") or to bribe you ("vote for Bob and I'll give you $50"). Today, I could try either of these approaches to fix the outcome of an election, but there would be no point in doing so because J. Random Voter could just say "I'll vote for Bob, please don't hurt me (and thanks for the bribe!)" and then go vote his conscience anyway. I'd have no way to prove that he did otherwise.
The requirement of anonymity forbids assigning public/private keys to each voter to sign her vote -- if the signature is nonrepudiable, you would have a provable record of who voted for whom. One could argue that the Elections Commission could prevent improper release of voter/vote pairs by imposing heavy legal penalties on the violators, but this argument should be just as distasteful to
Today, our election systems are heavily weighted in favor of voter anonymity, with relatively weak protection against multiple voting. This compromise made sense in late-19th-century America, when corporate robber barons frequently tried to coerce/cajole their employees into voting for pro-big-business candidates. It makes just as much sense today, for the same reasons.
The easy options for online voting today either move the current system online -- which makes multiple voting very much easier -- or guarantee no multiple votes through digital signatures -- which suffers from the aforementioned vote-tying problem. I believe there are known cryptographic solutions to the online voting dilemma, but they are too computationally expensive to deploy for more than a handful of voters.
Even easier... institute the death penalty for spamming and malicious port scanning.
Time to get out my copy of Niven's "The Long ARM of Gil Hamilton".
I scanned Unisys's page, and it appears they are claiming their licensing fees from everyone who uses any LZW-using formats. That includes PDF and PostScript files with compressed bitmaps.
I could care less if GIF bites the dust, but I'm more than a little perturbed about PDF. Does the PDF format define any alternate compression schemes?
I can't believe someone could actually write prose like that. My best guess right now is that the author wanted to post an encrypted message and used a high-order Markov model to encode the ciphertext as a plausible English document.
;-).
The training set for the model might be real RFC's, or possibly the U.S. Congressional Record
I don't think StarOffice will be absorbed into the Java Platform, being that the platform (at least the JavaOS part) just took a bullet.
Someone on BugTraq speculated, quite correctly IMHO, that one reason LinuxPPC may be holding up so well is that nobody has yet ported existing buffer overflow exploits for Linux apps to the PPC architecture. Thus, a large class of potential holes is less likely to be exploited than if the machine were running x86 Linux (any flavor).
Can someone who has experience writing exploits evaluate whether this hypothesis is reasonable? Are buffer overflows sufficiently easy to exploit that known holes would have been used by now?
To: postmaster@earth.sol.com
From: zork@gmaps.beta.lyrae.net
Subject: GRBH advisory
Dear Earthlings:
We have received numerous reports that your planet has been broadcasting unsolicited commercial email (commonly referred to as "spam"). Please be advised that your planet is now a candidate for Galactic Real-time Black Hole (GRBH) listing.
We understand that, as a young and technologically backward species, you may not be familiar with the rules of Galactic Etiquette. However, ignorance is no excuse for your present behavior. We have also heard that your planetary network maintains a so-called "black-hole list." Please note that your penchant for colorful metaphors is unique among sentient species; we of the galactic community are rather more literal-minded.
We personally doubt that you wish to see your planet torn apart by a gravitational vortex, so we urge you to cease transmitting spam immediately. Please inform us by interocitor of your intent to comply within the next 100 centons.
I just got a new Dell system with Phoenix BIOS, and it displays the Dell logo and "www.dell.com" in the top-right corner of the screen every time I boot. In fact, the shipped configuration displays a full-screen Dell logo instead of the usual self-test and hardware detection information. Fortunately, there's an option to turn that off.
Anyone know how to replace that logo with the bitmap of my choice? The BIOS is flashable, so I imagine that it's not too hard.
I've seen a lot of suggestions here about "baiting" email with phrases designed to attract Echelon sniffers. However, it's annoying to have to read the bait words (not to mention explaining their presence to your friend, your boss, your mom, &c) in every message.
Many mail user agents will let you add arbitrary headers to your message. Hence, one can get maximum spookage with minimum annoyance by adding an X-NSA header, e.g.
X-NSA: POTUS nerve agent militia encryption
In my experience, anyone who is clueful enough to display all message headers is also clueful enough to get the joke (HHOS).
Everyone is busy deconstructing the new jargon file entries, but nobody has noted the six casualties (see the ChangeLog). Let us respectfully intone the names of the deceased:
"DEChead"
"Open DeathTrap"
"Share and Enjoy!"
"double DECkers"
"microtape"
"pig, run like a"
Now I was never into DEC culture, but I *was* once a frequent user of "Share and Enjoy!". Sniff sniff...
Now seems a good time to mention that David Brin isn't the only SF author who has considered the implications of a total surveillance society. Check out David Drake's short story collection Lacey and his Friends for an alternative viewpoint. I read it years ago, but a quick check reveals that it's still for sale cheap on amazon.com.
I think your view of the "Star Trek surveillance society" is biased by the fact that ST:TOS, ST:TNG, ST:DS9, and ST:V all are intimately connected with Star Fleet, the military arm of the Federation. I don't recall pervasive surveillance in any of snapshots of "normal" civilian life.
Moreover, all the cameras in the galaxy didn't prevent numerous and massive screwups by Star Fleet which required the exertions of its most famous captains to uncover. See, for example, the most recent Star Trek movie.
The trouble is, there are never enough Jean-Luc Picards to go around.
If you suspect that the hardware RNG produces a bitstream with known correlations that an attacker could exploit, then scramble the bits further in software. For instance, instead of using the raw bitstream, pass it through your favorite stream cipher seeded with a key composed from a trusted random source like /dev/random. Or, for a lower-bandwidth application, read a random number of bits into a buffer, then compute the buffer's SHA-1 hash and use that as the next few bits of your stream.
Someone who knows more about crypto than I do can probably suggest a stronger scheme than the above. The goal is to make it computationally infeasible for an attacker to exploit his knowledge of the RNG's hidden weaknesses, while requiring many fewer trusted random bits than would be needed if the hardware RNG were not used at all.