You raise some interesting points. You're right that we should carefully choose what we support.
However, you are doing exactly what you accuse the article of.
Your post is factless. You should give some examples of what you are complaining about, rather than just complain.
There also doesn't seem to be a lot of connection between your points. What exactly does anti-drug propaganda have to do with this? It's unclear if you are comparing the Privacy International Report, the Register article or government restrictions and monitoring of the Internet to anti-drug propoganda.
I'm not saying that you're lying, but if you don't want us to think you are exagerating, back up your assertions.
Do you think that the problem was because of the separation between the screen and the transparent foil? It would have to be extremely precise.
The placement of the dots would also have to take in to effect the different angles that your eye would follow to see pixels on the left and right sides of the screen.
What about using a half-waveplate with holes punched in it for every other pixel? This could then be placed right up against the screen. The position would just need to be adjusted to fit the LCD pixel grid.
You would have to use something more rigid than cellophane, of course. You would also still need polarizing glasses.
I don't think this invalidates their conclusions, but there is one "fact" that is not actually true. The Star article states:
Schneier discovered that by typing "request catalog name address city state zip" into Google, a person gets links to more than 250,000 sites containing subscription and request Web forms.
Sure, Google says that it found "about 259,000" search results. However, paging through the results themselves reveals that it only found 839. Including the omitted, very similar pages, there are still only 997.
I think that the web has a huge number of automated forms that could be used for this kind of attack, but you would have to do a little more digging for them than the article implies.
There's no way that the iLoo is a feasible product. There are major conceptual and physical problems with it as presented in the News.com iLoo article.
The physical problems are an easier target, so let's start with those.
There's a plasma screen on the inside. There are two problems with this.
The smallest size plasma screen is 32 inches. From the iLoo illustration, the inner screen is 36% of the width of the booth. No scale is given, but porta-potties are usually 48 inches wide. With these numbers, we can estimate that the screen shown is a 19" model. Very reasonable for a LCD, but not for a Plasma.
Plasma screens are very delicate. Chooisng such a fragile display technology for such a public place would be ludicrous. Have a look at the massively padded cases required to ship plasma screens.
Another problem is the "Wireless LAN ADSL Module". Stringing a bunch of buzzwords together makes something that sound good, but doesn't actually make sense.
The article mentions that "A Windows XP-powered computer resides under the sink". How does this single computer manage to run an external display and keyboard along with the one inside the potty?
Most of the conceptual problems are actually mentioned in the article itself. It dismisses them humourously but not logically. The lineups for porta-potties at festivals and events are no joke. Encouraging people to stay in them longer than necessary would be a disaster!
Who is Matthew Whittingham, the man quoted as the "MSN UK spokesman"? Google reveals only one page mentioning him in relation to MSN, apart from the numerous pages about the iLoo. In this page, dated January 26th of this year, he is quoted as the "group marketing manager for MSN UK". That's a very different role than spokesman. My guess is that the hoaxsters picked a MSN UK employee at random to use in their story. In fact, if you google for "MSN UK" spokesman -iLoo, this same page appears at the top of the third page, since it mentions "spokesman" elsewere.
Finally, who in their right mind would use a keyboard that you *knew* had last been used by someone on the toilet?
When I started freelance programming, I really didn't like the idea of working from home. There's just too much isolation from the world, and not enough seperation of work and personal.
Fortunately, I found a few other people in similar situations who felt the same way.
We got together and rented some nice studio space together. We called ourselves the Soup Group, since we're a mixture of everything. To fill the space, we had to convince a few others that they should quit their jobs and go freelance.
Now, 8 years later, we have a great studio, filled with 16 people who like to be around each other. We're an intentional community, not a corporation whose members are decided by the whim of the HR department. There's lots of synergy, as we have programmers, designers, project managers, video editors, animators, and lots of other talents.
We save a lot of money by sharing resources like our boardroom, Internet connections, colour laser printer, fax machine, kitchen facilities, copier, etc. This especially helps people just starting out working for themselves.
So my advice is to do the same. There are a lot of freelancers out there, and a lot of great studio space. It might take some work to find the people to group up with, but it's worth it in the long run.
Caching sites to prevent the slashdot effect does need to be thought out and discussed in detail. Since so many sites referred to on Slashdot's front page are slashdotted, the majority of the discussions are based on guesses. The quality of discussion could be greatly improved if everyone could access the sites that are mentioned.
The basic problem is that some web site owners would like to have their pages cached, and some would not.
People who have an economic interest in increased hits (banner ads), and can withstand the traffic would not like to be cached. Webmasters with an inaccessible server and a rapidly increasing bandwidth bill would definitely like to be cached.
I propose that Slashdot should first always grab a cache of each site that it links to. It shouldn't use it right away, though. A web site owner who notices their site is being slashdotted could then fill out a form to activate this cache. They could easily be authenticated by an automated email to the admin, tech or billing contact for the domain. This email could even be pre-emptive to inform the webmaster of what is about to happen to their server.
The cache itself would have to check for updated content frequently, of course. This is common practice for any caching system.
Slashdot could even make the cache available only to subscribers. This could offset the extra bandwidth required to serve the cached site from slashdot's servers.
A problem with randomly choosing which transactions go through is trust. With the system I proposed, the Customer has to trust PepperCash to use the correct odds to determine whether the transaction goes through. The solution is transparency. Give customers and merchants the tools to verify the integrity of the system.
Each invoice emailed from PepperCash would have an MD5 checksum, and clear delimiters for what text is checksummed. That way, the customer can recreate the MD5 checksum themselves to verify it.
Merchants would also receive an MD5 checksum with each transaction verification. The text to be checksummed would be a concatenation of several fields uniquely identifying the transaction so that the merchant can recreate the checksum.
Each month, PepperCash would publish a database of every transaction. Each record would have only the transaction amount and the MD5 checksum. If an additional signup fee has been charged to a transaction, this will be in a seperate field.
Anyone with a spreadsheet will be able to see if all the $10 and $0 amounts charged to the Customers add up to all the micropayments made to the Merchants. Merchants and Customers can verify that the MD5 checksums for their transactions are in the database and the correct amounts are listed.
I have a better idea. Put all of the random selection of when to bill at the Customer side, instead of the Merchant side. Take out the requirement of the Customer needing a Peppercoin account. Here's what my system would look like, call it PepperCash:
Customer finds something they want to purchase on a Merchant's site for 50 cents
Customer enters in payment details, including their credit card number
Merchant transmits payment info to PepperCash servers
PepperCash randomly decides to charge nothing or $10 to the Customer's credit card account. The odds of this are calculated in the same way as Peppercoin, so that a 50 cent transaction has a 1 in 20 chance of going through as $10, and a 19 in 20 chance of not being charged at all.
PepperCash sends an email invoice of the actual amount billed to their credit card, $0 or $10
PepperCash deposits 50 cents into the merchant's PepperCash account
To further save on Bank fees, the merchant is only allowed to withdraw more than $10 at a time from their PepperCash account
Of course, we don't want people to enter in invalid credit card information, and let it go through 95% of the time. This could be avoided by the PepperCash servers storing a database record of the payment info of all previous transactions. To prevent security catastrophes, the credit card numbers themselves would not be stored, only an MD5 hash of the numbers.
Every time a transaction is received from a merchant, it is matched against this database. If no match is found, the actual value of the transaction is charged to the credit card, plus 3% and 50 cents to make up for Bank fees. The banking network then verifies that the payment information is valid.
This makes the very first Micropayment made with the system into a kind of signup fee. Depending on how deep the pockets of the Angel Investors are, this extra 3% + 50c fee could be waived.
I release this idea into the public domain. Software patents are bad.:)
When reading the article and FAQs on the Peppercoin site, I kept thinking that it made no sense from the merchant's point of view to throw away most of the transactions instead of verifying them with Peppercoin.
There are 4 point-to-point transactions occurring in the Peppercoin system:
Customer to Peppercoin Central Servers
Customer to Merchant
Merchant to Peppercoin Central Servers
Peppercoin Central Servers to VISA/MC/etc
The savings appear to only occur in transaction 3. Let's compare this system to a typical stored-value system like Paypal.
Paypal transactions always have the Customer log in to the Paypal site at some point to verify their identity, as in Transaction 1. With Peppercoin, the code to authorize the transaction seems to be created by the Customer's computer. However, since the customer's account appears to be debited the exact amount of each purchase, there must be communication between the Customer to Peppercoin for each transaction. The system cannot rely on an indirect communication through the merchant for this, since the merchant throws away most ( [10-paymentvalue]/10 *100% ) of the "Peppercoins", and doesn't report them. Peppercoin's central servers must be cryptographically involved in the creation of the Peppercoins to ensure that they are reported.
Transaction 2 is more onerous than a typical Paypal payment, as it requires the Customer to invoke a custom software application to create the Peppercoin.
Transaction 3 is much easier for the merchant. With Peppercoin, on average, they only have to process one transaction for every $10 worth of value received. Using Paypal's "MassPay" system, the merchant must contact Paypal's servers to confirm each transaction.
Transaction 4 is unknown. Peppercoin is vague about the account that customers have with them. Their web site and the article mentioned both imply that the roulette-style banking will not be used here. Quote:
Not "approximately the amount you spend". This seems to imply that Customers' Peppercoin accounts are simply stored value. Peppercoin will probably make a credit card charge of $10 or so to open an account, and then put another $10 charge through again each time the balance reaches $0. This will avoid a disproportionate amount of any micropayments from being eaten by bank fees.
But to optimize transaction #4, any stored value system could use the same methods. As long as Peppercoin is billing customers for the exact amount they spend, there is nothing new here. Paypal could easily implement the same optimizations.
So the whole point of the system must be to save computational and network resources at the merchant's end for processing each transaction. But the question is why? Exactly what problem are they trying to solve here?
A server to server transaction for a merchant to verify a Paypal payment involves very little network traffic. You need to send over the transaction code, some customer details, and you receive back a result code indicating that the transaction was successful or not.
For argument's sake, take a conservative estimate of 1KB of data flying back and forth per transaction. With today's inexpensive and reliable bandwidth and computing resources, this is very cheap. Put a price of $15 per GB for the bandwidth and a similar amount to lease the CPU cycles, and this costs about 3/100ths of a cent per transaction. So if a Peppercoin merchant has one $10 token to process instead of a twenty little 50 cent transactions, they will save about half a cent, a tiny fraction of the value involved.
For this system to make any sense at all, we must be talking about much smaller micropayments. What if each micropayment was 1/100th of a cent? In this case, the merchant would collect 100,000 payments on average before needing 3/100ths of a cent of resources to connect to Peppercoin servers to redeem a $10 coin. A Paypal merchant would have to make 100,000 http calls, costing them about $30 to collect $10 worth of micropayments.
For Peppercoin to work, the other transactions need to be limited as well. There's no point in saving the Merchant $30 of bandwidth and CPU resources if it cost Peppercoin $30 of resources in transaction #1, Customer to Peppercoin.
Transaction #1, Customer to Peppercoin could be scaled down by allowing some value to be stored on the Customer's system directly. If they could download $10 worth of Peppercoin into their local app, a network transaction would not be necessary for each micropayment. Previous, now-defunct systems have worked out the necessary cryptography to ensure that stored values can only be spent once.
I work at an even smaller shop than Lars, and we develop 90% of our web sites using ColdFusion.
For the smaller clients, they don't even ask what programming language we're going to use. We host most of the sites ourselves, but when a client has their own host, we are finding more and more ISPs waking up to CF and providing it.
A lot of our medium-sized clients are getting in to hosting their sites on their own boxes, and they are definitely interested in what software will be running the site. Once the benefits of ColdFusion are explained to them, they're happy to use it. The fact that the server software is so inexpensive doesn't hurt either. We usually also sell them on the fact that the development will cost less, since developer productivity is excellent with CF.
For the larger clients, I have to do a lot of talking. They sometimes run other sites/applications on the same web server, so they are very careful about what to install. That's one reason I'm very happy CFMX will now install on top of Java Application Servers like Websphere/etc. Larger clients also want to know how this will fit in with the scope of their larger development strategy. Is it a good choice for other applications? (usually) Does it run on our platform of choice (usually yes since it runs on windows, Solaris, Linux, etc.) Is there a large pool of CF development talent to draw on? (yes) Is high-quality tech support and training available. (yes)
On the other hand, although we can convince people to use it, nobody comes and asks for a site to be developed in CF. It's just not a buzzword right now. Everyone is talking about Java and JSP. We are moving towards JSP ourselves, but the environment needs to become more robust before we can make the switch. Coldfusion MX will help with this a lot, since it supports JSP as well.
The concept was that you were a God, and you were battling another Diety for control of worlds. Both you and your opponent started out with a few followers, and they would multiply rapidly through making settlements. You could make the settlements produce faster by improving the land around them.
You slowly built up Mana points that you could spend on disasters to inflict on your opponent's settlements and followers. Volcanos, quicksand, earthquakes, just to name a few. The more followers you had, the faster your Mana would accumulate.
It was the first game that I had ever seen that had multiple units to control at once. Instead of having direct control over each unit, you could direct them towards a "Papal Magnet" that you could place anywhere in the game world.
It even had a multiplayer option that you could play over a modem.
It was much closer to today's RTS games than Herzog Zwei!
Are you talking about having secure kiosks at each voting office? If you are, I assume that you mean to only allow voting from these kiosks, and not allow voting from home. If this is what you mean, then why use the Internet at all? Phone lines from each voting office to a central collection office would be much more secure. 56Kbps is plenty for this, since we are not talking about very much data, even with encryption.
If you are talking about having home users connect via the Internet to their local voting office, then you are missing the big security holes.
It is trivial to secure the actual connection between the voter and the voting office. The big problems lie in securing their PC.
Picture a version of any of any of the big worms that have circulated recently. All it would have to do is intercept the voter's mouse clicks in the voting app and redirect them to a different vote. If it was clever enough, it could even manipulate the video display buffer to make it appear to the voter that nothing has changed.
These worms spread like lightning, and could be unleashed on the day of the vote, making it unlikely that Joe User would update his virus checker in time.
How about recording audio files of your entire life!
The way to do it would be to carry around a small, lightweight device that would record each day's audio. The device would have 100BT ethernet and some custom software to connect it to a massive storage server. Some custom software would be written to transfer the files each night while the batteries are being recharged.
Aqcuiring Hardware
Pocket ePC-II System - $749
950g, 157mm (L) x 146mm (W) x 45mm (H)
PII 900Mhz, 128MB RAM, 10GB HD, 100BT Ethernet
4 Li-Ion Laptop batteries - $800 Mini Stereo Microphone - $65
Storage Required
128 kb per second for stereo mp3 at 128kbps
86400 seconds per day
1382.4 megabytes per day
504.576 Gigabytes per year
1TB would give you enough storage for 1 year, plus 1 complete redundant backup. Assume that every 18 months, the same amount of money will buy you a hard drive that is twice as big. Also assume that you throw away the old server every time you replace it with a new one, just so you don't end up with a huge pile of servers. I will start off with a 1.5TB server, which will last the same 18 months to make the math easier.
Storage Hardware
1.5 TB server
~ $8500
1st purchase at birth = 1.5TB, enough for 18 months
2nd purchase at 18 months = 3TB, enough for 3 years worth
3rd purchase at 3 years = 6TB, enough for 6 years
6 years = 12TB
12 years = 24TB
24 years = 48TB
48 years = 96TB, enough to last until you are 96 years old
So over your lifetime, you would have to make 7 purchases, for a total of $59,500. Add in the capture hardware of $1614, and you have a total lifetime cost $61,114. As the price of storage goes down, this will be even more affordable.
Soon, it will be feasible to do the same thing with high-quality video!
Slashdot Mirror
You raise some interesting points. You're right that we should carefully choose what we support.
However, you are doing exactly what you accuse the article of.
Your post is factless. You should give some examples of what you are complaining about, rather than just complain.
There also doesn't seem to be a lot of connection between your points. What exactly does anti-drug propaganda have to do with this? It's unclear if you are comparing the Privacy International Report, the Register article or government restrictions and monitoring of the Internet to anti-drug propoganda.
I'm not saying that you're lying, but if you don't want us to think you are exagerating, back up your assertions.
Sounds like an interesting experiment.
Do you think that the problem was because of the separation between the screen and the transparent foil? It would have to be extremely precise.
The placement of the dots would also have to take in to effect the different angles that your eye would follow to see pixels on the left and right sides of the screen.
What about using a half-waveplate with holes punched in it for every other pixel? This could then be placed right up against the screen. The position would just need to be adjusted to fit the LCD pixel grid.
You would have to use something more rigid than cellophane, of course. You would also still need polarizing glasses.
I don't think this invalidates their conclusions, but there is one "fact" that is not actually true. The Star article states:
Sure, Google says that it found "about 259,000" search results. However, paging through the results themselves reveals that it only found 839. Including the omitted, very similar pages, there are still only 997.I think that the web has a huge number of automated forms that could be used for this kind of attack, but you would have to do a little more digging for them than the article implies.
There's no way that the iLoo is a feasible product. There are major conceptual and physical problems with it as presented in the News.com iLoo article.
The physical problems are an easier target, so let's start with those.
There's a plasma screen on the inside. There are two problems with this.
Another problem is the "Wireless LAN ADSL Module". Stringing a bunch of buzzwords together makes something that sound good, but doesn't actually make sense.
The article mentions that "A Windows XP-powered computer resides under the sink". How does this single computer manage to run an external display and keyboard along with the one inside the potty?
Most of the conceptual problems are actually mentioned in the article itself. It dismisses them humourously but not logically. The lineups for porta-potties at festivals and events are no joke. Encouraging people to stay in them longer than necessary would be a disaster!
Who is Matthew Whittingham, the man quoted as the "MSN UK spokesman"? Google reveals only one page mentioning him in relation to MSN, apart from the numerous pages about the iLoo. In this page, dated January 26th of this year, he is quoted as the "group marketing manager for MSN UK". That's a very different role than spokesman. My guess is that the hoaxsters picked a MSN UK employee at random to use in their story. In fact, if you google for "MSN UK" spokesman -iLoo, this same page appears at the top of the third page, since it mentions "spokesman" elsewere.
Finally, who in their right mind would use a keyboard that you *knew* had last been used by someone on the toilet?
When I started freelance programming, I really didn't like the idea of working from home. There's just too much isolation from the world, and not enough seperation of work and personal.
Fortunately, I found a few other people in similar situations who felt the same way.
We got together and rented some nice studio space together. We called ourselves the Soup Group, since we're a mixture of everything. To fill the space, we had to convince a few others that they should quit their jobs and go freelance.
Now, 8 years later, we have a great studio, filled with 16 people who like to be around each other. We're an intentional community, not a corporation whose members are decided by the whim of the HR department. There's lots of synergy, as we have programmers, designers, project managers, video editors, animators, and lots of other talents.
We save a lot of money by sharing resources like our boardroom, Internet connections, colour laser printer, fax machine, kitchen facilities, copier, etc. This especially helps people just starting out working for themselves.
Have a look at the Soup studio.
So my advice is to do the same. There are a lot of freelancers out there, and a lot of great studio space. It might take some work to find the people to group up with, but it's worth it in the long run.
The basic problem is that some web site owners would like to have their pages cached, and some would not.
People who have an economic interest in increased hits (banner ads), and can withstand the traffic would not like to be cached. Webmasters with an inaccessible server and a rapidly increasing bandwidth bill would definitely like to be cached.
I propose that Slashdot should first always grab a cache of each site that it links to. It shouldn't use it right away, though. A web site owner who notices their site is being slashdotted could then fill out a form to activate this cache. They could easily be authenticated by an automated email to the admin, tech or billing contact for the domain. This email could even be pre-emptive to inform the webmaster of what is about to happen to their server.
The cache itself would have to check for updated content frequently, of course. This is common practice for any caching system.
Slashdot could even make the cache available only to subscribers. This could offset the extra bandwidth required to serve the cached site from slashdot's servers.
What do you think?
A problem with randomly choosing which transactions go through is trust. With the system I proposed, the Customer has to trust PepperCash to use the correct odds to determine whether the transaction goes through. The solution is transparency. Give customers and merchants the tools to verify the integrity of the system.
Each invoice emailed from PepperCash would have an MD5 checksum, and clear delimiters for what text is checksummed. That way, the customer can recreate the MD5 checksum themselves to verify it.
Merchants would also receive an MD5 checksum with each transaction verification. The text to be checksummed would be a concatenation of several fields uniquely identifying the transaction so that the merchant can recreate the checksum.
Each month, PepperCash would publish a database of every transaction. Each record would have only the transaction amount and the MD5 checksum. If an additional signup fee has been charged to a transaction, this will be in a seperate field.
Anyone with a spreadsheet will be able to see if all the $10 and $0 amounts charged to the Customers add up to all the micropayments made to the Merchants. Merchants and Customers can verify that the MD5 checksums for their transactions are in the database and the correct amounts are listed.
I have a better idea. Put all of the random selection of when to bill at the Customer side, instead of the Merchant side. Take out the requirement of the Customer needing a Peppercoin account. Here's what my system would look like, call it PepperCash:
Of course, we don't want people to enter in invalid credit card information, and let it go through 95% of the time. This could be avoided by the PepperCash servers storing a database record of the payment info of all previous transactions. To prevent security catastrophes, the credit card numbers themselves would not be stored, only an MD5 hash of the numbers.
Every time a transaction is received from a merchant, it is matched against this database. If no match is found, the actual value of the transaction is charged to the credit card, plus 3% and 50 cents to make up for Bank fees. The banking network then verifies that the payment information is valid.
This makes the very first Micropayment made with the system into a kind of signup fee. Depending on how deep the pockets of the Angel Investors are, this extra 3% + 50c fee could be waived.
I release this idea into the public domain. Software patents are bad. :)
When reading the article and FAQs on the Peppercoin site, I kept thinking that it made no sense from the merchant's point of view to throw away most of the transactions instead of verifying them with Peppercoin.
There are 4 point-to-point transactions occurring in the Peppercoin system:
The savings appear to only occur in transaction 3. Let's compare this system to a typical stored-value system like Paypal.
Paypal transactions always have the Customer log in to the Paypal site at some point to verify their identity, as in Transaction 1. With Peppercoin, the code to authorize the transaction seems to be created by the Customer's computer. However, since the customer's account appears to be debited the exact amount of each purchase, there must be communication between the Customer to Peppercoin for each transaction. The system cannot rely on an indirect communication through the merchant for this, since the merchant throws away most ( [10-paymentvalue]/10 *100% ) of the "Peppercoins", and doesn't report them. Peppercoin's central servers must be cryptographically involved in the creation of the Peppercoins to ensure that they are reported.
Transaction 2 is more onerous than a typical Paypal payment, as it requires the Customer to invoke a custom software application to create the Peppercoin.
Transaction 3 is much easier for the merchant. With Peppercoin, on average, they only have to process one transaction for every $10 worth of value received. Using Paypal's "MassPay" system, the merchant must contact Paypal's servers to confirm each transaction.
Transaction 4 is unknown. Peppercoin is vague about the account that customers have with them. Their web site and the article mentioned both imply that the roulette-style banking will not be used here. Quote:
http://www.peppercoin.com/consumer_faq.html
"You will be billed on your credit or charge card for the amount you spend " (emphasis mine)
Not "approximately the amount you spend". This seems to imply that Customers' Peppercoin accounts are simply stored value. Peppercoin will probably make a credit card charge of $10 or so to open an account, and then put another $10 charge through again each time the balance reaches $0. This will avoid a disproportionate amount of any micropayments from being eaten by bank fees.
But to optimize transaction #4, any stored value system could use the same methods. As long as Peppercoin is billing customers for the exact amount they spend, there is nothing new here. Paypal could easily implement the same optimizations.
So the whole point of the system must be to save computational and network resources at the merchant's end for processing each transaction. But the question is why? Exactly what problem are they trying to solve here?
A server to server transaction for a merchant to verify a Paypal payment involves very little network traffic. You need to send over the transaction code, some customer details, and you receive back a result code indicating that the transaction was successful or not.
For argument's sake, take a conservative estimate of 1KB of data flying back and forth per transaction. With today's inexpensive and reliable bandwidth and computing resources, this is very cheap. Put a price of $15 per GB for the bandwidth and a similar amount to lease the CPU cycles, and this costs about 3/100ths of a cent per transaction. So if a Peppercoin merchant has one $10 token to process instead of a twenty little 50 cent transactions, they will save about half a cent, a tiny fraction of the value involved.
For this system to make any sense at all, we must be talking about much smaller micropayments. What if each micropayment was 1/100th of a cent? In this case, the merchant would collect 100,000 payments on average before needing 3/100ths of a cent of resources to connect to Peppercoin servers to redeem a $10 coin. A Paypal merchant would have to make 100,000 http calls, costing them about $30 to collect $10 worth of micropayments.
For Peppercoin to work, the other transactions need to be limited as well. There's no point in saving the Merchant $30 of bandwidth and CPU resources if it cost Peppercoin $30 of resources in transaction #1, Customer to Peppercoin.
Transaction #1, Customer to Peppercoin could be scaled down by allowing some value to be stored on the Customer's system directly. If they could download $10 worth of Peppercoin into their local app, a network transaction would not be necessary for each micropayment. Previous, now-defunct systems have worked out the necessary cryptography to ensure that stored values can only be spent once.
Recording artists and performers are compensated for this by massive levies collected on all blank recording media sold in Canada.
This would be a handy device to take advantage of this law. It might take a few years to borrow and copy 1000 CDs from your friends, though.
I work at an even smaller shop than Lars, and we develop 90% of our web sites using ColdFusion.
For the smaller clients, they don't even ask what programming language we're going to use. We host most of the sites ourselves, but when a client has their own host, we are finding more and more ISPs waking up to CF and providing it.
A lot of our medium-sized clients are getting in to hosting their sites on their own boxes, and they are definitely interested in what software will be running the site. Once the benefits of ColdFusion are explained to them, they're happy to use it. The fact that the server software is so inexpensive doesn't hurt either. We usually also sell them on the fact that the development will cost less, since developer productivity is excellent with CF.
For the larger clients, I have to do a lot of talking. They sometimes run other sites/applications on the same web server, so they are very careful about what to install. That's one reason I'm very happy CFMX will now install on top of Java Application Servers like Websphere/etc. Larger clients also want to know how this will fit in with the scope of their larger development strategy. Is it a good choice for other applications? (usually) Does it run on our platform of choice (usually yes since it runs on windows, Solaris, Linux, etc.) Is there a large pool of CF development talent to draw on? (yes) Is high-quality tech support and training available. (yes)
On the other hand, although we can convince people to use it, nobody comes and asks for a site to be developed in CF. It's just not a buzzword right now. Everyone is talking about Java and JSP. We are moving towards JSP ourselves, but the environment needs to become more robust before we can make the switch. Coldfusion MX will help with this a lot, since it supports JSP as well.
I can't believe they left out Populous, published by Electronic Arts 3 years before Dune II, in 1989. See some screenshots, with bad translation. Gamespot considers it one of the 15 most influential games of all time.
The concept was that you were a God, and you were battling another Diety for control of worlds. Both you and your opponent started out with a few followers, and they would multiply rapidly through making settlements. You could make the settlements produce faster by improving the land around them.
You slowly built up Mana points that you could spend on disasters to inflict on your opponent's settlements and followers. Volcanos, quicksand, earthquakes, just to name a few. The more followers you had, the faster your Mana would accumulate.
It was the first game that I had ever seen that had multiple units to control at once. Instead of having direct control over each unit, you could direct them towards a "Papal Magnet" that you could place anywhere in the game world.
It even had a multiplayer option that you could play over a modem.
It was much closer to today's RTS games than Herzog Zwei!
Are you talking about having secure kiosks at each voting office? If you are, I assume that you mean to only allow voting from these kiosks, and not allow voting from home. If this is what you mean, then why use the Internet at all? Phone lines from each voting office to a central collection office would be much more secure. 56Kbps is plenty for this, since we are not talking about very much data, even with encryption.
If you are talking about having home users connect via the Internet to their local voting office, then you are missing the big security holes.
It is trivial to secure the actual connection between the voter and the voting office. The big problems lie in securing their PC.
Picture a version of any of any of the big worms that have circulated recently. All it would have to do is intercept the voter's mouse clicks in the voting app and redirect them to a different vote. If it was clever enough, it could even manipulate the video display buffer to make it appear to the voter that nothing has changed.
These worms spread like lightning, and could be unleashed on the day of the vote, making it unlikely that Joe User would update his virus checker in time.
What do we do with this kind of storage?
How about recording audio files of your entire life!
The way to do it would be to carry around a small, lightweight device that would record each day's audio. The device would have 100BT ethernet and some custom software to connect it to a massive storage server. Some custom software would be written to transfer the files each night while the batteries are being recharged.
Aqcuiring Hardware
Pocket ePC-II System - $749
950g, 157mm (L) x 146mm (W) x 45mm (H)
PII 900Mhz, 128MB RAM, 10GB HD, 100BT Ethernet
4 Li-Ion Laptop batteries - $800
Mini Stereo Microphone - $65
Storage Required
128 kb per second for stereo mp3 at 128kbps
86400 seconds per day
1382.4 megabytes per day
504.576 Gigabytes per year
1TB would give you enough storage for 1 year, plus 1 complete redundant backup. Assume that every 18 months, the same amount of money will buy you a hard drive that is twice as big. Also assume that you throw away the old server every time you replace it with a new one, just so you don't end up with a huge pile of servers. I will start off with a 1.5TB server, which will last the same 18 months to make the math easier.
Storage Hardware
1.5 TB server
~ $8500
1st purchase at birth = 1.5TB, enough for 18 months
2nd purchase at 18 months = 3TB, enough for 3 years worth
3rd purchase at 3 years = 6TB, enough for 6 years
6 years = 12TB
12 years = 24TB
24 years = 48TB
48 years = 96TB, enough to last until you are 96 years old
So over your lifetime, you would have to make 7 purchases, for a total of $59,500. Add in the capture hardware of $1614, and you have a total lifetime cost $61,114. As the price of storage goes down, this will be even more affordable.
Soon, it will be feasible to do the same thing with high-quality video!