The false-positive rate should be emphasized far more than it has been. What does it mean? It means that whatever system they have in place, if it's based on statistical indicators rather than someone's hunch, will inevitably identify several innocent people for every terrorist that they find. Depending on the sensitivity of the detection algoritm, the value of "several" could be anywhere from dozens to thousands.
Not only that - false positives can CREATE additional new terrorists and otherwise drive large numbers of people toward opposition political positions.
Persons flagged are subjected to additional scrutiny. Body searches, luggage searches, X-ray rather than magnetometer scanning, and so on. This results in added delays, inconvenience, and potential health risks (to both the subject and future offspring, from both stress and X-ray exposure). And since the system flags them because of their on-record characteristics, they will be subjected to this scruitny repeatedly. Effectively it creates an underclass of people who will be constantly hassled during air travel - just as Jim Crow laws once made southern blacks ride in the back of the bus.
This treatment can be expected to "radicalize" those subjected to it - making them more prone to opposition activity and recruitment by terrorists. (Claims, for instance, that the US government is satanic and attempting to destroy Islam are far more believable if the US government IS systematically dumping on Muslims' civil rights.)
This isn't just academic. I watched a similar thing occur during the Viet Nam conflict.
Nice Jewish kid. Offspring of a famous doctor/medical researcher/research organization head/discoverer of a neurotransmitter/etc. In high-school in top-tier suburb of major city. Duly propagandized with how awful the NAZIs were in WW II and "never [let it happen] again".
Friend got a pair of the just-out hi-tek transorized CB walkie-talkie toys. James Bond movies and their takeoffs (Man from Uncle etc.) were all the rage. Two of 'em were using walkie-talkies to play a game of spy/counterspy through the back streets and parks of the suburb.
Unbeknownst to them, the President was passing through the next morning, on his way to give a commencement address at a large university maybe 50 miles away. (Not something that made the news in the area, since the airport was BETWEEN the two cities.)
Secret service hears the CB chatter, swoops down, and grabs the two kids off the street. Separates them and holds them overnight and through much of the next day, incommunicado and in solitary confinement, while the president makes his trip and return. Totally terrorizes the "nice jewish kid" (who isn't even told what's happening until release).
Kid went on to become a campus radical, drop out of college, and dedicate self to left-wing, anarchist, and radical labor union activity - for decades. Finally burned out and found a bed-board-and-pocket-change position as a quadraplegic's aide. Disowned by family for decades (only reconciled at all in the last couple years).
Multiply such an experience by the number of people flagged by the CAPS system and see where it might get us.
[...W]e associate our VPN client with a personal firewall, so that when you're VPN-ed in, ALL data flows the VPN to the corporate network before getting out to the internet. So your POP3 password is securely transmitted (over the IPSec tunnel) to the inside, and then goes out from there. Similarly web broswing goes inside, then through our corporate proxy server and then outside.
That's the way to go: Use an encrypted tunnel to work (or home or wherever) and use the site at the other end of the tunnel as your forwarder/proxy for everything.
[...]VPN [rather than other fancy stuff] should [also] be the right answer [for in-building wireless].
Again dead on. In-building wireless doesn't STAY in-building. So treat it like the general internet, put it on the OUTSIDE of your firewall, and secure-tunnel through for access inside.
Option 1: You can treat your APs and the general Internet as TWO separate external nets, both outside your firewall. Then your laptop has to tunnel in and authenticate to make any use of the AP, effectively becoming wired to your lan.
Option 2: You can treat them as ONE outside-the-firewall net, routing packets between them as well as from each to your firewall. Then you become a hot-spot, and visitors (customers, vendors, partners) can also use THEIR laptops to VPN to THEIR private nets (or surf the web B-) ) without having privileges on YOUR local net.
For option 2 you can use WEP as a no-tresspassing sign (post the netname and current password or have them get it from security or their inside contact), set up some other authentication mechanism, or leave your APs open (if you want to do your neighbors a service).
Curious to figure out how it might work, I looked up my domain name. It gave me an address in Redwood City, CA. WTF?
(I once hosted with an ISP who had a POP there, but not at that location. My domain record has my correct address, as well as the correct contact addresses - which are in a different city in the same metro area.)
Digging around with google for that street address came up with Greatcircle - the maintainers of the majordomo mailing list. Nice guys, but I've never been associated with them. (Ought to install it some day. Back when I hosted mailing lists I administered them manually.)
Turns out that they've been using my domain name in their documentation as a generic domain name. And the doc is all over the web - including several mailing list archives in which Brent Chapman's signature appears, giving the company address. B-) Of course the doc is also on their website, as is there address.
Given the broad use and extensive documentation of majordomo, and the relatively low profile of my own little consulting firm, I suspect that my domain name appears on the net more often associated with the former than the latter.
I suspect the service is using webcrawler information to create a database of search terms vs things-that-look-like-addresses (either on the same page or the same site) then scoring matchups by frequency, and the search engine returns the highest score.
(Meanwhile I've found out where the spambots are harvesting one of the bogus usernames that keep showing up in spam to my site. B-) )
How long before someone bootstraps a distributed Artificial life simulator to their virus and then we all watch in amazement as the first AI evolves and owns all our computers. This could never happen though...right?
For a mainframe version of the story see _The Adolescence of P1_.
(I'd dig up an Amazon link but I'm busy right now.)
How About...Not having TLD at all... Like http://slashdot
That was ALREADY broken decades ago - which is why the dot.ist.domain.addressing was invented.
UUCP Mailnet (and others) used simple site names in a single namespace. Wile you could supply!an!explicit!route!to!somesite!joe, there were add-on tools that would examine the maps and let you mail joe@somesite.
But with all the sitenames in a common single namespace it was a BITCH to administer. After a short time all the "good" short names were taken. And as things other than mail needed naming (like sites with hundreds or thousands of desktops) it just got silly.
So the hierarchical namesystem was set up, with the three-pronged goals of automating the routing more generally, spreading the administrative load, and allowing the addition of machines at a site without further interaction with an outside authority.
Then it went commercial - with TLDs of.com,.net,.edu, and.gov. And essentially everybody ended up competing for second-level domains in.com. And Network Solutions started charging for them ($50/year at first). And made a bundle by essentially recreating the original broken system one level down under.com and charging to do the administration.
And it's evolved from there.
The commercial registries have no incentive to promote their own competition. ICANN is in their pocket and adding TLDs has implications netwide (since some customer systems, as well as the root servers, need tweaking for new TLDs). Thus addition of TLDs is glacial.
And sod the whingeing about "competitors having access to your 'proprietary information'". Your competitors already pay people to reverse-engineer your products, and you will get access to their "proprietary information".
That argument will NOT cut ice with corporations. Reverse-engineering costs a LOT - both in money and in time-to-market. And corporate executives, who have to actually PAY for software (and other) development have a real feel for just HOW MUCH it costs and HOW LONG it takes.
Once the knockoff is on the market they have to lower their prices, so every quarter they hold that off is another quarterly report with a high, rather than a low, profit margin.
If you want to convince them you have to show them how using open source gives them an advantage that more than compensates.
Two big ones are:
- It cuts their development costs to a pittance compared to doing it all themselves or buying the bulk of it. (This means that they don't have as large an investment to recover before it gets cloned and the price is driven down to commodity levels. In turn that means they can establish themselves and be ready to keep making money at commodity pricing levels.)
- It gets them to market much sooner (so even if the tail gets chopped off the neck is lengthened.)
First you have to gain access to the facility, then you have to have access to that area and then you have to have access to the files. It is not that easy to just stroll in there and get a copy of them.
At least in the case of the indian stuff it wasn't an issue of getting copies of the information.
They "lost" essentially all of the indians' money - and the records were corrupted enough that it was no longer possible to trace who took it.
The bureaucrats in charge (the likely suspects) then took advantage of the insecure network to finger-point away from themselves. And the systems were taken offline when it was shown that they were STILL wide open.
But now some people are starting to have REALLY fast pipes. And for them TCP is becoming the limiting factor.
Its pretty darn easy to get really fast pipes. Motherboards ship with Gigabit ethernet now, Gigabit switches are way down in price. Most companies these days are building their networks on TCP/IP, this could be a pretty big thing corporate networks, iSCSI, etc. 10GigE isnt all that far away either.
The much higher speeds on a LAN are a good point.
But.
"The Wall" for TCP is a lot faster within a building than across a continent.
The limit comes primarily from round-trip dealy - which is much shorter when things are microseconds apart then when they're milliseconds apart at speed-of-light-in-wire-or-fiber.
The limit also comes from timeouts after lost or corrupted packets - from line flakeyness or congestion. But line flakeyness is nearly nonexistent on a LAN. As for congestion, if you're using switches rather than hubs it's also not as much of an issue within a building as it is in a cross-continent backbone.
It would be interesting to know how far out an implimentation of such a protocol on a large scale is.
It already IS implemented.
Or do you mean a large-scale "rollout"?
If so, why bother? Unless you have a REALLY fat pipe and need to use it all for one stream, of course. (But not many need to do that, and the ones that do can now install it on both end points.)
The phrasing of the article is leading to confusion. This is about a PROTOCOL, not about the UNDERLYING TRANSPORT.
The TCP protocol, with its windows, handshaking turnarounds, and timeouts, imposes its own limit on the speed of the data transfer through it. For decades the limit imposed by TCP was so far above the limits imposed by the data rates of the underlying transport that it wasn't a major issue.
But now some people are starting to have REALLY fast pipes. And for them TCP is becoming the limiting factor.
So now reasearchers have come up with a tweaked version of TCP that won't hit the wall until the pipe is a LOT faster than what YOU can rent from your ISP. (Unless you're renting an OC-192, in which you might be starting to fall a little short of its capacity. But if you've got OC-48 or below you're fine.)
When you CAN rent something over 6 Gbps, and you want to routinely use it all for a single TCP connection to get a REALLY FAST fast download, you might want to ask the nice professors for a THIRD generation TCP. B-)
Meanwhile, if you're on an ordianry connection you're not going to increase your data rate by a factor of 6,000 by switching protocols. You might get a little bit closer to the line rate with this SECOND generation TCP. But that's it.
Expect to see this start to gradually start showing up in protocol stacks as an option - automatically configured if both ends know about it and the inventors have come up with a backward-compatible negotiation. That way you'll be able to make better use of fat pipes when you can finally get them.
I suppose that if you arbitrarily come up with a rule saying there can be only one person with a given set of recollections at a given religious destination for souls, then you can declare as a consequence that the soul is moved, not destroyed, or you'll have two John Does in heaven (or hell) (or purgatory) (or whatever you believe in), arguing over which one is the real one.
While it may not solve the metaphysical issues, one "advantage" of quantum teleportation is that you still end up with just one copy.
Hesienberg Uncertainty keeps you from measuring ALL of the state of the original, so you can't make an exact copy. Quantum Teleportation sidesteps this by using quantum-entangled matter at both ends, and interacting the original with one half of the quantum-entangled matter, measuring the result of its interaction and sending that information to the far end, where it forces the other half of the matter into a state totally duplicating the origianl. But the original is destroyed in the process.
The net result is you start with the original HERE, made out of a set of particles in state set A, and after you send the message and process it at the far end you end up with a totally indistinguishible set of particles in state set A THERE, with a mass of junk HERE. (It could be argued that what ended up at the far end is the original set of particles, which tunneled through and exchanged mass with the set at the far end.)
So no cloning of souls necessary. (Just assume that a soul, if it exists (and is actually different from the pattern of matter), stays "attached" to the pattern as the pattern is transferred from one place to another via quantum tweaks and information transfer rather than by physical motion.)
I don't know about you, but I'd be much less worried about whether I was still me after transmission by a device where physical limits of the universe prevent making a copy than if I were "transmitted" by remote duplication.
Spray hypodermics predated the Star Trek series. McCoy's injector was based on them - though of course vastly improved. (Dial-a-drug, hand-held rather than big gun with compressor sidekick, etc.)
The original discovery was made when a worker handled a high-pressure hydraulic hose with a pinhole leak, and reported to medical with a sore spot in his hand. The medic found a teaspoon or so of hydraulic fluid under the skin - but the worker hadn't felt it going in. Investigation quickly identified the leak and thus resulted in the discovery that a very small, very high-speed, jet of fluid will go subcutaneous or even intramusclular with minimal sensation.
Somehow this info didn't get lost, but resulted in the bright idea of doing it deliberately to reduce the discomfort and increase the speed and convenience of injections - especially mass injections. The military funded development of the first devices (primarily because they have to innoculate thousands of troops in batches efficiently, and also so they could innoculate a civilian population rapidly in case of a biowar attack - this being during the "cold war".)
But how do they determine who has "computer skills"?
Doesn't matter. They never put you to work in your specialty anyhow.
Or do it nearly so - like the expert electronics guy they assigned to dig (by hand) trenches to drive the radar trucks into so only the antenna was above ground, back in WW II.
For instance: Subscribing the Detroit area spammer and his lawyer to enough real-world junkmail lists to bury his bills and other US Main correspondence in several daily truckloads of catalogues and other solicitations
With all due respect, get a clue.
You don't fight a noisy neighbor by cranking up your stereo.
With all due respect, try actually reading what I wrote.
I didn't say it was RIGHT to do this. I PREDICTED that it WOULD HAPPEN. Very different thing.
Was out to lunch with three colleagues today and the subject of anti-spam measures came up.
I managed to appall the one from Berkeley by suggesting that the most practical solution was probably a moderate-size bomb.
B-)
But seriously:
In an arms race, weapons eventually defeat armor. Spam will continue until two real-world things are BOTH brought to bear on spammers:
- Economics
- Muscle
If a governmental solution applying both is not forthcoming soon, I predict that there WILL be vigilantism.
In fact we're already seeing it.
For instance: Subscribing the Detroit area spammer and his lawyer to enough real-world junkmail lists to bury his bills and other US Main correspondence in several daily truckloads of catalogues and other solicitations.
Soon to come: Retaliatory information-war software directed at DDoSer / spammer zombi-net machines. (As discussed in a recent Slashdot article.)
So software, claiming to be from Microsoft with a free license, is arriving at Army posts.
No doubt it's intended to be installed by army personnel and used as an office suite while processing internal messages, right?
If anybody on the command staff is thinking clearly, anybody who actually INSTALLS such an abomination has a LOT more to worry about than an Ethics violation.
Just think: If you were in the Army would YOU use free-in-the-mail software to process sensitive military information?
This is no joke. Battles have been lost because the size and location of the forces were betrayed by such things as an intercepted order for toilet paper.
Some day people will realize the answer is to remove the vulnerable hosts that are being used as attack sources.
This is the obvious solution (after all, no zombies = no DDoS-nets), but the problem is there's no practical way to achieve it.
I think I see a way:
First: A counter-probe to identify whether a suspected site actually is a zombie. This would eliminate friendly-fire counterattacks and lets-you-and-him-fight scenarios.
A good signature is the presence of a controlling port for the zombie (though this might be camoflaged during the attack, so you'd have to go after something else once the attackers catch on and redesign). What you probe for, of course, will vary with the attacking tool.
Second: An infected michine will have had one of the set of vulnerabilities known to the particular tool's infection mechanism. (That will probably still be in place, since the tool's author will want to leave it open for future use, or not try to close it due to the added complexity and risk of exposure.) It will usually also have additional backdoor(s) installed by the tool. These give you an exploit for counterattacking it.
As things stand today, there's no incentive pushing owners of compromised machines to react quickly to remove them from the net -- there's no financial cost for many home users if they don't do so, and they're shielded from liability by the "I didn't know I was infected" defense.
Seems to me that a few thousand machines scattered around the net that respond to the latest worms by breaking into the zombies, popping up a notifier that they're infected and need to fix it, shuting down the infection, and cutting them off from some of their network service until they fix it, might just give them an immediate incentive. B-)
A second problem is that for the average computer user, it can be very difficult to tell casually if your computer's been infected and is packeting someone else. The fraction of the computer population that checks their firewall to measure their traffic, or goes over the processes running in memory every once in a while, is probably fairly small. This means that infected computers tend to stay infected for a long time.
Another reason to install something on their machine that mildly harasses them until they fix it once they've been exploited and the exploit attacked YOU. Issue solved.
There's also no real, efficient way for a DDoS target to notify thousands of machines about the problem, much less expect a significant proportion of them to respond in any short amount of time.
See above.
I think all the bases you mentioned are covered.
Yes, there might be an issue with the anti-hacking laws. But I think the necessity defense would be applicable here.
"Your honor: Defendant stipulates that he did install software on his machine which did respond to an attack from the machines owned by states' witnesses 1 through 5 by breaking into their machines, disabling some of the software running there, and installing additional software, without their permission.
But at the time the software performed this operation, defendants machine, which is necessary to his livelyhood, was already under active attack by the software on witness 1 through 5s' machines, and thousands of others, due to an infection by software installed by an unknown and malicious third party. This attack, if not countered, would make it unusable for its primary purpose.
The third party's software was installed on their machines, and left running, at least partially due to their own negligence, and was causing serious harm to the defendant's own machine. The defendant's software, on the other hand, took extensive measures to insure that it only counter-attacked machines that were already attacking it, and to do make the minimum changes necessary to abort the attack and notify the owners of the attacking machines that the machines had been infected and needed to be fixed.
Defendant pleads necessity.
To apply the anti-hacking law to defendant in this case is the same as jailing a man who was being beaten by an enraged mob for violating the laws against assault in his effort to protect himself."
What I'd like to see is some small number of.TLDs to be administered solely by volunteers with SLDs handed out for free.
Get ICANN to approve that and bail out of the loop. Then we can put our ideology and resources to the test.
I'd say you'd need three of 'em, administered by three separate organizations, to insure that internal problems (such as resource exhaustion or faction fights) don't imperil the availability of servce. (Just like you need a minimum of three, not two, cell carriers in a region to have real competition.).gnu or.fsf might be given to the FSF to be run by whatever organization they delegate..free would be another good one. Any suggestions for a third?
Wow now this is interesting. Intel have decided that they're going to call on the massive contingent of Open Source developers for their Linux driver. This benefits them because they don't have to hire programmers or support the drivers and can outsource it to the community at large who will maintain it.
Better:
They open-sourced the driver proper, only keeping the firmware closed.
They're providing starter code and a contact guy who can look provide enough help with the proprietary stuff that the community doesn't need to worry about getting hung due to inaccessable info.
Short of opening the firmware this like the best support model yet.
Why don't they make a standard jack for an antenna or something? It'd be quite useful other than being limited to "the AP inside the same room" sort of thing.
I understand that some countries' FCC analogs mandate that WLAN not be connected to external antennas, or mandate special connectors to make this difficult. (Even in the US you're supposed to drop the signal strength a bit when you use a directional antenna - though not anywhere near the gain of the antenna and the FCC encourages the use of directionals.)
Second: A microwave RF jack is fragile and not cheap. PC board hacking for microwaves is difficult. Could be they're trying to save design, parts, and repair cost by eliminating a little-used feature.
If you want to connect an external antenna, use a cheap WIFI card with a connector. (Then when the connector breaks from plugging it in every time you come home with the laptop, replace the card. Or leave the card at home and plug THAT in, using the onboard, internal-antenna, WIFI when on the go.)
Only a year after there was an official announcement for linux drivers, which was later recanted, intel releases incomplete drivers.
Assuming it's the stock firmware and there isn't any undisclosed magic: Even if Intel completely bailed at this point the open-source community would be able to finish the job. Should be all spiffy "real soon now".
I'm sorry but Intel could of handled this situation a LOT better. I feel really sorry for the people who have had a "centrino" laptop for the past year and a useless wifi card.
WEP on an AP also makes it crystal clear that you're not expecting "visitors" so any legal proceedings later on are much more likely to bear fruit. Kind of hard for someone to say they just "stumbled" upon your network when the network is encrypted by default and requires effort to access.
Exactly.
Just as with file permission systems, WEP encryption performs two jobs:
- It makes it (slightly) harder to have the forbidden access.
- It informs the user that the system operator didn't INTEND him to have free access.
Interpreting permission settings as an expression of intent (and not, for instance, browsing other people's read-protected files without asking first or having a darned good reason - like policy enforcement or criminal investigation) is a long tradition in computer culture.
And (as you and others have already pointed out) it is the exact analogy of a "no tresspassing" sign or a latch on a flimsy screen door or window. This will likely give it a well-understood place in law, once precedents are established to make the correspondence explicit.
Could turbo codes be used with a 56K modem giving somewhere around 80kbps of bandwidth?
Nope. (They'd actually reduce the data rate if used.)
Turbo codes are members of the class "Forward Error Correction" codes, which are used to correct errors that creap in during signal propagation from a sender to a receiver over a noisy channel. They work by sending EXTRA bits (typically 3 times as many with turbo), then processing what you get to correct the errors.
Turbo codes are typically used on noisy analog channels - such as radio links. Because they make the data bits less susceptable to noise you can reduce the amount of power you use to transmit them. It's like saying the same sentence three times in a noisy room, rather than scraeming over the noise level just once, so the guy at the next table can hear exactly what you said.
Turbo code (and other FEC codes) send more bits. But because the underlying data is so much less likely to be received incorrectly the sender can can reduce the amount of power used for each bit by MORE than enough to make up for the extra bits. You can trade this "coding gain" either for more BPS at a given power level or a lower power consumption at a given BPS.
But adding bits also increases the amount of information you're sending - either by broadening the bandwidth or more finely dividing the signaling symbol (for instance: more tightly specifying and measuring the voltage on a signal). So if your bitrate is limited by the channel capacity rather than the noise level you're stuck. The coding scheme will "hit the wall" and after that the extra bits come right out of your data rate. Not a problem with Ultra Wideband, or with encoding more bits-per-baud to get closer to a noise floor. But a big problem with telephone connections.
If you had a pure analog telephone connection they would be useful for increasing your bandwidth utilization. And in the old days you did. And analog modems struggled to push first 110 BPS, then 300, then 1200 through it despite the distortion and noise. Then they got fancy and cranked it up to 9.6k and beyond by using DSPs.
But these days you don't have an analog connection all the way. Your analog call is digitized into 8,000 8-bit samples per second and transmitted at 64,000 BPS to the far end. No matter WHAT you do to your signal you can't get more than that number of bits through it.
(This is actually very good, by the way, if the connection is more than a couple miles long. The digital signal is propagated pretty much without error, while an analog signal would accumulate noise, crosstalk, and distortion. So for calls outside your neighborhood you usually get a better signal-to-noise ratio with the digital system for the long hops than with an analog system. That's why cross-continent calls these days sound better than cross-town calls in the '50s.)
In practice it's worse than 64,000 BPS - because the system sometimes steals one of the bits from one sample in six for signaling about dialing, off-hook, ringing, etc. And you don't know WHICH sample. So you can only trust 7 of the bits. 56,000 BPS max. (It's a tad worse yet, because some combinations of signals are forbidden due to regulatory restrictions on how much energy you can put on a phone line - a particular signal could slightly exceed the limit. This makes the actual bit rate a little lower. And you have to sacrifice a little bandwidth to keep the receiver synchronized, too.)
And you only get the approximately 56k in the downlink direction, because to use it you have to have a digital connection at the head end to make full use of the digital transmission. At your uplink you can't be sure enough of the sampling moment to create a waveform that would force exactly the right bit pattern out of the A-to-D converter. So you have to fall back to a modulation scheme that allows some slop when you're transmitting at the POTS end of the link. (If you had a digital connection at both ends - i.e. ISDN - yo
Buying legitimate smartcard writers has never been an issue. DirecTV sends the extortion letters to people who have specifically purchased specialty smartcard readers whose design intent is to program DirecTV cards (i.e. Mikobu, etc).
As I unserstand it, some of the devices you, and DirecTV, allege are "illegitimate", are far less expensive than the commercial devices you recommend. The extra features include a built-in microprocessor (easy to configure) to locally control the programming (and its timing and complexity) and tight control of the power supply (capable of "glitching" the card to cause it to make a directed computational error).
The price is a BIG incentive for a garage shop - or any other legitimate business. The coprocessor shortens development time for an application, which could save even more. The power-glitcher can be used for testing the implementation of a security application for robustness against power-glitch attacks.
So you claim a legitimate designer should pay an extra grand or two, waste weeks of his time working around a bad card programmer design, and (if he's a security application designer) be left (like DirecTV) with an application that might be susceptable to attack by anybody with a cheap off-the-web programmer.
And all because DirecTV claims the cheaper and more capable device is "illegitimate"?
Sorry, AC. DirecTV bought a badly designed system. Now they're trying to cover their tails by engaging in criminal activity to stifle innovation that MIGHT be used to take advantage of their error, along with price competition in a technological tool market.
It doesn't matter what the INTENT of the designer of the devices was. What matters is what EACH INDIVIDUAL OWNER does with his device. Just like filesharing, or video tape recorders. Even if MOST of the use of the device is illegal (like "MP3 swapping" or recording copyright material), if it has "substantial legitimate use" it is not to be banned, and each instance of illegal use must be proven before penalties can be assessed.
Would you like to be sued by the RIAA because you own a computer and have an internet connection, and the major use of such devices (in their opinion) is to swap MP3s of their copyright material?
Slashdot Mirror
The false-positive rate should be emphasized far more than it has been. What does it mean? It means that whatever system they have in place, if it's based on statistical indicators rather than someone's hunch, will inevitably identify several innocent people for every terrorist that they find. Depending on the sensitivity of the detection algoritm, the value of "several" could be anywhere from dozens to thousands.
Not only that - false positives can CREATE additional new terrorists and otherwise drive large numbers of people toward opposition political positions.
Persons flagged are subjected to additional scrutiny. Body searches, luggage searches, X-ray rather than magnetometer scanning, and so on. This results in added delays, inconvenience, and potential health risks (to both the subject and future offspring, from both stress and X-ray exposure). And since the system flags them because of their on-record characteristics, they will be subjected to this scruitny repeatedly. Effectively it creates an underclass of people who will be constantly hassled during air travel - just as Jim Crow laws once made southern blacks ride in the back of the bus.
This treatment can be expected to "radicalize" those subjected to it - making them more prone to opposition activity and recruitment by terrorists. (Claims, for instance, that the US government is satanic and attempting to destroy Islam are far more believable if the US government IS systematically dumping on Muslims' civil rights.)
This isn't just academic. I watched a similar thing occur during the Viet Nam conflict.
Nice Jewish kid. Offspring of a famous doctor/medical researcher/research organization head/discoverer of a neurotransmitter/etc. In high-school in top-tier suburb of major city. Duly propagandized with how awful the NAZIs were in WW II and "never [let it happen] again".
Friend got a pair of the just-out hi-tek transorized CB walkie-talkie toys. James Bond movies and their takeoffs (Man from Uncle etc.) were all the rage. Two of 'em were using walkie-talkies to play a game of spy/counterspy through the back streets and parks of the suburb.
Unbeknownst to them, the President was passing through the next morning, on his way to give a commencement address at a large university maybe 50 miles away. (Not something that made the news in the area, since the airport was BETWEEN the two cities.)
Secret service hears the CB chatter, swoops down, and grabs the two kids off the street. Separates them and holds them overnight and through much of the next day, incommunicado and in solitary confinement, while the president makes his trip and return. Totally terrorizes the "nice jewish kid" (who isn't even told what's happening until release).
Kid went on to become a campus radical, drop out of college, and dedicate self to left-wing, anarchist, and radical labor union activity - for decades. Finally burned out and found a bed-board-and-pocket-change position as a quadraplegic's aide. Disowned by family for decades (only reconciled at all in the last couple years).
Multiply such an experience by the number of people flagged by the CAPS system and see where it might get us.
Nice repost from a story from three days ago.
But in this article it's on topic.
[...W]e associate our VPN client with a personal firewall, so that when you're VPN-ed in, ALL data flows the VPN to the corporate network before getting out to the internet. So your POP3 password is securely transmitted (over the IPSec tunnel) to the inside, and then goes out from there. Similarly web broswing goes inside, then through our corporate proxy server and then outside.
That's the way to go: Use an encrypted tunnel to work (or home or wherever) and use the site at the other end of the tunnel as your forwarder/proxy for everything.
[...]VPN [rather than other fancy stuff] should [also] be the right answer [for in-building wireless].
Again dead on. In-building wireless doesn't STAY in-building. So treat it like the general internet, put it on the OUTSIDE of your firewall, and secure-tunnel through for access inside.
Option 1: You can treat your APs and the general Internet as TWO separate external nets, both outside your firewall. Then your laptop has to tunnel in and authenticate to make any use of the AP, effectively becoming wired to your lan.
Option 2: You can treat them as ONE outside-the-firewall net, routing packets between them as well as from each to your firewall. Then you become a hot-spot, and visitors (customers, vendors, partners) can also use THEIR laptops to VPN to THEIR private nets (or surf the web B-) ) without having privileges on YOUR local net.
For option 2 you can use WEP as a no-tresspassing sign (post the netname and current password or have them get it from security or their inside contact), set up some other authentication mechanism, or leave your APs open (if you want to do your neighbors a service).
Curious to figure out how it might work, I looked up my domain name. It gave me an address in Redwood City, CA. WTF?
(I once hosted with an ISP who had a POP there, but not at that location. My domain record has my correct address, as well as the correct contact addresses - which are in a different city in the same metro area.)
Digging around with google for that street address came up with Greatcircle - the maintainers of the majordomo mailing list. Nice guys, but I've never been associated with them. (Ought to install it some day. Back when I hosted mailing lists I administered them manually.)
Turns out that they've been using my domain name in their documentation as a generic domain name. And the doc is all over the web - including several mailing list archives in which Brent Chapman's signature appears, giving the company address. B-) Of course the doc is also on their website, as is there address.
Given the broad use and extensive documentation of majordomo, and the relatively low profile of my own little consulting firm, I suspect that my domain name appears on the net more often associated with the former than the latter.
I suspect the service is using webcrawler information to create a database of search terms vs things-that-look-like-addresses (either on the same page or the same site) then scoring matchups by frequency, and the search engine returns the highest score.
(Meanwhile I've found out where the spambots are harvesting one of the bogus usernames that keep showing up in spam to my site. B-) )
How long before someone bootstraps a distributed Artificial life simulator to their virus and then we all watch in amazement as the first AI evolves and owns all our computers. This could never happen though...right?
For a mainframe version of the story see _The Adolescence of P1_.
(I'd dig up an Amazon link but I'm busy right now.)
How About...Not having TLD at all... Like http://slashdot
.com, .net, .edu, and .gov. And essentially everybody ended up competing for second-level domains in .com. And Network Solutions started charging for them ($50/year at first). And made a bundle by essentially recreating the original broken system one level down under .com and charging to do the administration.
That was ALREADY broken decades ago - which is why the dot.ist.domain.addressing was invented.
UUCP Mailnet (and others) used simple site names in a single namespace. Wile you could supply!an!explicit!route!to!somesite!joe, there were add-on tools that would examine the maps and let you mail joe@somesite.
But with all the sitenames in a common single namespace it was a BITCH to administer. After a short time all the "good" short names were taken. And as things other than mail needed naming (like sites with hundreds or thousands of desktops) it just got silly.
So the hierarchical namesystem was set up, with the three-pronged goals of automating the routing more generally, spreading the administrative load, and allowing the addition of machines at a site without further interaction with an outside authority.
Then it went commercial - with TLDs of
And it's evolved from there.
The commercial registries have no incentive to promote their own competition. ICANN is in their pocket and adding TLDs has implications netwide (since some customer systems, as well as the root servers, need tweaking for new TLDs). Thus addition of TLDs is glacial.
And sod the whingeing about "competitors having access to your 'proprietary information'". Your competitors already pay people to reverse-engineer your products, and you will get access to their "proprietary information".
That argument will NOT cut ice with corporations. Reverse-engineering costs a LOT - both in money and in time-to-market. And corporate executives, who have to actually PAY for software (and other) development have a real feel for just HOW MUCH it costs and HOW LONG it takes.
Once the knockoff is on the market they have to lower their prices, so every quarter they hold that off is another quarterly report with a high, rather than a low, profit margin.
If you want to convince them you have to show them how using open source gives them an advantage that more than compensates.
Two big ones are:
- It cuts their development costs to a pittance compared to doing it all themselves or buying the bulk of it. (This means that they don't have as large an investment to recover before it gets cloned and the price is driven down to commodity levels. In turn that means they can establish themselves and be ready to keep making money at commodity pricing levels.)
- It gets them to market much sooner (so even if the tail gets chopped off the neck is lengthened.)
First you have to gain access to the facility, then you have to have access to that area and then you have to have access to the files. It is not that easy to just stroll in there and get a copy of them.
At least in the case of the indian stuff it wasn't an issue of getting copies of the information.
They "lost" essentially all of the indians' money - and the records were corrupted enough that it was no longer possible to trace who took it.
The bureaucrats in charge (the likely suspects) then took advantage of the insecure network to finger-point away from themselves. And the systems were taken offline when it was shown that they were STILL wide open.
But now some people are starting to have REALLY fast pipes. And for them TCP is becoming the limiting factor.
Its pretty darn easy to get really fast pipes. Motherboards ship with Gigabit ethernet now, Gigabit switches are way down in price. Most companies these days are building their networks on TCP/IP, this could be a pretty big thing corporate networks, iSCSI, etc. 10GigE isnt all that far away either.
The much higher speeds on a LAN are a good point.
But.
"The Wall" for TCP is a lot faster within a building than across a continent.
The limit comes primarily from round-trip dealy - which is much shorter when things are microseconds apart then when they're milliseconds apart at speed-of-light-in-wire-or-fiber.
The limit also comes from timeouts after lost or corrupted packets - from line flakeyness or congestion. But line flakeyness is nearly nonexistent on a LAN. As for congestion, if you're using switches rather than hubs it's also not as much of an issue within a building as it is in a cross-continent backbone.
It would be interesting to know how far out an implimentation of such a protocol on a large scale is.
It already IS implemented.
Or do you mean a large-scale "rollout"?
If so, why bother? Unless you have a REALLY fat pipe and need to use it all for one stream, of course. (But not many need to do that, and the ones that do can now install it on both end points.)
The phrasing of the article is leading to confusion. This is about a PROTOCOL, not about the UNDERLYING TRANSPORT.
The TCP protocol, with its windows, handshaking turnarounds, and timeouts, imposes its own limit on the speed of the data transfer through it. For decades the limit imposed by TCP was so far above the limits imposed by the data rates of the underlying transport that it wasn't a major issue.
But now some people are starting to have REALLY fast pipes. And for them TCP is becoming the limiting factor.
So now reasearchers have come up with a tweaked version of TCP that won't hit the wall until the pipe is a LOT faster than what YOU can rent from your ISP. (Unless you're renting an OC-192, in which you might be starting to fall a little short of its capacity. But if you've got OC-48 or below you're fine.)
When you CAN rent something over 6 Gbps, and you want to routinely use it all for a single TCP connection to get a REALLY FAST fast download, you might want to ask the nice professors for a THIRD generation TCP. B-)
Meanwhile, if you're on an ordianry connection you're not going to increase your data rate by a factor of 6,000 by switching protocols. You might get a little bit closer to the line rate with this SECOND generation TCP. But that's it.
Expect to see this start to gradually start showing up in protocol stacks as an option - automatically configured if both ends know about it and the inventors have come up with a backward-compatible negotiation. That way you'll be able to make better use of fat pipes when you can finally get them.
I suppose that if you arbitrarily come up with a rule saying there can be only one person with a given set of recollections at a given religious destination for souls, then you can declare as a consequence that the soul is moved, not destroyed, or you'll have two John Does in heaven (or hell) (or purgatory) (or whatever you believe in), arguing over which one is the real one.
While it may not solve the metaphysical issues, one "advantage" of quantum teleportation is that you still end up with just one copy.
Hesienberg Uncertainty keeps you from measuring ALL of the state of the original, so you can't make an exact copy. Quantum Teleportation sidesteps this by using quantum-entangled matter at both ends, and interacting the original with one half of the quantum-entangled matter, measuring the result of its interaction and sending that information to the far end, where it forces the other half of the matter into a state totally duplicating the origianl. But the original is destroyed in the process.
The net result is you start with the original HERE, made out of a set of particles in state set A, and after you send the message and process it at the far end you end up with a totally indistinguishible set of particles in state set A THERE, with a mass of junk HERE. (It could be argued that what ended up at the far end is the original set of particles, which tunneled through and exchanged mass with the set at the far end.)
So no cloning of souls necessary. (Just assume that a soul, if it exists (and is actually different from the pattern of matter), stays "attached" to the pattern as the pattern is transferred from one place to another via quantum tweaks and information transfer rather than by physical motion.)
I don't know about you, but I'd be much less worried about whether I was still me after transmission by a device where physical limits of the universe prevent making a copy than if I were "transmitted" by remote duplication.
Spray hypodermics predated the Star Trek series. McCoy's injector was based on them - though of course vastly improved. (Dial-a-drug, hand-held rather than big gun with compressor sidekick, etc.)
The original discovery was made when a worker handled a high-pressure hydraulic hose with a pinhole leak, and reported to medical with a sore spot in his hand. The medic found a teaspoon or so of hydraulic fluid under the skin - but the worker hadn't felt it going in. Investigation quickly identified the leak and thus resulted in the discovery that a very small, very high-speed, jet of fluid will go subcutaneous or even intramusclular with minimal sensation.
Somehow this info didn't get lost, but resulted in the bright idea of doing it deliberately to reduce the discomfort and increase the speed and convenience of injections - especially mass injections. The military funded development of the first devices (primarily because they have to innoculate thousands of troops in batches efficiently, and also so they could innoculate a civilian population rapidly in case of a biowar attack - this being during the "cold war".)
But how do they determine who has "computer skills"?
Doesn't matter. They never put you to work in your specialty anyhow.
Or do it nearly so - like the expert electronics guy they assigned to dig (by hand) trenches to drive the radar trucks into so only the antenna was above ground, back in WW II.
For instance: Subscribing the Detroit area spammer and his lawyer to enough real-world junkmail lists to bury his bills and other US Main correspondence in several daily truckloads of catalogues and other solicitations
With all due respect, get a clue.
You don't fight a noisy neighbor by cranking up your stereo.
With all due respect, try actually reading what I wrote.
I didn't say it was RIGHT to do this. I PREDICTED that it WOULD HAPPEN. Very different thing.
Was out to lunch with three colleagues today and the subject of anti-spam measures came up.
I managed to appall the one from Berkeley by suggesting that the most practical solution was probably a moderate-size bomb.
B-)
But seriously:
In an arms race, weapons eventually defeat armor. Spam will continue until two real-world things are BOTH brought to bear on spammers:
- Economics
- Muscle
If a governmental solution applying both is not forthcoming soon, I predict that there WILL be vigilantism.
In fact we're already seeing it.
For instance: Subscribing the Detroit area spammer and his lawyer to enough real-world junkmail lists to bury his bills and other US Main correspondence in several daily truckloads of catalogues and other solicitations.
Soon to come: Retaliatory information-war software directed at DDoSer / spammer zombi-net machines. (As discussed in a recent Slashdot article.)
So software, claiming to be from Microsoft with a free license, is arriving at Army posts.
No doubt it's intended to be installed by army personnel and used as an office suite while processing internal messages, right?
If anybody on the command staff is thinking clearly, anybody who actually INSTALLS such an abomination has a LOT more to worry about than an Ethics violation.
Just think: If you were in the Army would YOU use free-in-the-mail software to process sensitive military information?
This is no joke. Battles have been lost because the size and location of the forces were betrayed by such things as an intercepted order for toilet paper.
I bet a lot of schools and charities would love that software.
I bet the kiddies would love a free bag of herion or crack, too. But does that mean you should donate one?
Let's not get another generation hooked on Windows.
Some day people will realize the answer is to remove the vulnerable hosts that are being used as attack sources.
This is the obvious solution (after all, no zombies = no DDoS-nets), but the problem is there's no practical way to achieve it.
I think I see a way:
First: A counter-probe to identify whether a suspected site actually is a zombie. This would eliminate friendly-fire counterattacks and lets-you-and-him-fight scenarios.
A good signature is the presence of a controlling port for the zombie (though this might be camoflaged during the attack, so you'd have to go after something else once the attackers catch on and redesign). What you probe for, of course, will vary with the attacking tool.
Second: An infected michine will have had one of the set of vulnerabilities known to the particular tool's infection mechanism. (That will probably still be in place, since the tool's author will want to leave it open for future use, or not try to close it due to the added complexity and risk of exposure.) It will usually also have additional backdoor(s) installed by the tool. These give you an exploit for counterattacking it.
As things stand today, there's no incentive pushing owners of compromised machines to react quickly to remove them from the net -- there's no financial cost for many home users if they don't do so, and they're shielded from liability by the "I didn't know I was infected" defense.
Seems to me that a few thousand machines scattered around the net that respond to the latest worms by breaking into the zombies, popping up a notifier that they're infected and need to fix it, shuting down the infection, and cutting them off from some of their network service until they fix it, might just give them an immediate incentive. B-)
A second problem is that for the average computer user, it can be very difficult to tell casually if your computer's been infected and is packeting someone else. The fraction of the computer population that checks their firewall to measure their traffic, or goes over the processes running in memory every once in a while, is probably fairly small. This means that infected computers tend to stay infected for a long time.
Another reason to install something on their machine that mildly harasses them until they fix it once they've been exploited and the exploit attacked YOU. Issue solved.
There's also no real, efficient way for a DDoS target to notify thousands of machines about the problem, much less expect a significant proportion of them to respond in any short amount of time.
See above.
I think all the bases you mentioned are covered.
Yes, there might be an issue with the anti-hacking laws. But I think the necessity defense would be applicable here.
"Your honor: Defendant stipulates that he did install software on his machine which did respond to an attack from the machines owned by states' witnesses 1 through 5 by breaking into their machines, disabling some of the software running there, and installing additional software, without their permission.
But at the time the software performed this operation, defendants machine, which is necessary to his livelyhood, was already under active attack by the software on witness 1 through 5s' machines, and thousands of others, due to an infection by software installed by an unknown and malicious third party. This attack, if not countered, would make it unusable for its primary purpose.
The third party's software was installed on their machines, and left running, at least partially due to their own negligence, and was causing serious harm to the defendant's own machine. The defendant's software, on the other hand, took extensive measures to insure that it only counter-attacked machines that were already attacking it, and to do make the minimum changes necessary to abort the attack and notify the owners of the attacking machines that the machines had been infected and needed to be fixed.
Defendant pleads necessity.
To apply the anti-hacking law to defendant in this case is the same as jailing a man who was being beaten by an enraged mob for violating the laws against assault in his effort to protect himself."
What I'd like to see is some small number of .TLDs to be administered solely by volunteers with SLDs handed out for free.
.gnu or .fsf might be given to the FSF to be run by whatever organization they delegate. .free would be another good one. Any suggestions for a third?
Get ICANN to approve that and bail out of the loop. Then we can put our ideology and resources to the test.
I'd say you'd need three of 'em, administered by three separate organizations, to insure that internal problems (such as resource exhaustion or faction fights) don't imperil the availability of servce. (Just like you need a minimum of three, not two, cell carriers in a region to have real competition.)
Wow now this is interesting. Intel have decided that they're going to call on the massive contingent of Open Source developers for their Linux driver. This benefits them because they don't have to hire programmers or support the drivers and can outsource it to the community at large who will maintain it.
Better:
They open-sourced the driver proper, only keeping the firmware closed.
They're providing starter code and a contact guy who can look provide enough help with the proprietary stuff that the community doesn't need to worry about getting hung due to inaccessable info.
Short of opening the firmware this like the best support model yet.
Why don't they make a standard jack for an antenna or something? It'd be quite useful other than being limited to "the AP inside the same room" sort of thing.
I understand that some countries' FCC analogs mandate that WLAN not be connected to external antennas, or mandate special connectors to make this difficult. (Even in the US you're supposed to drop the signal strength a bit when you use a directional antenna - though not anywhere near the gain of the antenna and the FCC encourages the use of directionals.)
Second: A microwave RF jack is fragile and not cheap. PC board hacking for microwaves is difficult. Could be they're trying to save design, parts, and repair cost by eliminating a little-used feature.
If you want to connect an external antenna, use a cheap WIFI card with a connector. (Then when the connector breaks from plugging it in every time you come home with the laptop, replace the card. Or leave the card at home and plug THAT in, using the onboard, internal-antenna, WIFI when on the go.)
Only a year after there was an official announcement for linux drivers, which was later recanted, intel releases incomplete drivers.
Assuming it's the stock firmware and there isn't any undisclosed magic: Even if Intel completely bailed at this point the open-source community would be able to finish the job. Should be all spiffy "real soon now".
I'm sorry but Intel could of handled this situation a LOT better. I feel really sorry for the people who have had a "centrino" laptop for the past year and a useless wifi card.
I'm with you on that.
WEP on an AP also makes it crystal clear that you're not expecting "visitors" so any legal proceedings later on are much more likely to bear fruit. Kind of hard for someone to say they just "stumbled" upon your network when the network is encrypted by default and requires effort to access.
Exactly.
Just as with file permission systems, WEP encryption performs two jobs:
- It makes it (slightly) harder to have the forbidden access.
- It informs the user that the system operator didn't INTEND him to have free access.
Interpreting permission settings as an expression of intent (and not, for instance, browsing other people's read-protected files without asking first or having a darned good reason - like policy enforcement or criminal investigation) is a long tradition in computer culture.
And (as you and others have already pointed out) it is the exact analogy of a "no tresspassing" sign or a latch on a flimsy screen door or window. This will likely give it a well-understood place in law, once precedents are established to make the correspondence explicit.
Could turbo codes be used with a 56K modem giving somewhere around 80kbps of bandwidth?
Nope. (They'd actually reduce the data rate if used.)
Turbo codes are members of the class "Forward Error Correction" codes, which are used to correct errors that creap in during signal propagation from a sender to a receiver over a noisy channel. They work by sending EXTRA bits (typically 3 times as many with turbo), then processing what you get to correct the errors.
Turbo codes are typically used on noisy analog channels - such as radio links. Because they make the data bits less susceptable to noise you can reduce the amount of power you use to transmit them. It's like saying the same sentence three times in a noisy room, rather than scraeming over the noise level just once, so the guy at the next table can hear exactly what you said.
Turbo code (and other FEC codes) send more bits. But because the underlying data is so much less likely to be received incorrectly the sender can can reduce the amount of power used for each bit by MORE than enough to make up for the extra bits. You can trade this "coding gain" either for more BPS at a given power level or a lower power consumption at a given BPS.
But adding bits also increases the amount of information you're sending - either by broadening the bandwidth or more finely dividing the signaling symbol (for instance: more tightly specifying and measuring the voltage on a signal). So if your bitrate is limited by the channel capacity rather than the noise level you're stuck. The coding scheme will "hit the wall" and after that the extra bits come right out of your data rate. Not a problem with Ultra Wideband, or with encoding more bits-per-baud to get closer to a noise floor. But a big problem with telephone connections.
If you had a pure analog telephone connection they would be useful for increasing your bandwidth utilization. And in the old days you did. And analog modems struggled to push first 110 BPS, then 300, then 1200 through it despite the distortion and noise. Then they got fancy and cranked it up to 9.6k and beyond by using DSPs.
But these days you don't have an analog connection all the way. Your analog call is digitized into 8,000 8-bit samples per second and transmitted at 64,000 BPS to the far end. No matter WHAT you do to your signal you can't get more than that number of bits through it.
(This is actually very good, by the way, if the connection is more than a couple miles long. The digital signal is propagated pretty much without error, while an analog signal would accumulate noise, crosstalk, and distortion. So for calls outside your neighborhood you usually get a better signal-to-noise ratio with the digital system for the long hops than with an analog system. That's why cross-continent calls these days sound better than cross-town calls in the '50s.)
In practice it's worse than 64,000 BPS - because the system sometimes steals one of the bits from one sample in six for signaling about dialing, off-hook, ringing, etc. And you don't know WHICH sample. So you can only trust 7 of the bits. 56,000 BPS max. (It's a tad worse yet, because some combinations of signals are forbidden due to regulatory restrictions on how much energy you can put on a phone line - a particular signal could slightly exceed the limit. This makes the actual bit rate a little lower. And you have to sacrifice a little bandwidth to keep the receiver synchronized, too.)
And you only get the approximately 56k in the downlink direction, because to use it you have to have a digital connection at the head end to make full use of the digital transmission. At your uplink you can't be sure enough of the sampling moment to create a waveform that would force exactly the right bit pattern out of the A-to-D converter. So you have to fall back to a modulation scheme that allows some slop when you're transmitting at the POTS end of the link. (If you had a digital connection at both ends - i.e. ISDN - yo
Buying legitimate smartcard writers has never been an issue. DirecTV sends the extortion letters to people who have specifically purchased specialty smartcard readers whose design intent is to program DirecTV cards (i.e. Mikobu, etc).
As I unserstand it, some of the devices you, and DirecTV, allege are "illegitimate", are far less expensive than the commercial devices you recommend. The extra features include a built-in microprocessor (easy to configure) to locally control the programming (and its timing and complexity) and tight control of the power supply (capable of "glitching" the card to cause it to make a directed computational error).
The price is a BIG incentive for a garage shop - or any other legitimate business. The coprocessor shortens development time for an application, which could save even more. The power-glitcher can be used for testing the implementation of a security application for robustness against power-glitch attacks.
So you claim a legitimate designer should pay an extra grand or two, waste weeks of his time working around a bad card programmer design, and (if he's a security application designer) be left (like DirecTV) with an application that might be susceptable to attack by anybody with a cheap off-the-web programmer.
And all because DirecTV claims the cheaper and more capable device is "illegitimate"?
Sorry, AC. DirecTV bought a badly designed system. Now they're trying to cover their tails by engaging in criminal activity to stifle innovation that MIGHT be used to take advantage of their error, along with price competition in a technological tool market.
It doesn't matter what the INTENT of the designer of the devices was. What matters is what EACH INDIVIDUAL OWNER does with his device. Just like filesharing, or video tape recorders. Even if MOST of the use of the device is illegal (like "MP3 swapping" or recording copyright material), if it has "substantial legitimate use" it is not to be banned, and each instance of illegal use must be proven before penalties can be assessed.
Would you like to be sued by the RIAA because you own a computer and have an internet connection, and the major use of such devices (in their opinion) is to swap MP3s of their copyright material?
I didn't think so.