The information which a bricks and mortar store records about you is not easily indexable, searchable, correlatable (word?). They cannot easily and cheaply ask "what was Joe Schmoe's average speed?" Or "Did Schmoe gaze longer at steaks or pork chops?" The info is there for them if it's important, but it's not automatically in a database for data mining.
The customer in a store has no reasonable expectation of privacy. He sees one-way mirrors and camera domes everywhere. There is usually a sign at the entrance warning of video surveillance. In contrast, the web user has a reasonable expectation of privacy while navigating within a page. According to a common understanding of the web, reading a page which has been downloaded does not transmit signals to a remote server. If the user were aware of the privacy invasion he might feel more constrained in the information he reveals; clearly anyone who uses this invasive technique is counting on user ignorance.
In keeping with that second point, I'd like to point out the dishonesty of the researcher claiming this will help to be 'more responsive to customers' or whatever cant he used. Commercial web sites have already shown their utter unresponsiveness to customers. Even when a customer took the time to compose a detailed email explaining what was wrong with a site, it was either discarded or read with gales of laughter. I know because I was there. If web sites want to serve customers better, they could start by reading and responding to email. Second, watch the error log and fix bugs. Third, watch the access log and find 'dead ends' where people give up. There is no need to spy on customers.
I wonder if we could make a filter that intelligently detects the 'arbitrary identifier' and replaces it with equivalent random characters of the same set. In this case it's pretty obvious. Of course the ultimate counter-weapon to that detector would be making all the image URL's identically formatted strings of base64 crap. But for the time being there might be some way to automate the anti-bug filter.
Of course this is ultimately futile since the server has the data anyway - web bugs are just a cheap way of sharing data with another server.
The ultimate filtering would be collaberative. If I got logo.jpg-234987575 (11k) as the first IMG on the page, and you got logo.jpg-332215533 (also 11k) our software could communicate (ala RBL) and reach a shared decision that the numeric portion is a tracking number. Then future clients (in our network) would randomly generate the number.
Equipment: The whole thing hinges on the possibility of the equipment becoming cheap. A lot of things have followed that path. If the equipment is forever expensive, the scenario won't happen.
Energy: It makes sense that hi-res fabrication will consume more energy than traditional production. Of course, less energy will be spent on transport.
Time: Replication takes longer than traditional production. But production+shipping could take longer than replication. And I think the machines will get faster.
Waste: It seems like a replicator using a uniform raw material would produce waste of the same material (possibly fused, melted, charred or otherwise altered) that could be recycled into the raw material.
Distribution: ?
Raw Materials: We could have a cost-effective infrastructure for delivering these. Stage 1: people buy 75 pound bags at a store. Stage 2: Tanker trucks fill tanks under your lawn (as is done with heating oil in the northeast US). Step 3: Material flows through pipes under the streets and each replicator has a feed hose. Note that each of these delivery mechanisms is cheaper than moving the equivalent mass of finished goods, because the material takes less space and because there is no switching, or decision-making. In comparison with a five-pound parcel shipped via UPS, five pounds of raw material will take a much simpler (thus cheaper) route.
R&D / Design: Of the replicator or part? If part, I think we'll see a lot of free designs on the net. (To avoid the thorny question of proprietary designs.)
Why would shipping the specific goods someone wanted be more expensive...
Because raw material might lend itself to bulk handling technologies, like pipelines and pumps. Also, no packaging materials.
I guess the relationship of dedicated production equipment to replicators will be like that of CD pressing plants to CDRs. One is cheaper when a large quantity is needed; the other lends itself to ad-hoc production of customized units.
A machine that only builds one thing is going to produce that one thing faster and cheaper than a machine that can build anything.
s/builds/computes and you have the conventional wisdom of the pre-computer age. A machine custom built for computing mortgages would be cheaper than a general-purpose computer, right?
I was reading an interview with a Bell Labs engineer in which the engineer discussed the reluctance to go digital. Bell Labs had perfected the electromechanical switch - with bistable ferreeds they were approaching something like 5 cents per crosspoint. How could digital possibly compete?
I think the answer to all these questions lies in the concentration of engineering effort on one task. If a certain replicator technology becomes viable, companies will keep focusing on making it cheaper and faster. We could get a 'Moore's Law' of fabrication.
I work with Visual C++ 5 days a week, and there are real limitations in its scripting.
Interesting. Stallman wrote an essay describing the design logic of Emacs. One thing he pointed out is that a scripting language tacked onto the side of an application as a 'feature' will always suck. It won't be a very high priority for the application's creators and maintainers.
The proper approach is to write the upper layers of the application in the scripting language. So Visual C++ should be made with the compiler, linker, metadata-store etc. in C/C++ and the control/GUI in VB. Or something.
The obvious side effect is that Microsoft's programmers would have felt the pain of an inadequate scripting interface/language and enhanced it.
I write free software in order to write code that will be used in the real world. Most of the code that I write professionally will never see the light of day. The project will change directions at an executive's whim, or the whole project will be canceled, or the company will go bankrupt.
I suspect that very little of the software written for hire is every put into production.
Second, the stuff I write commercially is always twisted to some extent by the organizational/marketing agenda of the employer/customer. Free Software is my chance to write code that's clean and logical.
Third, software that I write for hire is never really finished. There is no money in budgets for polishing code. Once it works I'm on to something else, although the code is full of commented-out bits and unused variables and might need a complete rewrite.
Summary: programming for a living causes an ever-increasing accumulation of bitterness. Writing Free Software counteracts that bitterness with the sweetness of a clean, logical, complete project that might be used by many.
Wow. Thanks for pointing that out. I now think that Solomon's a fool. He attacks Dilbert for not leading some Marxist crusade against corporations. I think he misunderstands what the strip is about. He seems to think it's very ironic that Scott Adams supports downsizing. Adams explains that Dilbertesque workplaces are a product of overstaffing. What's strange about that?
And the "foreword" by Tom Tomorrow underscores the humorless earnestness of this crusade. I guess this pair needs it spelled out in 6" block letters:
We are not oppressed. We're not interested in overthrowing capitalism. We find management fads and language funny. We like Dilbert because it pokes fun at them.
I don't agree that it's bad that we don't teach the average person to know as much about computers as we geeks.
That level of knowledge is not required. What "we" (I presume I agree with the poster) want is for the average person to know as much about computers as he does about cars, and as much about electronic information as he does about pen, paper and books. In other words, the rudimentary education that will save him from lots of trouble and grief. A society of illiterate savages cannot be a democratic republic. In such a society, the individual citizens lack the conceptual tools to effectively use their theoretical freedom.
We are entering an era when most human activity is mediated by computers, software and networks. The fact that the majority have almost no knowledge of these things, and are in fact plunged in the most profound superstition and ignorance is not a good omen.
Much of the prosperity of the 20th century was powered by widespread literacy. Learning to read and write is hard (much harder than the basics of computers) but as a society we've decided that everyone should have these skills. Yes, even those:
building the cars, cooking the food, sweeping the floors, healing the sick, fighting the fires, etc.
In a sense, the medical doctors have already succeeded in forcing a little of their knowledge on us: health class, or sexual education in high school. It doesn't make you an MD, but it's a reasonable distillation of parts of medical knowledge likely to affect a young person. I think we should draw up a corresponding curriculum of basic computer knowledge and urge its adoption.
I think you missed the point. Crowhard was not stating the modern shared universe of play is 'better'. He was stating that it has driven out the previous modes of play.
Kids today mostly share the same culture. It's as if they are all sitting in the same room with the same teacher/clown/entertainer. The shared culture is 'cool' to one's peers. Anything a kid creates by himself is not cool, because it doesn't have a marketing budget.
Well, gee whiz, how did kids ever play togther before there was TV?
That's the whole point. When TV and it's accompanying mass culture came along, they pushed out older modes of play and imagination.
...if anything I think the problem with Lego is that it's not Lego anymore...
That's obviously the 'problem' in terms of decreased appeal to intelligent adults. However in terms of sales, the perversion of the original idea has been the company's salvation, as the article makes clear. In other words, the stuff you don't like is the big money-maker.
I'm sorry if you feel the way you do...
I didn't read Crowhard as celebrating this trend, merely describing it. To avoid confusion, let's define two different different goals: 1) Amuse and develop intelligent people. 2) Make money. Lego's problem is with #2 - they are losing vast quantities of money. To survive, they need to market new toys that make money. I think most people agree that the system of generic blocks was 'better' per criterion #1.
I agree with most of what you're saying. Two points, though:
We're heading towards paying by transfer not by bandwidth. Paying by bandwidth means paying for KB/s channel capacity. Paying for transfer means paying for GB moved this month. There's also the possiblility of paying for 95 percentile bandwidth usage - the highest KB/s you achieved in the month after discarding the 5% highest time windows. This seems to be quite popular with colocation providers.
I think in practive we'll have "all you can eat*" for casual users, where "*" means "up to 3G per month." Most people won't know or care about the cap. Those who do will pay for transfer past the cap. Much healthier than all the crappy things they're doing now to reduce usage.
If ISP's are making money on transfer, they have an incentive to upgrade their network. Also, they'll encourage grassroots networking rather than fight it.
I don't understand the tradeoff between bandwidth and encryption that you posit. When you feed cleartext through a block cipher, the result is roughly the same size (rounded up to the block size, typically 8 bytes). If you use a stream cipher like RC4, the encrypted product is the same size as the cleartext. So encryption won't make a 14.4 link any slower.
Maybe you're talking about public key encryption used to establish a session key? I don't think it's enough to really impact your bandwidth.
I think that any crypto built into hardware sold to consumers will be deeply flawed. So far, this has been true. The crypto is too strong for the casual hobbyist, but easy for the government to crack. You mention 802.11 encryption. Recently, researchers at AT&T implemented a previous theorized attack that allows a notebook computer to penetrate 802.11's WEP (wired equivalent privacy) crypto.
Eventually they will get smart enough to make crypto that isn't obviously flawed. The flaws will only be visible to those in on the secret. This is called 'red threading'. Anyhow, the fundamental problem is that making chips is hard and expensive, and chips are opaque to users. Chip makers are very vulnerable to pressure from government agencies. However, so far I don't think they need much pressure - industry associations keep standardizing on bad, flawed cryptosystems.
The US had law enforcement long before the FBI existed. Law enforcement does not necessarily need to snoop on communications. Real crimes leave evidence in the real world. Crimes that require eavesdropping to prove probably shouldn't be crimes.
I'm sure there are exceptions, most of which involve people conspiring to commit "real world" crimes. But are the exceptions worth the price?
What part of "subject to court order" don't you understand?
As I understand the article, Microsoft sent letters and envelopes to people and persuaded the people to sign the letters and mail them. Sleazy, but not illegal.
The best way to deal with it is exactly how it was dealt with - public exposure.
Like most of the Outlook 'viruses', this exploit relied on human gullibility. Microsoft didn't forge anyone's signature - rather they sent the letters and envelopes to people and somehow persuaded them to sign and mail them. The fundamental problem is that many people are so pliable that they are simply putty in the hands of any persuasive talker.
One of the 'victims' said, "I sure was misled." Was he? Did he believe the things in the letter which he signed?
This is similar to the democrats busing in senior citizens to vote. The alleged autonomy of the human being is superceded by the gullibility of individuals.
I like this theory, but it probably won't happen. I like it because it rings true with the way institutions evolve - we go from individual merchants maintaining credit files to associations to corporations.
Why it probably won't happen: the DMCA. That's right, if the DMCA were never passed, ISP's could still have huge liability for infringment and might band together to reduce risk. That's really the driver of credit bureaus - risk reduction. But under the DMCA, the ISP just has to yank your access and they have no liability. Therefore they have no incentive to spend money figuring out if you're going to infringe - they simply get the letter and pull the plug.
The DMCA has at least two different provisions. The one you're familiar with is "no trafficking in circumvention devices". However, it also has a provision for handling alleged copyright infringement on the net. The goal, which is actually quite sound, was to clarify the responsibilities of ISP's so they couldn't get sued left and right for the activities of their subscribers.
Unfortunately they chose the wrong solution, from a commoner's perspective. I think the right solution would be that the ISP is never responsible for content, period. If ordered by a court, they would of course have to remove access.
Except that the only part of the complaint letter that is under penalty of perjury is the claim that the writer acts on behalf of the copyright holder. The claim of infringement is not under penalty of perjury, and the DMCA allows 'good faith' as a defense against false claims.
So the MPAA has absolutely no risk. What did you expect?
You are essentially taking the tack that TW is a private entity entitled to enter into, and terminate agreements with other private entities. However they are utilizing your community's streets and telephone poles to run their cable. This comes at a high cost to the community in terms of ripped-up streets, visual intrusion, increased probability of a telephone outage, and opportunity cost - there's only room on the poles for so much cable.
They were granted this privilege, a 'franchise' in exchanging for meeting the community's requirements. Generally, these requirements include a rate tarriff and provision of community access channels. Given the monopoly position they are granted by virtue of their franchise, and given the increasing importance of internet connectivity, their is every reason to support increased regulation of their service. No other utility is allowed to arbitrarily discontinue service.
This does not address the fact that per DMCA they may be compelled by law to discontinue service. I'm just pointing out an important fallacy used by corporatists - they want the corporation to be a private citizen when it comes to contracts, but a public utility when it comes to special privileges from the government.
If the ISP terminates a user's account based on a false accusation the user might just have legal claims against them.
I don't think so, because that's what the DMCA requires. It doesn't matter if the infringement letter is true or false. As we saw in this story, the ISP can even refuse to show you the letter, so you have no way of debating its validity.
This is not about intercepting the ssh login password. It's about interceping passwords entered during an ssh session. Here is the relevant code from sshconnect1.c in OpenSSH:
for (i = 0; i < options.number_of_password_prompts; i++) {
if (i != 0)
error("Permission denied, please try again.");
password = read_passphrase(prompt, 0);
packet_start(SSH_CMSG_AUTH_PASSWORD);
ssh_put_password(password);
memset(password, 0, strlen(password));
xfree(password);
packet_send();
packet_write_wait();
type = packet_read(&payload_len);
if (type == SSH_SMSG_SUCCESS)
return 1;
if (type != SSH_SMSG_FAILURE)
packet_disconnect("Protocol error: got %d in response to
passwd auth", type);
}
Many people do not understand this. Some believe they are protecting themselves from this risk via RSA authentication. Of course they're not, because the risk only affects passwords in session:
gorf: My solution is simply not to use passwords at all; I use RSA keys exclusively...
SagSaw: The best way I can think of is to use the RSA key authentication method. A RSA key pair is used to authenticate, rather than a password. This way, the password is never typed over the network connection.
Pinball Wizard: Well, if you use RSA you don't need to type a password so that would solve that particular problem.
subsolar2: I use RSA authentication for remote access, and have since day one. So the only real worry is somebody getting a copy of my private key...
Greyfox: As has been noted, RSA is the way to go, at least with SSH authentication...
Others think that a GUI client is more secure entering a password in a dialog box suggests batch processing:
stripes: My Java ssh client happens to have "gotten it right" not because I'm smarter then other ssh client authors but because I had a dialog box to ask for the password.
Hyperbolix: Teraterm... has several SSH extensions. I beleive one of them has you type in the password all at once and then sends it as a single string, which means that key timing can't be determined.
rgmoore: I think that most Windows terminal emulators have similar functionality. It seems like a very simple step to take to help preserve passwords.
garcia: don't most GUI terminal packages (including MacSSH, etc) all send it as a single string (SecureCRT)?
Rimbo:...I use the free ttssh extension to the freeware terminal program Tera Term. When it asks you for a password, it captures everything in a dialog box, and sends the password as one chunk.
Jormundgard: Also, every SSH program I've used in windows takes in the whole password before sending it along.
The very few who got it:
Ethan: It's a moot point with SSH anyway, because SSH transmits the password in one chunk as far as I know...
Todd Knarr: I think this applies only to passwords typed during an SSH session, not the password during the authentication phase.
rtj: There seems to be some confusion as to the nature of this attack on ssh...All ssh implementatons send your password in one packet
Argh! This has *nothing* to do with ssh password authentication. It's about typing passwords via ssh after the connection is established. Ssh2 does have a 'keyboard-interactive' mode of authentication, but it's the least preferred so it doesn't get used much.
Try running tcpdump to capture a password-based ssh login. You won't see one-packet-per-key unless you happen to be in that unfortunate keyboard-interactive mode.
Ssh password authentication does not leak timing information.
"It exposes partial information about passwords, but the whole point of using SSH is that you don't need to authenticate through the firewall with passwords, so attackers
have no launch point," adds Rose.
Login is not the only application of passwords. Many people enter passwords for su or sudo. Such passwords are vulnerable to this attack, in the sense that it would make it 50x easier to crack a stolen password file.
Re:Informative - More like criminal action actuall
on
Hotmail Hacked
·
· Score: 2
Not disagreeing with you, but that post seemed to be a paste from a message on Bugtraq on Saturday. Bugtraq always has full disclosure exploits. Why hasn't this legal theory been applied to Bugtraq yet, as they are quite high profile?
Slashdot Mirror
In keeping with that second point, I'd like to point out the dishonesty of the researcher claiming this will help to be 'more responsive to customers' or whatever cant he used. Commercial web sites have already shown their utter unresponsiveness to customers. Even when a customer took the time to compose a detailed email explaining what was wrong with a site, it was either discarded or read with gales of laughter. I know because I was there. If web sites want to serve customers better, they could start by reading and responding to email. Second, watch the error log and fix bugs. Third, watch the access log and find 'dead ends' where people give up. There is no need to spy on customers.
I wonder if we could make a filter that intelligently detects the 'arbitrary identifier' and replaces it with equivalent random characters of the same set. In this case it's pretty obvious. Of course the ultimate counter-weapon to that detector would be making all the image URL's identically formatted strings of base64 crap. But for the time being there might be some way to automate the anti-bug filter.
Of course this is ultimately futile since the server has the data anyway - web bugs are just a cheap way of sharing data with another server.
The ultimate filtering would be collaberative. If I got logo.jpg-234987575 (11k) as the first IMG on the page, and you got logo.jpg-332215533 (also 11k) our software could communicate (ala RBL) and reach a shared decision that the numeric portion is a tracking number. Then future clients (in our network) would randomly generate the number.
- Equipment: The whole thing hinges on the possibility of the equipment becoming cheap. A lot of things have followed that path. If the equipment is forever expensive, the scenario won't happen.
- Energy: It makes sense that hi-res fabrication will consume more energy than traditional production. Of course, less energy will be spent on transport.
- Time: Replication takes longer than traditional production. But production+shipping could take longer than replication. And I think the machines will get faster.
- Waste: It seems like a replicator using a uniform raw material would produce waste of the same material (possibly fused, melted, charred or otherwise altered) that could be recycled into the raw material.
- Distribution: ?
- Raw Materials: We could have a cost-effective infrastructure for delivering these. Stage 1: people buy 75 pound bags at a store. Stage 2: Tanker trucks fill tanks under your lawn (as is done with heating oil in the northeast US). Step 3: Material flows through pipes under the streets and each replicator has a feed hose. Note that each of these delivery mechanisms is cheaper than moving the equivalent mass of finished goods, because the material takes less space and because there is no switching, or decision-making. In comparison with a five-pound parcel shipped via UPS, five pounds of raw material will take a much simpler (thus cheaper) route.
- R&D / Design: Of the replicator or part? If part, I think we'll see a lot of free designs on the net. (To avoid the thorny question of proprietary designs.)
Because raw material might lend itself to bulk handling technologies, like pipelines and pumps. Also, no packaging materials.I guess the relationship of dedicated production equipment to replicators will be like that of CD pressing plants to CDRs. One is cheaper when a large quantity is needed; the other lends itself to ad-hoc production of customized units.
s/builds/computes and you have the conventional wisdom of the pre-computer age. A machine custom built for computing mortgages would be cheaper than a general-purpose computer, right?
I was reading an interview with a Bell Labs engineer in which the engineer discussed the reluctance to go digital. Bell Labs had perfected the electromechanical switch - with bistable ferreeds they were approaching something like 5 cents per crosspoint. How could digital possibly compete?
I think the answer to all these questions lies in the concentration of engineering effort on one task. If a certain replicator technology becomes viable, companies will keep focusing on making it cheaper and faster. We could get a 'Moore's Law' of fabrication.
Interesting. Stallman wrote an essay describing the design logic of Emacs. One thing he pointed out is that a scripting language tacked onto the side of an application as a 'feature' will always suck. It won't be a very high priority for the application's creators and maintainers.
The proper approach is to write the upper layers of the application in the scripting language. So Visual C++ should be made with the compiler, linker, metadata-store etc. in C/C++ and the control/GUI in VB. Or something.
The obvious side effect is that Microsoft's programmers would have felt the pain of an inadequate scripting interface/language and enhanced it.
I write free software in order to write code that will be used in the real world. Most of the code that I write professionally will never see the light of day. The project will change directions at an executive's whim, or the whole project will be canceled, or the company will go bankrupt.
I suspect that very little of the software written for hire is every put into production.
Second, the stuff I write commercially is always twisted to some extent by the organizational/marketing agenda of the employer/customer. Free Software is my chance to write code that's clean and logical.
Third, software that I write for hire is never really finished. There is no money in budgets for polishing code. Once it works I'm on to something else, although the code is full of commented-out bits and unused variables and might need a complete rewrite.
Summary: programming for a living causes an ever-increasing accumulation of bitterness. Writing Free Software counteracts that bitterness with the sweetness of a clean, logical, complete project that might be used by many.
And the "foreword" by Tom Tomorrow underscores the humorless earnestness of this crusade. I guess this pair needs it spelled out in 6" block letters:
That level of knowledge is not required. What "we" (I presume I agree with the poster) want is for the average person to know as much about computers as he does about cars, and as much about electronic information as he does about pen, paper and books. In other words, the rudimentary education that will save him from lots of trouble and grief. A society of illiterate savages cannot be a democratic republic. In such a society, the individual citizens lack the conceptual tools to effectively use their theoretical freedom.
We are entering an era when most human activity is mediated by computers, software and networks. The fact that the majority have almost no knowledge of these things, and are in fact plunged in the most profound superstition and ignorance is not a good omen.
Much of the prosperity of the 20th century was powered by widespread literacy. Learning to read and write is hard (much harder than the basics of computers) but as a society we've decided that everyone should have these skills. Yes, even those:
In a sense, the medical doctors have already succeeded in forcing a little of their knowledge on us: health class, or sexual education in high school. It doesn't make you an MD, but it's a reasonable distillation of parts of medical knowledge likely to affect a young person. I think we should draw up a corresponding curriculum of basic computer knowledge and urge its adoption.
Kids today mostly share the same culture. It's as if they are all sitting in the same room with the same teacher/clown/entertainer. The shared culture is 'cool' to one's peers. Anything a kid creates by himself is not cool, because it doesn't have a marketing budget.
That's the whole point. When TV and it's accompanying mass culture came along, they pushed out older modes of play and imagination.
That's obviously the 'problem' in terms of decreased appeal to intelligent adults. However in terms of sales, the perversion of the original idea has been the company's salvation, as the article makes clear. In other words, the stuff you don't like is the big money-maker.
I didn't read Crowhard as celebrating this trend, merely describing it. To avoid confusion, let's define two different different goals: 1) Amuse and develop intelligent people. 2) Make money. Lego's problem is with #2 - they are losing vast quantities of money. To survive, they need to market new toys that make money. I think most people agree that the system of generic blocks was 'better' per criterion #1.
- RPM is licensed under the GPL.
- Apt-get is part of the Debian Operating System, which is licensed under the GPL.
- Linuxconf is licensed under the GPL.
- YaST is not free software.
Tools 1-3 are free software. They are not "tied" to any distro, contrary to your assertion.I agree with most of what you're saying. Two points, though:
We're heading towards paying by transfer not by bandwidth. Paying by bandwidth means paying for KB/s channel capacity. Paying for transfer means paying for GB moved this month. There's also the possiblility of paying for 95 percentile bandwidth usage - the highest KB/s you achieved in the month after discarding the 5% highest time windows. This seems to be quite popular with colocation providers.
I think in practive we'll have "all you can eat*" for casual users, where "*" means "up to 3G per month." Most people won't know or care about the cap. Those who do will pay for transfer past the cap. Much healthier than all the crappy things they're doing now to reduce usage.
If ISP's are making money on transfer, they have an incentive to upgrade their network. Also, they'll encourage grassroots networking rather than fight it.
I don't understand the tradeoff between bandwidth and encryption that you posit. When you feed cleartext through a block cipher, the result is roughly the same size (rounded up to the block size, typically 8 bytes). If you use a stream cipher like RC4, the encrypted product is the same size as the cleartext. So encryption won't make a 14.4 link any slower.
Maybe you're talking about public key encryption used to establish a session key? I don't think it's enough to really impact your bandwidth.
I think that any crypto built into hardware sold to consumers will be deeply flawed. So far, this has been true. The crypto is too strong for the casual hobbyist, but easy for the government to crack. You mention 802.11 encryption. Recently, researchers at AT&T implemented a previous theorized attack that allows a notebook computer to penetrate 802.11's WEP (wired equivalent privacy) crypto.
Eventually they will get smart enough to make crypto that isn't obviously flawed. The flaws will only be visible to those in on the secret. This is called 'red threading'. Anyhow, the fundamental problem is that making chips is hard and expensive, and chips are opaque to users. Chip makers are very vulnerable to pressure from government agencies. However, so far I don't think they need much pressure - industry associations keep standardizing on bad, flawed cryptosystems.
I'm sure there are exceptions, most of which involve people conspiring to commit "real world" crimes. But are the exceptions worth the price?
This part.
As I understand the article, Microsoft sent letters and envelopes to people and persuaded the people to sign the letters and mail them. Sleazy, but not illegal.
The best way to deal with it is exactly how it was dealt with - public exposure.
Like most of the Outlook 'viruses', this exploit relied on human gullibility. Microsoft didn't forge anyone's signature - rather they sent the letters and envelopes to people and somehow persuaded them to sign and mail them. The fundamental problem is that many people are so pliable that they are simply putty in the hands of any persuasive talker.
One of the 'victims' said, "I sure was misled." Was he? Did he believe the things in the letter which he signed?
This is similar to the democrats busing in senior citizens to vote. The alleged autonomy of the human being is superceded by the gullibility of individuals.
I like this theory, but it probably won't happen. I like it because it rings true with the way institutions evolve - we go from individual merchants maintaining credit files to associations to corporations.
Why it probably won't happen: the DMCA. That's right, if the DMCA were never passed, ISP's could still have huge liability for infringment and might band together to reduce risk. That's really the driver of credit bureaus - risk reduction. But under the DMCA, the ISP just has to yank your access and they have no liability. Therefore they have no incentive to spend money figuring out if you're going to infringe - they simply get the letter and pull the plug.
Cool theory though.
The DMCA has at least two different provisions. The one you're familiar with is "no trafficking in circumvention devices". However, it also has a provision for handling alleged copyright infringement on the net. The goal, which is actually quite sound, was to clarify the responsibilities of ISP's so they couldn't get sued left and right for the activities of their subscribers.
Unfortunately they chose the wrong solution, from a commoner's perspective. I think the right solution would be that the ISP is never responsible for content, period. If ordered by a court, they would of course have to remove access.
Except that the only part of the complaint letter that is under penalty of perjury is the claim that the writer acts on behalf of the copyright holder. The claim of infringement is not under penalty of perjury, and the DMCA allows 'good faith' as a defense against false claims.
So the MPAA has absolutely no risk. What did you expect?
You are essentially taking the tack that TW is a private entity entitled to enter into, and terminate agreements with other private entities. However they are utilizing your community's streets and telephone poles to run their cable. This comes at a high cost to the community in terms of ripped-up streets, visual intrusion, increased probability of a telephone outage, and opportunity cost - there's only room on the poles for so much cable.
They were granted this privilege, a 'franchise' in exchanging for meeting the community's requirements. Generally, these requirements include a rate tarriff and provision of community access channels. Given the monopoly position they are granted by virtue of their franchise, and given the increasing importance of internet connectivity, their is every reason to support increased regulation of their service. No other utility is allowed to arbitrarily discontinue service.
This does not address the fact that per DMCA they may be compelled by law to discontinue service. I'm just pointing out an important fallacy used by corporatists - they want the corporation to be a private citizen when it comes to contracts, but a public utility when it comes to special privileges from the government.
I don't think so, because that's what the DMCA requires. It doesn't matter if the infringement letter is true or false. As we saw in this story, the ISP can even refuse to show you the letter, so you have no way of debating its validity.
for (i = 0; i < options.number_of_password_prompts; i++) {
if (i != 0)
error("Permission denied, please try again.");
password = read_passphrase(prompt, 0);
packet_start(SSH_CMSG_AUTH_PASSWORD);
ssh_put_password(password);
memset(password, 0, strlen(password));
xfree(password);
packet_send();
packet_write_wait();
type = packet_read(&payload_len);
if (type == SSH_SMSG_SUCCESS)
return 1;
if (type != SSH_SMSG_FAILURE)
packet_disconnect("Protocol error: got %d in response to
passwd auth", type);
}
Many people do not understand this. Some believe they are protecting themselves from this risk via RSA authentication. Of course they're not, because the risk only affects passwords in session:
- gorf: My solution is simply not to use passwords at all; I use RSA keys exclusively...
- SagSaw: The best way I can think of is to use the RSA key authentication method. A RSA key pair is used to authenticate, rather than a password. This way, the password is never typed over the network connection.
- Pinball Wizard: Well, if you use RSA you don't need to type a password so that would solve that particular problem.
- subsolar2: I use RSA authentication for remote access, and have since day one. So the only real worry is somebody getting a copy of my private key...
- Greyfox: As has been noted, RSA is the way to go, at least with SSH authentication...
Others think that a GUI client is more secure entering a password in a dialog box suggests batch processing:- stripes: My Java ssh client happens to have "gotten it right" not because I'm smarter then other ssh client authors but because I had a dialog box to ask for the password.
- Hyperbolix: Teraterm
... has several SSH extensions. I beleive one of them has you type in the password all at once and then sends it as a single string, which means that key timing can't be determined. - rgmoore: I think that most Windows terminal emulators have similar functionality. It seems like a very simple step to take to help preserve passwords.
- garcia: don't most GUI terminal packages (including MacSSH, etc) all send it as a single string (SecureCRT)?
- Rimbo:
...I use the free ttssh extension to the freeware terminal program Tera Term. When it asks you for a password, it captures everything in a dialog box, and sends the password as one chunk.
- Jormundgard: Also, every SSH program I've used in windows takes in the whole password before sending it along.
The very few who got it:Argh! This has *nothing* to do with ssh password authentication. It's about typing passwords via ssh after the connection is established. Ssh2 does have a 'keyboard-interactive' mode of authentication, but it's the least preferred so it doesn't get used much.
Try running tcpdump to capture a password-based ssh login. You won't see one-packet-per-key unless you happen to be in that unfortunate keyboard-interactive mode.
Ssh password authentication does not leak timing information.
Login is not the only application of passwords. Many people enter passwords for su or sudo. Such passwords are vulnerable to this attack, in the sense that it would make it 50x easier to crack a stolen password file.
Not disagreeing with you, but that post seemed to be a paste from a message on Bugtraq on Saturday. Bugtraq always has full disclosure exploits. Why hasn't this legal theory been applied to Bugtraq yet, as they are quite high profile?