You're conflating the arguments against a voter-verifiable paper trail (where the receipt is kept in a lockbox and never touched by the voter) and a hypothetical system of receipts which the voter takes with them and then can use to prove how they voted. Nobody thinks the latter is a good idea, and I agree; reason (3) is just icing on the cake. Lots of people think the former is a good idea -- it has opposition for reasons (1) and (2), but (cost concerns or no) it's one of the few mechanisms for making electronic voting adequately trustable that most people with credibility in computer security agree will actually work.
If you want to argue against having any kind of a VVPT, argue against the lockbox style approach -- it's the ones that security experts take credibly, despite the practical concerns involved. Mixing in the arguments against the hypothetical walk-out-with-a-receipt approach adds nothing but confusion.
With e-voting, you don't need to corrupt the officials -- you can corrupt the technicians, over whom the officials have no effective oversight. Even worse, some systems are so ineffectively built that they can be subverted by an individual without any inside access -- see the photos of unattended machines from the last elections, documentation on attacks that would work against them, etc.
Further, there are effective countermeasures for ballot box stuffing. There are judges from both major parties at any polling location validating that one person walking in corresponds to one name marked off the rolls; the number of names marked off and the number of votes cast at that location can then be correlated to match. Physical security measures, again with oversight from each major party, are available to protect both the rolls (tracking which people voted) and the boxes (tracking how they voted); these can be stored separately to increase the number of measures which need to be compromised to pull off an attack.
People understand physical security measures, and the adversarial system [where many of the folks involved in the actual work of implementing an election are selected by the competing parties] helps to prevent corruption. Not so many people understand electronic security, and it's much less amenable to traditional oversight and validation mechanisms.
And if someone can reprogram the machine to record votes a certain way, why can't they program it to dispense the correct paper audits as well?
That's why they're behind glass where the voter can look at the paper before confirming his or her vote. If I told the machine I'm voting for Bob but the piece of paper behind the glass window says Alice, I (the voter) know there's something wrong.
And a lock-box? Secure? You're right back to the same problem you have with paper ballots.
Those problems aren't too bad; We know how to contain them, even though those are largely procedural methods. Folks can look at a lockbox for pick marks, and those boxes don't get lost without it being noticed; once an electronic counter is tampered with, there can be no proof whatsoever that that tampering even occured.
I could cope with electronic voting if its security were only as bad as paper voting. The problem is that as it stands, there's potential for it to be much much worse -- and undetectably so.
No, no, no! That's not how voter-verifiable paper trails work! If you let the voter keep the piece of paper, they can use it to show how they voted (to collect a payment for their vote, or avoid being beat up or fired). If the piece of paper can't be visually read by the voter for them to know what it says, it isn't "voter-verifiable" any longer and doesn't allow immediate detection of fraud. Nobody wants to let the voter keep a piece of paper. (Well, almost nobody. There are some proposals where the paper is only readable using separate equipment which the voter is only allowed to access when alone, but that's a corner case and has problems of its own).
Instead, VVPT systems have a traditional physical lockbox. Think of the paper as being something behind glass; the user looks at it, validates that it says what they want it to say, and then press "yes" or "no". Press yes? It's deposited in a lockbox which can be secured via traditional methods. Press no? It's marked as void, or shredded, or whatever. It's not the voter's responsibility or burden to track the paper; rather, it's kept in the voting system for use in audits and recounts. (Audits being a very important thing -- having the ability to audit means you can take a sample of the physical ballots, check whether the proportions match what the electronic counters said, and know whether you have a big enough problem to require a larger recount).
This is still an improvement over pure paper ballots because you have the usability and accessibility enhancements associated with electronic voting, but the enhanced auditability associated with a piece of paper which a voter has looked at and approved.
Yes, IBM should have done this, or the kernel developers should have done that. When elephants battle, it is the grass that suffers.
As a user, I don't care whether it is the kernel developers or IBM who yields over their licensing concerns. I care that I can't use OpenAFS against new kernels.
Well, not everyone agrees that the non-GPL-compatible-free-software-can-rot attitude is very productive. In the case of OpenAFS, for instance, its GPL incompatibility is because (quoting the FSF) "it requires certain patent licenses be given that the GPL does not require. (We don't think those patent license requirements are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL)". Letting software rot (in this case) because its license protects freedoms more effectively than the GPL does is counterproductive from a software freedom standpoint, and not exactly representative of the pragmatism Linus is well-known for either.
By "updating" these pages by not supporting the old format you will breaking the layout of some documents that need a consistent layout.
You're missing his point: When converting the file to OOXML, one can and should add generic tags indicating the specific (broken) behavior which should emulated (such as "scale small caps by this percentage point") rather than just specifying a generic "Do What I Mean" marker without any useful guidance on how rendering of documents containing this marker should be implemented.
As long as tags indicate for all the relevant changes (like scaling small caps), the document will then look the same even without the DWIM markers.
Oh, and by the way, Wii Sports is my personal Game of the Year. Yeah, Zelda is a much better game in every way, except... Playing Wii Sports against a few pals is the most fun I've ever had with a console. Nothing comes even close.
Might I point you at Rayman Raving Rabbids? I haven't seen anything even close to the cow toss in terms of getting non-gamers excited. The single person I've seen who wasn't impressed by Rayman (which I took to a large family get-together) was a more serious gamer who was expecting a single, large, contiguous game rather than a minigame collection.
What do you mean, a "personal application"? Is that as opposed to an application installed or used for work-related purposes, or as opposed to an application installed for use by all folks with access to the system?
There are two scenarios that make sense:
- Application stores data on the other end of a network. Requires a net connection; doesn't make sense when you're working from a customer site or from home.
- Application stores data under home directory. File's (or directory's) owner may have permissions set to allow other users to read or write.
Any other scenario requires that an arbitrary, user-invoked application have write access to parts of the hard drive which are not under the user's home directory, which Just Shouldn't Happen. Even in cases (like databases) where files are owned and controlled by a daemon -- that daemon can darned well store its data under a home directory of its own on the encrypted partition; in this way, a daemon should be treated no differently from any other user. Obviously, the application code won't be encrypted -- but this action is in response to high-profile cases of data being lost; I haven't heard any situations from the public sector where there's been a particularly big fuss made about a proprietary binary getting into the wild.
There's a reason that modern versions of Windows have caught up with ancient versions of UNIX in requiring applications to store data under "Documents and Settings\<Username>\Application Data" (~/.<app> in UNIX, of course) when running as non-administrator and preventing access to HKEY_LOCAL_MACHINE (/etc). Doing anything else is stupid: It allows users to step on each others' toes or to change the operation of the system as a whole in a way that can't be reversed simply be wiping their home directory or restoring it from backup. In a security-conscious environment, this just isn't a good situation to have as standard operating procedure.
I'm referring, btw, only to dynamic data -- that which can be created or modified through user's actions. Static data required for a piece of software to operate, loaded at install-time and never modified thereafter typically has no need to be encrypted at all; it can be safely considered part of the software for such purposes. Data loaded at software install time and later user-modified, on the other hand, can have the modifications stored under the user-owned part of the filesystem tree, providing (again) for reversion to initial state simply by wiping the user account. It's the clean, obvious Right Way to do things -- and static data is almost never under the same kind of confidentiality requirements that dynamic data is. (If you're an IRS auditor, the information about the auditee you load before going on-site are dynamic; it thus has its rightful place under your home directory, and thus will be encrypted).
Not a troll. If your system is appropriately configured, you (and your applications) won't be *allowed* to save things anywhere on the local drive other than your home directory. Temp and swap space are also good candidates for encryption -- but putting temp space in a ramdisk and encrypting swap is a pretty reasonable way to do this. Anything other than those should be code, not data -- and thus nonsensitive. Why spend the cycles to encrypt and decrypt without a need to do so?
All that said, I think that giving a contract like this to a commercial vendor developing proprietary software would be... unfortunate. Funding addition of missing, necessary features to TrueCrypt would be a one-time expense (rather than one which scales with the number of systems deployed), and would benefit the private sector as well.
And it's a religion, which means it's not supposed to be subject to rational thought - you take it on faith, unquestioning
Faith doesn't necessarily imply that one be unthinking about it. The Bible is full of room for interpretation (historical context; questionable translations; internal inconsistencies requiring context to resolve; accuracy of the decision on which texts to include in the first place) -- just look at the number of variants on Protestantism!
I haven't self-identified as a Christian in many, many years; however, I grew up attending a small-town church governed by a board of elders with very different interpretations of the faith as a whole, and with a wide variety of individuals preaching (if I'd come up with a worthwhile sermon and passed it by the board, I could have gotten up to speak some Sunday myself). If we'd unthinkingly believed everything handed down from the pulpit, we'd have all been schizophrenics; to the contrary, we were actively encouraged to do our own research into the accuracy of the suggested interpretations.
Every other church I've attended to has had the expectation that those in the audience would be unthinking sheep, and it's this disappointment which prevented me from finding another church to associate with in the years immediately since. Just because many Christians treat their faith as requiring unthinking acceptance of their pastor's words as if passed down directly from God himself, however, does not mean that this is or in any way should be representative of religion as a whole.
At least in the US, what you're saying is at odds with the documented intent of those who added the Copyright Clause to the Constitution. Their intent was to encourage creation of new works and inventions -- and by doing so, to benefit the public at large. Do copyright and patent laws benefit artists and inventors? Absolutely. Should they be written with the artists and inventors in mind, as opposed to the wellbeing of the general public? No. The goal, as immortalized in the Constitution (and more extensively documented in Jefferson's notes) is "to promote the arts and sciences" -- a matter of public good -- rather than the private benefit of those who are more immediate beneficiaries.
I think it exceedingly unfortunate that our lawmakers have forgotten this.
In this case, since the individual in question is directly observed by an officer committing trespass (typically a misdemeanor without circumstances causing it to be otherwise), the officer had the ability and authority to arrest the individual -- or at least, would in my state; I don't know about the laws where this occurred. Following said arrest, there's potential for both civil and criminal trespassing charges, charges of resisting arrest, etc.
So, answering your question directly: The appropriate response is forceful ejection and arrest. "Arrest", however, should not mean repeated taserings unless the officer has a reasonable belief that such is necessary for his or her safety -- which is clearly not the case in this situation.
I'm not saying the library as an entity doesn't have the right to eject, and charge with trespassing, anyone who is there in violation of the rules.
"Eject, and charge with trespassing" does not imply tazering.
The point about privacy rights is that the individual in question was making an effort to protect those rights. Can the library choose to eject persons who choose to exercise those rights? Certainly. Again, though, it's no excuse for this level of response.
it's really too bad that average citizens don't have any vested interest in the accuracy of a voting machine's tabulations...
It's the "ability to audit" thing that's a problem.
I can audit an ATM's accuracy by looking at my bank statement. I can't check whether a voting machine recorded my vote -- unless I use something like the punchscan solution.
You are either helping us, or you aren't. You are either with us, or you are against us.
I, for one, don't trust this amorphous "us" -- and I do mean amorphous. After all, the Will Of The People changes every election -- and if I did trust the current government with stronger police powers, how would I know I could trust the next one? Freedoms aren't easily reclaimable once revoked, so giving up even the least of them should be done only with the greatest of caution.
The USA was founded by a set of revolutionaries who tried to place strict limits on what their government could do so that it would not become as abusive as the one it was replacing. "Fighting terrorists" is no excuse -- or, at least, a very poor one -- for ripping those protections out.
How many people have been killed by terrorist attacks on US soil in our entire history? Less than are killed by car accidents every month. And you would give up the liberties our forefathers died for... for what?
Ya know, this is one of those cases where intent matters quite a bit, as does notice.
If a developer makes software which is intentionally difficult to uninstall and fails to effectively notify potential users of this property, there are arguably elements of fraud going on. There's also the common-sense test as to whether the license agreement which the user submits to does in fact provide something of value to each party and is not so one-sided as to be innately unreasonable. (There's a specific term, but it's been a looong time since I took B-law).
The WOW strawman is obviously that (or you're unfamiliar with the specs on these things; they're not going to be running WOW). As for your counterproposal, "a chance to see" a computer (or use one in a central location) doesn't have nearly the potential impact of having one's own equipment which one can use for research or communication on a day-to-day basis or tinker with to gain understanding of how it works.
Now, getting more to the point: Communications infrastructure is a core element in having an effective and efficient society, and one part of what these things are about is *communication*. Having an automatic mesh network means that an entire village can benefit from only a single outbound endpoint -- and Internet access is potentially valuable to everyone. Think about farmers tracking the weather (or finding out what the best time will be to haul their crop out to sell), or a family looking up an illness someone has come down with.
Giving away housing and food is a temporary band-aid patch, and does nothing to make those who receive such handouts self-sustaining; giving folks better communications infrastructure (and these laptops, with their low-power mesh networking abilities, are infrastructure and education rolled into one) is a considerably longer-term investment. Folks with better communications infrastructure (and who grew up with access to such) are more likely to be able to do something -other- than toil in fields or Nike factories and create jobs by which others likewise have choices -- and that's a Damned Good Thing.
An investment in a diamond ring may be reasonable, so long as it comes with the right guarantees.
I purchased a diamond engagement ring for my (now-)wife from a jeweler willing to credit the full purchase price towards an upgrade to anything twice as expensive. After the bottom drops out of the diamond market, we'll be able to replace it with something having less transient value.
I don't see why you would even want to homebrew, unless you're one of those guys who puts Linux on your Xbox to 'stick it to The Man'. Or whyever the fuck people do that.
Well -- I'm anxiously awaiting hardware to allow me to run homebrew on my DS so that I can help out a guy who's developing some DS-native tools for learning Lojban. (Actually, helping him out is the whole reason I bought the DS, though Brain Age has turned out to be quite an excellent secondary reason).
Part of the point of doing homebrew is being able to build niche games or apps that no commercial developer would ever fund.
Slashdot Mirror
You're conflating the arguments against a voter-verifiable paper trail (where the receipt is kept in a lockbox and never touched by the voter) and a hypothetical system of receipts which the voter takes with them and then can use to prove how they voted. Nobody thinks the latter is a good idea, and I agree; reason (3) is just icing on the cake. Lots of people think the former is a good idea -- it has opposition for reasons (1) and (2), but (cost concerns or no) it's one of the few mechanisms for making electronic voting adequately trustable that most people with credibility in computer security agree will actually work.
If you want to argue against having any kind of a VVPT, argue against the lockbox style approach -- it's the ones that security experts take credibly, despite the practical concerns involved. Mixing in the arguments against the hypothetical walk-out-with-a-receipt approach adds nothing but confusion.
With e-voting, you don't need to corrupt the officials -- you can corrupt the technicians, over whom the officials have no effective oversight. Even worse, some systems are so ineffectively built that they can be subverted by an individual without any inside access -- see the photos of unattended machines from the last elections, documentation on attacks that would work against them, etc.
Further, there are effective countermeasures for ballot box stuffing. There are judges from both major parties at any polling location validating that one person walking in corresponds to one name marked off the rolls; the number of names marked off and the number of votes cast at that location can then be correlated to match. Physical security measures, again with oversight from each major party, are available to protect both the rolls (tracking which people voted) and the boxes (tracking how they voted); these can be stored separately to increase the number of measures which need to be compromised to pull off an attack.
People understand physical security measures, and the adversarial system [where many of the folks involved in the actual work of implementing an election are selected by the competing parties] helps to prevent corruption. Not so many people understand electronic security, and it's much less amenable to traditional oversight and validation mechanisms.
That's why they're behind glass where the voter can look at the paper before confirming his or her vote. If I told the machine I'm voting for Bob but the piece of paper behind the glass window says Alice, I (the voter) know there's something wrong.
Those problems aren't too bad; We know how to contain them, even though those are largely procedural methods. Folks can look at a lockbox for pick marks, and those boxes don't get lost without it being noticed; once an electronic counter is tampered with, there can be no proof whatsoever that that tampering even occured.
I could cope with electronic voting if its security were only as bad as paper voting. The problem is that as it stands, there's potential for it to be much much worse -- and undetectably so.
No, no, no! That's not how voter-verifiable paper trails work! If you let the voter keep the piece of paper, they can use it to show how they voted (to collect a payment for their vote, or avoid being beat up or fired). If the piece of paper can't be visually read by the voter for them to know what it says, it isn't "voter-verifiable" any longer and doesn't allow immediate detection of fraud. Nobody wants to let the voter keep a piece of paper. (Well, almost nobody. There are some proposals where the paper is only readable using separate equipment which the voter is only allowed to access when alone, but that's a corner case and has problems of its own).
Instead, VVPT systems have a traditional physical lockbox. Think of the paper as being something behind glass; the user looks at it, validates that it says what they want it to say, and then press "yes" or "no". Press yes? It's deposited in a lockbox which can be secured via traditional methods. Press no? It's marked as void, or shredded, or whatever. It's not the voter's responsibility or burden to track the paper; rather, it's kept in the voting system for use in audits and recounts. (Audits being a very important thing -- having the ability to audit means you can take a sample of the physical ballots, check whether the proportions match what the electronic counters said, and know whether you have a big enough problem to require a larger recount).
This is still an improvement over pure paper ballots because you have the usability and accessibility enhancements associated with electronic voting, but the enhanced auditability associated with a piece of paper which a voter has looked at and approved.
Yes, IBM should have done this, or the kernel developers should have done that. When elephants battle, it is the grass that suffers.
As a user, I don't care whether it is the kernel developers or IBM who yields over their licensing concerns. I care that I can't use OpenAFS against new kernels.
Well, not everyone agrees that the non-GPL-compatible-free-software-can-rot attitude is very productive. In the case of OpenAFS, for instance, its GPL incompatibility is because (quoting the FSF) "it requires certain patent licenses be given that the GPL does not require. (We don't think those patent license requirements are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL)". Letting software rot (in this case) because its license protects freedoms more effectively than the GPL does is counterproductive from a software freedom standpoint, and not exactly representative of the pragmatism Linus is well-known for either.
Remember, he's not in "GPL hippie-land" -- so inclusion upstream isn't an option.
That said, I think the whole GPL-only symbols thing is stupid, myself -- it means that Free-but-non-GPL projects like OpenAFS get hamstrung.
You're missing his point: When converting the file to OOXML, one can and should add generic tags indicating the specific (broken) behavior which should emulated (such as "scale small caps by this percentage point") rather than just specifying a generic "Do What I Mean" marker without any useful guidance on how rendering of documents containing this marker should be implemented.
As long as tags indicate for all the relevant changes (like scaling small caps), the document will then look the same even without the DWIM markers.
What do you mean, a "personal application"? Is that as opposed to an application installed or used for work-related purposes, or as opposed to an application installed for use by all folks with access to the system?
There are two scenarios that make sense:
- Application stores data on the other end of a network. Requires a net connection; doesn't make sense when you're working from a customer site or from home.
- Application stores data under home directory. File's (or directory's) owner may have permissions set to allow other users to read or write.
Any other scenario requires that an arbitrary, user-invoked application have write access to parts of the hard drive which are not under the user's home directory, which Just Shouldn't Happen. Even in cases (like databases) where files are owned and controlled by a daemon -- that daemon can darned well store its data under a home directory of its own on the encrypted partition; in this way, a daemon should be treated no differently from any other user. Obviously, the application code won't be encrypted -- but this action is in response to high-profile cases of data being lost; I haven't heard any situations from the public sector where there's been a particularly big fuss made about a proprietary binary getting into the wild.
There's a reason that modern versions of Windows have caught up with ancient versions of UNIX in requiring applications to store data under "Documents and Settings\<Username>\Application Data" (~/.<app> in UNIX, of course) when running as non-administrator and preventing access to HKEY_LOCAL_MACHINE (/etc). Doing anything else is stupid: It allows users to step on each others' toes or to change the operation of the system as a whole in a way that can't be reversed simply be wiping their home directory or restoring it from backup. In a security-conscious environment, this just isn't a good situation to have as standard operating procedure.
I'm referring, btw, only to dynamic data -- that which can be created or modified through user's actions. Static data required for a piece of software to operate, loaded at install-time and never modified thereafter typically has no need to be encrypted at all; it can be safely considered part of the software for such purposes. Data loaded at software install time and later user-modified, on the other hand, can have the modifications stored under the user-owned part of the filesystem tree, providing (again) for reversion to initial state simply by wiping the user account. It's the clean, obvious Right Way to do things -- and static data is almost never under the same kind of confidentiality requirements that dynamic data is. (If you're an IRS auditor, the information about the auditee you load before going on-site are dynamic; it thus has its rightful place under your home directory, and thus will be encrypted).
Not a troll. If your system is appropriately configured, you (and your applications) won't be *allowed* to save things anywhere on the local drive other than your home directory. Temp and swap space are also good candidates for encryption -- but putting temp space in a ramdisk and encrypting swap is a pretty reasonable way to do this. Anything other than those should be code, not data -- and thus nonsensitive. Why spend the cycles to encrypt and decrypt without a need to do so?
All that said, I think that giving a contract like this to a commercial vendor developing proprietary software would be... unfortunate. Funding addition of missing, necessary features to TrueCrypt would be a one-time expense (rather than one which scales with the number of systems deployed), and would benefit the private sector as well.
I haven't self-identified as a Christian in many, many years; however, I grew up attending a small-town church governed by a board of elders with very different interpretations of the faith as a whole, and with a wide variety of individuals preaching (if I'd come up with a worthwhile sermon and passed it by the board, I could have gotten up to speak some Sunday myself). If we'd unthinkingly believed everything handed down from the pulpit, we'd have all been schizophrenics; to the contrary, we were actively encouraged to do our own research into the accuracy of the suggested interpretations.
Every other church I've attended to has had the expectation that those in the audience would be unthinking sheep, and it's this disappointment which prevented me from finding another church to associate with in the years immediately since. Just because many Christians treat their faith as requiring unthinking acceptance of their pastor's words as if passed down directly from God himself, however, does not mean that this is or in any way should be representative of religion as a whole.
At least in the US, what you're saying is at odds with the documented intent of those who added the Copyright Clause to the Constitution. Their intent was to encourage creation of new works and inventions -- and by doing so, to benefit the public at large. Do copyright and patent laws benefit artists and inventors? Absolutely. Should they be written with the artists and inventors in mind, as opposed to the wellbeing of the general public? No. The goal, as immortalized in the Constitution (and more extensively documented in Jefferson's notes) is "to promote the arts and sciences" -- a matter of public good -- rather than the private benefit of those who are more immediate beneficiaries.
I think it exceedingly unfortunate that our lawmakers have forgotten this.
In this case, since the individual in question is directly observed by an officer committing trespass (typically a misdemeanor without circumstances causing it to be otherwise), the officer had the ability and authority to arrest the individual -- or at least, would in my state; I don't know about the laws where this occurred. Following said arrest, there's potential for both civil and criminal trespassing charges, charges of resisting arrest, etc.
So, answering your question directly: The appropriate response is forceful ejection and arrest. "Arrest", however, should not mean repeated taserings unless the officer has a reasonable belief that such is necessary for his or her safety -- which is clearly not the case in this situation.
I'm not saying the library as an entity doesn't have the right to eject, and charge with trespassing, anyone who is there in violation of the rules.
"Eject, and charge with trespassing" does not imply tazering.
The point about privacy rights is that the individual in question was making an effort to protect those rights. Can the library choose to eject persons who choose to exercise those rights? Certainly. Again, though, it's no excuse for this level of response.
Well, yes -- but it's a lot easier to believe that you're doing a fine job as it is and simply trust the vendors' claims.
It's been proposed, and even implemented. Not popular with the election officials due to expense and maintenance hassle.
"Auditing of any sort" is one thing. Auditing packaged such that the states' election officials are willing to actually buy it is a different matter.
It's the "ability to audit" thing that's a problem.
I can audit an ATM's accuracy by looking at my bank statement. I can't check whether a voting machine recorded my vote -- unless I use something like the punchscan solution.
I, for one, don't trust this amorphous "us" -- and I do mean amorphous. After all, the Will Of The People changes every election -- and if I did trust the current government with stronger police powers, how would I know I could trust the next one? Freedoms aren't easily reclaimable once revoked, so giving up even the least of them should be done only with the greatest of caution.
The USA was founded by a set of revolutionaries who tried to place strict limits on what their government could do so that it would not become as abusive as the one it was replacing. "Fighting terrorists" is no excuse -- or, at least, a very poor one -- for ripping those protections out.
How many people have been killed by terrorist attacks on US soil in our entire history? Less than are killed by car accidents every month. And you would give up the liberties our forefathers died for... for what?
Ya know, this is one of those cases where intent matters quite a bit, as does notice.
If a developer makes software which is intentionally difficult to uninstall and fails to effectively notify potential users of this property, there are arguably elements of fraud going on. There's also the common-sense test as to whether the license agreement which the user submits to does in fact provide something of value to each party and is not so one-sided as to be innately unreasonable. (There's a specific term, but it's been a looong time since I took B-law).
(I Am, by the way, very much Not A Lawyer).
The WOW strawman is obviously that (or you're unfamiliar with the specs on these things; they're not going to be running WOW). As for your counterproposal, "a chance to see" a computer (or use one in a central location) doesn't have nearly the potential impact of having one's own equipment which one can use for research or communication on a day-to-day basis or tinker with to gain understanding of how it works.
Now, getting more to the point: Communications infrastructure is a core element in having an effective and efficient society, and one part of what these things are about is *communication*. Having an automatic mesh network means that an entire village can benefit from only a single outbound endpoint -- and Internet access is potentially valuable to everyone. Think about farmers tracking the weather (or finding out what the best time will be to haul their crop out to sell), or a family looking up an illness someone has come down with.
Giving away housing and food is a temporary band-aid patch, and does nothing to make those who receive such handouts self-sustaining; giving folks better communications infrastructure (and these laptops, with their low-power mesh networking abilities, are infrastructure and education rolled into one) is a considerably longer-term investment. Folks with better communications infrastructure (and who grew up with access to such) are more likely to be able to do something -other- than toil in fields or Nike factories and create jobs by which others likewise have choices -- and that's a Damned Good Thing.
An investment in a diamond ring may be reasonable, so long as it comes with the right guarantees.
I purchased a diamond engagement ring for my (now-)wife from a jeweler willing to credit the full purchase price towards an upgrade to anything twice as expensive. After the bottom drops out of the diamond market, we'll be able to replace it with something having less transient value.
However, he's a private asshat who spends a lot of time persuading public servants (like the judge in question) to spend their time on his pet issues.
Well -- I'm anxiously awaiting hardware to allow me to run homebrew on my DS so that I can help out a guy who's developing some DS-native tools for learning Lojban. (Actually, helping him out is the whole reason I bought the DS, though Brain Age has turned out to be quite an excellent secondary reason).
Part of the point of doing homebrew is being able to build niche games or apps that no commercial developer would ever fund.
No, that's an example of who is operating under an explicit exemption made by the copyright holder.