Get a hardware router/switch. Make sure it does not, I repeat not, support Universal Plug-and-Play. You do not want arbitrary applications able to manipulate your firewall.
Install and update Windows as normal. The firewall will prevent anyone outside from initiating connections to your machine. All you have to worry about is websites you visit and e-mails you read before you finish the security-update process and get your anti-virus and anti-malware software and software firewall (to protect the rest of the world from you) up and running.
Hardware routers of this sort run for well under $100 and are a lot easier to deal with than the convolutions needed if they aren't there.
I truly hope they skip the 1st-Amendment arguments entirely. There was an early case in computers involving a user making backup copies of software, and the software maker tried to sue him for violating copyright. IIRC the judge in that case not only ruled that making backup copies of computer software was fair use under copyright law (and the DMCA specifically says that nothing in it may be construed as limiting fair-use rights) but that any license provision purporting to take away or limit those rights wasn't legal. That right there would take the legs right out from under the game company's case, and would leave 'em with the hard argument to make that the courts should ignore existing precedent.
I'll see if I can dig it up. This was back when Postel was still running the assigned-numbers authority and NSI was just a glorified record-keeper. I'd been looking into registering a domain, and NSI flat-out wouldn't accept a registration which didn't list at least 2 (might have been 3) nameservers for the top-level zone files, at least one of which had to be in a netblock you didn't own. Basicaly NSI was enforcing the recommendations laid down in RFC920 that said the name servers for a domain should have no common point of failure.
The problem is that those sites created their own single point of failure by all using Akamai for DNS. When Akamai DNS fails, sites that depend on it for their own DNS fail.
It used to be nearly impossible for this to happen. The original rules for DNS were that you had to have at least 2 nameservers for your domain, preferrably 3 or more, and they couldn't be on the same physical networks. With that rule having a single network go down rarely made any domain unresolvable (backbone networks whose outages could render dozens or hundreds of other networks unreachable being the exception). Maybe we should put the old nameserver-diversity rules back into place.
Actually the problems wouldn't be as bad. Even if you had IE and OE exactly as they are on Windows but running on Linux, the problem would be less. The main reason: on Linux IE and OE would not be allowed to install system software. They could mess with the user's software and set up cron jobs, but they couldn't overwrite system libraries, install things into the startup scripts, disable checks in the system mail software, shut off the system security/anti-virus scans or otherwise interfere with the vast majority of the system. More importantly no Unix system developer would dream of making some of the security choices Microsoft has made on Windows (such as allowing externally-loaded software to ever execute outside a very restricted environment, or tying one specific Web browser tightly into privileged and restricted sections of the system that don't need a Web browser at all), so the problems that plague MS systems would be reduced even further. I suppose the MS programming drones could start moving to Linux and bring their bad choices along with them, but they'd find a very hostile environment indeed as few distributions would accomodate them.
The sad truth is, most of Windows' security problems aren't bugs, they're deliberate design choices by Microsoft. Windows isn't insecure because it's broken, it's insecure because it's working exactly as it was designed to work and that's a lot harder a problem to fix.
They keep saying that filters are becoming ineffective. Yet, between SpamAssassin and some hand-coded rules on my mail server (primarily the "not addressed to me" rule) and bogofilter and some more hand-coded rules on my client (mainly looking for specific charset encodings and document types), I end up with only half-a-dozen messages or so a day getting past my filters out of several hundred pieces of spam. So far the filters seem highly effective to me, far more effective and less intrusive than the solutions the "spam protection" companies are proposing.
I don't think the disclaimer and warnings would last 5 minutes in court. There's one critical thing needed to make those "confidential" warnings effective: I must have a duty not to disclose that confidential information. If I'm an employee of the company then I signed a contract stating that I had such a duty. If I'm visiting the company I've probably been told not to take any confidential material and a judge would consider my continuing the visit implicit agreement to that. If I'm J. Random Person Off The Street and I find the documents blowing out of the unsecured dumpster, I've agreed to nothing explicitly or implicitly and I've no duty not to disclose. The company can come down on whoever put the documents in the trash going to the dumpster instead of into the shredder, but all they can do is growl threateningly at me from the end of their legal leash.
Anyone sending e-mails should follow the same rules as someone sending physical documents. If you need the contents to be kept confidential or anything, get an agreement about that before sending them.
No, we aren't the "mass market". We're the people the mass market goes to when they get their new computer and realize they have no idea how to set it up, or when they get hit by the worm du jour and need their system repaired. If they won't change the defaults from what Redmond gives them, why would they be any more likeliy to change the defaults the neighborhood geek gave them when he cleaned up their system and installed the anti-spam/anti-malware packages?
Never throw one of these letters away without a response. It can come back to bite you later. If you didn't ever download the file or make it available, send them a written response saying that . If their abuse person says it was a mistake and to ignore it, ask them to put that in writing and send it to you. Don't ignore it until after you've gotten that letter saying to ignore it. This has two purposes: a) to make sure that, if they decide to come down on you anyway, they can't use your ignoring the situation against you, and b) to make it more annoying for them when they make a mistake.
The people who install this are sitting ducks. You see spam from them, do one of two things:
If it originates from a residential account, forward the spam to their ISP with full headers showing where it originated. They're almost certainly violating two different provisions of their ISP's TOS/AUP: running a server and commercial use.
If it's coming from a business (office PC or something), or if the ISP doesn't do anything, report the business/ISP to their upstream provider and/or some of the big blacklists as a spam source.
The fundamental flaw is that the spammers can and probably will have access to the code formulas. Even today spammers are using trojans to hijack ordinary PCs to relay their spam. The hijacked PC has to have the formulas to generate codes for everyone the PC's owner sends mail to. All the trojan has to do is snag the password, grab and decrypt the formula tables and use them. At that point the codes become useless.
For extra nasty points, the trojan can send copies of the tables it obtains back to the author, who can resell them to spammers and anyone else who wants a way around the blocks the recipients using this scheme have set up.
First off, how much training does it really require to learn the basics of using a windowing system? Or an office suite? Most of the time, the hard part of teaching a Linux office suite to someone is getting them to stop making it hard and just start doing what you'd expect to do in Windows. Just because it's OO on Linux doesn't mean that that icon with a printer in it suddenly doesn't print the document like it would in Windows, or that that font pull-down doesn't select your font like it would in Windows. If you need to train someone in stuff like that, you'd need to train them to use MS Office and it'd take about as long as the same training for OpenOffice. The same goes for the basic environment. The big difference between a modern Windows system and a modern Gnome or KDE system is the icon on the equivalent of the Start menu button, and it shouldn't take more than 15 seconds to learn that. Selecting items from the start menu, moving and closing windows, the Cancel/Apply/OK buttons, they're all just about identical between Windows, Gnome and KDE. Again, the big gap seems to be deliberately introduced, not any actual differences in the software.
If you really want to see what I mean, split prospective employees into two groups. Give them both identical Linux/OpenOffice systems, tell one group what they've got but tell the other that they're using the company's customized Windows environment instead. You'll see a marked difference, and it can't be due to the actual systems since they're identical.
Why would you install OO multiple times? Install it once on a server, export that directory tree for remote mounting, have each client mount it read-only at the appropriate place in it's directory tree. Or, if you absolutely need it on local disk for performance reasons, simply tar the installation tree up, scp it over to the client and untar it into the appropriate spot. Once you have the first install done on the server, additional installs should take as long as it takes to copy that much data across the network plus maybe 30 seconds, and the admin doing the install shouldn't need to leave his desk to do it.
Never, ever fall into the trap of comparing the cost of doing it the MS way on Windows with doing it the MS way on Unix.
The objection to the RIAA, though, was that they weren't filing John Doe lawsuits. Those would require going to court and actually proving that something the plaintiff could sue for did in fact occur, then getting a subpoena to find the identity of the person who did it. The problem we have with the RIAA is they want to skip right to the subpoena part without going to the trouble of filing a lawsuit and proving that anything they could sue for happened.
The article covered this. Consistently, the newbies had an easier time finding out what else they could do and learning how to do it from the command line than they had in the GUI. Apparently the GUI isn't all that discoverable if you're not a geek.
So, if I'm tknarr@silverglass.org and tknarr@xmission.com and tknarr@somecompany.com and tknarr@cox.net, how does your proposal allow me to use all 4 of them on a single machine, or allow me to suddenly and without warning use pricewatch@silverglass.org (which is a legal e-mail address for me, and which I'd probably use if I needed to give PriceWatch an e-mail address to contact me at) but not use pricewatch@xmission.com (which would not be legal for me)? And to complicate matters, how do you handle my laptop where for 9 hours out of the day 3 out of those 4 initial addresses are illegal and one is legal but for the other 15 that one is illegal and the other 3 are legal?
I suspect you can't come up with a way to make this work. More, I don't think there is a way to make this work that doesn't allow arbitrary forgery of addresses.
So what is my e-mail address? I'm not talking philosophically or in generalities, I'm talking about me, this user, specifically. I have, currently, a minimum of 4 "correct" e-mail addresses, each in a completely different domain, all usable from any of 5 active systems. In practice it's more like 12 "correct" addresses and only 3 systems I use routinely.
Your suggestion assumes that a) each user has only 1 e-mail address, 2) each user has only 1 computer and c) each computer has only 1 user. None of these is correct except in very limited circumstances.
Problem with pay-to-send
on
Gates on Spam
·
· Score: 1
One fundamental problem: Gates is too late. Pay-to-send would've worked a year or two ago, when spammers were sending from machines they owned or leased, even if the machines were overseas. Now, spammers increasingly use distributed networks of malware-infected machines to send e-mail. Requiring computation might slow them down, but any sort of monetary payment wouldn't bother the spammers one bit. The owners of the co-opted machines would be getting the bill for the postage, not the spammers.
OK then, scenario: the machine reports 1 vote for B in an election where there was only one question and one voter, me. All of the internal records indicate 1 vote for B. Problem: I voted for A, not B. How precisely do you go about proving that the results don't match the cast votes?
Because in many cases the local telco has a legal monopoly on those lines, granted as part of their agreement with the city/county/state. Anyone else could build lines, technically, but they may not run them on or through city property. It's considered unfair competition for them to be able to deny competitors access to their network when their network is the only way those competitors can legally reach customers. Even when that's not the case, the local telco was subsidized in building their network and had the luxury of legally guaranteed profit margins while they paid off the enormous initial investments involved, and it's considered unfair for them to take advantage of that now when their competitors aren't allowed the same subsidies and guarantees.
And of course then there's the telco's behavior when the shoe's on the other foot. Some CLECs who did build their own networks specialized in business phone services. Suddenly the telcos discovered that it was they who needed access to the CLEC's networks to complete their customer's calls to the businesses being served by the CLECs. In that case, the telcos fought tooth and nail against the right of the CLECs to charge for access to their networks.
There's only one problem: the only thing you could scrutinize would be the counts emitted by the machines. There's no other record to look at. If the exit polls say 90% of the voters voted A and the machines say 90% voted B and you think that's just not plausible, you're stuck because the only record of what the votes actually were is the count reported by the machine. You can ask it to repeat that number, but the original votes no longer exist to recount.
I'm not sure Prof. Rubin's right about the smart cards not being a big vulnerability. If someone manufactures altered cards it's easy to come in with one in your pocket, get a legit card, use the altered card to vote and return the legit card. You couldn't stuff the ballot box this way, but you could vote a different ballot than the one you were assigned. This would get caught when checking the voting machine's tally of ballot types against the number of each type issued, but there'd still be no way of correcting the results.
The zero machine is the big problem. I think it's why Diebold makes such a big deal out of the security of the actual voting process: the zero machine makes the security of the voting itself irrelevant. That one machine tallies all votes, and it gets access to all of the PCMCIA cards that hold the tallies from the other machines. It's in a position to simply discard all the actual results and replace them with whatever it wants, and once it has there's no way to tell it's happened. I can think of several easy ways to keep that code undetected, too. Unverified code loaded at the last minute (after all the testing had been done) to fix a convenient bug, for example. Just disallowing updates won't stop me, though. Prof. Rubin mentioned using PIN 1111 during training but a different PIN when setting the machines up for an election. So, I put the result-replacement code into the zero machine before it's delivered to the state, but put in a check: if the PIN is 1111 then disable the replacement code, otherwise enable it. During training, during test elections, during everything that uses that special PIN 1111 the machine will behave exactly as if no malicious code was present. Set it up for a real election using a real PIN other than 1111, and suddenly code that's never been active before is active and waiting to force the results. Note that it doesn't have to be Diebold loading the code, anyone who can get enough access to the zero machine to load a program update into it could do this. Given Diebold's track record for doing on-the-sly updates to the code, I think there's a non-negligible chance of someone being able to slip their code into an update and have it go through even if we assume Diebold themselves wouldn't (and I'm far from willing to assume that).
The big danger in my opinion isn't so much that this is possible, but that it's possible without leaving any evidence it's happened. The one thing paper ballots do well is give us an audit trail from the actual cast ballots all the way through the final results. The results can be altered, but it's very difficult to alter them while keeping the audit trail intact and consistent. It's not the electronic voting machines that are the major problem, it's the lack of a verifiable audit trail. With paper ballots you don't need to trust the counting process to verify whether the final results are correct. With the current electronic machines this isn't the case.
I'd extend the orphan clause to be more of an in-print requirement for all copyrighted material. Once you've published it openly, the timer is armed. If you let the material go out of print or otherwise become unavailable, the timer starts ticking. If the material stays out-of-print/unavailable for 5 years, copyright expires.
I'd also change the way copyrights are transferred, making them more like a stack. If the author signs over rights to a book to a publisher, the law "remembers" that. If the publisher lets the book go out-of-print, when the 5-year timer expires copyright doesn't terminate, it reverts to the author and another 5-year timer starts to run. The author can then take the book to another publisher, or they can leave it out of print in which case at the end of that second 5 years the author's copyright terminates and the book enters the public domain.
That, I think, would put an end to one of the most egregious misuses of copyright.
At current, the DMCA takes precedence. It is an all inclusive law that supersedes prior copyright law.
USC Title 17 section 1201 "Circumvention of copyright protection systems", 1201(c)(1): "Nothing in this section shall affect rights, remedies, limitations, or defenses to copyright infringement, including fair use, under this title."
Slashdot Mirror
It's a two-step process:
- Get a hardware router/switch. Make sure it does not, I repeat not, support Universal Plug-and-Play. You do not want arbitrary applications able to manipulate your firewall.
- Install and update Windows as normal. The firewall will prevent anyone outside from initiating connections to your machine. All you have to worry about is websites you visit and e-mails you read before you finish the security-update process and get your anti-virus and anti-malware software and software firewall (to protect the rest of the world from you) up and running.
Hardware routers of this sort run for well under $100 and are a lot easier to deal with than the convolutions needed if they aren't there.I truly hope they skip the 1st-Amendment arguments entirely. There was an early case in computers involving a user making backup copies of software, and the software maker tried to sue him for violating copyright. IIRC the judge in that case not only ruled that making backup copies of computer software was fair use under copyright law (and the DMCA specifically says that nothing in it may be construed as limiting fair-use rights) but that any license provision purporting to take away or limit those rights wasn't legal. That right there would take the legs right out from under the game company's case, and would leave 'em with the hard argument to make that the courts should ignore existing precedent.
I'll see if I can dig it up. This was back when Postel was still running the assigned-numbers authority and NSI was just a glorified record-keeper. I'd been looking into registering a domain, and NSI flat-out wouldn't accept a registration which didn't list at least 2 (might have been 3) nameservers for the top-level zone files, at least one of which had to be in a netblock you didn't own. Basicaly NSI was enforcing the recommendations laid down in RFC920 that said the name servers for a domain should have no common point of failure.
The problem is that those sites created their own single point of failure by all using Akamai for DNS. When Akamai DNS fails, sites that depend on it for their own DNS fail.
It used to be nearly impossible for this to happen. The original rules for DNS were that you had to have at least 2 nameservers for your domain, preferrably 3 or more, and they couldn't be on the same physical networks. With that rule having a single network go down rarely made any domain unresolvable (backbone networks whose outages could render dozens or hundreds of other networks unreachable being the exception). Maybe we should put the old nameserver-diversity rules back into place.
Actually the problems wouldn't be as bad. Even if you had IE and OE exactly as they are on Windows but running on Linux, the problem would be less. The main reason: on Linux IE and OE would not be allowed to install system software. They could mess with the user's software and set up cron jobs, but they couldn't overwrite system libraries, install things into the startup scripts, disable checks in the system mail software, shut off the system security/anti-virus scans or otherwise interfere with the vast majority of the system. More importantly no Unix system developer would dream of making some of the security choices Microsoft has made on Windows (such as allowing externally-loaded software to ever execute outside a very restricted environment, or tying one specific Web browser tightly into privileged and restricted sections of the system that don't need a Web browser at all), so the problems that plague MS systems would be reduced even further. I suppose the MS programming drones could start moving to Linux and bring their bad choices along with them, but they'd find a very hostile environment indeed as few distributions would accomodate them.
The sad truth is, most of Windows' security problems aren't bugs, they're deliberate design choices by Microsoft. Windows isn't insecure because it's broken, it's insecure because it's working exactly as it was designed to work and that's a lot harder a problem to fix.
They keep saying that filters are becoming ineffective. Yet, between SpamAssassin and some hand-coded rules on my mail server (primarily the "not addressed to me" rule) and bogofilter and some more hand-coded rules on my client (mainly looking for specific charset encodings and document types), I end up with only half-a-dozen messages or so a day getting past my filters out of several hundred pieces of spam. So far the filters seem highly effective to me, far more effective and less intrusive than the solutions the "spam protection" companies are proposing.
I don't think the disclaimer and warnings would last 5 minutes in court. There's one critical thing needed to make those "confidential" warnings effective: I must have a duty not to disclose that confidential information. If I'm an employee of the company then I signed a contract stating that I had such a duty. If I'm visiting the company I've probably been told not to take any confidential material and a judge would consider my continuing the visit implicit agreement to that. If I'm J. Random Person Off The Street and I find the documents blowing out of the unsecured dumpster, I've agreed to nothing explicitly or implicitly and I've no duty not to disclose. The company can come down on whoever put the documents in the trash going to the dumpster instead of into the shredder, but all they can do is growl threateningly at me from the end of their legal leash.
Anyone sending e-mails should follow the same rules as someone sending physical documents. If you need the contents to be kept confidential or anything, get an agreement about that before sending them.
No, we aren't the "mass market". We're the people the mass market goes to when they get their new computer and realize they have no idea how to set it up, or when they get hit by the worm du jour and need their system repaired. If they won't change the defaults from what Redmond gives them, why would they be any more likeliy to change the defaults the neighborhood geek gave them when he cleaned up their system and installed the anti-spam/anti-malware packages?
Never throw one of these letters away without a response. It can come back to bite you later. If you didn't ever download the file or make it available, send them a written response saying that . If their abuse person says it was a mistake and to ignore it, ask them to put that in writing and send it to you. Don't ignore it until after you've gotten that letter saying to ignore it. This has two purposes: a) to make sure that, if they decide to come down on you anyway, they can't use your ignoring the situation against you, and b) to make it more annoying for them when they make a mistake.
I think someone needs to reiterate to these companies a bit of advice from Michael Rathbun:
The people who install this are sitting ducks. You see spam from them, do one of two things:
The fundamental flaw is that the spammers can and probably will have access to the code formulas. Even today spammers are using trojans to hijack ordinary PCs to relay their spam. The hijacked PC has to have the formulas to generate codes for everyone the PC's owner sends mail to. All the trojan has to do is snag the password, grab and decrypt the formula tables and use them. At that point the codes become useless.
For extra nasty points, the trojan can send copies of the tables it obtains back to the author, who can resell them to spammers and anyone else who wants a way around the blocks the recipients using this scheme have set up.
First off, how much training does it really require to learn the basics of using a windowing system? Or an office suite? Most of the time, the hard part of teaching a Linux office suite to someone is getting them to stop making it hard and just start doing what you'd expect to do in Windows. Just because it's OO on Linux doesn't mean that that icon with a printer in it suddenly doesn't print the document like it would in Windows, or that that font pull-down doesn't select your font like it would in Windows. If you need to train someone in stuff like that, you'd need to train them to use MS Office and it'd take about as long as the same training for OpenOffice. The same goes for the basic environment. The big difference between a modern Windows system and a modern Gnome or KDE system is the icon on the equivalent of the Start menu button, and it shouldn't take more than 15 seconds to learn that. Selecting items from the start menu, moving and closing windows, the Cancel/Apply/OK buttons, they're all just about identical between Windows, Gnome and KDE. Again, the big gap seems to be deliberately introduced, not any actual differences in the software.
If you really want to see what I mean, split prospective employees into two groups. Give them both identical Linux/OpenOffice systems, tell one group what they've got but tell the other that they're using the company's customized Windows environment instead. You'll see a marked difference, and it can't be due to the actual systems since they're identical.
Why would you install OO multiple times? Install it once on a server, export that directory tree for remote mounting, have each client mount it read-only at the appropriate place in it's directory tree. Or, if you absolutely need it on local disk for performance reasons, simply tar the installation tree up, scp it over to the client and untar it into the appropriate spot. Once you have the first install done on the server, additional installs should take as long as it takes to copy that much data across the network plus maybe 30 seconds, and the admin doing the install shouldn't need to leave his desk to do it.
Never, ever fall into the trap of comparing the cost of doing it the MS way on Windows with doing it the MS way on Unix.
The objection to the RIAA, though, was that they weren't filing John Doe lawsuits. Those would require going to court and actually proving that something the plaintiff could sue for did in fact occur, then getting a subpoena to find the identity of the person who did it. The problem we have with the RIAA is they want to skip right to the subpoena part without going to the trouble of filing a lawsuit and proving that anything they could sue for happened.
The ISPs here are going about it the right way.
The article covered this. Consistently, the newbies had an easier time finding out what else they could do and learning how to do it from the command line than they had in the GUI. Apparently the GUI isn't all that discoverable if you're not a geek.
So, if I'm tknarr@silverglass.org and tknarr@xmission.com and tknarr@somecompany.com and tknarr@cox.net, how does your proposal allow me to use all 4 of them on a single machine, or allow me to suddenly and without warning use pricewatch@silverglass.org (which is a legal e-mail address for me, and which I'd probably use if I needed to give PriceWatch an e-mail address to contact me at) but not use pricewatch@xmission.com (which would not be legal for me)? And to complicate matters, how do you handle my laptop where for 9 hours out of the day 3 out of those 4 initial addresses are illegal and one is legal but for the other 15 that one is illegal and the other 3 are legal?
I suspect you can't come up with a way to make this work. More, I don't think there is a way to make this work that doesn't allow arbitrary forgery of addresses.
So what is my e-mail address? I'm not talking philosophically or in generalities, I'm talking about me, this user, specifically. I have, currently, a minimum of 4 "correct" e-mail addresses, each in a completely different domain, all usable from any of 5 active systems. In practice it's more like 12 "correct" addresses and only 3 systems I use routinely.
Your suggestion assumes that a) each user has only 1 e-mail address, 2) each user has only 1 computer and c) each computer has only 1 user. None of these is correct except in very limited circumstances.
One fundamental problem: Gates is too late. Pay-to-send would've worked a year or two ago, when spammers were sending from machines they owned or leased, even if the machines were overseas. Now, spammers increasingly use distributed networks of malware-infected machines to send e-mail. Requiring computation might slow them down, but any sort of monetary payment wouldn't bother the spammers one bit. The owners of the co-opted machines would be getting the bill for the postage, not the spammers.
OK then, scenario: the machine reports 1 vote for B in an election where there was only one question and one voter, me. All of the internal records indicate 1 vote for B. Problem: I voted for A, not B. How precisely do you go about proving that the results don't match the cast votes?
Because in many cases the local telco has a legal monopoly on those lines, granted as part of their agreement with the city/county/state. Anyone else could build lines, technically, but they may not run them on or through city property. It's considered unfair competition for them to be able to deny competitors access to their network when their network is the only way those competitors can legally reach customers. Even when that's not the case, the local telco was subsidized in building their network and had the luxury of legally guaranteed profit margins while they paid off the enormous initial investments involved, and it's considered unfair for them to take advantage of that now when their competitors aren't allowed the same subsidies and guarantees.
And of course then there's the telco's behavior when the shoe's on the other foot. Some CLECs who did build their own networks specialized in business phone services. Suddenly the telcos discovered that it was they who needed access to the CLEC's networks to complete their customer's calls to the businesses being served by the CLECs. In that case, the telcos fought tooth and nail against the right of the CLECs to charge for access to their networks.
There's only one problem: the only thing you could scrutinize would be the counts emitted by the machines. There's no other record to look at. If the exit polls say 90% of the voters voted A and the machines say 90% voted B and you think that's just not plausible, you're stuck because the only record of what the votes actually were is the count reported by the machine. You can ask it to repeat that number, but the original votes no longer exist to recount.
I'm not sure Prof. Rubin's right about the smart cards not being a big vulnerability. If someone manufactures altered cards it's easy to come in with one in your pocket, get a legit card, use the altered card to vote and return the legit card. You couldn't stuff the ballot box this way, but you could vote a different ballot than the one you were assigned. This would get caught when checking the voting machine's tally of ballot types against the number of each type issued, but there'd still be no way of correcting the results.
The zero machine is the big problem. I think it's why Diebold makes such a big deal out of the security of the actual voting process: the zero machine makes the security of the voting itself irrelevant. That one machine tallies all votes, and it gets access to all of the PCMCIA cards that hold the tallies from the other machines. It's in a position to simply discard all the actual results and replace them with whatever it wants, and once it has there's no way to tell it's happened. I can think of several easy ways to keep that code undetected, too. Unverified code loaded at the last minute (after all the testing had been done) to fix a convenient bug, for example. Just disallowing updates won't stop me, though. Prof. Rubin mentioned using PIN 1111 during training but a different PIN when setting the machines up for an election. So, I put the result-replacement code into the zero machine before it's delivered to the state, but put in a check: if the PIN is 1111 then disable the replacement code, otherwise enable it. During training, during test elections, during everything that uses that special PIN 1111 the machine will behave exactly as if no malicious code was present. Set it up for a real election using a real PIN other than 1111, and suddenly code that's never been active before is active and waiting to force the results. Note that it doesn't have to be Diebold loading the code, anyone who can get enough access to the zero machine to load a program update into it could do this. Given Diebold's track record for doing on-the-sly updates to the code, I think there's a non-negligible chance of someone being able to slip their code into an update and have it go through even if we assume Diebold themselves wouldn't (and I'm far from willing to assume that).
The big danger in my opinion isn't so much that this is possible, but that it's possible without leaving any evidence it's happened. The one thing paper ballots do well is give us an audit trail from the actual cast ballots all the way through the final results. The results can be altered, but it's very difficult to alter them while keeping the audit trail intact and consistent. It's not the electronic voting machines that are the major problem, it's the lack of a verifiable audit trail. With paper ballots you don't need to trust the counting process to verify whether the final results are correct. With the current electronic machines this isn't the case.
I'd extend the orphan clause to be more of an in-print requirement for all copyrighted material. Once you've published it openly, the timer is armed. If you let the material go out of print or otherwise become unavailable, the timer starts ticking. If the material stays out-of-print/unavailable for 5 years, copyright expires.
I'd also change the way copyrights are transferred, making them more like a stack. If the author signs over rights to a book to a publisher, the law "remembers" that. If the publisher lets the book go out-of-print, when the 5-year timer expires copyright doesn't terminate, it reverts to the author and another 5-year timer starts to run. The author can then take the book to another publisher, or they can leave it out of print in which case at the end of that second 5 years the author's copyright terminates and the book enters the public domain.
That, I think, would put an end to one of the most egregious misuses of copyright.
At current, the DMCA takes precedence. It is an all inclusive law that supersedes prior copyright law.
USC Title 17 section 1201 "Circumvention of copyright protection systems", 1201(c)(1): "Nothing in this section shall affect rights, remedies, limitations, or defenses to copyright infringement, including fair use, under this title."