Physical attributes of the reader. It needs to be about the same size as a medium-thickness paperback book, big enough to have good display area but small enough to be conveniently carried. It needs to be tough enough that I can throw it in a backpack and otherwise treat it roughly the same as I'd treat a book without overmuch damage (dings in the case are OK, damage to the display isn't). The screen needs to be large enough and have a high enough contrast to hold a page of text and still be readable. The screen has to be readable outside in bright sunlight, while still ideally being readable in a dim room indoors. It's got to have enough battery life that I don't have to constantly worry about where I'm going to recharge it, and enough storage capacity to hold everything I'm going to want to read over the course of a couple of days.
Attributes of the content. Content needs to not just be available, it's got to be available in forms that let me do what I normally do with books. I've got to be able to move it around from device to device, much the same way I can move a book around to wherever I want it at the moment. I've got to be able to back it up so failure or loss of the device holding it at the moment doesn't also mean loss of the content. And it should be manipulable, I want to be able to put it in whatever form I need to to do whatever I want to do with it. If it's electronic data, I want to be able to treat it as electronic data for purposes of searching, modifying and the like. I can add margin notes and highlighting to a physical book, I should be able to do the same with an electronic one. Or, if the electronic form's going to be severely limited to where all I can do is read it, it needs to be significantly cheaper than a physical book or I'd frankly be better off buying the physical book instead.
My right to make backup copies of material I own. Most DRM prohibits or severely limits this. Copyright law places no limits on the number of additional copies I can make for personal use (other than requiring that if I transfer any copy I have to transfer or destroy all other copies).
My right to convert material I own a copy of into other forms. The canonical example was taking a record and dubbing it onto a cassette tape to play in a car stereo.
My right to time-shift over-the-air broadcasts. This hasn't actually happened yet, but they're trying mightily to get the Broadcast Flag implemented.
The right of teachers to make multiple copies for use in the classroom.
And yes, all of those things are explicitly legal. For example, see USC Title 17 Section 107 regarding the last one: "Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phonorecords or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright.". The legality of time-shifting was declared in Sony Corp. of America v. Universal City Studios, Inc. 464 U.S. 417, decided by the Supreme Court in 1976 and hasn't been disturbed since.
And no, the DMCA doesn't change this. To quote USC Title 17 Section 1201: "(c)(1) Nothing in this section shall affect rights, remedies, limitations, or defenses to copyright infringement, including fair use, under this title.". IOW, the DMCA explicitly says that if a limitation on a claim of infringement or a defense against such a claim exists without the DMCA, including a defense of fair use, it's unaffected by the DMCA. Since this is in the section on circumvention of technological protection measures, it would be odd for that language to not apply to circumvention of technological protection measures.
As for the P2P users squirreling away stuff in violation of copyright, I'd have to agree with you: just because those users want it for free doesn't obligate anyone to let them have it for free. If they want a copy, go buy a copy.
However, I then have to turn around and make a similar statement about the music labels and movie studios. What they want with DRM goes beyond what's written in copyright law. They want to impose restrictions on things that copyright law says copy owners can legally do, and they want to give the enforcement of those restrictions the force of law without actually changing copyright law. Just because they'd like that doesn't mean we have to give it to them either. If they want restrictions beyond what the law specifies, negotiate a contract with each and every buyer before accepting their money and delivering the product. If they don't want to negotiate an explicit contract every time, live with what the law says. And they can stop complaining that P2P software can be used to violate their copyrights. Their DRM can be used to violate the rights of copy owners too. If P2P should be outlawed because it can be used in violation of the law then DRM has to be outlawed for exactly the same reason.
I think the objection many GPL objectors have isn't that you're giving it away, but that you're demanding that they pay back in kind if they want to benefit in certain ways from what you gave away. They'd rather you gave them stuff without asking anything from them in return. They're certainly entitled to want stuff without any strings attached, but we aren't obligated to give it to them just because they want it.
No, the rules aren't retarded. Suppose a pension fund is set up to mirror the S&P 500. That fund then must buy exactly the stocks that make up the S&P 500 in exactly the same proportions. This should cause the fund's value to exactly mirror the movement of the S&P 500. This means, though, that if they don't like Google's policies but Google's stock is part of the S&P 500, they have to buy Google's stock anyway to keep the fund mirroring the index.
The lockdown doesn't work quite that way. No proof of identity is required to remove the lockdown (normally, at least). What is required is a specific code that's given out when the freeze is put in place and only to the party requesting the freeze. If the request for a report's accompanied by that code the report will be issued, otherwise the request is refused. Makes it very hard for an impersonator to override a freeze unless they were the ones who placed it, since if they didn't they wouldn't have gotten the code.
And yes, there's procedures for dealing with false freezes. They aren't trivial because it's supposed to be hard for an impersonater to remove a freeze, but an attempted DoS on your credit report can be dealt with.
I've said it before, and I'll say it again: what the article speaks of won't help. Even if it's implemented perfectly and is utterly mathematically secure, it won't stop identity theft. That's because it doesn't address the largest hole in the system, the way most identity thieves steal your identity: authenticating the organization the user wants to talk to to the user. It doesn't matter how securely I can prove who I am to my bank, if Mister X out there can impersonate my bank to me he doesn't have to steal my credentials because I'll be giving them to him voluntarily (if unknowingly). The only way to stop this is for the bank to prove to me who it is before asking me to prove who I am.
This isn't even new. It's been long known that you don't trust the other end when they initiated the communication. If someone calls up saying you're late on your electric bill but if you want they can do a check over the phone if you'll just give them your bank account information, common wisdom is that you take note of this, hang up the phone, call the number on your electric bill for the power company's billing department and talk to them. You do that so that you know that you're in fact talking to the real power company before handing over details to them. Same thing for bills in the mail, if out of the blue you receive a bill saying you owe $BIGNUM on your car loan immediately and please send the check in the enclosed return envelope, you don't blindly use it until you've made sure it's to the same address as your regular loan-payment envelopes and you've confirmed with the lender that the bill's for real.
So why, when it comes to identity and security, is all the emphasis in electronic transactions on authenticating the user to the organization when in real life the first thing in a similar transaction is to authenticate the organization to the user?
First thing you need to do is talk to a lawyer specializing in IP and patents. The company's very likely to try legal action against you if you release your driver, and you're going to need legal advice and help to deal with them. A couple of questions:
Did you sign an agreement prohibiting reverse-engineering before they accepted your money? Unlikely, but if you did you're probably SOL.
Did you click the "I Agree" button on an EULA prohibiting reverse-engineering? If you did, you really need a second lawyer, one specializing in the Uniform Commercial Code and dealing with vendors who attempt to prevent your use of a product after payment's been accepted and delivery taken. The only way to win against an EULA-based argument from the company would be to recast the whole thing as not an EULA issue, but one of the vendor attempting through the EULA to change the terms of a UCC default contract of sale after the fact.
If you didn't sign any agreement and weren't presented with an EULA and can provide evidence of both, then you can probably beat them if you're willing to spend the money fighting them. Note that you'll still be out the money, and recovering it is a whole 'nother matter.
Any patent, if and when issued, is more difficult to get around than the reverse-engineering portion. It depends heavily on exactly what they've patented, when they applied for the patent and when the application was published. This is why you need a lawyer who specializes in patent law.
The main point above is that you're in for legal flack even if you're completely in the clear, so talk to a lawyer first.
However worms, viruses and Trojans are designed to do their thing either without informing the user or without the user being able to stop them. Google Desktop, by contrast, tells the user exactly what it's going to do and requires that the user go out and obtain it and install it themselves.
The problem with Google Desktop isn't the software or it's design. It's the same problem as with the worker who loads corporate information onto his laptop so he can take it with him to the local coffeeshop and work while enjoying a cup of coffee and their free wireless access: corporate policy says you don't take corporate data off the corporate network. In both cases, what we have is a user who's oblivious to corporate policy and is acting as if what they were doing had no consequences for corporate data.
Agreed. For a large percentage of employees there's no need to install software period. For them an X-terminal (no local storage) or X-server-only PC with all actual software on a central server would do fine. Put home directories on a filesystem mounted noexec, don't put $HOME in their default path and don't give them a shell from their normal desktop icons/menus and it's going to take a fairly persistent and knowledgeable employee to get around the barriers and install anything unauthorized (at which point you have enough evidence that they knowingly and deliberately circumvented corporate policies that you can skip right to the pink-slip-and-final-paycheck stage, pour discourager les autres).
Google Desktop is doing what it's designed to do: keep user's data on central servers so it's accessible from anywhere. It's just that it makes the assumption that all of the computer belongs to the user. Obviously in a corporate environment that's not the case, but Google Desktop doesn't know what kind of computer it's on so it can't do anything about that. The company needs to be more emphatic about the "no unauthorized software" rule (they do have a "no unauthorized software" rule, don't they?).
There's one problem in Bush's analysis. If all the manufacturing is in India, China and the like, and all the product support is outsourced to the same places, and all the consumers are in those places, then why precisely should those consumers go to an American company to buy locally-made goods and services?
OSS needs big business to be successful? Oh, then I guess that Linux thing can't have become a huge success, then. And Apache, that can't have been successful as a Web server. And Sendmail couldn't be a very successful MTA. What? All of those are successful? How odd.:)
I think the "open-source needs big business" is wishful thinking on the part of big business. They depend heavily on open-source software for critical things, and to admit that it could be successful without them would invalidate too many of the assumptions their world's based on.
If one company chooses to levy a fee for access, does it not follow that consumers would rationally choose to switch to another company, or accept the fee? The idea that the government might pass a law outlawing what should be a simple business policy is frightening.
It ought to follow, but it doesn't. It doesn't follow because most of those companies wanting to levy fees for preferred treatment of traffic also have a government-granted monopoly on service in their area. Telcos and cable companies operate under agreements which prohibit competitors from installing physical wiring, and they've successfully lobbied for rules which let them prevent competitors from using their wiring even if those competitors are willing to pay for the access. Where I live, this means I have exactly three choices for Internet access: Cox Cable, PacBell DSL, or dial-up (over either a Cox or SBC phone line). If Cox and PacBell decide to start charging premiums, I can't switch to an alternative cable-internet or DSL provider because none are allowed to serve me.
This sounds like a basic one-time password device (SecurID or similar) using sound to transmit the password. Everything except those portions of claims referring to the transmission mechanism should be attackable based on that prior art, and that doesn't leave much to attack on grounds of obviousness.
There's one big difference: with snail-mail the sender is paying the freight with the postage they have to put on the item to send it to me. If they're paying, they can do what they want. But as I also noted earlier, you (ie. the people sending spam) aren't paying for their use of my mailbox and they're not asking permission to use it. It's the same as someone sending me snail-mail postage due and claiming their right to free speech gives them the right to do that. Sorry, but no.
Your living room is your property. My e-mail inbox is my property. If you have a right to use my property for your free speech, I (or any political group) have just as much of a right to use your property for my free speech. If you can "speak" using e-mail without using my inbox without payment or permission, feel free. If you're going to eat up resources I have to pay for, though, I'll be happy to quote you my rates.
Free speech may be more important than an inbox but what you're demanding isn't free speech, it's the right to commandeer other people's property in pursuit of your political agenda.
I no more invited trespass by having an e-mail inbox than I invite trespass of my house by having my house number and my name on a sign by the street. If I don't ask someone to speak to me, I've given no invitation to them.
It's not a matter of inbox clutter. It's a matter of the companion right to your right to speak: my right to not listen. If you want to pontificate on a street corner that's fine, but the right to do that doesn't give you the right to grab and detain people to make them listen. If you want to give a speech that's fine, but the right to give that speech doesn't give you the right to commandeer someone's hall to speak in without their permission and without paying them. Your right to say what you want doesn't grant you a right to come onto my front lawn to make your statement.
Or should I schedule the next meeting of <insert offensive-to-you political group here> in your living room? After all, some things are more important than convenience, and making political speech, even if it is annoying, illegal is a very bad idea.:)
Except that anti-spam laws aren't a free-speech matter. Free speech means your right to say what you want. It does not mean your right to use my hall without my permission to say what you want, nor does it mean your right to demand that I listen to you. If you're paying for the venue/publication, or you're using public property, then talk away all you want. But I don't see you paying my ISP subscription and my e-mail inbox (which is part of that subscription) isn't public property, and the First Amendment doesn't apply to your use of them without permission and without paying.
Because the Chinese government isn't inclined to look the other way. Their Great Firewall operates on a "default deny" principle (or it can be made to trivially): block everything except government-approved data. Were I in charge of this for the Chinese government (I wouldn't be because I'm adamantly against it, but imagine I was) it wouldn't be that hard for me to block everything to Google's netblocks and all traffic that didn't look like approved protocols (regardless of port) to approved destinations. I'd have to buy a fair amount of hardware to do it, but if I had a government's checkbook behind me I could do it. If I can do it, I seriously doubt the Chinese government's ruled it out as an option. So if Google did release such an application, they'd find themselves locked out of China completely and the Chinese people locked in even more thoroughly than they are now.
Anti-censorship tricks only work decently when your opponent's willing to allow a sizeable amount of traffic they can't recognize. If they're willing to block anything they don't recognize, whether or not it's really legitimate, you're SOL.
I've had mixed results with standardizing on a language. All too often it's done purely for the sake of standardizing, with no thought to anything else. Programming languages are tools, and ones being used by a team not just one person. You want to minimize the number of variations in your tools so people don't have to worry about needless vagaries from one tool to another. At the same time, you don't want to standardize so far that you eliminate entire kinds of tools and end up doing the equivalent of trying to use a rock as a hammer because your shop's standardized on screwdrivers and screws for holding things together and so doesn't have hammers (the programming equivalent would be trying to do simple scripting jobs, that'd be 5 lines in Perl or bash, in C++ because that's the language your shop standardized on).
The only times I've seen standardizing languages work is when the first step was to not standardize. The first step in a successful standardization effort will be to ignore languages and instead take stock of what kinds of programs you need to write. Include all those little one-off jobs that you have to do several of every week, eg. the little hack to extract the error messages you're interested in from the logfile. Then, for each kind of program, look at the languages suited to writing that kind of program and see what one your developers are most comfortable with and, just as importantly, what your existing code is written in. An inferior langauge that all your developers know well is superior to a superior language that they're not familiar with, and if you've a large body of code in one language then that language is better than a different language. If several kinds of programs can be served sufficiently well by one language, well and good. If not, well and good too. The goal is to simplify getting the job done, not hamstring yourself with rules not related to getting the job done.
In the Unix world, normally I expect at least 4 standard languages. You'll have shell script (typically sh because so many other tools expect it, but csh is possible), make (because every development environment typically depends on make at some point), another scripting language (Perl, Python, Ruby, etc.) and a "real" programming language (commonly C, C++ or Java, add VB and C# in a Windows environment, others are possible).
Many are stopping, hence the screeches from companies.:)
My person rule about security-related bugs is that I'll give a company 1 month (30 days) from being notified to either a) release a fix, b) disclose the problem and any existing workarounds to the public, or c) get back to me with a really good reason why it's not possible to do either A or B (and "It'll embarrass us." is not a good reason). If there's evidence the problem's already being exploited (real exploits affecting computers at large, not proof-of-concept stuff) then disclosure will happen immediately to within a few days depending on whether there's a functional work-around and how willing the company seems to be to work on a rapid disclosure (theory here being that if the black hats are already using the vulnerability disclosure won't make the situation worse).
Many are stopping, hence the screeches from companies.:)
My person rule about security-related bugs is that I'll give a company 1 month (30 days) from being notified to either a) release a fix, b) disclose the problem and any existing workarounds to the public, or c) get back to me with a really good reason why it's not possible to do either A or B (and "It'll embarrass us." is not
If Oracle can't fix the problem in 3 months, at least they could inform their own customers so they could take protective measures of their own. That Oracle could do inside of 3 months no matter how complex the bug is to finally fix.
Litchfield is putting Oracle's customers at risk? I don't think so. Oracle put their customers at risk, Litchfield merely told those customers they were at risk and in what way. He gave Oracle 3 months to either fix the problem or inform their customers, Oracle did neither, I'd say the problem's all of Oracle's making. If they'd placed their customer's security over their own PR in a reasonable timeframe, Litchfield wouldn't have had to embarrass them this way.
Another example of why "reasonable disclosure" doesn't work well.
Slashdot Mirror
To me it boils down to two areas:
Physical attributes of the reader. It needs to be about the same size as a medium-thickness paperback book, big enough to have good display area but small enough to be conveniently carried. It needs to be tough enough that I can throw it in a backpack and otherwise treat it roughly the same as I'd treat a book without overmuch damage (dings in the case are OK, damage to the display isn't). The screen needs to be large enough and have a high enough contrast to hold a page of text and still be readable. The screen has to be readable outside in bright sunlight, while still ideally being readable in a dim room indoors. It's got to have enough battery life that I don't have to constantly worry about where I'm going to recharge it, and enough storage capacity to hold everything I'm going to want to read over the course of a couple of days.
Attributes of the content. Content needs to not just be available, it's got to be available in forms that let me do what I normally do with books. I've got to be able to move it around from device to device, much the same way I can move a book around to wherever I want it at the moment. I've got to be able to back it up so failure or loss of the device holding it at the moment doesn't also mean loss of the content. And it should be manipulable, I want to be able to put it in whatever form I need to to do whatever I want to do with it. If it's electronic data, I want to be able to treat it as electronic data for purposes of searching, modifying and the like. I can add margin notes and highlighting to a physical book, I should be able to do the same with an electronic one. Or, if the electronic form's going to be severely limited to where all I can do is read it, it needs to be significantly cheaper than a physical book or I'd frankly be better off buying the physical book instead.
And yes, all of those things are explicitly legal. For example, see USC Title 17 Section 107 regarding the last one: "Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phonorecords or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright.". The legality of time-shifting was declared in Sony Corp. of America v. Universal City Studios, Inc. 464 U.S. 417, decided by the Supreme Court in 1976 and hasn't been disturbed since.
And no, the DMCA doesn't change this. To quote USC Title 17 Section 1201: "(c)(1) Nothing in this section shall affect rights, remedies, limitations, or defenses to copyright infringement, including fair use, under this title.". IOW, the DMCA explicitly says that if a limitation on a claim of infringement or a defense against such a claim exists without the DMCA, including a defense of fair use, it's unaffected by the DMCA. Since this is in the section on circumvention of technological protection measures, it would be odd for that language to not apply to circumvention of technological protection measures.
As for the P2P users squirreling away stuff in violation of copyright, I'd have to agree with you: just because those users want it for free doesn't obligate anyone to let them have it for free. If they want a copy, go buy a copy.
However, I then have to turn around and make a similar statement about the music labels and movie studios. What they want with DRM goes beyond what's written in copyright law. They want to impose restrictions on things that copyright law says copy owners can legally do, and they want to give the enforcement of those restrictions the force of law without actually changing copyright law. Just because they'd like that doesn't mean we have to give it to them either. If they want restrictions beyond what the law specifies, negotiate a contract with each and every buyer before accepting their money and delivering the product. If they don't want to negotiate an explicit contract every time, live with what the law says. And they can stop complaining that P2P software can be used to violate their copyrights. Their DRM can be used to violate the rights of copy owners too. If P2P should be outlawed because it can be used in violation of the law then DRM has to be outlawed for exactly the same reason.
If you want the straight dope, look at the draft GPL V3 language and accompanying commentary/elaborations.
I think the objection many GPL objectors have isn't that you're giving it away, but that you're demanding that they pay back in kind if they want to benefit in certain ways from what you gave away. They'd rather you gave them stuff without asking anything from them in return. They're certainly entitled to want stuff without any strings attached, but we aren't obligated to give it to them just because they want it.
No, the rules aren't retarded. Suppose a pension fund is set up to mirror the S&P 500. That fund then must buy exactly the stocks that make up the S&P 500 in exactly the same proportions. This should cause the fund's value to exactly mirror the movement of the S&P 500. This means, though, that if they don't like Google's policies but Google's stock is part of the S&P 500, they have to buy Google's stock anyway to keep the fund mirroring the index.
The lockdown doesn't work quite that way. No proof of identity is required to remove the lockdown (normally, at least). What is required is a specific code that's given out when the freeze is put in place and only to the party requesting the freeze. If the request for a report's accompanied by that code the report will be issued, otherwise the request is refused. Makes it very hard for an impersonator to override a freeze unless they were the ones who placed it, since if they didn't they wouldn't have gotten the code.
And yes, there's procedures for dealing with false freezes. They aren't trivial because it's supposed to be hard for an impersonater to remove a freeze, but an attempted DoS on your credit report can be dealt with.
I've said it before, and I'll say it again: what the article speaks of won't help. Even if it's implemented perfectly and is utterly mathematically secure, it won't stop identity theft. That's because it doesn't address the largest hole in the system, the way most identity thieves steal your identity: authenticating the organization the user wants to talk to to the user. It doesn't matter how securely I can prove who I am to my bank, if Mister X out there can impersonate my bank to me he doesn't have to steal my credentials because I'll be giving them to him voluntarily (if unknowingly). The only way to stop this is for the bank to prove to me who it is before asking me to prove who I am.
This isn't even new. It's been long known that you don't trust the other end when they initiated the communication. If someone calls up saying you're late on your electric bill but if you want they can do a check over the phone if you'll just give them your bank account information, common wisdom is that you take note of this, hang up the phone, call the number on your electric bill for the power company's billing department and talk to them. You do that so that you know that you're in fact talking to the real power company before handing over details to them. Same thing for bills in the mail, if out of the blue you receive a bill saying you owe $BIGNUM on your car loan immediately and please send the check in the enclosed return envelope, you don't blindly use it until you've made sure it's to the same address as your regular loan-payment envelopes and you've confirmed with the lender that the bill's for real.
So why, when it comes to identity and security, is all the emphasis in electronic transactions on authenticating the user to the organization when in real life the first thing in a similar transaction is to authenticate the organization to the user?
First thing you need to do is talk to a lawyer specializing in IP and patents. The company's very likely to try legal action against you if you release your driver, and you're going to need legal advice and help to deal with them. A couple of questions:
The main point above is that you're in for legal flack even if you're completely in the clear, so talk to a lawyer first.
However worms, viruses and Trojans are designed to do their thing either without informing the user or without the user being able to stop them. Google Desktop, by contrast, tells the user exactly what it's going to do and requires that the user go out and obtain it and install it themselves. The problem with Google Desktop isn't the software or it's design. It's the same problem as with the worker who loads corporate information onto his laptop so he can take it with him to the local coffeeshop and work while enjoying a cup of coffee and their free wireless access: corporate policy says you don't take corporate data off the corporate network. In both cases, what we have is a user who's oblivious to corporate policy and is acting as if what they were doing had no consequences for corporate data.
Agreed. For a large percentage of employees there's no need to install software period. For them an X-terminal (no local storage) or X-server-only PC with all actual software on a central server would do fine. Put home directories on a filesystem mounted noexec, don't put $HOME in their default path and don't give them a shell from their normal desktop icons/menus and it's going to take a fairly persistent and knowledgeable employee to get around the barriers and install anything unauthorized (at which point you have enough evidence that they knowingly and deliberately circumvented corporate policies that you can skip right to the pink-slip-and-final-paycheck stage, pour discourager les autres).
Google Desktop is doing what it's designed to do: keep user's data on central servers so it's accessible from anywhere. It's just that it makes the assumption that all of the computer belongs to the user. Obviously in a corporate environment that's not the case, but Google Desktop doesn't know what kind of computer it's on so it can't do anything about that. The company needs to be more emphatic about the "no unauthorized software" rule (they do have a "no unauthorized software" rule, don't they?).
There's one problem in Bush's analysis. If all the manufacturing is in India, China and the like, and all the product support is outsourced to the same places, and all the consumers are in those places, then why precisely should those consumers go to an American company to buy locally-made goods and services?
OSS needs big business to be successful? Oh, then I guess that Linux thing can't have become a huge success, then. And Apache, that can't have been successful as a Web server. And Sendmail couldn't be a very successful MTA. What? All of those are successful? How odd. :)
I think the "open-source needs big business" is wishful thinking on the part of big business. They depend heavily on open-source software for critical things, and to admit that it could be successful without them would invalidate too many of the assumptions their world's based on.
If one company chooses to levy a fee for access, does it not follow that consumers would rationally choose to switch to another company, or accept the fee? The idea that the government might pass a law outlawing what should be a simple business policy is frightening.
It ought to follow, but it doesn't. It doesn't follow because most of those companies wanting to levy fees for preferred treatment of traffic also have a government-granted monopoly on service in their area. Telcos and cable companies operate under agreements which prohibit competitors from installing physical wiring, and they've successfully lobbied for rules which let them prevent competitors from using their wiring even if those competitors are willing to pay for the access. Where I live, this means I have exactly three choices for Internet access: Cox Cable, PacBell DSL, or dial-up (over either a Cox or SBC phone line). If Cox and PacBell decide to start charging premiums, I can't switch to an alternative cable-internet or DSL provider because none are allowed to serve me.
This sounds like a basic one-time password device (SecurID or similar) using sound to transmit the password. Everything except those portions of claims referring to the transmission mechanism should be attackable based on that prior art, and that doesn't leave much to attack on grounds of obviousness.
The proper response to her "virtually impossible" comment would be "Ummm, and as copyright holders that's our problem how again?". :)
There's one big difference: with snail-mail the sender is paying the freight with the postage they have to put on the item to send it to me. If they're paying, they can do what they want. But as I also noted earlier, you (ie. the people sending spam) aren't paying for their use of my mailbox and they're not asking permission to use it. It's the same as someone sending me snail-mail postage due and claiming their right to free speech gives them the right to do that. Sorry, but no.
Your living room is your property. My e-mail inbox is my property. If you have a right to use my property for your free speech, I (or any political group) have just as much of a right to use your property for my free speech. If you can "speak" using e-mail without using my inbox without payment or permission, feel free. If you're going to eat up resources I have to pay for, though, I'll be happy to quote you my rates.
Free speech may be more important than an inbox but what you're demanding isn't free speech, it's the right to commandeer other people's property in pursuit of your political agenda.
I no more invited trespass by having an e-mail inbox than I invite trespass of my house by having my house number and my name on a sign by the street. If I don't ask someone to speak to me, I've given no invitation to them.
It's not a matter of inbox clutter. It's a matter of the companion right to your right to speak: my right to not listen. If you want to pontificate on a street corner that's fine, but the right to do that doesn't give you the right to grab and detain people to make them listen. If you want to give a speech that's fine, but the right to give that speech doesn't give you the right to commandeer someone's hall to speak in without their permission and without paying them. Your right to say what you want doesn't grant you a right to come onto my front lawn to make your statement.
Or should I schedule the next meeting of <insert offensive-to-you political group here> in your living room? After all, some things are more important than convenience, and making political speech, even if it is annoying, illegal is a very bad idea. :)
Except that anti-spam laws aren't a free-speech matter. Free speech means your right to say what you want. It does not mean your right to use my hall without my permission to say what you want, nor does it mean your right to demand that I listen to you. If you're paying for the venue/publication, or you're using public property, then talk away all you want. But I don't see you paying my ISP subscription and my e-mail inbox (which is part of that subscription) isn't public property, and the First Amendment doesn't apply to your use of them without permission and without paying.
Because the Chinese government isn't inclined to look the other way. Their Great Firewall operates on a "default deny" principle (or it can be made to trivially): block everything except government-approved data. Were I in charge of this for the Chinese government (I wouldn't be because I'm adamantly against it, but imagine I was) it wouldn't be that hard for me to block everything to Google's netblocks and all traffic that didn't look like approved protocols (regardless of port) to approved destinations. I'd have to buy a fair amount of hardware to do it, but if I had a government's checkbook behind me I could do it. If I can do it, I seriously doubt the Chinese government's ruled it out as an option. So if Google did release such an application, they'd find themselves locked out of China completely and the Chinese people locked in even more thoroughly than they are now.
Anti-censorship tricks only work decently when your opponent's willing to allow a sizeable amount of traffic they can't recognize. If they're willing to block anything they don't recognize, whether or not it's really legitimate, you're SOL.
I've had mixed results with standardizing on a language. All too often it's done purely for the sake of standardizing, with no thought to anything else. Programming languages are tools, and ones being used by a team not just one person. You want to minimize the number of variations in your tools so people don't have to worry about needless vagaries from one tool to another. At the same time, you don't want to standardize so far that you eliminate entire kinds of tools and end up doing the equivalent of trying to use a rock as a hammer because your shop's standardized on screwdrivers and screws for holding things together and so doesn't have hammers (the programming equivalent would be trying to do simple scripting jobs, that'd be 5 lines in Perl or bash, in C++ because that's the language your shop standardized on).
The only times I've seen standardizing languages work is when the first step was to not standardize. The first step in a successful standardization effort will be to ignore languages and instead take stock of what kinds of programs you need to write. Include all those little one-off jobs that you have to do several of every week, eg. the little hack to extract the error messages you're interested in from the logfile. Then, for each kind of program, look at the languages suited to writing that kind of program and see what one your developers are most comfortable with and, just as importantly, what your existing code is written in. An inferior langauge that all your developers know well is superior to a superior language that they're not familiar with, and if you've a large body of code in one language then that language is better than a different language. If several kinds of programs can be served sufficiently well by one language, well and good. If not, well and good too. The goal is to simplify getting the job done, not hamstring yourself with rules not related to getting the job done.
In the Unix world, normally I expect at least 4 standard languages. You'll have shell script (typically sh because so many other tools expect it, but csh is possible), make (because every development environment typically depends on make at some point), another scripting language (Perl, Python, Ruby, etc.) and a "real" programming language (commonly C, C++ or Java, add VB and C# in a Windows environment, others are possible).
Many are stopping, hence the screeches from companies. :)
My person rule about security-related bugs is that I'll give a company 1 month (30 days) from being notified to either a) release a fix, b) disclose the problem and any existing workarounds to the public, or c) get back to me with a really good reason why it's not possible to do either A or B (and "It'll embarrass us." is not a good reason). If there's evidence the problem's already being exploited (real exploits affecting computers at large, not proof-of-concept stuff) then disclosure will happen immediately to within a few days depending on whether there's a functional work-around and how willing the company seems to be to work on a rapid disclosure (theory here being that if the black hats are already using the vulnerability disclosure won't make the situation worse).
Many are stopping, hence the screeches from companies. :)
My person rule about security-related bugs is that I'll give a company 1 month (30 days) from being notified to either a) release a fix, b) disclose the problem and any existing workarounds to the public, or c) get back to me with a really good reason why it's not possible to do either A or B (and "It'll embarrass us." is not
If Oracle can't fix the problem in 3 months, at least they could inform their own customers so they could take protective measures of their own. That Oracle could do inside of 3 months no matter how complex the bug is to finally fix.
Litchfield is putting Oracle's customers at risk? I don't think so. Oracle put their customers at risk, Litchfield merely told those customers they were at risk and in what way. He gave Oracle 3 months to either fix the problem or inform their customers, Oracle did neither, I'd say the problem's all of Oracle's making. If they'd placed their customer's security over their own PR in a reasonable timeframe, Litchfield wouldn't have had to embarrass them this way.
Another example of why "reasonable disclosure" doesn't work well.