And what's the other end of your tunnel? If it's a VoIP call, the call setup goes through the VoIP provider, and they're required to not only make the packets available, but also to provide any keys/etc needed to decode it. They're also required to make it impossible for the target to know they're being tapped. This means they can't set up point-to-point IP calls - they'll have to route all calls through RTP proxies, tapped or not. This is a very BAD thing for call quality due to delay.
BTW, you don't want to send media streams in a call over TCP at all. Very bad idea. You could use UDP in an IPSec tunnel in theory, but normal voice protocols don't include any way to establish the tunnel. And you still need to worry about call-setup-induced MiTM.
Correct. The ruling also covers any broadband over 200Kbps separately - i.e. they can force your ISP to tap your connection. The act really is about forcing the ISPs to install equipment to make it EASY to tap by flipping a switch electronically - they already had the power to order a tap; it's just that it might be hard/slow/impossible for the ISP to comply. And yes, this means there's a HUGE gaping hole waiting for someone to exploit. Knowing the capability is there is 1/2 the battle of accessing it, and CALEA spells out a lot of specifics about the interface.
This lawsuit is about the part of the ruling that states that in addition to the ISP, any VoIP supplier who has any connection (even through a 3rd party!) to a PSTN gateway must provide the same ease-of-tapping under CALEA for ALL calls. Not just calls going to/from the PSTN, ALL calls.
Colleges are suing as well (separately), over the up to 7 or more BILLION dollars to re-architect and rebuild their campus networks to support this. The original CALEA was aimed at telephone companies; gave them years to comply; and reimbursed them for their expenses. None of that here.
This means Skype (unless they drop SkypeOut/SkypeIn). Ditto Vonage, sipphone, etc. I think FWD might be ok since it's IP-2-IP only.
"Microsoft cofounded the XML working group at the W3C in July 96 and actively participated in the definition of the standard."
This was used in IE4.00 for their Channel Definition File (used to schedule "Pull" of channels, an idea that's largely died). I was implementing CDF files at Scala in '96/97. The patent was filed in '97.
Note: the CALEA ruling requires that the service provider make it easy and quick to do taps. If that means no encryption, then they can't use encryption (or they have to have a way to recover the keys or MITM the call).
Working with that is the text from the policy statement that users can run whatever devices and programs they want, "subject to the needs of law enforcement". What a difference 7 words make.
They do exempt (from CALEA, not the policy statement) private networks. However, I don't think they consider a VPN over the open internet to be "private". They mean private switches and routers.
The FBI/NSA tried to force backdoors into encryption products before (see Clipper Chip). Those 7 words imply they'd like to do that again, but applied to software running on your PC (which can now encrypt at reasonable levels of security and speed). Which means control of software on you PC, or at least control over streams in/out of your PC - an encrypted stream might be considered evidence of running a "banned" application. Google "Police State".
That's only as safe as the LDAP server is. (yes, your app may notice the change in key if someone subverts the server - if it had talked to the 'real' other end of the conversation before, and it remembered the key.)
To do this, you need a PKI (which is what you're basically proposing without realizing it) - and it needs to be trusted, or it's subject to the attacks mentioned.
So far, user-level PKI is a bust. If we had it, encrypted/signed email would be common too.
I'm a slashdot subscriber. I saw this article before it went "live" and reported it as a dup to the editor on duty. Apparently the editor is asleep, adn has been asleep all day.
(I was the Original Poster of the article that this is a dup of.)
1. Adding this ability inherently reduces security for everyone. The fact that this ability exists and that it's designed to make it easy to set up taps makes it an amazingly tempting target, even ignoring misuse by law enforcement.
2. The FBI and government in the US has a history of misusing abilities like this. Witness J. Edgar Hoover. (Many of you may be too young to remember when it was a common joke in college to talk about what files the FBI had on all of us.) Witness how at the time, the FBI was more than willing to use information from illegal wiretaps to embarrass or blackmail people. (Minor figures such as Martin Luther King.) Witness Nixon's "enemies list". (You think Bush wouldn't like that idea if they could get away with it?) How many agents/police feel that bending the rules is justified because they're the "good guys", or that the ends justify the means?
3. In the past they needed a warrant before tapping/keylogging. Post-Patriot Act, it's much looser; all they need is a statement basically, or at most a go-ahead from a secret court (FISA) - you knew we had a secret court, didn't you? And you knew that secret court has never turned down a request? And that Roberts will now be selecting who is on the secret court?
4. Innocent civilians are frequently at risk of abuse of police powers. Witness the Republican convention in Philadelphia in 2000 (before the Patriot Act) - police officers infiltrated all sorts of protest groups, and in some cases incited them to break the law. Peace groups (who mostly are retirees eating cookies at meetings) were infiltrated in California. Officers or officials who have a grudge against someone and target them. Etc, etc.
5. Law enforcement has frequently argued that the results of illegal taps and illegal questioning, etc should not be thrown out.
6. Most importantly, the threat and knowledge that some people get targeted, and some people get tapped, is a MAJOR damper on free speech, political expression, etc. I know that my inlaws (in their 70's) are very reluctant to speak out publicly because they're already afraid that "something" will happen if they do. Just knowing that the police can do this and occasionally do is a massive deterent on the more timid/fearful.
You assume you'll continue to be able to use AES....;-) (See the FBI memo)
Also - what secured your key exchange? How did you _know_ who the other side of the transaction was? And are you sure there are no keyloggers/etc masquerading as normal spyware?
You're correct that CALEA doesn't *authorize* wiretaps - but it does require that providers make calls easily tappable (when they might otherwise be slow, hard or impossible to tap).
And as it applies to VoIP providers, it requires they set things up to allow tapping calls that previously weren't covered (IP-to-IP calls), if the service offers _any_ sort of connection to the PSTN, even through a 3rd party.
TFA has all the footnotes justifying this expansion of powers... Basically if the data goes through a switch or router on a public network, they're covered.
And how do you know the downloads aren't signed? TFTP is fine for a download; it could verify the signature after reception (whether or not they're encrypted). The signature could even be transmitted separately by a different channel.
if someone really wants to avoid John Law they could just write a proprietary program with a proprietary encryption protocol. Is that technically illegal?
If the FBI's policy memo is true and enforced, it could be. Read the second CNET article.
However, if you read the 59-page PDF of the CALEA ruling, you'll see CALEA applies to broadband operators in general. You're correct that it doesn't apply to email services - so hotmail doesn't have to deal with CALEA, but your ISP does.
Also, they state on page 20 that CALEA doesn't apply to the storage of email at your ISP. This is true. However, they state CALEA does apply to the "switching and transmission" component of the ISP's service. So they can't ask for a copy of your stored email - but they CAN ask to tap all the traffic to and from your PC.
High-voltage stuff does have significant fields - though any effect on humans is far, far from proven. The flourescent light trick is cool (and scary to some), but means little. The whole worries over power lines seemed to spring originally from the reporting over Love Canal. Most people don't understand electricity, and the idea of an unseen field flowing through their body is unnerving to them (irregardless of the facts).
Most of the studies of power-lines have trouble accounting for the fact that housing prices right next to HV powerlines are noticably lower - originally mostly for esthetic and sound reasons, now also due to fear of the unknown. In addition to causing different demographics of buyers, there are other related issues. For example, when planning powerlines, they don't just draw a line across a map - they try to minimize the cost of buying the land. Guess what? Brownfields are cheaper, and industrial area have less people objecting than "virgin" suburban land. And once the lines are in, businesses are more likely to be willing to set up shop under/near HV power lines - esthetics isn't as important to them, price is. Businesses (especially in already-low-value areas) tend to be the ones most likely to release toxins (you don't often see that in farmland). Untangling all this is really tough.
This causes a difference in demographics that's hard to account for. And even so, the demographics don't scream "cause".
More to the point, the original commentor was correct - this question is at best misleading and at worst promotes yet more bad science thinking by assuming facts not in evidence. I wonder how many readers won't notice TFA is from 1996, or won't even read it and assume the poster is correct about "increasing evidence".
Ah, yes. That looks right. And the ack sliding windows are twice as large downstream as upstream. I wish I still had design docs; the other PlayNet programmers from then I was able to ping had thrown out what they had some number of moves ago; I'm still in contact with three of the primary programmers, and a few other people who worked there. They're mostly bemused by all this...
P3 - that terminology must be AOL/Quantum specific. (I'd guess P1 was the original PlayNET protocol?)
It avoided NULs and CR's, max 255 characters, header with CRC-16 broken into multiple bytes (4?), packet type (ack/nack/data, though that might have been encoded in other values, I forget), sequence number and an ACK value (sliding windows), 2-character message code (that you refer to), etc. Designed to work over X25 PADs (Telenet, Tymenet). I designed the protocol using the Tannenbaum Networking book as my bible. The CRC-16 was implemented bit-at-a-time on the C64, byte-at-a-time on the Stratus using tables.
Even at Playnet, the data was extracted at the receiver (and CRC's were checked, nack's sent, etc), then the useful data was passed in a message to the handler for that session. The software was VERY message-passing oriented, designed from the start for ridiculous loads to load-balance among server farms (and to support remote server farms). We often tested the modules by writing little programs that let us build and display messages by hand.
All the server code was in PL/1 subset G on Stratuses.
Actually, that vaguely rings a bell (at least about PC-Link). Of course, that was well after PlayNet licensed to CVC/Quantum (summer 1985), and after PlayNET went into bankruptcy and all programmers were laid off (Feb. 1986).
At PlayNET we had strongly considered porting to the Apple II and IBM PC (and Amiga), had an Apple II lying around, etc (color graphic text was a bitch on the Apple II; as best I remember we figured we'd go monochrome for the chat portions of the screen).
Steve Bohram and I went down to CVC to train them on how to modify the system to do things such as change how menu highlighting was done (we moved the menu, they moved the highlight I believe), how to do builds, install new versions, etc. Spent a while with the lead programmer there (can't remember the name, but it would ring a bell).
Quantum finally got out from under the x% of revenue license to the remainders of PlayNET in 87 or 88 (88 I think), at which point the court dissolved the remainders of PlayNET.
The 10-character AOL username limit that was in place until a few years ago was due to the width of a C64 screen, lines we were willing to devote to displaying names, the number of users we wanted to allow in one room, plus roomname, one space and commas; determined over lunch one day. I was always astounded that they hadn't relaxed that limit...
As you can see here: http://slashdot.org/comments.pl?sid=22404&cid=2408 020, I was one of the designers/programmers of PlayNet (which was later tweaked and named QLink). They're _still_ (last I checked) using a variant of my error-correcting protocol designed specifically for X.25 PADs, running over TCP (which is kinda dumb). Now, they may not use it for much anymore; probably mostly just login I'd guess.
I promised these guys I'd dig through my old C64 development disks to see if there's any source; guess I better do that now. Anyone got a 9-track magtape reader lying around that works? I have 3 tapes, one of which might by my personal dump from Way Back Then. (Another I know is my files from GE Corp Research, and one from my RPI ACM account (in EBCDIC)).
PC-link/AppleLink and the similar thing for Amiga developers were, I believe, different from QLink/AOL - BBS/ASCII oriented. QLink/AOL were server/client. However, I don't know PC-Link/AppleLink that well.
Or you base your code on a really useful library at the time, but then that library atrophies and doesn't get updated with support for 'foo' or 'bar', or serious bugs X, Y and Z don't get fixed. You may now be screwed and either have to take over an external project (that you may well not have the skills/resources to handle) or redo your code to replace that libary with something else (which hopefully is available and not TOO much of a modification to use).
The problem is by choosing the short-run-suboptimal choice, the users may never get the long-term benefits you want/claim, because they don't use it or stop using it. Or rather a much smaller number of them will, which is NOT a good thing.
For example, let's say you could prove it was inherently safer to drive on the left (say, due to 9/10 users being right-handed). So you produce a right-hand-drive (driver on right side) car to sell in the US. Can it be used? Yes. Good idea? No.
Now, that's a rather contrived and extreme analogy, but it shows the point. And this isn't an absolute. But anytime you break with a fairly established convention/expectation, you better have a darn good reason (not "I prefer cancel on the left/right/top"), and explain that reasoning to the user and the end benefit to dealing with reworking their expectations/habits. Doubly so since many of them may end up having to switch between conventions on a daily basis.
Let's see... one reason for people finding vulnerabilities might be...
Mozilla.org pays users who find security bugs. Given that the source is available to look for errors in, it makes it easier for people to audit code. This is GOOD, because vulnerabilities and exploits are found BEFORE scammers use them in the wild.
He gave an account of the number of vulnerabilities. He didn't say how many were found to be actively used in the wild against people. That answer is probably wildly more positive for Firefox....
He also doesn't take into account the severity (as you mentioned) of the vulnerabilities.
Disclaimer: I work on mozilla/firefox in my occasional spare time
Smaller and squatter than Homo sapiens but with larger brains, Neanderthals lived in Europe, parts of central Asia and the Middle East for about 170,000 years.
Ummm, they were larger than modern humans... though they did have larger brains (avg 1500-1600cc), though well within the range of modern humans (1000-2000cc, avg 1300cc).
It is interesting to see proof of overlap in a single area, though this isn't surprising. Also, currently mitocondrial data indicates that there isn't a major influx of DNA from them, though some interbreeding could have occurred and survived to today, especially if it conferred a survival advantage in northern climes, for example.
So, if you were to have old ASCII or EBCDIC 9-track tapes, where would one go to get them read? I have some dating to the late 80's I'd love to get the data off of. For amusement, mostly.
I wonder how many "mainstream" programs still read Amiga IFF files (for common types like Deluxe Paint/ILBM, WP files, etc)... Sort of a more-efficient (binary) predecessor to XML; highly extensible with some basic functionalities you could extend (FORM, BODY, etc)
Slashdot Mirror
And what's the other end of your tunnel? If it's a VoIP call, the call setup goes through the VoIP provider, and they're required to not only make the packets available, but also to provide any keys/etc needed to decode it. They're also required to make it impossible for the target to know they're being tapped. This means they can't set up point-to-point IP calls - they'll have to route all calls through RTP proxies, tapped or not. This is a very BAD thing for call quality due to delay.
BTW, you don't want to send media streams in a call over TCP at all. Very bad idea. You could use UDP in an IPSec tunnel in theory, but normal voice protocols don't include any way to establish the tunnel. And you still need to worry about call-setup-induced MiTM.
Correct. The ruling also covers any broadband over 200Kbps separately - i.e. they can force your ISP to tap your connection. The act really is about forcing the ISPs to install equipment to make it EASY to tap by flipping a switch electronically - they already had the power to order a tap; it's just that it might be hard/slow/impossible for the ISP to comply. And yes, this means there's a HUGE gaping hole waiting for someone to exploit. Knowing the capability is there is 1/2 the battle of accessing it, and CALEA spells out a lot of specifics about the interface.
.
This lawsuit is about the part of the ruling that states that in addition to the ISP, any VoIP supplier who has any connection (even through a 3rd party!) to a PSTN gateway must provide the same ease-of-tapping under CALEA for ALL calls. Not just calls going to/from the PSTN, ALL calls.
Colleges are suing as well (separately), over the up to 7 or more BILLION dollars to re-architect and rebuild their campus networks to support this. The original CALEA was aimed at telephone companies; gave them years to comply; and reimbursed them for their expenses. None of that here.
This means Skype (unless they drop SkypeOut/SkypeIn). Ditto Vonage, sipphone, etc. I think FWD might be ok since it's IP-2-IP only.
Check out http://pulver.com/ and Pulver's blog on this http://pulverblog.pulver.com/archives/003241.html
From http://www.xml.com/pub/a/w3j/s3.paoli.html:
"Microsoft cofounded the XML working group at the W3C in July 96 and actively participated in the definition of the standard."
This was used in IE4.00 for their Channel Definition File (used to schedule "Pull" of channels, an idea that's largely died). I was implementing CDF files at Scala in '96/97. The patent was filed in '97.
Note: the CALEA ruling requires that the service provider make it easy and quick to do taps. If that means no encryption, then they can't use encryption (or they have to have a way to recover the keys or MITM the call).
Working with that is the text from the policy statement that users can run whatever devices and programs they want, "subject to the needs of law enforcement". What a difference 7 words make.
They do exempt (from CALEA, not the policy statement) private networks. However, I don't think they consider a VPN over the open internet to be "private". They mean private switches and routers.
The FBI/NSA tried to force backdoors into encryption products before (see Clipper Chip). Those 7 words imply they'd like to do that again, but applied to software running on your PC (which can now encrypt at reasonable levels of security and speed). Which means control of software on you PC, or at least control over streams in/out of your PC - an encrypted stream might be considered evidence of running a "banned" application. Google "Police State".
Right....
That's only as safe as the LDAP server is. (yes, your app may notice the change in key if someone subverts the server - if it had talked to the 'real' other end of the conversation before, and it remembered the key.)
To do this, you need a PKI (which is what you're basically proposing without realizing it) - and it needs to be trusted, or it's subject to the attacks mentioned.
So far, user-level PKI is a bust. If we had it, encrypted/signed email would be common too.
I'm a slashdot subscriber. I saw this article before it went "live" and reported it as a dup to the editor on duty. Apparently the editor is asleep, adn has been asleep all day.
(I was the Original Poster of the article that this is a dup of.)
2. The FBI and government in the US has a history of misusing abilities like this. Witness J. Edgar Hoover. (Many of you may be too young to remember when it was a common joke in college to talk about what files the FBI had on all of us.) Witness how at the time, the FBI was more than willing to use information from illegal wiretaps to embarrass or blackmail people. (Minor figures such as Martin Luther King.) Witness Nixon's "enemies list". (You think Bush wouldn't like that idea if they could get away with it?) How many agents/police feel that bending the rules is justified because they're the "good guys", or that the ends justify the means?
3. In the past they needed a warrant before tapping/keylogging. Post-Patriot Act, it's much looser; all they need is a statement basically, or at most a go-ahead from a secret court (FISA) - you knew we had a secret court, didn't you? And you knew that secret court has never turned down a request? And that Roberts will now be selecting who is on the secret court?
4. Innocent civilians are frequently at risk of abuse of police powers. Witness the Republican convention in Philadelphia in 2000 (before the Patriot Act) - police officers infiltrated all sorts of protest groups, and in some cases incited them to break the law. Peace groups (who mostly are retirees eating cookies at meetings) were infiltrated in California. Officers or officials who have a grudge against someone and target them. Etc, etc.
5. Law enforcement has frequently argued that the results of illegal taps and illegal questioning, etc should not be thrown out.
6. Most importantly, the threat and knowledge that some people get targeted, and some people get tapped, is a MAJOR damper on free speech, political expression, etc. I know that my inlaws (in their 70's) are very reluctant to speak out publicly because they're already afraid that "something" will happen if they do. Just knowing that the police can do this and occasionally do is a massive deterent on the more timid/fearful.
You assume you'll continue to be able to use AES.... ;-) (See the FBI memo)
Also - what secured your key exchange? How did you _know_ who the other side of the transaction was? And are you sure there are no keyloggers/etc masquerading as normal spyware?
Original poster here.
You're correct that CALEA doesn't *authorize* wiretaps - but it does require that providers make calls easily tappable (when they might otherwise be slow, hard or impossible to tap).
And as it applies to VoIP providers, it requires they set things up to allow tapping calls that previously weren't covered (IP-to-IP calls), if the service offers _any_ sort of connection to the PSTN, even through a 3rd party.
TFA has all the footnotes justifying this expansion of powers... Basically if the data goes through a switch or router on a public network, they're covered.
And how do you know the downloads aren't signed? TFTP is fine for a download; it could verify the signature after reception (whether or not they're encrypted). The signature could even be transmitted separately by a different channel.
However, if you read the 59-page PDF of the CALEA ruling, you'll see CALEA applies to broadband operators in general. You're correct that it doesn't apply to email services - so hotmail doesn't have to deal with CALEA, but your ISP does.
Also, they state on page 20 that CALEA doesn't apply to the storage of email at your ISP. This is true. However, they state CALEA does apply to the "switching and transmission" component of the ISP's service. So they can't ask for a copy of your stored email - but they CAN ask to tap all the traffic to and from your PC.
High-voltage stuff does have significant fields - though any effect on humans is far, far from proven. The flourescent light trick is cool (and scary to some), but means little. The whole worries over power lines seemed to spring originally from the reporting over Love Canal. Most people don't understand electricity, and the idea of an unseen field flowing through their body is unnerving to them (irregardless of the facts).
Most of the studies of power-lines have trouble accounting for the fact that housing prices right next to HV powerlines are noticably lower - originally mostly for esthetic and sound reasons, now also due to fear of the unknown. In addition to causing different demographics of buyers, there are other related issues. For example, when planning powerlines, they don't just draw a line across a map - they try to minimize the cost of buying the land. Guess what? Brownfields are cheaper, and industrial area have less people objecting than "virgin" suburban land. And once the lines are in, businesses are more likely to be willing to set up shop under/near HV power lines - esthetics isn't as important to them, price is. Businesses (especially in already-low-value areas) tend to be the ones most likely to release toxins (you don't often see that in farmland). Untangling all this is really tough.
This causes a difference in demographics that's hard to account for. And even so, the demographics don't scream "cause".
More to the point, the original commentor was correct - this question is at best misleading and at worst promotes yet more bad science thinking by assuming facts not in evidence. I wonder how many readers won't notice TFA is from 1996, or won't even read it and assume the poster is correct about "increasing evidence".
Ah, yes. That looks right. And the ack sliding windows are twice as large downstream as upstream. I wish I still had design docs; the other PlayNet programmers from then I was able to ping had thrown out what they had some number of moves ago; I'm still in contact with three of the primary programmers, and a few other people who worked there. They're mostly bemused by all this...
P3 - that terminology must be AOL/Quantum specific. (I'd guess P1 was the original PlayNET protocol?)
It avoided NULs and CR's, max 255 characters, header with CRC-16 broken into multiple bytes (4?), packet type (ack/nack/data, though that might have been encoded in other values, I forget), sequence number and an ACK value (sliding windows), 2-character message code (that you refer to), etc. Designed to work over X25 PADs (Telenet, Tymenet). I designed the protocol using the Tannenbaum Networking book as my bible. The CRC-16 was implemented bit-at-a-time on the C64, byte-at-a-time on the Stratus using tables.
Even at Playnet, the data was extracted at the receiver (and CRC's were checked, nack's sent, etc), then the useful data was passed in a message to the handler for that session. The software was VERY message-passing oriented, designed from the start for ridiculous loads to load-balance among server farms (and to support remote server farms). We often tested the modules by writing little programs that let us build and display messages by hand.
All the server code was in PL/1 subset G on Stratuses.
Actually, that vaguely rings a bell (at least about PC-Link). Of course, that was well after PlayNet licensed to CVC/Quantum (summer 1985), and after PlayNET went into bankruptcy and all programmers were laid off (Feb. 1986).
At PlayNET we had strongly considered porting to the Apple II and IBM PC (and Amiga), had an Apple II lying around, etc (color graphic text was a bitch on the Apple II; as best I remember we figured we'd go monochrome for the chat portions of the screen).
Steve Bohram and I went down to CVC to train them on how to modify the system to do things such as change how menu highlighting was done (we moved the menu, they moved the highlight I believe), how to do builds, install new versions, etc. Spent a while with the lead programmer there (can't remember the name, but it would ring a bell).
Quantum finally got out from under the x% of revenue license to the remainders of PlayNET in 87 or 88 (88 I think), at which point the court dissolved the remainders of PlayNET.
The 10-character AOL username limit that was in place until a few years ago was due to the width of a C64 screen, lines we were willing to devote to displaying names, the number of users we wanted to allow in one room, plus roomname, one space and commas; determined over lunch one day. I was always astounded that they hadn't relaxed that limit...
As you can see here: http://slashdot.org/comments.pl?sid=22404&cid=2408 020, I was one of the designers/programmers of PlayNet (which was later tweaked and named QLink). They're _still_ (last I checked) using a variant of my error-correcting protocol designed specifically for X.25 PADs, running over TCP (which is kinda dumb). Now, they may not use it for much anymore; probably mostly just login I'd guess.
I promised these guys I'd dig through my old C64 development disks to see if there's any source; guess I better do that now. Anyone got a 9-track magtape reader lying around that works? I have 3 tapes, one of which might by my personal dump from Way Back Then. (Another I know is my files from GE Corp Research, and one from my RPI ACM account (in EBCDIC)).
Amiga was never supported by QLink...
PC-link/AppleLink and the similar thing for Amiga developers were, I believe, different from QLink/AOL - BBS/ASCII oriented. QLink/AOL were server/client. However, I don't know PC-Link/AppleLink that well.
Or you base your code on a really useful library at the time, but then that library atrophies and doesn't get updated with support for 'foo' or 'bar', or serious bugs X, Y and Z don't get fixed. You may now be screwed and either have to take over an external project (that you may well not have the skills/resources to handle) or redo your code to replace that libary with something else (which hopefully is available and not TOO much of a modification to use).
The problem is by choosing the short-run-suboptimal choice, the users may never get the long-term benefits you want/claim, because they don't use it or stop using it. Or rather a much smaller number of them will, which is NOT a good thing.
For example, let's say you could prove it was inherently safer to drive on the left (say, due to 9/10 users being right-handed). So you produce a right-hand-drive (driver on right side) car to sell in the US. Can it be used? Yes. Good idea? No.
Now, that's a rather contrived and extreme analogy, but it shows the point. And this isn't an absolute. But anytime you break with a fairly established convention/expectation, you better have a darn good reason (not "I prefer cancel on the left/right/top"), and explain that reasoning to the user and the end benefit to dealing with reworking their expectations/habits. Doubly so since many of them may end up having to switch between conventions on a daily basis.
Exactly.
Let's see... one reason for people finding vulnerabilities might be...
Mozilla.org pays users who find security bugs. Given that the source is available to look for errors in, it makes it easier for people to audit code. This is GOOD, because vulnerabilities and exploits are found BEFORE scammers use them in the wild.
He gave an account of the number of vulnerabilities. He didn't say how many were found to be actively used in the wild against people. That answer is probably wildly more positive for Firefox....
He also doesn't take into account the severity (as you mentioned) of the vulnerabilities.
Disclaimer: I work on mozilla/firefox in my occasional spare time
It is interesting to see proof of overlap in a single area, though this isn't surprising. Also, currently mitocondrial data indicates that there isn't a major influx of DNA from them, though some interbreeding could have occurred and survived to today, especially if it conferred a survival advantage in northern climes, for example.
So, if you were to have old ASCII or EBCDIC 9-track tapes, where would one go to get them read? I have some dating to the late 80's I'd love to get the data off of. For amusement, mostly.
I wonder how many "mainstream" programs still read Amiga IFF files (for common types like Deluxe Paint/ILBM, WP files, etc) ... Sort of a more-efficient (binary) predecessor to XML; highly extensible with some basic functionalities you could extend (FORM, BODY, etc)
r /LW80/8lwsdk/docs/filefmts/ilbm.html
I know Gimp supports it via a plugin. Here's a Newtek/Lightwave link:
http://www.newtek.com/products/lightwave/develope