Somewhat how sales of books made available for free in unprotected HTML format through the Baen Free Library dried up? Oh wait a second, according to the authors of those books sales of those titles, both in electronic form and in hardcopy, went up after they were made freely available. And sales of their other books went up. Which nearly caused some coronaries, since it's received wisdom that sales of backlist titles never go up.
If you want to argue sales, you'll lose every time. And if you want to argue "belongs to someone else", well, the problem there is that the perception's that authors and other creators are trying to demand all the advantages with none of the consequences. In this case, the Author's Guild seems to be wanting all the advantages of selling in the mass market under standard copyright law, but they want to retain the absolute control over all those copies they've sold that copyright law doesn't give them.
You also persist in mixing up two unrelated things. You object to people doing things with their own copies, but you base your arguments on people distributing additional copies. The two aren't the same, much as the Author's Guild would find it convenient if they were. That it's a violation of copyright law for me to make additional copies of those research papers you describe and sell them doesn't change the fact that it's a) legal for me to make copies of ones I own for my own use and b) legal for me to quote limited portions of them in my own original works. Neither of those involves distributing additional copies in violation of copyright law, so your arguments are not only false, they'd be irrelevant even if they weren't false.
Simple: their worry isn't about losing the lawsuits, it's about the cost of winning them. The copyright holders are going to lose, but it's going to cost Kinko's all those legal fees to defend themselves even though the defense is a slam-dunk. The argument the copyright holders usually make isn't "We can win.", but "Look, even if you win it's going to cost you $50K to beat us. It's cheaper to just pay us the $20K we're asking for to go away.". Same tactic the RIAA and MPAA are using, that SCO tried to use on IBM, and that the Lemelson foundation used for many years.
The problem is that, as all of the above groups have found, that game only works until you run up against someone whose main concern isn't the cost or who's got other issues that make the cost of fighting a legal fight the smallest part of the financial equation.
I think the US government fails to grasp that they don't have a choice in the matter. The root DNS servers are the roots because most DNS servers point to them in the root hints configuration. Any DNS server operator can point their servers to a different set of root servers by just changing that's in the root hints configuration. The question isn't whether the US government will allow a different set of roots but whether the alternate roots can convince the majority of DNS servers to re-point to them instead of the current roots.
And the above doesn't really matter directly anyway. The critical servers aren't the roots, really, but the TLD servers the roots delegate to, particularly the ones for the.com domain where it seems most of the biggest domain names are. That's where the real hands-on control is. The roots only affect things in a major way in that they determine what the TLD servers are for a given TLD. The only way alternate root servers can really affect things is if, in addition to getting a lot of people to use them, their operators can also convince people that using alternate, non-official TLD servers for the big domains is also a good idea. For practical reasons I don't see that happening anytime soon.
True, they're copying it in it's entirety without the author's permission. The problem is, you don't need the author's permission to copy. All you need is permission. There's three places you can get that permission: the author, copyright law itself, and that vague area known as "fair use". So, for example, since it's been legally established that making a copy of a television program to view at a later time is permitted by fair use, it matters not one whit whether the broadcaster grants or withholds that permission since his withholding it doesn't affect the fair-use grant.
Oh, and by the way: yes, if I buy a book, I can make copies of it. An unlimited number, in fact. As long, that is, as I still own the original copy I bought and the other copies are for my personal use, and I insure that if I sell or give away the original copy that I either destroy all the additional copies or transfer them along with the original. Again, this is a long-settled matter of la Authors may wish fair use would go away, but they're not the only parties to the copyright balance and, quite frankly, a large number of the other parties are starting to see the authors as being far greedier than is reasonable. Hence why the problems.
I saw this with MyMP3.com, and I'll make you a little prediction: if the Author's Guild succeeds, they'll end up either a) wondering why their members' books aren't selling while the authors who opt to submit their work to Google are raking in the sales, or b) fighting hundreds of off-shore engines that don't have the restrictions on availability that Google has built in and have no incentive to be reasonable since, well, look what happened to Google when they tried to be reasonable.
Firstly, Google isn't copying and distributing the works, so your plaint fails by starting on a falsehood. Google is quoting from the work, but that's been ruled legal time and time again. If it weren't, book reviews couldn't quote snippets from books and newspaper and magazine articles couldn't quote small bits.
Secondly, copyright has traditionally deemed control of distribution to extend to first sale only. After that first sale of a copy, the creator has no more say over distribution of that copy. That's why used book and record stores can exist.
Copyright isn't an unlimited right to control all use of your work.
The thing is, your numeric codes are equivalent to barcodes. They're both an encoding of the actual selection, and require a mapping from the code to the selection. That opens the possibility of tampering not with the ballot but with the mapping. With the actual selection printed out (name, proposition yes/no, etc.) there's no mapping to tamper with, the ballot itself contains everything needed to tell how that ballot should be counted. The idea is that that is the only thing humans normally need to interpret directly. All else is for the convenience of machines. Humans never interpret the barcode, the most they do is check whether the barcode printed on the ballot matches the template barcode that goes with the human-readable selection. Yes, we can OCR printed text, but it's not as fast or reliable as scanning barcode. With smudges, creases and such OCR has a 90-95% accuracy, but barcode has a better than 99% accuracy rate (and essentially 100% of the failures will be failure-to-scan instead of an incorrect scan result). The lower the error rate, the less hassles we have with false-incorrect counts (scanned count doesn't match electronic count only because of errors in scanning).
You're right, but then that's what I said: we need a system where we never have to trust any one piece completely. We can't trust the hardware. Even if it's open-source, we can't trust the software because the hardware might not be running the software we think it is. So you design a system where even if the voting terminals are completely compromised we can still tell whether they produced the correct count or not.
In short, I don't want a system we can trust, I want a system we don't have to trust to be confident in the results.
Problem: human-readable is hard for machines to interpret at high speed. With barcode you can scan ballots and tally them basically as fast as you can feed sheets through the scanner. That allows for convenient cross-checking of the electronic total, and makes it feasible to verify a large percentage of the ballots (in theory you could scan 100% of the ballots in a few days, making the electronic totals simply an early prediction and not the official result). That makes it really hard to fudge the electronic totals without it being caught.
And yes, I allowed for the possibility of the terminals programmed to print a different barcode than the voter wanted. That's why there's also a human-readable version printed. To check whether the human-readable and barcode entries are the same, a human can read the name, pick a template of the barcode that should go with that name, put the template against the printed barcode and see if it seamlessly matches (barcode OK) or if the lines don't match (barcode doesn't match name). Humans are good at that kind of visual pattern-matching, so it should be possible to check 20% or so of ballots this way. If the checks are done at random, it should be very very hard for the barcodes to be fudged without it being caught.
As a final check, in case someone has managed to both alter the barcodes the terminals print and the templates used to check the barcode-to-name matching, you can manually count ballots using only the human-readable names. You wouldn't do this for a large percentage of the ballots, say 1 precinct in 20 selected at random. I'd have both the selection and the counting of ballots done not by election officials but by representatives of the various parties and interest groups observing the election. They don't all want the same outcome, so it'll be very hard to get all of them to agree to fudge the results the same way. If the manual count disagrees with the electronic or barcode counts, we go to more extensive manual counts.
Three different layers, all using different technologies and methods to verify the count. If the barcode scanners are made by a different vendor than the voting terminals, the barcode checking templates are prepared by someone unconnected to the terminal and scanner vendors and the name counting is done by people not connected to the rest of the voting system and with competing interests, it should be almost impossible to fudge the count by any method other than wholesale replacement of the printed ballots prior to the first barcode scan. And that, quite frankly, is a problem that can be handled by simpler techniques than those needed to secure a fully-electronic system.
I think they need to concentrate not on a system that's open-source, but on a system where you don't need to trust the hardware to be able to verify the results. Open-source would be nice, but IMHO the critical requirement is more that you should be able to determine whether the reported results are correct without having to put unconditional trust in any one part of the system.
Eg., a system where the terminal records your vote electronically, then produces a printed ballot with both human-readable and barcode on it. The barcodes can be scanned quickly, so it's possible to compare the electronic results to the printed ballots. A template of the barcode for each possible value can be used to let humans quickly determine whether the barcodes match the human-readable name. And the voter can verify before putting his printed ballot in the box that the human-readable names on his ballot match the way he voted. Securing the physical ballots is similarly amenable to methods that insure that it'd take an improbable conspiracy to actually succeed in tampering with them.
You're parroting the same falsehood as the RIAA. No, I don't own the song. I do, however, own that copy of the song. Same as a book: I don't own the book, but I do own my copy of the book. And no, I don't own a license, I own the copy. See the Uniform Commercial Code for the relevant contract of sale (which applies if no other terms are agreed to at or before the time of sale). If the RIAA wants the transaction to not be a sale under the UCC, then they need to either have an appropriate agreement made or make the transaction not have the form and appearance of a sale.
Not quite right. I pay (or rather, my apartment management pays and includes the charge in my rent) for water service from the city water system. I've bought that water from my tap. Sure, if the tap water quality's high enough having it available from the city makes it harder for Evian to sell their water, but I don't recall where Evian ever obtained an exclusive right to provide water in my city so that's just one of the risks of doing business for them. The owners of the music being pirated, by comparison, do have an exclusive right to determine how they'll distribute it. You may not like how they're doing it, but it's their right to do it and it's their right to be stupid about it and ignore what their customers want if they so choose.
NB: the exclusive right to distribute doesn't IMHO extend to a right to conrol use after first sale, but everyone arguing "We haven't taken anything from them!" is always demanding to go beyond use and into making and distributing copies to people who don't already own the song so I've no sympathy for 'em there.
I keep hearing this argument repeated, and it's false. If I have a one-of-a-kind car and you go and create and sell replicas of it without permission, it certainly does take something away from me since it reduces the value of my car. The same thing with pirated music: if you copy and distribute a song without permission, it reduces the value of the authorized distribution channel for that song. Not everything needs to be physical to be stolen, see "identity theft" for a really nasty example.
I think the music industry's problem is that the market has decided, and it's decided it doesn't like the music industry's standard terms. The music industry doesn't like that decision and is trying everything they can including whining like a spoiled brat to get it changed. Unfortunately for them, the market isn't buying it (in several senses).
No, this was a very recent hole (within the last week or so) involving very long URLs and an IDN decoding buffer that wasn't length-checked. They issued a patch yesterday, but prior to that simply disabling IDN blocked the attempt to decode and avoided the buffer overrun.
This looks like the IDN hole that was reported a bit ago. My understanding is that no patch was needed, just type "about:config" into the URL bar, find the "network.enableIDN" entry and change the setting to "false". Once you do that, the buffer overrun the exploit uses never happens, so the bug can't be exploited anymore.
There's one big idea I'll bet is on the lab's list of things not to research: "Make movies people want to watch, and distribute them the way customers want to get them at prices customers want to pay.".
Because with Mozilla it's almost impossible for a vulnerability not to be publicly acknowledged by the Mozilla organization. The internal details may not be public, but the vulnerability itself would have been reported through the public Bugzilla interface. Contrast this to MS's vulnerability announcements, where it's unusual for the vulnerability to have been reported to MS less than a month prior to MS acknowledging it to the public.
Actually it can be completely compromised even with Mozilla. If a buffer overflow bug or something similar allows execution of arbitrary binary code, then it doesn't matter what the program is your system's potentially completely compromised. It's just that IE offers so many ways to compromise your system without needing to get arbitrary binary code executed.
Because most often the IE holes are yet another instance of the same underlying bug. That they keep showing up indicates that MS is just patching instances as they appear, not fixing the bug at the heart of the problem.
I think this is the kicker. The 25 vulnerabilities for Mozilla are almost certainly all the known vulnerabilities. For IE, how many vulnerabilities are there that've been reported that MS hasn't publicly acknowledged?
In addition, what's the severity? The last Mozilla vulnerability was the IDN bug, which was trivially worked-around by changing one config setting until a patch was released. Contrast that to the recent vulnerability in IE that MS won't discuss details of, other than to say that it allows total compromise of the machine and they won't be patching it until next month, and there's no workaround for the bug because nobody knows what the bug is (outside of MS, the security company that found it and the black-hats, of course).
My take on it: Mozilla may be having more vulnerabilities reported, but it's still fewer than in IE and those vulnerabilities are less severe, easier to work around without crippling your system and fixed sooner than IE's holes. From a user's viewpoint, this makes Mozilla more secure than IE.
So then why did INETA accept the application for a slot? If they didn't think it was appropriate, why not simply reject the request for a slot, instead of trying to act like it didn't happen?
Well, if I have full details of the vulnerability, I can test their fix myself to confirm it works. I can also confirm whether I'm actually vulnerable (see for example the OpenSSH vulnerabilities that, while critical, could be eliminated by simply disabling a little-used authorization method, so none of my systems were vulnerable even though they were running the "vulnerable" version). I think where we disagree is in focus. I don't care about the vendor at all. For me there's only my machines, the vulnerability and the black hats. The vendor's issues are irrelevant to me, I'm concerned only with protecting my machines from the black hats. To me, that's the one big advantage of open source: I can understand and evaluate the problem, cover my immediate exposure and keep myself from ever having a problem most of the time. The ability to sue somebody presumes that all protections have failed and I've been damaged in some way I could sue over. My goal is to keep that from happening in the first place.
I have a slightly different take on it. As a user, whether or not the vendor has released a patch there are still things I can do to mitigate my own risk from the vulnerability. I can, for example, restrict or block access to the vulnerable services, or change from the vulnerable software to some other software that's not vulnerable. But I can only do that if I know the problem exists. As a user I don't particularly like a vendor deciding that their QA resources are more valuable than my network and systems, which is what they're doing when they fail to disclose or delay disclosure of a problem to me because they aren't done testing the fix. When I hear about how inconvenient or hard it is for the vendor to fix a problem, I have to immediately ask "OK, how about how much hell I'm going to go through cleaning up after some black-hat cracks my network by exploiting this problem? Vendor, you going to pony up if that happens between the time you knew about the problem and the time you let me find out about it? No? Right then, you don't want the responsibility for delaying the disclosure, you forfeit any authority to delay the disclosure.".
Refuse to sign the NDA. Then make a public announcement: "$AGENCY has notified us that a possible vulnerability exists, however they won't tell us what the vulnerability is unless we sign an NDA. Comitting a patch to fix the problem to CVS or releasing fixed code before they allow it would violate the NDA, and we aren't willing to agree to deliberately not fix a security bug.". Let the resulting PR headache be $AGENCY's headache.
Open-source coders and OO.o can add one or two things to help MA apply egg to MS's face. Those things are light-weight, small plug-in viewers for various Web browsers on Windows that can be set up to be installed through the browser's standard plug-in/add-on installation interface. Make it easy, when people hit a Web page referring to OO.o documents on MA's sites, to get their browser set up to view, print and save the documents (editing isn't, I believe, too neccesary here). Have the viewer, when it's installed, add the appropriate hooks so that once OO.o documents are saved the browser and plug-in get used when you double-click on the document later. In short, make the viewing experience as seamless as possible so it's only MSOffice that seems to have problems with OO.o documents. We all know what the average Windows user is like, so make it Microsoft's problem to explain why MSOffice won't work when they get calls like "Word won't open this document! When I visit the MA web site I can see it just fine, but Word won't open it! Why's Word broken?".:)
MA can add to that by putting links to the OO.o downloads page on all the pages that link to OO.o documents. Make it easy for users to ask "But everybody else makes it so easy, why is Office the only thing that gives me problems?".
Slashdot Mirror
Somewhat how sales of books made available for free in unprotected HTML format through the Baen Free Library dried up? Oh wait a second, according to the authors of those books sales of those titles, both in electronic form and in hardcopy, went up after they were made freely available. And sales of their other books went up. Which nearly caused some coronaries, since it's received wisdom that sales of backlist titles never go up.
If you want to argue sales, you'll lose every time. And if you want to argue "belongs to someone else", well, the problem there is that the perception's that authors and other creators are trying to demand all the advantages with none of the consequences. In this case, the Author's Guild seems to be wanting all the advantages of selling in the mass market under standard copyright law, but they want to retain the absolute control over all those copies they've sold that copyright law doesn't give them.
You also persist in mixing up two unrelated things. You object to people doing things with their own copies, but you base your arguments on people distributing additional copies. The two aren't the same, much as the Author's Guild would find it convenient if they were. That it's a violation of copyright law for me to make additional copies of those research papers you describe and sell them doesn't change the fact that it's a) legal for me to make copies of ones I own for my own use and b) legal for me to quote limited portions of them in my own original works. Neither of those involves distributing additional copies in violation of copyright law, so your arguments are not only false, they'd be irrelevant even if they weren't false.
Simple: their worry isn't about losing the lawsuits, it's about the cost of winning them. The copyright holders are going to lose, but it's going to cost Kinko's all those legal fees to defend themselves even though the defense is a slam-dunk. The argument the copyright holders usually make isn't "We can win.", but "Look, even if you win it's going to cost you $50K to beat us. It's cheaper to just pay us the $20K we're asking for to go away.". Same tactic the RIAA and MPAA are using, that SCO tried to use on IBM, and that the Lemelson foundation used for many years.
The problem is that, as all of the above groups have found, that game only works until you run up against someone whose main concern isn't the cost or who's got other issues that make the cost of fighting a legal fight the smallest part of the financial equation.
I think the US government fails to grasp that they don't have a choice in the matter. The root DNS servers are the roots because most DNS servers point to them in the root hints configuration. Any DNS server operator can point their servers to a different set of root servers by just changing that's in the root hints configuration. The question isn't whether the US government will allow a different set of roots but whether the alternate roots can convince the majority of DNS servers to re-point to them instead of the current roots.
And the above doesn't really matter directly anyway. The critical servers aren't the roots, really, but the TLD servers the roots delegate to, particularly the ones for the .com domain where it seems most of the biggest domain names are. That's where the real hands-on control is. The roots only affect things in a major way in that they determine what the TLD servers are for a given TLD. The only way alternate root servers can really affect things is if, in addition to getting a lot of people to use them, their operators can also convince people that using alternate, non-official TLD servers for the big domains is also a good idea. For practical reasons I don't see that happening anytime soon.
True, they're copying it in it's entirety without the author's permission. The problem is, you don't need the author's permission to copy. All you need is permission. There's three places you can get that permission: the author, copyright law itself, and that vague area known as "fair use". So, for example, since it's been legally established that making a copy of a television program to view at a later time is permitted by fair use, it matters not one whit whether the broadcaster grants or withholds that permission since his withholding it doesn't affect the fair-use grant.
Oh, and by the way: yes, if I buy a book, I can make copies of it. An unlimited number, in fact. As long, that is, as I still own the original copy I bought and the other copies are for my personal use, and I insure that if I sell or give away the original copy that I either destroy all the additional copies or transfer them along with the original. Again, this is a long-settled matter of la Authors may wish fair use would go away, but they're not the only parties to the copyright balance and, quite frankly, a large number of the other parties are starting to see the authors as being far greedier than is reasonable. Hence why the problems.
I saw this with MyMP3.com, and I'll make you a little prediction: if the Author's Guild succeeds, they'll end up either a) wondering why their members' books aren't selling while the authors who opt to submit their work to Google are raking in the sales, or b) fighting hundreds of off-shore engines that don't have the restrictions on availability that Google has built in and have no incentive to be reasonable since, well, look what happened to Google when they tried to be reasonable.
Firstly, Google isn't copying and distributing the works, so your plaint fails by starting on a falsehood. Google is quoting from the work, but that's been ruled legal time and time again. If it weren't, book reviews couldn't quote snippets from books and newspaper and magazine articles couldn't quote small bits.
Secondly, copyright has traditionally deemed control of distribution to extend to first sale only. After that first sale of a copy, the creator has no more say over distribution of that copy. That's why used book and record stores can exist.
Copyright isn't an unlimited right to control all use of your work.
The thing is, your numeric codes are equivalent to barcodes. They're both an encoding of the actual selection, and require a mapping from the code to the selection. That opens the possibility of tampering not with the ballot but with the mapping. With the actual selection printed out (name, proposition yes/no, etc.) there's no mapping to tamper with, the ballot itself contains everything needed to tell how that ballot should be counted. The idea is that that is the only thing humans normally need to interpret directly. All else is for the convenience of machines. Humans never interpret the barcode, the most they do is check whether the barcode printed on the ballot matches the template barcode that goes with the human-readable selection. Yes, we can OCR printed text, but it's not as fast or reliable as scanning barcode. With smudges, creases and such OCR has a 90-95% accuracy, but barcode has a better than 99% accuracy rate (and essentially 100% of the failures will be failure-to-scan instead of an incorrect scan result). The lower the error rate, the less hassles we have with false-incorrect counts (scanned count doesn't match electronic count only because of errors in scanning).
You're right, but then that's what I said: we need a system where we never have to trust any one piece completely. We can't trust the hardware. Even if it's open-source, we can't trust the software because the hardware might not be running the software we think it is. So you design a system where even if the voting terminals are completely compromised we can still tell whether they produced the correct count or not.
In short, I don't want a system we can trust, I want a system we don't have to trust to be confident in the results.
Problem: human-readable is hard for machines to interpret at high speed. With barcode you can scan ballots and tally them basically as fast as you can feed sheets through the scanner. That allows for convenient cross-checking of the electronic total, and makes it feasible to verify a large percentage of the ballots (in theory you could scan 100% of the ballots in a few days, making the electronic totals simply an early prediction and not the official result). That makes it really hard to fudge the electronic totals without it being caught.
And yes, I allowed for the possibility of the terminals programmed to print a different barcode than the voter wanted. That's why there's also a human-readable version printed. To check whether the human-readable and barcode entries are the same, a human can read the name, pick a template of the barcode that should go with that name, put the template against the printed barcode and see if it seamlessly matches (barcode OK) or if the lines don't match (barcode doesn't match name). Humans are good at that kind of visual pattern-matching, so it should be possible to check 20% or so of ballots this way. If the checks are done at random, it should be very very hard for the barcodes to be fudged without it being caught.
As a final check, in case someone has managed to both alter the barcodes the terminals print and the templates used to check the barcode-to-name matching, you can manually count ballots using only the human-readable names. You wouldn't do this for a large percentage of the ballots, say 1 precinct in 20 selected at random. I'd have both the selection and the counting of ballots done not by election officials but by representatives of the various parties and interest groups observing the election. They don't all want the same outcome, so it'll be very hard to get all of them to agree to fudge the results the same way. If the manual count disagrees with the electronic or barcode counts, we go to more extensive manual counts.
Three different layers, all using different technologies and methods to verify the count. If the barcode scanners are made by a different vendor than the voting terminals, the barcode checking templates are prepared by someone unconnected to the terminal and scanner vendors and the name counting is done by people not connected to the rest of the voting system and with competing interests, it should be almost impossible to fudge the count by any method other than wholesale replacement of the printed ballots prior to the first barcode scan. And that, quite frankly, is a problem that can be handled by simpler techniques than those needed to secure a fully-electronic system.
I think they need to concentrate not on a system that's open-source, but on a system where you don't need to trust the hardware to be able to verify the results. Open-source would be nice, but IMHO the critical requirement is more that you should be able to determine whether the reported results are correct without having to put unconditional trust in any one part of the system.
Eg., a system where the terminal records your vote electronically, then produces a printed ballot with both human-readable and barcode on it. The barcodes can be scanned quickly, so it's possible to compare the electronic results to the printed ballots. A template of the barcode for each possible value can be used to let humans quickly determine whether the barcodes match the human-readable name. And the voter can verify before putting his printed ballot in the box that the human-readable names on his ballot match the way he voted. Securing the physical ballots is similarly amenable to methods that insure that it'd take an improbable conspiracy to actually succeed in tampering with them.
You're parroting the same falsehood as the RIAA. No, I don't own the song. I do, however, own that copy of the song. Same as a book: I don't own the book, but I do own my copy of the book. And no, I don't own a license, I own the copy. See the Uniform Commercial Code for the relevant contract of sale (which applies if no other terms are agreed to at or before the time of sale). If the RIAA wants the transaction to not be a sale under the UCC, then they need to either have an appropriate agreement made or make the transaction not have the form and appearance of a sale.
Not quite right. I pay (or rather, my apartment management pays and includes the charge in my rent) for water service from the city water system. I've bought that water from my tap. Sure, if the tap water quality's high enough having it available from the city makes it harder for Evian to sell their water, but I don't recall where Evian ever obtained an exclusive right to provide water in my city so that's just one of the risks of doing business for them. The owners of the music being pirated, by comparison, do have an exclusive right to determine how they'll distribute it. You may not like how they're doing it, but it's their right to do it and it's their right to be stupid about it and ignore what their customers want if they so choose.
NB: the exclusive right to distribute doesn't IMHO extend to a right to conrol use after first sale, but everyone arguing "We haven't taken anything from them!" is always demanding to go beyond use and into making and distributing copies to people who don't already own the song so I've no sympathy for 'em there.
I keep hearing this argument repeated, and it's false. If I have a one-of-a-kind car and you go and create and sell replicas of it without permission, it certainly does take something away from me since it reduces the value of my car. The same thing with pirated music: if you copy and distribute a song without permission, it reduces the value of the authorized distribution channel for that song. Not everything needs to be physical to be stolen, see "identity theft" for a really nasty example.
I think the music industry's problem is that the market has decided, and it's decided it doesn't like the music industry's standard terms. The music industry doesn't like that decision and is trying everything they can including whining like a spoiled brat to get it changed. Unfortunately for them, the market isn't buying it (in several senses).
No, this was a very recent hole (within the last week or so) involving very long URLs and an IDN decoding buffer that wasn't length-checked. They issued a patch yesterday, but prior to that simply disabling IDN blocked the attempt to decode and avoided the buffer overrun.
This looks like the IDN hole that was reported a bit ago. My understanding is that no patch was needed, just type "about:config" into the URL bar, find the "network.enableIDN" entry and change the setting to "false". Once you do that, the buffer overrun the exploit uses never happens, so the bug can't be exploited anymore.
There's one big idea I'll bet is on the lab's list of things not to research: "Make movies people want to watch, and distribute them the way customers want to get them at prices customers want to pay.".
Because with Mozilla it's almost impossible for a vulnerability not to be publicly acknowledged by the Mozilla organization. The internal details may not be public, but the vulnerability itself would have been reported through the public Bugzilla interface. Contrast this to MS's vulnerability announcements, where it's unusual for the vulnerability to have been reported to MS less than a month prior to MS acknowledging it to the public.
Actually it can be completely compromised even with Mozilla. If a buffer overflow bug or something similar allows execution of arbitrary binary code, then it doesn't matter what the program is your system's potentially completely compromised. It's just that IE offers so many ways to compromise your system without needing to get arbitrary binary code executed.
Because most often the IE holes are yet another instance of the same underlying bug. That they keep showing up indicates that MS is just patching instances as they appear, not fixing the bug at the heart of the problem.
I think this is the kicker. The 25 vulnerabilities for Mozilla are almost certainly all the known vulnerabilities. For IE, how many vulnerabilities are there that've been reported that MS hasn't publicly acknowledged?
In addition, what's the severity? The last Mozilla vulnerability was the IDN bug, which was trivially worked-around by changing one config setting until a patch was released. Contrast that to the recent vulnerability in IE that MS won't discuss details of, other than to say that it allows total compromise of the machine and they won't be patching it until next month, and there's no workaround for the bug because nobody knows what the bug is (outside of MS, the security company that found it and the black-hats, of course).
My take on it: Mozilla may be having more vulnerabilities reported, but it's still fewer than in IE and those vulnerabilities are less severe, easier to work around without crippling your system and fixed sooner than IE's holes. From a user's viewpoint, this makes Mozilla more secure than IE.
So then why did INETA accept the application for a slot? If they didn't think it was appropriate, why not simply reject the request for a slot, instead of trying to act like it didn't happen?
Well, if I have full details of the vulnerability, I can test their fix myself to confirm it works. I can also confirm whether I'm actually vulnerable (see for example the OpenSSH vulnerabilities that, while critical, could be eliminated by simply disabling a little-used authorization method, so none of my systems were vulnerable even though they were running the "vulnerable" version). I think where we disagree is in focus. I don't care about the vendor at all. For me there's only my machines, the vulnerability and the black hats. The vendor's issues are irrelevant to me, I'm concerned only with protecting my machines from the black hats. To me, that's the one big advantage of open source: I can understand and evaluate the problem, cover my immediate exposure and keep myself from ever having a problem most of the time. The ability to sue somebody presumes that all protections have failed and I've been damaged in some way I could sue over. My goal is to keep that from happening in the first place.
I have a slightly different take on it. As a user, whether or not the vendor has released a patch there are still things I can do to mitigate my own risk from the vulnerability. I can, for example, restrict or block access to the vulnerable services, or change from the vulnerable software to some other software that's not vulnerable. But I can only do that if I know the problem exists. As a user I don't particularly like a vendor deciding that their QA resources are more valuable than my network and systems, which is what they're doing when they fail to disclose or delay disclosure of a problem to me because they aren't done testing the fix. When I hear about how inconvenient or hard it is for the vendor to fix a problem, I have to immediately ask "OK, how about how much hell I'm going to go through cleaning up after some black-hat cracks my network by exploiting this problem? Vendor, you going to pony up if that happens between the time you knew about the problem and the time you let me find out about it? No? Right then, you don't want the responsibility for delaying the disclosure, you forfeit any authority to delay the disclosure.".
Refuse to sign the NDA. Then make a public announcement: "$AGENCY has notified us that a possible vulnerability exists, however they won't tell us what the vulnerability is unless we sign an NDA. Comitting a patch to fix the problem to CVS or releasing fixed code before they allow it would violate the NDA, and we aren't willing to agree to deliberately not fix a security bug.". Let the resulting PR headache be $AGENCY's headache.
Open-source coders and OO.o can add one or two things to help MA apply egg to MS's face. Those things are light-weight, small plug-in viewers for various Web browsers on Windows that can be set up to be installed through the browser's standard plug-in/add-on installation interface. Make it easy, when people hit a Web page referring to OO.o documents on MA's sites, to get their browser set up to view, print and save the documents (editing isn't, I believe, too neccesary here). Have the viewer, when it's installed, add the appropriate hooks so that once OO.o documents are saved the browser and plug-in get used when you double-click on the document later. In short, make the viewing experience as seamless as possible so it's only MSOffice that seems to have problems with OO.o documents. We all know what the average Windows user is like, so make it Microsoft's problem to explain why MSOffice won't work when they get calls like "Word won't open this document! When I visit the MA web site I can see it just fine, but Word won't open it! Why's Word broken?". :)
MA can add to that by putting links to the OO.o downloads page on all the pages that link to OO.o documents. Make it easy for users to ask "But everybody else makes it so easy, why is Office the only thing that gives me problems?".