Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
As others have noted, spreading a virus and teaching others to spread a virus is dangerous, even if the virus is "benign." If the virus spreads to the system of any person who did not consent, you have committed an unethical and possibly unlawful act.
That said, it is necessary to learn and to teach. If you have responsible students who have agreed to take proper precautions, it may be permissible to perform certain exercises with viruses. However, while you can get ideas from Slashdot, you should not accept advice. You should verify the ideas independently with professionals in computer security.
I am not one, but one idea is to take some ideas from the methods used to prevent biological organisms from spreading while experimenting on those. For example, design the virus to spread only to systems that contain a special marker, such as a file in a known location that contains the text "This system is part of the equipment for course 123 in the Fall 2012 semester." This would prevent the virus from spreading to other systems even if a network connection were made or somebody moved a disk from your isolated systems to a networked system. It would not, of course, stop one of your students from disabling that part of the virus and making themselves a fun "toy" to play with, which is why you need to ensure your students are trustworthy.
"Hell, what if they said 'If you keep taking that pill, you will die in 10 years, otherwise you will die in 15'? Well, right now some might actually say 'I'll keep taking it', speaking for that person in 9 3/4 years who may answer VERY differently-- again a human inability to logically analyze the situation and come to an honest conclusion."
That example does not demonstrate any inability to analyze the situation. A person might value their quality of life with the pill more than 50% more than their quality of life without the pill, in which case 10 years with the pill is worth more than 15 years without the pill.
Then, in 9 3/4 years, their choice is 1/4 year with the pill versus 5 1/4 year without the pill, in which case it makes sense to discontinue the pill, unless their quality of life is much, much greater with the pill.
Because your bank or broker gives you statements that you must keep for tax or evidentiary purposes, and you think you can read them, but they break sometime in the future when your bank or broker "upgrades" their system.
Because you keep important information in Google Documents or some other quasi-online service, and you lose access to them in the future when the service is discontinued. Or when the free service is changed to a paid service.
Because the software is important to your business, and you need to ensure you will be able to continue to run it.
Because you want to keep a copy of the agreement offered when you opened an account.
Because you want to study the encryption and other security features used to protect your information or to allow qualified professionals to study the security features so they can advise the public about them. (E.g., you would like skilled and informed university professors to analyze the security features so they can warn you when certain software is not up to snuff, so that extra care can be taken.)
If you just use your web "browser" to browse or play games, you might not care about the software running in it. But if you use it for things you rely on, for safety or security or important information or record-keeping or making money, then you care about the software running on it, and you want some assurance and control over it.
"What I mean, is that to pay with credit cards, from what I know, you only need the data that is written right on the card."
No, there are other safeguards. For one thing, you need to know some address information associated with the card, such as house number and postal code. If the product is not being shipped to an address the credit card issuer knows is associated with the card, then there may be additional checks. There is a three-digit verification code that the purchaser may be asked to supply. This code is not printed in raised lettering, so it is not recorded on old-style physical imprints of the card, and merchants are not supposed to keep a record of it once the transaction has been approved. (They have the credit card number and an approval number unique to the transaction.)
As another respondent mentions, the credit card holder is responsible for reviewing their statements and notifying the credit card issuer of fraudulent transactions. Then the issuer can withhold the money from the merchant or otherwise get it back.
In Germany, you can send money to people by writing some information about your account and about the payee and their account on a bank form and depositing it into a box at your bank. What prevents that from being used fraudulently? I wondered about that when I lived there. I suppose the fact that the money goes to account provides some safety, as the destination back should have some knowledge of their customer.
"Why in the world do modern e-mail clients still allow reply all to hundreds of recipients without an additional safety question."
Because the client has no information about the number of recipients. It only knows the number of addresses the message is addressed to. A "reply all" on the lists I participate in commonly generates a message with two destination addresses, the individual sender and the list. The client does not know how many people are on the list or even that it is a list.
Certainly a client ought to ask for confirmation when there are more than a few addresses (subject to a customizable threshold so users who regularly send messages to many people can do so easily). However, you also need list servers to guard against email storms. Perhaps servers should request confirmation when there are symptoms of inadvertent, indiscriminate, or ignorant reply-all messages, such as trivial new text in a message with much quoted text, requests to unsubscribe, a reply from a new first-time sender on the list, etc.