(Supposing, for a moment, that I were Canadian and this were to pass...)
So under this plan, I could choose to pay $x/mo; and if I did, I could legally share some content (but how do I know which content?)...
Of course, I already had -- and still have -- the choice to pay for my music as I acquire it, yet I was choosing to share it illegally instead. Why would this be different? Why wouldn't I opt out and take my chances just like I always did?
Maybe I'm sharing $xxx worth of music every month, and while I'm not willing to pay that, I think $x/mo is a pretty good price for protection.
In other words, only heavy utilizers are going to opt-in (or rather, not opt-out). Which means any participating music supplier is offering a de-facto steep discount to these customers. Which means only songs that aren't able to fetch full price are going to be offered. Which means as a music consumer I have that much less incentive to stay in the program, because suddenly my $x/mo isn't buying me what I really want.
Forget it. The whole idea is stupid. You either have to compel everyone (even those who don't want to buy the music) to participate, which is immoral, or the system won't bring in enough money to work.
If you're at a party and someone tells the host you're hitting on his wife, does he have to give you a jury trial before he throws you out?
AT&T is a private company. Access to the service they provide is not a right. All allusions to due process, burden of proof, trial, etc. are off-point in this conversation. Why shouldn't AT&T be able to make the business decision to drop some ISP customers?
If it's disruptive to too many customers, it'll cost them money (at the benefit of their competitors). If it's a money-losing business decision (putting cooperation with the RIAA above profits), perhaps the shareholders can sue.
But meanwhile, you might want to check your contract, because the things they're agreeing to monitor are likely to be against the ToS already.
No, I am not talking about the "danger" of proprietary code. (Actually, I don't consider proprietary code a "danger".)
You could ask how you get someone to use Office, and the answer is "marketing". This is completely different from the answer to "how do you get someone's computer to run malware without them knowing about it" -- that cannot be done by marketing.
The feature RMS is describing opens up a new path by which malware can attack a system. You can acknowledge that risk and design a way to mitigate it, or you can hide behind non-sequiturs to pretend there is no issue. Doesn't really matter to me.
You don't have to upload the client to the bank's site -- if you could do that, you wouldn't need an RMS-compliant browser to stage the attack.
The question is: "how do I (1) put my custom code on your local PC and (2) trick your browser into running it?
The first part (put the code on your system) is the basis of virtually all malware. The second part (trick your browser into running it) is hard today, but easy if the browser specifically facilitates local versions of the client script.
I think it's you who doesn't understand what's being asked for. Think through how it would actually be done.
Are you going to go to the web page, then tell the browser "now switch to this other code"? Probably not; that's a lot of user intervention to run a custom app.
Are you going to enter some modified URL to notify your browser that you want custom code? Again, probably not; web apps that have many pages aren't going to know which URL's to modify when you navigate between them, so your client integration would be awful. Never mind the broken user experience, some apps wouldn't even function properly.
No, what you're going to do is (1) store the modified client on your computer, and (2) give your browser standing orders mapping different web sites to different local client scripts. An attacker need only write to your code repository (and possibly some area that registers code with URL's), and you will end up running a modified client possibly without even knowing it.
"Control over the browser's user interface", whatever that's even supposed to mean, has nothing to do with it.
To your 1st and 3rd points: As I've said previously, we can have a philosophical debate about how software should be written, or we can have a practical discussion about how software is written. I don't care if the reason a client-side customization fails is that the server was poorly coded; if it fails, it fails.
"anyone making modifications knows the risks they're running. They will most likely know or guess any problems they encounter are with their modifications and how to fix it."
Really? Like how people that modified their iPhone software in unsupported ways accepted responsibility for the results of their changes?
You might think you'd react appropriately, and you might be right. If you think "anyone making modifications" will react appropriately, you aren't considering the real environment of web app development and usage.
"Fourth, what to hash is pretty much also what to let the user substitute with his own code. That's an implementation detail and not a big problem."
Then if it's not a big problem, answer the question. Knowing the structure of a web page and the random ways in which code can be embedded, I think it is a big problem.
"Also, are you seriously saying you'd move elements around in the code just for the fun of it, without actually making any other updates?"
No, I don't think that is what I said. Mostly because you inserted an incorrect motive ("for the fun of it") and an incorrect assumption (that the re-ordering of elements has no meaning).
Let's say I'm changing the look-and-feel of a page. I move a control. The control's tag has script embedded in it. The top-down ordering of script commands in the page changes, and so does your hash.
Would I do it? Depends if I have a reason to do it. Does it happen? I'm not willing to bet against it.
It sounds like everyone agrees that they saw the effect they claim, and reported it accurately. People don't agree about the cause.
The disagreement isn't necessarily "nuclear vs. chemical"; at least one guy is saying this may be a low-temperature nuclear effect but not cold fusion.
From a pragmatic standpoint, that might be a matter of semantics. Depends on how a few things fall out. "Well, yes, you can get net postiive energy out of this setup, and it's cheap and clean, but it isn't technically fusion so we were right to rip the cold fusion camp a new one." So then everybody can be happy...
Or maybe the mechanism behind this can't scale to a practical energy source the way people assumed cold fusion would. Or maybe the things it consumes and produces mean that it isn't cheap and clean when you do scale it. Or maybe it will never be net-positive energy output at all.
Understanding the mechanism will hopefully make those things clear.
You seem to be thinking security is the only thing that could break if the client-side code doesn't change when the author expects it to. This assumption is incorrect. Actually security (from the server perspective) is the one thing that should never be compromised (although I still hold that the risk of 3rd-party attacks on the client increases).
It's not about "trusting" the client. It's about knowing the range of client software that might be interactnig with your server, so that the server can respond appropriately to the client. When the server is free to change any aspect of the protocol it wishes, there is no defined interface boundary between it and the client; so the two are effectively one software system. Or you can continue in the blissful belief that all web developers will code for backward-compatibility.
Twice you've said that you think the world is divided into two groups: FS advocates, and people who think they can trust the client in their security model. Then you've shown your biases.
That's one approach to letting the browser know that its version is out of sync. It's not trivial, though.
First of all, you don't see all of the code for a web app when you first load it; you see one page at a time. Consider this sequence of events:
1) I write an app made up of Page A and Page B.
2) Page A has some behavior that doesn't seem to matter, so you modify it.
3) I upgrade the app, making changes to Page B that take advantage of that behavior on Page A. (Apparently that behavior you replaced was groundwork for the feature I've just finished implementing.)
4) You visit the site, and see that the hash of Page A still matches. You run your version. Then you go to Page B, and you see a changed hash so you download the new version... but your session is in a bad state.
Also, even on a page-by-page basis, what do you hash? The entire page, so that even a cosmetic change invalidates your modified client? Or do you have to parse out all of the script code, concatenate it in some way, and hash that (which could still break if I moved elements around in the code)?
The technical implciations are a bit more involved than "modify how the browser loads code".
Right now, a web develoepr can rely on the fact that every visitor to his site is getting an up-to-date copy of the client software. We can have an interesting philosophical debate about whether they should rely on this assumption, or a much more practical one about how many do rely on it.
So I make non-backward-compatible changes to my website, and you run your cached/modified version of the client. Some features don't work. Your browser behaves in ways my server no longer expects. Depending on whether I forsaw this occurance, maybe the effect is harmless (except you're out of luck until you revert to a new download, and then start making your chnages again); or maybe if I was particularly clumsy or just have lousy luck, you corrupt some resource on the server.
We can mitigate the worst problems "merely" by re-educating every web developer everywhere; but realistically we're calling for a client-server handshake so that the server can let the modified client know that it's out of sync (and/or revert to a backward-compatible mode if possible).
Personally I don't see customization of web apps as a pressing need (prior to this article I've never thought about trying it, so clearly it isn't that important to my daily life). So to me, it isn't worth the trouble. YMMV.
True. But my browser makes it hard for your malware to cause me to run your version of the bank's client on their website; GP's point is that under RMS's proposal it wouldn't be as difficult to do that.
It's not about you attacking the bank; it's about you attacking me when I try to use the bank's services.
If its about who needs ad revenue, the FS camp is going to lose. The vast majority of computer users on the Internet are quite happy to use Windows, and even those who primarily use FS are not all die-hards of the FS-or-the-highway mindset.
Yes, if a website won't comply with demands related to software freedom, FS advocates have the option of not using it; I think that understanding was implied in GP's post.
Now, I do have to question how committed you expect people to be to FS ideals. If your bank refuses to GPL the code that runs for their online banking site, are you going to revert to all-paper, or perhaps change banks? Maybe you will; most won't.
It's not a question of whether people intellectually understand how "billion" is related to "million". It's a question of perceptual impact.
Given what we know about how people process information, it is misleading to throw out large numbers without cnotext. The comic summarizes the context in a concise, visual way; a news outlet might instead provide context by pointing out that the bonuses account for ~0.1% of the bailout money in question.
Then if people still want to be angry, at least it's an honest reaction.
So the Roman Empire grew large, and that shows that its electoral system worked? How so? How is the total power accumulated by the government a measure of that government's reflection of the people's will? China has gotten quite powerful; does that mean that their model of government is a working democracy?
BTW, it's a nice rhetorical trick to imply (without quite saying) that the empire fell by replacing open balloting with secret ballot, but I think we both know that isn't what happened.
Now tell me -- did everyone in Rome vote their own mind, or was their pressure (from the politically powerful, from gangs, thugs, and bullies, etc.) that changed how people voted? Do you have enough insight into Roman society to answer that question, or did you merely cherry-pick an ancient example in hopes of skirting the specific issues that were raised?
For extra credit, go have a look at some current examples of what happens when the ballot isn't secret.
IANAQP, though I try from time to time to read up on the subject.
Every time I approach it, I hit the same wall. The math, though complicated and counter-intutive, I can accept. The common interpretations, though... they get a bit rough.
So now we see "if an experimentor's choice of test isn't determined by available information, then the result of the experiment isn't determined by accessible information either", and we interpret that as "if humans have free will, then so do electrons."
Yeah, ok... except QP already predicts that the results of the experiment are not determined by available information. They're freaking random. That's the whole point, no?
This reads to me like a clever ploy by determinists to use rhetorical games of making the true sound absurd, in order to convince the gullable that science can lead to conclusions in abstract philosophy.
I'm not sure how doing away with secret ballot would help, really. You'd still have to trust somebody to audit the millions of datapoints to validate the result.
But ok... the first legitimate purpose of the secret ballot is to make it harder to sell votes. (I won't buy your vote if I can't prove you voted as instructed.) These... er... gentlemen have demonstrated that if you're close enough to the process, you can still buy and sell votes; but I, for example, cannot sell my vote to the coworker across the aisle, because I could never prove to him that I'd deliver on my end of the bargain.
A closely related problem is extortion or intimidation of voters. If a gang in an area wants a particular candidate in power (because, say, he/she is easy on their brand of crime), and the gang can see who voted for which candidate, then those in the area might just feel pressumre to vote for the candidate of their choosing.
You cannot mitigate these problems without controlling the information of who voted for whom. You could make it known to some people but not others, but that tends to invite bribery and also still leaves the information in the hands of someone with power over the voter.
So then you could try a solution where the person who cast a vote can verify how that particular vote was counted. Maybe you could build that up into a fraud-proof system... Except now I'm back in a position to sell my vote, because I have a way to prove to the buyer how I voted. (If I can't prove it to someone else, then me seeing how my vote was counted is useless, because any accusation of fraud I would make would be unprovable as well.) And extortionists are back to having a way to control my vote ("That's a nice house you have there. It'd be a shame if anything happens to it. You should consider voting for Candidate X and proving to me that you did so.")
The solution isn't to get rid of the secret ballot. The solution is to figure out exactly what you think gettnig rid of the secret ballot will do to reduce voter fraud, and find another way to do it.
Well, if we're putting words in each others mouths, then I suppose you prefer a "I should get whatever makes my life easier, no matter how it affects people around me" approach.
Now actually I'm not saying one way is right for everyone. (You're the one who's claiming only one way will work, which is provably false.) I am saying that just because you haven't gone to the trouble of figuring out how to live your life without a car, doesn't create for you a right to drive that trumps the safety of others.
I have lived in places with no public transit. I have worked midnight shifts. Unlike you, I can't buy my way out of an inability to drive for a mere $XX/mo. Quit whining and accept that there are costs to convenience.
Hey, life isn't always convenient. I can't pass the vision test to drive; I don't get to say "yeah, but the public transportation is awful, so let me drive anyway." If you don't meet the requirements to drive (which include having the financial means to carry insurance so others are covered for any harm you might cause), you don't get to drive. It's that simple.
Slashdot Mirror
Yes... and how will you, the individual copyright holder whose rights this plan respects, get paid assuming you don't opt-out?
I'll bet you won't. I'll bet this doesn't respect your ownership of copyright at all.
(Supposing, for a moment, that I were Canadian and this were to pass...)
So under this plan, I could choose to pay $x/mo; and if I did, I could legally share some content (but how do I know which content?)...
Of course, I already had -- and still have -- the choice to pay for my music as I acquire it, yet I was choosing to share it illegally instead. Why would this be different? Why wouldn't I opt out and take my chances just like I always did?
Maybe I'm sharing $xxx worth of music every month, and while I'm not willing to pay that, I think $x/mo is a pretty good price for protection.
In other words, only heavy utilizers are going to opt-in (or rather, not opt-out). Which means any participating music supplier is offering a de-facto steep discount to these customers. Which means only songs that aren't able to fetch full price are going to be offered. Which means as a music consumer I have that much less incentive to stay in the program, because suddenly my $x/mo isn't buying me what I really want.
Forget it. The whole idea is stupid. You either have to compel everyone (even those who don't want to buy the music) to participate, which is immoral, or the system won't bring in enough money to work.
If you're at a party and someone tells the host you're hitting on his wife, does he have to give you a jury trial before he throws you out?
AT&T is a private company. Access to the service they provide is not a right. All allusions to due process, burden of proof, trial, etc. are off-point in this conversation. Why shouldn't AT&T be able to make the business decision to drop some ISP customers?
If it's disruptive to too many customers, it'll cost them money (at the benefit of their competitors). If it's a money-losing business decision (putting cooperation with the RIAA above profits), perhaps the shareholders can sue.
But meanwhile, you might want to check your contract, because the things they're agreeing to monitor are likely to be against the ToS already.
No, I am not talking about the "danger" of proprietary code. (Actually, I don't consider proprietary code a "danger".)
You could ask how you get someone to use Office, and the answer is "marketing". This is completely different from the answer to "how do you get someone's computer to run malware without them knowing about it" -- that cannot be done by marketing.
The feature RMS is describing opens up a new path by which malware can attack a system. You can acknowledge that risk and design a way to mitigate it, or you can hide behind non-sequiturs to pretend there is no issue. Doesn't really matter to me.
Running a red is a moving violation.
In most places that use them, these cameras issue non-moving citations. That's how they get around proving who was driving.
So it's not realistic to say you get the penalty for running a red. Really they've created an entirely separate offense.
Again, this is not an attack on the bank.
You don't have to upload the client to the bank's site -- if you could do that, you wouldn't need an RMS-compliant browser to stage the attack.
The question is: "how do I (1) put my custom code on your local PC and (2) trick your browser into running it?
The first part (put the code on your system) is the basis of virtually all malware. The second part (trick your browser into running it) is hard today, but easy if the browser specifically facilitates local versions of the client script.
If there's any file on your system I can change, then there are no files on your system I can't change?
Your security model isn't very good.
I think it's you who doesn't understand what's being asked for. Think through how it would actually be done.
Are you going to go to the web page, then tell the browser "now switch to this other code"? Probably not; that's a lot of user intervention to run a custom app.
Are you going to enter some modified URL to notify your browser that you want custom code? Again, probably not; web apps that have many pages aren't going to know which URL's to modify when you navigate between them, so your client integration would be awful. Never mind the broken user experience, some apps wouldn't even function properly.
No, what you're going to do is (1) store the modified client on your computer, and (2) give your browser standing orders mapping different web sites to different local client scripts. An attacker need only write to your code repository (and possibly some area that registers code with URL's), and you will end up running a modified client possibly without even knowing it.
"Control over the browser's user interface", whatever that's even supposed to mean, has nothing to do with it.
To your 1st and 3rd points: As I've said previously, we can have a philosophical debate about how software should be written, or we can have a practical discussion about how software is written. I don't care if the reason a client-side customization fails is that the server was poorly coded; if it fails, it fails.
"anyone making modifications knows the risks they're running. They will most likely know or guess any problems they encounter are with their modifications and how to fix it."
Really? Like how people that modified their iPhone software in unsupported ways accepted responsibility for the results of their changes?
You might think you'd react appropriately, and you might be right. If you think "anyone making modifications" will react appropriately, you aren't considering the real environment of web app development and usage.
"Fourth, what to hash is pretty much also what to let the user substitute with his own code. That's an implementation detail and not a big problem."
Then if it's not a big problem, answer the question. Knowing the structure of a web page and the random ways in which code can be embedded, I think it is a big problem.
"Also, are you seriously saying you'd move elements around in the code just for the fun of it, without actually making any other updates?"
No, I don't think that is what I said. Mostly because you inserted an incorrect motive ("for the fun of it") and an incorrect assumption (that the re-ordering of elements has no meaning).
Let's say I'm changing the look-and-feel of a page. I move a control. The control's tag has script embedded in it. The top-down ordering of script commands in the page changes, and so does your hash.
Would I do it? Depends if I have a reason to do it. Does it happen? I'm not willing to bet against it.
1) Cold is a relative term. Think more in terms of "not as hot as the Sun"
2) The term "cold fusion" describes the input conditions; it doesn't mean you wouldn't harness the output energy as heat. I'd have to guess you would.
It sounds like everyone agrees that they saw the effect they claim, and reported it accurately. People don't agree about the cause.
The disagreement isn't necessarily "nuclear vs. chemical"; at least one guy is saying this may be a low-temperature nuclear effect but not cold fusion.
From a pragmatic standpoint, that might be a matter of semantics. Depends on how a few things fall out. "Well, yes, you can get net postiive energy out of this setup, and it's cheap and clean, but it isn't technically fusion so we were right to rip the cold fusion camp a new one." So then everybody can be happy...
Or maybe the mechanism behind this can't scale to a practical energy source the way people assumed cold fusion would. Or maybe the things it consumes and produces mean that it isn't cheap and clean when you do scale it. Or maybe it will never be net-positive energy output at all.
Understanding the mechanism will hopefully make those things clear.
You seem to be thinking security is the only thing that could break if the client-side code doesn't change when the author expects it to. This assumption is incorrect. Actually security (from the server perspective) is the one thing that should never be compromised (although I still hold that the risk of 3rd-party attacks on the client increases).
It's not about "trusting" the client. It's about knowing the range of client software that might be interactnig with your server, so that the server can respond appropriately to the client. When the server is free to change any aspect of the protocol it wishes, there is no defined interface boundary between it and the client; so the two are effectively one software system. Or you can continue in the blissful belief that all web developers will code for backward-compatibility.
Twice you've said that you think the world is divided into two groups: FS advocates, and people who think they can trust the client in their security model. Then you've shown your biases.
That's one approach to letting the browser know that its version is out of sync. It's not trivial, though.
First of all, you don't see all of the code for a web app when you first load it; you see one page at a time. Consider this sequence of events:
1) I write an app made up of Page A and Page B.
2) Page A has some behavior that doesn't seem to matter, so you modify it.
3) I upgrade the app, making changes to Page B that take advantage of that behavior on Page A. (Apparently that behavior you replaced was groundwork for the feature I've just finished implementing.)
4) You visit the site, and see that the hash of Page A still matches. You run your version. Then you go to Page B, and you see a changed hash so you download the new version... but your session is in a bad state.
Also, even on a page-by-page basis, what do you hash? The entire page, so that even a cosmetic change invalidates your modified client? Or do you have to parse out all of the script code, concatenate it in some way, and hash that (which could still break if I moved elements around in the code)?
The technical implciations are a bit more involved than "modify how the browser loads code".
Right now, a web develoepr can rely on the fact that every visitor to his site is getting an up-to-date copy of the client software. We can have an interesting philosophical debate about whether they should rely on this assumption, or a much more practical one about how many do rely on it.
So I make non-backward-compatible changes to my website, and you run your cached/modified version of the client. Some features don't work. Your browser behaves in ways my server no longer expects. Depending on whether I forsaw this occurance, maybe the effect is harmless (except you're out of luck until you revert to a new download, and then start making your chnages again); or maybe if I was particularly clumsy or just have lousy luck, you corrupt some resource on the server.
We can mitigate the worst problems "merely" by re-educating every web developer everywhere; but realistically we're calling for a client-server handshake so that the server can let the modified client know that it's out of sync (and/or revert to a backward-compatible mode if possible).
Personally I don't see customization of web apps as a pressing need (prior to this article I've never thought about trying it, so clearly it isn't that important to my daily life). So to me, it isn't worth the trouble. YMMV.
True. But my browser makes it hard for your malware to cause me to run your version of the bank's client on their website; GP's point is that under RMS's proposal it wouldn't be as difficult to do that.
It's not about you attacking the bank; it's about you attacking me when I try to use the bank's services.
If its about who needs ad revenue, the FS camp is going to lose. The vast majority of computer users on the Internet are quite happy to use Windows, and even those who primarily use FS are not all die-hards of the FS-or-the-highway mindset.
Yes, if a website won't comply with demands related to software freedom, FS advocates have the option of not using it; I think that understanding was implied in GP's post.
Now, I do have to question how committed you expect people to be to FS ideals. If your bank refuses to GPL the code that runs for their online banking site, are you going to revert to all-paper, or perhaps change banks? Maybe you will; most won't.
It's not a question of whether people intellectually understand how "billion" is related to "million". It's a question of perceptual impact.
Given what we know about how people process information, it is misleading to throw out large numbers without cnotext. The comic summarizes the context in a concise, visual way; a news outlet might instead provide context by pointing out that the bonuses account for ~0.1% of the bailout money in question.
Then if people still want to be angry, at least it's an honest reaction.
So the Roman Empire grew large, and that shows that its electoral system worked? How so? How is the total power accumulated by the government a measure of that government's reflection of the people's will? China has gotten quite powerful; does that mean that their model of government is a working democracy?
BTW, it's a nice rhetorical trick to imply (without quite saying) that the empire fell by replacing open balloting with secret ballot, but I think we both know that isn't what happened.
Now tell me -- did everyone in Rome vote their own mind, or was their pressure (from the politically powerful, from gangs, thugs, and bullies, etc.) that changed how people voted? Do you have enough insight into Roman society to answer that question, or did you merely cherry-pick an ancient example in hopes of skirting the specific issues that were raised?
For extra credit, go have a look at some current examples of what happens when the ballot isn't secret.
What do you mean, you can't ignore it? Of course you can. Patents aren't like trademarks, if that's what you're thinking...
IANAQP, though I try from time to time to read up on the subject.
Every time I approach it, I hit the same wall. The math, though complicated and counter-intutive, I can accept. The common interpretations, though... they get a bit rough.
So now we see "if an experimentor's choice of test isn't determined by available information, then the result of the experiment isn't determined by accessible information either", and we interpret that as "if humans have free will, then so do electrons."
Yeah, ok... except QP already predicts that the results of the experiment are not determined by available information. They're freaking random. That's the whole point, no?
This reads to me like a clever ploy by determinists to use rhetorical games of making the true sound absurd, in order to convince the gullable that science can lead to conclusions in abstract philosophy.
I'm not sure how doing away with secret ballot would help, really. You'd still have to trust somebody to audit the millions of datapoints to validate the result.
But ok... the first legitimate purpose of the secret ballot is to make it harder to sell votes. (I won't buy your vote if I can't prove you voted as instructed.) These... er... gentlemen have demonstrated that if you're close enough to the process, you can still buy and sell votes; but I, for example, cannot sell my vote to the coworker across the aisle, because I could never prove to him that I'd deliver on my end of the bargain.
A closely related problem is extortion or intimidation of voters. If a gang in an area wants a particular candidate in power (because, say, he/she is easy on their brand of crime), and the gang can see who voted for which candidate, then those in the area might just feel pressumre to vote for the candidate of their choosing.
You cannot mitigate these problems without controlling the information of who voted for whom. You could make it known to some people but not others, but that tends to invite bribery and also still leaves the information in the hands of someone with power over the voter.
So then you could try a solution where the person who cast a vote can verify how that particular vote was counted. Maybe you could build that up into a fraud-proof system... Except now I'm back in a position to sell my vote, because I have a way to prove to the buyer how I voted. (If I can't prove it to someone else, then me seeing how my vote was counted is useless, because any accusation of fraud I would make would be unprovable as well.) And extortionists are back to having a way to control my vote ("That's a nice house you have there. It'd be a shame if anything happens to it. You should consider voting for Candidate X and proving to me that you did so.")
The solution isn't to get rid of the secret ballot. The solution is to figure out exactly what you think gettnig rid of the secret ballot will do to reduce voter fraud, and find another way to do it.
Well, if we're putting words in each others mouths, then I suppose you prefer a "I should get whatever makes my life easier, no matter how it affects people around me" approach.
Now actually I'm not saying one way is right for everyone. (You're the one who's claiming only one way will work, which is provably false.) I am saying that just because you haven't gone to the trouble of figuring out how to live your life without a car, doesn't create for you a right to drive that trumps the safety of others.
I have lived in places with no public transit. I have worked midnight shifts. Unlike you, I can't buy my way out of an inability to drive for a mere $XX/mo. Quit whining and accept that there are costs to convenience.
And yet somehow countless people without cars do get to class/work. When you say you "can't", you mean you don't want to go to the trouble.
Hey, life isn't always convenient. I can't pass the vision test to drive; I don't get to say "yeah, but the public transportation is awful, so let me drive anyway." If you don't meet the requirements to drive (which include having the financial means to carry insurance so others are covered for any harm you might cause), you don't get to drive. It's that simple.
Yeah... too bad the blacklist is enforced administratively rather than by filtering, so your spider would see everything as "available".
And, I really don't think you grasp the scope of "every URL on the internet".