That's the thing, though: it shouldn't need to add significant friction. There's no games to play, and minimal management that ought to be needed. It should be about as complicated as keeping track of the credit cards in your wallet, which seems to be well within the realm of the majority.
I want a return to an old principle: "A government official cannot, by definition, act outside the law or their authority, because when they do they are not acting in an official capacity and shall not be treated as if they were.".
Why should it be hard? We're not talking about getting a CA-signed certificate verifying identity here, it's a self-signed certificate to insure that only the person who created the account accesses it. Prompt for a couple of things like name, generate and sign and add to the appropriate certificate stores for use. Assuming you're not just reusing a certificate you've already generated. This should be trivial, it's just that the toolmakers (browser makers, etc.) don't bother with proper support for more than the bare basics of SSL.
Masking was intended to keep people from shoulder-surfing your password as you entered it. In the days of public computer rooms where you'd have a dozen people behind you who could see your screen, masking made a lot of sense. When you're already in private, though, and there's nobody behind you to see your screen, password masking doesn't make any sense anymore. However, if you think about it there's still lots of time when you're not in private. In your own home you don't need masking most times, but think about sitting at the local coffee shop. Or in the airport on a trip. Or in an open-plan office. All those times you may have someone behind you who can see your screen. Or who's got a camera with enough resolution he can enlarge the picture later to get the screen contents. Those times I'd prefer the passwords be masked so eavesdroppers can't see them.
Of course the two aren't mutually exclusive. HTML for instance defines fields that're protected/masked. Just use them and let the user control with a setting whether protected/masked fields should be masked or their contents displayed. Then the user can decide which to use, and they're the ones who'll have to bear the consequences if their password gets out so they've an incentive to make a reasonable choice.
Well, SSL/TLS can, with the proper use of certificates, secure the endpoints against impersonation attacks. If, for instance, the browser has the server's certificate directly in it and won't accept any others, then it doesn't matter if the attacker can redirect the traffic to their server and forge DNS perfectly, the browser will still reject the server because it doesn't have the certificate the browser expects. Ditto the other way using client certificates. An attacker would have to compromise the endpoint itself and gain access to it's private keys to compromise the communication. You still do have to protect the server against things like buffer-overflow attacks on the software it's running, but that's sort of a given regardless of what else you use.
SSL/TLS won't, of course, protect a client against malicious content sent by a valid server. But then it's not intended to. It protects the communications channel, it doesn't make guarantees about what the endpoints will send across that channel.
There already is a standard: SSL. It includes encryption (to secure the content going across the channel against eavesdropping) along with bidirectional authentication (server certificates to verify that you're talking to the server you think you're talking to, as well as the less-commonly-used client certificates to authenticate to the server that you're who you claim to be).
If I were setting up a secure site, it'd be SSL-only. As part of the account-setup process, you'd be asked to generate a client certificate and upload the public certificate (over an SSL connection) to the server to be attached to your account. From that point on, when you attempted to log on using your username the server would only accept the request if it came over a connection presenting the client certificate attached to that username. And I've long suggested that, for user security, browsers have a feature where the user can associate server certificates with identities and then, by selecting an identity to communicate with, limit the browser to accepting only servers presenting one of the certificates associated with that identity. Have a way for the user to download the server certificate as part of the account setup process and you pretty much eliminate the need for PKI to support the whole thing, self-signed certificates will work since they were gotten directly from the source. You still need verification of both ends, but it's limited to just during the account setup process and isn't an ongoing thing.
The one difference is that in most cases the recursive resolver will be under the control of either the user themselves or the owner of the network. Eg., home computers implement stub resolvers talking to the nameserver included in the home router, which does the DNSSEC. You have to trust the server the stub resolvers are talking to, but that server's the little box sitting on the shelf above your computer instead of some random nameserver several hops out under the control of someone you don't know. Or you're at a company and you're trusting the nameservers the company runs for their network.
The only place it breaks down is when you're attached to an untrusted, public network (eg. the wireless hotspot at the local coffee shop), at which point you want additional precautions anyway because that kind of network could be using IP routing to funnel all your traffic through a malicious server even if you're getting the correct IP addresses from DNS.
I'd note that we get free energy all the time. We get more energy out of a gallon of gasoline than was put into making it. We get far more power from a pound of fuel in a nuclear reactor than we put into mining the uranium, refining it and turning it into nuclear fuel. Neither of those violates the first or second laws of thermodynamics. That's because those laws apply to closed systems, and we're not in a closed system. In the case of gasoline, the sun put energy into the system from outside. In the case of uranium, the supernova that created the uranium atoms put the energy into creating them. So it's entirely possible to have a source of energy that's simply tapping something outside our normal view of the system. Such a source would appear to be providing free energy.
OTOH, Steorn seems to have failed the acid test: producing results. It'd've been much more convincing if they could've just dropped a unit down on the bench and told their jury "Here it is, here's how to turn it on and off, here's where the power comes out. Have fun with it.". A working prototype trumps all theoretical arguments, and Steorn couldn't produce a working prototype. Until they can, I'm inclined to believe they're either mistaken or running a scam.
Using dynamic replacement of elements has most of those same problems, though: you end up with bookmarks that don't refer to the page you bookmarked, the back button doesn't work since the previous page isn't the previous step in the history, etc. etc.. At least with frames I can right-click and display the desired frame in it's own window or tab and get a correct URL to bookmark the content.
The only advantage AJAX has is in layout, and more often than not when faced with a layout where AJAX really does make it possible I find myself wishing the site designer had picked a simpler layout with fewer mis-features getting in the way of my reading/using the content. Eg., expanding FAQs where I have to click on every single item to browse all of it instead of just scrolling through reading it.
Seconded. You don't need Javascript to do a simple hyperlink. You don't need a scrolling text-box to display your page, the browser can scroll the page just fine thankyouveddymuch. You don't need to dynamically replace elements to change content while maintaining a navigation header or sidebar when appropriate (note: appropriate) use of frames will accomplish exactly what you want.
The two sins of engineering: making it more complicated than it needs to be, and making it simpler than it needs to be. Avoid them.
I assume that, if a human can figure out the e-mail address, a spammer can too. After all, if nothing else they'll simply hire an IT sweatshop over in Asia or Africa to scan the pages for addresses at a dollar an hour or a nickel an address. JS obfuscation doesn't even take that, if your browser can evaluate the Javascript then the spammer's page-scraping software can too. So I assume that the only obfuscation that'll work is one that renders a human unable to read the address, at which point why bother putting the address there at all. And if all else fails, the well-known spammer tactic of just shotgunning every possible e-mail address in a domain will find anything their other tricks didn't (just like the auto-dialers that dial every number in a given exchange will find even unlisted, unpublished, known-only-to-the-owner phone numbers).
The only viable defense is at the mail-server level. The spammers will get your address, so prepare your mail server to deal with them. Reject connections from known residential/dial-up netblocks that shouldn't be contacting your mail server directly. Apply SpamAssassin and other filtering to incoming mail. Use reliable blacklists (evaluate their policies yourself against your own tolerance for false positives, and remember that the spammers don't want you to use any blacklists because using them stops them from spamming). Use what your filters learn by blocking netblocks that generate too many filter-rejected messages. You can't stop them from sending that first SYN, but you can decide whether to SYN-ACK or NAK them.
Give it time. If Bing catches on in any sort of way, it's dead certain the same people gaming Google will start to target Bing too. And when that happens I think we'll see Google's years of experience with dealing with being gamed give it the advantage again.
The government doesn't enforce that condition. The ISPs enforce it through the courts, by suing the local government if it breaches the contract it signed with them.
In many cases, the ISPs. Most phone companies (DSL) and cable companies (cable Internet) would only run service in an area on the condition that the government would grant them exclusive access to the right-of-way for that kind of service. So for the government it wasn't a choice between giving the cable company exclusive access or leaving it open to competition, it was between granting them exclusive access or them not serving that area. The usual argument they made was that they needed a guaranteed customer base and guaranteed revenue to justify the cost of running physical infrastructure to provide the service, that if they had to compete with other cable companies in an area then their fraction of the customer base wouldn't be enough to justify the fixed costs.
Which conveniently omits that ODF was submitted under PAS - the process for reviewing and approving something that's already a standard and is already in use. ODF officially started the standardization process in OASIS in December of 2002, starting from the StarOffice format.
As for OASIS's track record, I refer you to http://www.oasis-open.org/specs/ that lists the standards they've originated. These include DocBook and a large number of SOAP-related standards. That's hardly "no track record at all". And their heavy concentration in XML-based standards makes them a good place for another XML-based standard.
One flaw in that analysis: typically in that case people only start looking for evidence of the exploit being used after the public disclosure happens. After all, nobody knew to look for that evidence before the announcement because nobody knew there was anything there to look for. Definitely you're going to see some groups of bad guys racing to add a newly-announced exploit to their malware packages. There's always groups who find it easier to wait for somebody else to do the hard work. But my experience has been that those aren't all the groups of bad guys out there, and few people bother going back through the logs (or even have the logs) to find out if the exploit was in use before the announcement.
As a helpdesk user, I tried being polite and nice. But take today's issue. sourceforge.net is blocked by the Web filtering software. Problem with that is that that's where the gSOAP software we use is hosted, in particular where the support forums and bug reporting and tracking system is hosted. We've got a bug to report and a couple of issues I want an opinion from the developer on before I go messing around with his code. My manager agrees those are legitimate reasons to have the site unblocked. So I tried being nice. I submitted a ticket 3 weeks ago, with the idea being there'd be plenty of time to get the site unblocked without having to rush anyone. I put the details of why in the ticket, plus the e-mail address of my manager if Helpdesk or the admins needed any further authorization. Followed up with all the information Helpdesk asked for. Kept the requests for status down to once, maybe twice a week. Didn't go bugging them, didn't get demanding, no reason to since we had plenty of time.
3 weeks and no progress. And today we have a major issue with it and I can't even check whether the issue's already a known bug or not. My boss wants progress made. So I stop being nice, proceed over to the helpdesk area and corner the person the ticket's assigned to. I need this fixed, I need it fixed now, and I'm not going away until it's done. And you know what? 5 minutes later the problem's fixed. I can get to sourceforge.net and get into the bug tracking system for gSOAP and get my questions answered.
As I told the tech, "Being nice got me no response from you for 3 weeks. Being a jerk got my issue fixed in 5 minutes. My boss in on me about things like this not getting resolved quickly. And my boss is the one who writes my evaluations come end of the year, not you.".
2 weeks to fix, yes it's short. 2 weeks to get the detailed information, review it, confirm whether or not the problems actually exist and respond to the submitter? That should be eminently doable. It's not like they have to find the vulnerabilities and figure out how to fix them, just determine whether the techniques given work as described. Speaking as a professional developer myself, if they can't do that in 2 weeks they shouldn't be writing software for use by others in the first place. Hells, my boss starts bugging me if it takes me more than 2 hours.
The problem with that approach is that the day after you announce that the exploit exists the company's going to sue you for defamation and libel. They're going to use the fact that you didn't provide any evidence to support your claim against you as evidence that you don't have any evidence and are lying specifically to harm their reputation. And one of the first things they're going to ask for is an order barring you from libeling them any further, which is going to prevent you from disclosing anything to help clear your reputation. By the time you get the lawsuit untangled you won't be able to demonstrate that the vulnerability really existed (the fix will have been quietly added during a regular update and your exploit won't work anymore) and you'll end up with the trashed reputation.
My position:
Contact the vendor with full details. Give them working exploit code so they can verify for themselves that it really works. They get 2 weeks to respond confirming they've received your material, and no more than an additional 4 weeks to at least notify their customers of the problem.
If the vendor fails to meet either of those deadlines, publicly release a full report on the problem including sufficient details and/or code for other parties to verify the correctness of your claims and any known workarounds or steps that can be taken to mitigate the vulnerability. By this point the bad guys already have all this information, now the affected users also have it and can take steps to protect themselves.
Don't threaten. Don't bluff. Your position should be Londo's: "Actually, now that you mention it...".
There is a fundamental tension between wanting to know if a system you own is vulnerable to some defect, and wanting to keep the exploit code out of the hands of The Bad Guys(TM).
I've never thought there was any tension: if I know about the vulnerability, track record says the bad guys already have the exploit code. The only tension is between giving enough information to the affected parties to let them confirm that it really is a vulnerability and I'm not just blowing smoke, or not giving them enough information and letting the vendor convince them I'm mistaken or lying and they have nothing to worry about. For myself, I want all the details. That way I don't have to trust some security researcher I've never heard of before, I can check things myself. And even if a patch isn't available, if I know the vulnerability exists I can fix it. The fix may involve closing down services or changing software, but a short-term fix almost always exists.
My experience has been that software companies will not even admit the problem exists, let alone put effort into a fix, until after working code demonstrating the exploit, or at least sufficient detail to let anyone verify that the exploit works, is made so public that the company can't handwave it away. They have too consistent a track record for me to think otherwise. The sword of public disclosure hanging over their heads is the only thing motivating them to fix the problems, and since I don't like having my systems vulnerable I have no choice but to resist anything that takes that sword away. It's my systems at risk, after all.
As for the first question, it's not so much a bug in the GPL/LGPL as a situation they aren't designed to cover. And I don't think they can without purporting to require parties outside the US to abide by US patent law, something I doubt the FSF will be willing to do.
As for the last, you'd have to ask a lawyer but I suspect if you'd abided by the license terms you could probably sue to force performance according to the license. The author may not be required to abide by the terms the way a recipient would, but they do have to honor the terms they offered and you accepted. They can't, for instance, sue you for copyright infringement if you redistribute according to the terms in their license (or if they do sue, they'll lose), and if they require you to redistribute the source code then they'll have to give you that source code some way or another (either in the initial distribution to you or later) (note that that won't require them to continue offering the license forever, but if they stop and stop offering the code then they may be on the hook for proving that they actually distributed the code to direct recipients).
Not if they distribute within the USA, it isn't. It's just that if the patent-holder is in the US and the infringer is in a country that doesn't recognize the type of patent in question it's a major pain for the patent-holder to get an enforceable judgment against the infringer themselves.
Of course, getting judgments against any users of the product barring it's use will be a lot easier to get. Monetary damages are unlikely, but a plain cease-and-desist is likely to be granted.
True, but the author is offering terms and will be required by the courts to abide by them if/when anyone accepts them. If they put the code under the terms of the LPGL 2.1, then the courts won't let them refuse to make good on their offer once someone's accepted it. Note that copyright has nothing to do with patent rights, except that the courts will tend to take the position that if the copyright holder also held patent rights (or a patent license that allowed them the pass rights on to others) then when they offered someone else the right to redistribute the code (as they do by offering it under terms of the LGPL 2.1) they implicitly grant patent rights sufficient to legally enable that redistribution (which would include the right to use the patents and rights to sublicense the right-to-use).
You're forgetting a few things. Both GPL v2 and v3 talk about granting the recipient rights to redistribute the license. If the author was the patent-holder or a licensee, then to grant people that license without granting patent rights would render those clauses meaningless. Without both rights to use the patent and some right to pass on those rights, the recipients can't exercise the redistribution rights the license purports to give them. Courts are loathe to declare terms of a license meaningless, so the typical reading of those kinds of clauses is that the grant of the right to redistribute implicitly includes all the other rights necessary for redistribution that the licensor has the ability to give out. So if the author was the author of the code and either held the patents or held patent licenses covering it that allow sublicensing, the courts are pretty likely to hold that they gave out rights to use the patents when they applied the GPL/LGPL to their code. They may not be subject to the license they give out themselves, but they are offering terms and the courts will require them to live up to their half of the deal if someone accepts their license.
But since Google isn't the author of the infringing code in this case, none of that's really applicable to them. It's only applicable to the FFMPEG authors. They aren't the patent-holders and they aren't licensees, so the only question is whether their initial distribution of their library constitutes patent infringement. I'm pretty sure a US court would consider it to be, but it looks like there's serious jurisdictional and logistical problems with actually getting an enforceable judgment.
I think Google's relying on a technicality, but it's a significant one. In this case Google isn't the creator of the library, they received it from it's creator. So either it's creator could grant them an LGPL 2.1-compatible patent license, or the library can be distributed without a license, or it's creator couldn't have legally distributed the library to them. I think that, right or wrong, Google's probably on solid legal ground there. They didn't introduce the patented code into the library, they didn't create the library, so I don't think the law'll have much trouble allowing them to redistribute the code under the same terms and with the same rights as they got from it's creator.
I think it's a situation the GPL and LGPL don't contemplate explicitly. The situation where Google was adding the infringing code to a library they received under (L)GPL terms and then redistributing the results, that's exactly what the v2 language covers. But I'm not sure even the v3 language covers the situation where the holder of the patent license isn't the one who put the infringing code into the library and where the person who did put it in doesn't hold a patent license and has no rights to grant downstream recipients. If the library was under LGPL v3 I think you could make an argument that the automatic grant of rights in paragraph 11 kicks in, since Google does hold a relevant patent license, and that if their license doesn't let them do what paragraph 11 requires then they can't redistribute, but LGPL 2.1 doesn't contain anything explicit corresponding to v3's paragraph 11.
I think Google's right here, it does in fact come down to what the patent-holder says. If they sue Google and get an order blocking Google from distributing infringing code, then Google can't distribute the library. If the patent holders sue the library's author and get an order blocking distribution of the library without a patent license, Google can't distribute the library. But until then, Google can't be forced to add any rights that they didn't get when they received the library.
Slashdot Mirror
That's the thing, though: it shouldn't need to add significant friction. There's no games to play, and minimal management that ought to be needed. It should be about as complicated as keeping track of the credit cards in your wallet, which seems to be well within the realm of the majority.
I want a return to an old principle: "A government official cannot, by definition, act outside the law or their authority, because when they do they are not acting in an official capacity and shall not be treated as if they were.".
Why should it be hard? We're not talking about getting a CA-signed certificate verifying identity here, it's a self-signed certificate to insure that only the person who created the account accesses it. Prompt for a couple of things like name, generate and sign and add to the appropriate certificate stores for use. Assuming you're not just reusing a certificate you've already generated. This should be trivial, it's just that the toolmakers (browser makers, etc.) don't bother with proper support for more than the bare basics of SSL.
Masking was intended to keep people from shoulder-surfing your password as you entered it. In the days of public computer rooms where you'd have a dozen people behind you who could see your screen, masking made a lot of sense. When you're already in private, though, and there's nobody behind you to see your screen, password masking doesn't make any sense anymore. However, if you think about it there's still lots of time when you're not in private. In your own home you don't need masking most times, but think about sitting at the local coffee shop. Or in the airport on a trip. Or in an open-plan office. All those times you may have someone behind you who can see your screen. Or who's got a camera with enough resolution he can enlarge the picture later to get the screen contents. Those times I'd prefer the passwords be masked so eavesdroppers can't see them.
Of course the two aren't mutually exclusive. HTML for instance defines fields that're protected/masked. Just use them and let the user control with a setting whether protected/masked fields should be masked or their contents displayed. Then the user can decide which to use, and they're the ones who'll have to bear the consequences if their password gets out so they've an incentive to make a reasonable choice.
Well, SSL/TLS can, with the proper use of certificates, secure the endpoints against impersonation attacks. If, for instance, the browser has the server's certificate directly in it and won't accept any others, then it doesn't matter if the attacker can redirect the traffic to their server and forge DNS perfectly, the browser will still reject the server because it doesn't have the certificate the browser expects. Ditto the other way using client certificates. An attacker would have to compromise the endpoint itself and gain access to it's private keys to compromise the communication. You still do have to protect the server against things like buffer-overflow attacks on the software it's running, but that's sort of a given regardless of what else you use.
SSL/TLS won't, of course, protect a client against malicious content sent by a valid server. But then it's not intended to. It protects the communications channel, it doesn't make guarantees about what the endpoints will send across that channel.
There already is a standard: SSL. It includes encryption (to secure the content going across the channel against eavesdropping) along with bidirectional authentication (server certificates to verify that you're talking to the server you think you're talking to, as well as the less-commonly-used client certificates to authenticate to the server that you're who you claim to be).
If I were setting up a secure site, it'd be SSL-only. As part of the account-setup process, you'd be asked to generate a client certificate and upload the public certificate (over an SSL connection) to the server to be attached to your account. From that point on, when you attempted to log on using your username the server would only accept the request if it came over a connection presenting the client certificate attached to that username. And I've long suggested that, for user security, browsers have a feature where the user can associate server certificates with identities and then, by selecting an identity to communicate with, limit the browser to accepting only servers presenting one of the certificates associated with that identity. Have a way for the user to download the server certificate as part of the account setup process and you pretty much eliminate the need for PKI to support the whole thing, self-signed certificates will work since they were gotten directly from the source. You still need verification of both ends, but it's limited to just during the account setup process and isn't an ongoing thing.
The one difference is that in most cases the recursive resolver will be under the control of either the user themselves or the owner of the network. Eg., home computers implement stub resolvers talking to the nameserver included in the home router, which does the DNSSEC. You have to trust the server the stub resolvers are talking to, but that server's the little box sitting on the shelf above your computer instead of some random nameserver several hops out under the control of someone you don't know. Or you're at a company and you're trusting the nameservers the company runs for their network.
The only place it breaks down is when you're attached to an untrusted, public network (eg. the wireless hotspot at the local coffee shop), at which point you want additional precautions anyway because that kind of network could be using IP routing to funnel all your traffic through a malicious server even if you're getting the correct IP addresses from DNS.
I'd note that we get free energy all the time. We get more energy out of a gallon of gasoline than was put into making it. We get far more power from a pound of fuel in a nuclear reactor than we put into mining the uranium, refining it and turning it into nuclear fuel. Neither of those violates the first or second laws of thermodynamics. That's because those laws apply to closed systems, and we're not in a closed system. In the case of gasoline, the sun put energy into the system from outside. In the case of uranium, the supernova that created the uranium atoms put the energy into creating them. So it's entirely possible to have a source of energy that's simply tapping something outside our normal view of the system. Such a source would appear to be providing free energy.
OTOH, Steorn seems to have failed the acid test: producing results. It'd've been much more convincing if they could've just dropped a unit down on the bench and told their jury "Here it is, here's how to turn it on and off, here's where the power comes out. Have fun with it.". A working prototype trumps all theoretical arguments, and Steorn couldn't produce a working prototype. Until they can, I'm inclined to believe they're either mistaken or running a scam.
Using dynamic replacement of elements has most of those same problems, though: you end up with bookmarks that don't refer to the page you bookmarked, the back button doesn't work since the previous page isn't the previous step in the history, etc. etc.. At least with frames I can right-click and display the desired frame in it's own window or tab and get a correct URL to bookmark the content.
The only advantage AJAX has is in layout, and more often than not when faced with a layout where AJAX really does make it possible I find myself wishing the site designer had picked a simpler layout with fewer mis-features getting in the way of my reading/using the content. Eg., expanding FAQs where I have to click on every single item to browse all of it instead of just scrolling through reading it.
Seconded. You don't need Javascript to do a simple hyperlink. You don't need a scrolling text-box to display your page, the browser can scroll the page just fine thankyouveddymuch. You don't need to dynamically replace elements to change content while maintaining a navigation header or sidebar when appropriate (note: appropriate) use of frames will accomplish exactly what you want.
The two sins of engineering: making it more complicated than it needs to be, and making it simpler than it needs to be. Avoid them.
I assume that, if a human can figure out the e-mail address, a spammer can too. After all, if nothing else they'll simply hire an IT sweatshop over in Asia or Africa to scan the pages for addresses at a dollar an hour or a nickel an address. JS obfuscation doesn't even take that, if your browser can evaluate the Javascript then the spammer's page-scraping software can too. So I assume that the only obfuscation that'll work is one that renders a human unable to read the address, at which point why bother putting the address there at all. And if all else fails, the well-known spammer tactic of just shotgunning every possible e-mail address in a domain will find anything their other tricks didn't (just like the auto-dialers that dial every number in a given exchange will find even unlisted, unpublished, known-only-to-the-owner phone numbers).
The only viable defense is at the mail-server level. The spammers will get your address, so prepare your mail server to deal with them. Reject connections from known residential/dial-up netblocks that shouldn't be contacting your mail server directly. Apply SpamAssassin and other filtering to incoming mail. Use reliable blacklists (evaluate their policies yourself against your own tolerance for false positives, and remember that the spammers don't want you to use any blacklists because using them stops them from spamming). Use what your filters learn by blocking netblocks that generate too many filter-rejected messages. You can't stop them from sending that first SYN, but you can decide whether to SYN-ACK or NAK them.
Give it time. If Bing catches on in any sort of way, it's dead certain the same people gaming Google will start to target Bing too. And when that happens I think we'll see Google's years of experience with dealing with being gamed give it the advantage again.
The government doesn't enforce that condition. The ISPs enforce it through the courts, by suing the local government if it breaches the contract it signed with them.
In many cases, the ISPs. Most phone companies (DSL) and cable companies (cable Internet) would only run service in an area on the condition that the government would grant them exclusive access to the right-of-way for that kind of service. So for the government it wasn't a choice between giving the cable company exclusive access or leaving it open to competition, it was between granting them exclusive access or them not serving that area. The usual argument they made was that they needed a guaranteed customer base and guaranteed revenue to justify the cost of running physical infrastructure to provide the service, that if they had to compete with other cable companies in an area then their fraction of the customer base wouldn't be enough to justify the fixed costs.
Which conveniently omits that ODF was submitted under PAS - the process for reviewing and approving something that's already a standard and is already in use. ODF officially started the standardization process in OASIS in December of 2002, starting from the StarOffice format.
As for OASIS's track record, I refer you to http://www.oasis-open.org/specs/ that lists the standards they've originated. These include DocBook and a large number of SOAP-related standards. That's hardly "no track record at all". And their heavy concentration in XML-based standards makes them a good place for another XML-based standard.
One flaw in that analysis: typically in that case people only start looking for evidence of the exploit being used after the public disclosure happens. After all, nobody knew to look for that evidence before the announcement because nobody knew there was anything there to look for. Definitely you're going to see some groups of bad guys racing to add a newly-announced exploit to their malware packages. There's always groups who find it easier to wait for somebody else to do the hard work. But my experience has been that those aren't all the groups of bad guys out there, and few people bother going back through the logs (or even have the logs) to find out if the exploit was in use before the announcement.
As a helpdesk user, I tried being polite and nice. But take today's issue. sourceforge.net is blocked by the Web filtering software. Problem with that is that that's where the gSOAP software we use is hosted, in particular where the support forums and bug reporting and tracking system is hosted. We've got a bug to report and a couple of issues I want an opinion from the developer on before I go messing around with his code. My manager agrees those are legitimate reasons to have the site unblocked. So I tried being nice. I submitted a ticket 3 weeks ago, with the idea being there'd be plenty of time to get the site unblocked without having to rush anyone. I put the details of why in the ticket, plus the e-mail address of my manager if Helpdesk or the admins needed any further authorization. Followed up with all the information Helpdesk asked for. Kept the requests for status down to once, maybe twice a week. Didn't go bugging them, didn't get demanding, no reason to since we had plenty of time.
3 weeks and no progress. And today we have a major issue with it and I can't even check whether the issue's already a known bug or not. My boss wants progress made. So I stop being nice, proceed over to the helpdesk area and corner the person the ticket's assigned to. I need this fixed, I need it fixed now, and I'm not going away until it's done. And you know what? 5 minutes later the problem's fixed. I can get to sourceforge.net and get into the bug tracking system for gSOAP and get my questions answered.
As I told the tech, "Being nice got me no response from you for 3 weeks. Being a jerk got my issue fixed in 5 minutes. My boss in on me about things like this not getting resolved quickly. And my boss is the one who writes my evaluations come end of the year, not you.".
2 weeks to fix, yes it's short. 2 weeks to get the detailed information, review it, confirm whether or not the problems actually exist and respond to the submitter? That should be eminently doable. It's not like they have to find the vulnerabilities and figure out how to fix them, just determine whether the techniques given work as described. Speaking as a professional developer myself, if they can't do that in 2 weeks they shouldn't be writing software for use by others in the first place. Hells, my boss starts bugging me if it takes me more than 2 hours.
The problem with that approach is that the day after you announce that the exploit exists the company's going to sue you for defamation and libel. They're going to use the fact that you didn't provide any evidence to support your claim against you as evidence that you don't have any evidence and are lying specifically to harm their reputation. And one of the first things they're going to ask for is an order barring you from libeling them any further, which is going to prevent you from disclosing anything to help clear your reputation. By the time you get the lawsuit untangled you won't be able to demonstrate that the vulnerability really existed (the fix will have been quietly added during a regular update and your exploit won't work anymore) and you'll end up with the trashed reputation.
My position:
There is a fundamental tension between wanting to know if a system you own is vulnerable to some defect, and wanting to keep the exploit code out of the hands of The Bad Guys(TM).
I've never thought there was any tension: if I know about the vulnerability, track record says the bad guys already have the exploit code. The only tension is between giving enough information to the affected parties to let them confirm that it really is a vulnerability and I'm not just blowing smoke, or not giving them enough information and letting the vendor convince them I'm mistaken or lying and they have nothing to worry about. For myself, I want all the details. That way I don't have to trust some security researcher I've never heard of before, I can check things myself. And even if a patch isn't available, if I know the vulnerability exists I can fix it. The fix may involve closing down services or changing software, but a short-term fix almost always exists.
My experience has been that software companies will not even admit the problem exists, let alone put effort into a fix, until after working code demonstrating the exploit, or at least sufficient detail to let anyone verify that the exploit works, is made so public that the company can't handwave it away. They have too consistent a track record for me to think otherwise. The sword of public disclosure hanging over their heads is the only thing motivating them to fix the problems, and since I don't like having my systems vulnerable I have no choice but to resist anything that takes that sword away. It's my systems at risk, after all.
As for the first question, it's not so much a bug in the GPL/LGPL as a situation they aren't designed to cover. And I don't think they can without purporting to require parties outside the US to abide by US patent law, something I doubt the FSF will be willing to do.
As for the last, you'd have to ask a lawyer but I suspect if you'd abided by the license terms you could probably sue to force performance according to the license. The author may not be required to abide by the terms the way a recipient would, but they do have to honor the terms they offered and you accepted. They can't, for instance, sue you for copyright infringement if you redistribute according to the terms in their license (or if they do sue, they'll lose), and if they require you to redistribute the source code then they'll have to give you that source code some way or another (either in the initial distribution to you or later) (note that that won't require them to continue offering the license forever, but if they stop and stop offering the code then they may be on the hook for proving that they actually distributed the code to direct recipients).
Not if they distribute within the USA, it isn't. It's just that if the patent-holder is in the US and the infringer is in a country that doesn't recognize the type of patent in question it's a major pain for the patent-holder to get an enforceable judgment against the infringer themselves.
Of course, getting judgments against any users of the product barring it's use will be a lot easier to get. Monetary damages are unlikely, but a plain cease-and-desist is likely to be granted.
True, but the author is offering terms and will be required by the courts to abide by them if/when anyone accepts them. If they put the code under the terms of the LPGL 2.1, then the courts won't let them refuse to make good on their offer once someone's accepted it. Note that copyright has nothing to do with patent rights, except that the courts will tend to take the position that if the copyright holder also held patent rights (or a patent license that allowed them the pass rights on to others) then when they offered someone else the right to redistribute the code (as they do by offering it under terms of the LGPL 2.1) they implicitly grant patent rights sufficient to legally enable that redistribution (which would include the right to use the patents and rights to sublicense the right-to-use).
You're forgetting a few things. Both GPL v2 and v3 talk about granting the recipient rights to redistribute the license. If the author was the patent-holder or a licensee, then to grant people that license without granting patent rights would render those clauses meaningless. Without both rights to use the patent and some right to pass on those rights, the recipients can't exercise the redistribution rights the license purports to give them. Courts are loathe to declare terms of a license meaningless, so the typical reading of those kinds of clauses is that the grant of the right to redistribute implicitly includes all the other rights necessary for redistribution that the licensor has the ability to give out. So if the author was the author of the code and either held the patents or held patent licenses covering it that allow sublicensing, the courts are pretty likely to hold that they gave out rights to use the patents when they applied the GPL/LGPL to their code. They may not be subject to the license they give out themselves, but they are offering terms and the courts will require them to live up to their half of the deal if someone accepts their license.
But since Google isn't the author of the infringing code in this case, none of that's really applicable to them. It's only applicable to the FFMPEG authors. They aren't the patent-holders and they aren't licensees, so the only question is whether their initial distribution of their library constitutes patent infringement. I'm pretty sure a US court would consider it to be, but it looks like there's serious jurisdictional and logistical problems with actually getting an enforceable judgment.
I think Google's relying on a technicality, but it's a significant one. In this case Google isn't the creator of the library, they received it from it's creator. So either it's creator could grant them an LGPL 2.1-compatible patent license, or the library can be distributed without a license, or it's creator couldn't have legally distributed the library to them. I think that, right or wrong, Google's probably on solid legal ground there. They didn't introduce the patented code into the library, they didn't create the library, so I don't think the law'll have much trouble allowing them to redistribute the code under the same terms and with the same rights as they got from it's creator.
I think it's a situation the GPL and LGPL don't contemplate explicitly. The situation where Google was adding the infringing code to a library they received under (L)GPL terms and then redistributing the results, that's exactly what the v2 language covers. But I'm not sure even the v3 language covers the situation where the holder of the patent license isn't the one who put the infringing code into the library and where the person who did put it in doesn't hold a patent license and has no rights to grant downstream recipients. If the library was under LGPL v3 I think you could make an argument that the automatic grant of rights in paragraph 11 kicks in, since Google does hold a relevant patent license, and that if their license doesn't let them do what paragraph 11 requires then they can't redistribute, but LGPL 2.1 doesn't contain anything explicit corresponding to v3's paragraph 11.
I think Google's right here, it does in fact come down to what the patent-holder says. If they sue Google and get an order blocking Google from distributing infringing code, then Google can't distribute the library. If the patent holders sue the library's author and get an order blocking distribution of the library without a patent license, Google can't distribute the library. But until then, Google can't be forced to add any rights that they didn't get when they received the library.