If he's still using the system he presented last summer at BlackHat, he's actually doing something rather clever:
The system does a standard Diffie-Hellman key exchange between the two softphones, and hashes that exchange to words that each caller is supposed to read to the other (you see what they're supposed to say, and they see what you're supposed to say). So, unless the man-in-the-middle can also impersonate your voice, MITM'ing the connection is very difficult.
Also, the hashes used to generate that vocal exchange are stored for each destination you call for every call, and fed into the new hash generation. So, even if you skip a round of comparing the hashes, if you do it for a later call & it works, you can be assured that the *previous* call was also clean.
I know you're kidding, but jiggling it back and forth is probably exactly what they're going to do. If it's just stuck in place, that's probably the least dangerous thing to try to fix it. Since they can't exactly go out & fix it (it's rather far away), you start with the stuff that's easy & obvious.
Nonono. Jar Jar was meant to be Boba Fett, but Lucas chickened out. See, at the big lightsabre duel at the end of episode III, Jar Jar was supposed to fall in the lava, disfiguring him so totally that he needed the suit to survive, and tearing away any hint of cheer from his personality. But, by episode II, Lucas had decided that this tragic arc of JarJar to Boba was too distracting from the tragic arc of Anakin to Darth, so he left it out. (The fact that people were cheering when they read that scene of the script may have influenced the decision as well.)
Nintendo has had front-page headlines in the game world for a week with almost zero marketing cost to them. *Everyone* in the game community knows the name and identity of their product.
From a marketing point of view, this name is a colossal success. It worked. You know what their product is, you know what it's for, you remember its name. That's all that matters.
Speakeasy has a POP in the DC area. If you can get DSL, you can most likely get them. They're not the cheapest out there, but their sysadmin packages include static IPs standard, and they have no problems changing reverse DNS on the IPs they give you to whatever you ask (which is part of why my home mail server is still going...my forward and reverse match).
I'm rooting for them to shift to rappers after the animal thing's done. Easy-E, Marky Mark...there's a huge collection waiting to be used. As a plus, a rapper-themed naming scheme has built-in celebrity endorsement tie-ins. ("Use Ubuntu, yo! Fo Shiz!")
Oracle's security record is abyssmal, their products have major usability issues (yes, including their database...god that thing's arcane), and the company itself is arrogant as hell. Please, don't let that beast absorb a sensible distro.
Patches from MS are cryptographically signed. You need to do more than just poison teh DNS for these hosts. You need to either steal MS' private signing key or break RSA.
Offtopic a bit, but it may be interesting to note that almost no one is actually claiming "Common Carrier" status. Including AOL. The problem is that being a "Common Carrier" in the US includes several requirements that people don't want to meet.
Also, note that from the wiki entry on common carriers ISPs aren't considered telecommunications services (where common carrier status applies)...they're "information services":
...which holds that ISP service (both "retail" and backbone) is an "information service" (not subject to common carrier obligations) rather than a "telecommunications service" (which might be classified as "common carriage").
So, they're already not a common carrier. They probably never really were.
As I said, if an ISP offers a service to third parties that allows the third party to bump up the user's bandwidth (ie my 1.5Mbps connection becomes a 5Mbps, with the extra 3.5Mbps being reserved for the third party), then nobody's service is being downgraded.
QoS (which is the only way that exists today to do this kind of thing that I know of) doesn't work that way. If you want dynamic re-provisioning of bandwidth based on source messaging, you're going to have to get the IETF to design a new protocol to handle it, and get the vendors to agree to implement it. That won't happen anytime in the next 6-10 years, if ever. Since this seems duplicative of QoS, and would only apply to a small number of access link methods that have extra bandwidth (you couldn't do this on a T1 line, for example...it has a fixed bandwidth with no extra overhead), I wouldn't be optimistic.
In the meantime, we have to live with what we have, which is QoS. QoS can only make latency/bandwidth worse, not better.
But at the same time, I don't necessarily see a problem with external entities being able to pay my ISP for better access.
A very insightful person (who I should be attributing, but I don't remember who it was...sorry) once said:
QoS cannot improve service. It can only degrade.
In other words, your ISP won't give paying sites "better" access. It will give non-paying sites *worse* access. I know this seems like splitting hairs, but it's an important thing to realize for how they're managing their network: they're not proposing making things better for some...they're proposing making things worse for everyone else.
All this is really an argument for a base at L4 or L5, if you ask me:
Pro:
Just as close as the moon
Smaller gravity well from the moon, though still gravitationally stable
No dust
No issues with rotation blocking sunlight for solar cells
Con:
No resources at all, have to ship in everything.
I think whoever starts building at L4/L5 first will have a huge long-term advantage over any of the other space-faring groups. Lack of supplies is, I think, a minor concern, given that we'll have to do the same for a Moon station.
There are really two paths you're talking about here, and folks tend to confuse the two:
1) Software *development* change mangement. Meaning: tracking things like changes to software code.
2) Software *configuration* change management. Meaning: tracking changes to the configuration of the software. I presume you're talking about this one, but it's not completely clear.
Development change management is well served by tools of varying complexity from ClearCase to Subversion/CVS. Subversion/CVS seem to be very common, as they're free, but I've worked in offices using ClearCase before (not that anyone was terribly happy about it, though).
Configuration change management is much harder, as you're talking about managing the configuration of applications across potentially hundreds of machines. The tools for this vary widely, depending on how hard-core you want to be. They vary from CFengine to full-on provisioning systems (openQMS, for example)...none of them tend to be easy to set up or manage, which makes them less common.
1) compressors have nothing to do with frequency. What they do is slow the growth of amplitude in a sound, after hitting a certain trigger level. They do this across the board for all frequencies: they're amplitude devices, not a frequency ones.
2) Setting up a compressor *right* is a skill, and is very dependent on the sound you're compressing. A poorly-configured compressor sounds like crap. You do not want to hear the compressor "breathing" (triggering & releasing hard & quickly)...it sounds like ass.
3) The compressor has no idea what sound level is actually coming out of the headphones. All it knows about is the electric signal passing through it. So, it would have to be set for specific headsets, as the different headsets are more/less efficient. This would be complicated & expensive.
4) Classical music folks *hate* compressors. You can hear the difference when you compress classical, and it sounds wrong. You really don't want to do this to classical if you can at all avoid it.
We're arguing about it (and we care) because we have evidence in the past of Verisign pulling messy stunts with.com and.net (wildcarding the zone, for example), and refusing to back down until threatened with legal action by ICANN and an outraged user base.
They still don't acknowledge that the wildcard was a bad idea, and they've as much as promised to do it again, once they have the legal clearances in place to stop ICANN from messing with them.
Verisign has proven themselves untrustworthy, and the root of the DNS is a big deal. Therefore, we care. You should, too.
NASA's scientific consitituency is the scientists that make up NASA's grant applicants. Basically, it's the group of folks who are qualified & likely to win NASA research grants. It's an obvious statement that NASA doesn't have the funding to run *all* of the programs that people want to run, so his statement is a massive understatement of the problem.
The problem has been that NASA is not only declining to fund new satellite programs, they're also cutting funding for existing ones, and going back on promises to fund projects already underway. (Some commentary from Nature on the subject is at http://www.nature.com/nature/journal/v439/n7078/fu ll/439768a.html...unfortunately you need to subscribe to read it. The short version is that more than one sattelite program has learned from a press releasese that their funding was being cut...sometimes years after they'd started building based on earlier funding, and just weeks after being promised this wouldn't happen.)
I see the effect mentioned in the article (lots of work, more coming, so you don't have time to fully *finish* everything) in offices with lots of tech-savvy workers, and in offices without them. I don't think tech familarity fixes the problem, it just shifts which problems become your time sinks.
I think that's the core of the problem: not that we're getting better at tech, but that finishing some tasks faster with tech doesn't necessarily allow us to actually *accomplish* more. (Does it help me accomplish more if I can talk to my boss more often via email? Maybe. Maybe not.)
I hate to sound like a fogey, but I'm in my mid-thirties, I grew up using computers, and trust me, it won't help.
The problem is not familiarity with computers. It's an overload of tasks. Productivity is expected to rise on a regular basis (heck, we measure the growth of our economy this way), which means we are expected to do more with the same resources. Automation of common tasks has helped immensely in keeping up with this curve, but eventuallly the edge cases (the things that don't fit in the automation) overwhelm your time.
I'm starting to see that regularly at my office: I've automated about as much as I can automate, and my job now consists of firefighting the systems that (for various technical and political reasons) I can't automate. It's not that I don't know how to use computers, it's that the task list is rising faster than I can finish them or automate them away.
I ran into this a while ago, and found a commentary on French encryption. This has apparently been relaxed since that paper was written, but as recently as a few years ago, you could still only use 40-bit encryption in France due to French law (without escrowing your keys to them).
The 40-bit limitation is not a US limitation, it's a French one. For quite a while (don't know if this has changed recently or not), the French government would not allow any encryption to be used in France that the government couldn't break.
Slashdot Mirror
If he's still using the system he presented last summer at BlackHat, he's actually doing something rather clever:
The system does a standard Diffie-Hellman key exchange between the two softphones, and hashes that exchange to words that each caller is supposed to read to the other (you see what they're supposed to say, and they see what you're supposed to say). So, unless the man-in-the-middle can also impersonate your voice, MITM'ing the connection is very difficult.
Also, the hashes used to generate that vocal exchange are stored for each destination you call for every call, and fed into the new hash generation. So, even if you skip a round of comparing the hashes, if you do it for a later call & it works, you can be assured that the *previous* call was also clean.
I know you're kidding, but jiggling it back and forth is probably exactly what they're going to do. If it's just stuck in place, that's probably the least dangerous thing to try to fix it. Since they can't exactly go out & fix it (it's rather far away), you start with the stuff that's easy & obvious.
Nonono. Jar Jar was meant to be Boba Fett, but Lucas chickened out. See, at the big lightsabre duel at the end of episode III, Jar Jar was supposed to fall in the lava, disfiguring him so totally that he needed the suit to survive, and tearing away any hint of cheer from his personality. But, by episode II, Lucas had decided that this tragic arc of JarJar to Boba was too distracting from the tragic arc of Anakin to Darth, so he left it out. (The fact that people were cheering when they read that scene of the script may have influenced the decision as well.)
Nintendo has had front-page headlines in the game world for a week with almost zero marketing cost to them. *Everyone* in the game community knows the name and identity of their product.
From a marketing point of view, this name is a colossal success. It worked. You know what their product is, you know what it's for, you remember its name. That's all that matters.
Speakeasy has a POP in the DC area. If you can get DSL, you can most likely get them. They're not the cheapest out there, but their sysadmin packages include static IPs standard, and they have no problems changing reverse DNS on the IPs they give you to whatever you ask (which is part of why my home mail server is still going...my forward and reverse match).
I'm rooting for them to shift to rappers after the animal thing's done. Easy-E, Marky Mark...there's a huge collection waiting to be used. As a plus, a rapper-themed naming scheme has built-in celebrity endorsement tie-ins. ("Use Ubuntu, yo! Fo Shiz!")
Oracle's security record is abyssmal, their products have major usability issues (yes, including their database...god that thing's arcane), and the company itself is arrogant as hell. Please, don't let that beast absorb a sensible distro.
Nononono, it's Oracle Web Novell Enterprise Desktop.
Patches from MS are cryptographically signed. You need to do more than just poison teh DNS for these hosts. You need to either steal MS' private signing key or break RSA.
Let me know if you manage the second one.
I have 3 words for you: Mythical Man Month.
Also, note that from the wiki entry on common carriers ISPs aren't considered telecommunications services (where common carrier status applies)...they're "information services":
So, they're already not a common carrier. They probably never really were.
QoS (which is the only way that exists today to do this kind of thing that I know of) doesn't work that way. If you want dynamic re-provisioning of bandwidth based on source messaging, you're going to have to get the IETF to design a new protocol to handle it, and get the vendors to agree to implement it. That won't happen anytime in the next 6-10 years, if ever. Since this seems duplicative of QoS, and would only apply to a small number of access link methods that have extra bandwidth (you couldn't do this on a T1 line, for example...it has a fixed bandwidth with no extra overhead), I wouldn't be optimistic.
In the meantime, we have to live with what we have, which is QoS. QoS can only make latency/bandwidth worse, not better.
A very insightful person (who I should be attributing, but I don't remember who it was...sorry) once said:
QoS cannot improve service. It can only degrade.
In other words, your ISP won't give paying sites "better" access. It will give non-paying sites *worse* access. I know this seems like splitting hairs, but it's an important thing to realize for how they're managing their network: they're not proposing making things better for some...they're proposing making things worse for everyone else.
All this is really an argument for a base at L4 or L5, if you ask me:
Pro:
Just as close as the moon
Smaller gravity well from the moon, though still gravitationally stable
No dust
No issues with rotation blocking sunlight for solar cells
Con:
No resources at all, have to ship in everything.
I think whoever starts building at L4/L5 first will have a huge long-term advantage over any of the other space-faring groups. Lack of supplies is, I think, a minor concern, given that we'll have to do the same for a Moon station.
There are really two paths you're talking about here, and folks tend to confuse the two:
1) Software *development* change mangement. Meaning: tracking things like changes to software code.
2) Software *configuration* change management. Meaning: tracking changes to the configuration of the software. I presume you're talking about this one, but it's not completely clear.
Development change management is well served by tools of varying complexity from ClearCase to Subversion/CVS. Subversion/CVS seem to be very common, as they're free, but I've worked in offices using ClearCase before (not that anyone was terribly happy about it, though).
Configuration change management is much harder, as you're talking about managing the configuration of applications across potentially hundreds of machines. The tools for this vary widely, depending on how hard-core you want to be. They vary from CFengine to full-on provisioning systems (openQMS, for example)...none of them tend to be easy to set up or manage, which makes them less common.
A few things:
1) compressors have nothing to do with frequency. What they do is slow the growth of amplitude in a sound, after hitting a certain trigger level. They do this across the board for all frequencies: they're amplitude devices, not a frequency ones.
2) Setting up a compressor *right* is a skill, and is very dependent on the sound you're compressing. A poorly-configured compressor sounds like crap. You do not want to hear the compressor "breathing" (triggering & releasing hard & quickly)...it sounds like ass.
3) The compressor has no idea what sound level is actually coming out of the headphones. All it knows about is the electric signal passing through it. So, it would have to be set for specific headsets, as the different headsets are more/less efficient. This would be complicated & expensive.
4) Classical music folks *hate* compressors. You can hear the difference when you compress classical, and it sounds wrong. You really don't want to do this to classical if you can at all avoid it.
We're arguing about it (and we care) because we have evidence in the past of Verisign pulling messy stunts with .com and .net (wildcarding the zone, for example), and refusing to back down until threatened with legal action by ICANN and an outraged user base.
They still don't acknowledge that the wildcard was a bad idea, and they've as much as promised to do it again, once they have the legal clearances in place to stop ICANN from messing with them.
Verisign has proven themselves untrustworthy, and the root of the DNS is a big deal. Therefore, we care. You should, too.
Two reasons:
Healer/Nuker/Warrior
NASA's scientific consitituency is the scientists that make up NASA's grant applicants. Basically, it's the group of folks who are qualified & likely to win NASA research grants. It's an obvious statement that NASA doesn't have the funding to run *all* of the programs that people want to run, so his statement is a massive understatement of the problem.
u ll/439768a.html ...unfortunately you need to subscribe to read it. The short version is that more than one sattelite program has learned from a press releasese that their funding was being cut...sometimes years after they'd started building based on earlier funding, and just weeks after being promised this wouldn't happen.)
The problem has been that NASA is not only declining to fund new satellite programs, they're also cutting funding for existing ones, and going back on promises to fund projects already underway. (Some commentary from Nature on the subject is at http://www.nature.com/nature/journal/v439/n7078/f
I see the effect mentioned in the article (lots of work, more coming, so you don't have time to fully *finish* everything) in offices with lots of tech-savvy workers, and in offices without them. I don't think tech familarity fixes the problem, it just shifts which problems become your time sinks.
I think that's the core of the problem: not that we're getting better at tech, but that finishing some tasks faster with tech doesn't necessarily allow us to actually *accomplish* more. (Does it help me accomplish more if I can talk to my boss more often via email? Maybe. Maybe not.)
I hate to sound like a fogey, but I'm in my mid-thirties, I grew up using computers, and trust me, it won't help.
The problem is not familiarity with computers. It's an overload of tasks. Productivity is expected to rise on a regular basis (heck, we measure the growth of our economy this way), which means we are expected to do more with the same resources. Automation of common tasks has helped immensely in keeping up with this curve, but eventuallly the edge cases (the things that don't fit in the automation) overwhelm your time.
I'm starting to see that regularly at my office: I've automated about as much as I can automate, and my job now consists of firefighting the systems that (for various technical and political reasons) I can't automate. It's not that I don't know how to use computers, it's that the task list is rising faster than I can finish them or automate them away.
...the report says basically "we don't know anything, but we think it's hard, so they won't make it."
Right. Remind me to call them nextx time I need random guesswork done.
I ran into this a while ago, and found a commentary on French encryption. This has apparently been relaxed since that paper was written, but as recently as a few years ago, you could still only use 40-bit encryption in France due to French law (without escrowing your keys to them).
The 40-bit limitation is not a US limitation, it's a French one. For quite a while (don't know if this has changed recently or not), the French government would not allow any encryption to be used in France that the government couldn't break.