I was looking at it, and wondering about the people who disagree with the judgement, no not believe MS has a monopoly on PC OSs, believe no action should be taken, and think the judge went too far.
I'm located on Canada's west coast, and we get a lot of TV stations from Washington state. Most of the newscasts from that area were about as pro-MS as possible under the circumstances.
They talked about how MS brings in more money than Boeing, about how so many people own stock in MS and would be affected by this... Sort of a "local boy makes good but now the fedz are gonna ruin it" type of slant.
And of course, the "informal polls" where they ask the people on the street what they think. As expected, it was all "I think MS is great", etc. One person who appeared to be in a cybercafe said something to the effect, "When you think of PCs, you think Microsoft. What's wrong with that?"
But I guess being Washington State that sort of falls under the "MS employees" bit.:)
Outside of the Washington State area I'm sure there are a lot of people who just take the "no government interference, ever" stance, which might explain the rest of the vote.
And then there are the unwashed masses of AOLusers and other clueless folk who think MS is a great innovator because "If it weren't for Microsoft we'd all still be using DOS!" and all that ignorant crap.
Mozilla, once completed, should provide us with a stable and efficient web browser. But many of the problems described will remain.
There will still be Windows-only plugins, IE HTML extensions, polluted Java, etc.
The only way to solve this is to convince everyone that "cross-platform" is good, and that Microsoft is completely proprietary (read: bad) and not a "standard" the way many people like to think MS is.
Yes, especially when the robotic flies get caught by an ordinary spider.:)
We saw a "SlugBot" article on Slashdot today... When these robotic flies become more common, maybe people who don't like being watched will have robotic spiders that feed on robotic flies.
I know an old lady who swallowed a robotic spider She swallowed the robotic spider to catch the robotic fly But I don't know why she swallowed the robotic fly Perhaps she'll be deactivated
CGI programs are usually accessable to the world which makes them easy targets for hax0rs. If you want to write your program in C you have to either double-check every line of code to make sure there are no buffer overflows, or put it up as-is and keep your fingers crossed.
With Perl's automatic bounds checking, along with the "-wT" option and "use strict", you can avoid most stupid mistakes that people make with C.
Performance isn't much of an issue, as mod_perl can make Perl CGI programs work faster than the compiled C equivalent by eliminating the overhead of starting another process.
took four IQ tests from some stupid book with approximately two-hour intervals, and had a bottle of beer approximately 30 minutes before the second one. While my results on the first, third, and fourth tests were approximately the same, the second one was 15 points higher
What type of beer was it?
I've been told by a British friend that beer in Europe is different from beer in North America. European beer is full of vitamins (mostly B vitamins from the yeast), but the North American beer makers filter all the "good stuff" out.
What is the difference between Apache-SSL and mod_ssl? Pros/cons?
I don't mean to start a religious war; I'm really interested in what the difference is. I have to set up an SSL server soon so I'll need info to decide.
I'm not in the USA so the RSA patent is a non-issue.
Most of the past promises have been "kept", sort of. The export regs have been changed but never enough to actually free strong crypto.
The government always has, and still does, consider widespread strong encryption to be their enemy. That's something very fundamental, folks. They're not going to free crypto until there is a fundamental change in their thinking.
We're going to see many more promises of relaxed regulations before we see any real change.
Personally, I think that when 100% of the world's communications are strongly encrypted, we'll still be hearing promises of relaxed export regs.
Obviously the gov can't stop everyone from using crypto. They know that. They just want to stop most people from using crypto. And they've done that very effectively so far.
Only about one percent of email traffic is encrypted. Most people don't even know that web browsers come in "domestic" and "international" flavours, let alone what version they have. Cellphone traffic is encrypted weakly, if at all. Landline telephone traffic is almost completely unencrypted.
To accomplish this the feds have done everything they can to discourage the free flow of cryptographic software. The export controls have been one of the most effective means for this, as it gives them a sort of veto over what products can be sold. In theory they can only stop export, but in practice most companies want to sell one product globally, and that means government-approved crypto. The feds are going to do everything they can to maintain this status quo.
Bernstein argued that source code was speech because it expresses an intellectual construct. The gov argued that it was a functional device because it can be compiled to perform a function. They're both right of course, and it's up to the courts to decide how to resolve the issue.
It's conceivable that the government will manage to convince the court to sit on the fence. I'm no legal expert, but this is what I think will happen:
-- The courts will rule that source code is speech if it is intended to express an idea, but a functional export-restricted device if it is just intended to be compiled into object code. The intent will be the deciding factor.
-- The feds will interpret the ruling as meaning that you have to prove that your source code will not be compiled by some foreigner. If you can't accomplish this impossible task, they won't let you export the software. Anyone who exports unapproved crypto will face the possibility of criminal charges for violating export regs. Even if such charges are totally bogus, it would mean a long and drawn-out court battle. Most hardware and software companies won't take the chance. This type of government FUD has worked very well to date.
-- End result: Bernstein can export the Snuffle source, but the export restrictions remain fundamentally unchanged.
Check out this link for some interesting wiretap info.
This 11 neuron system is capable of differentiating four words, each of which was trained extensively. That's a very tight niche. Until we have a system where each word doesn't have to be trained explicitly, we won't have gotten too far. (Imagine training your computer with the estimated 1+ million English words...)
Doesn't the English languages use only a few dozen sounds ("phonems" or something)?
Once you can recognize those sounds I'm pretty sure it's easy convert a list of those sounds to a written sentence. I'd bet it could be done in under 200 lines of Perl.:)
Why should Exchange users be the only ones to enjoy the pretty blue user interface? Now even Sendmail admins can benefit from revolutionary new error messages!
The BSOD was the only thing missing from Unix sendmail. Well, that and a Navajo code talker to translate the.cf files.
You have new mail. You will have to restart your computer for this change to take effect.
If XML were used with wrapper classes to access conf files some people might be tempted to port those conf files into a database and change the wrapper library to a database wrapper instead.... to a naive user (how many of these are there now?... but in 5 years?) there would be no difference. [...] A database system may look nice from the outside and have lots of great features, but when something goes wrong and the settings for your favorite daemon are in a corrupt database entry what are you going to do?
FreeBSD already uses a database system for information from/etc/passwd to improve performance on sites with a large number of users. Parsing a ten thousand line file every time you want to login, print username for ls/ps/etc. is not very efficient design. Databases solve that problem.
The/etc/passwd and/etc/master.passwd (shadow passwords) are there as usual, but there are also/etc/pwd.db and/etc/spwd.db. You make your changes to the regular password file and then run pwd_mkdb. Vipw, chsh, etc. handle this automatically. The getpwuid and getpwname functions in libc read the database version, providing a real improvement on systems with a large number of users.
I haven't heard of any reliability problems with this system, probably because vipw does proper locking of the database, and if the database ever did get corrupted it's easy to run pwd_mkdb to rebuild the thing from the traditional text files. The regular/etc/passwd files also provide backwards compatability for programs that don't call the database-using libc functions.
FreeBSD (and probably other BSDs as well) made this change a long time ago and haven't looked back. It really does work well.
Just lurking in all the stories about linux vs NT security challenges, and it seems like most slashdotters are incredibly one-sided in their views, driven more by a sense of rebellion than anything else.
Yes, and the Micro$ofties are equally one-sided. Anyone truely impartial probably doesn't care enough one way or the other to state an opinion.
When somebody challenges people to break into their linux box, somebody eventually does, and all kinds of excuses are offered.
I think the Linux PPC box is still running unhacked.
When somebody challenges people to break into their NT box, the linux sneetches with stars upon thars scoff, "Us? Condescend to help Microsoft by breaking into their pitiful OS? The very idea!"
Agreed, that seems to me to be a cop out. I think the Unix advocates know too little about NT to actually make an attempt. I think the reverse is probably true as well, the NT advocates don't know enough about Unix, which is why they have these "hacking contests" (which seem to be mostly promoted by Windows people) to get the Unix folks to do the Unix cracking for them.
Really, I think the main reason Unix gets more attention from hackers than NT is because Unix is just more interesting to hack. There have been decades of real-world experience to understand the security issues associated with Unix. And once you're in, you actually have a rich remotely-accessable environment to play in.
NT on the other hand is a different beast. Being a closed system and relatively new, the security issues are not nearly as well understood, even by NT "experts". And everyone seems to acknowledge than NT is not as good a system to access remotely, which makes a successful crack less fruitfull.
Ultimately I think it's more a security vs. obscurity thing. People don't hack NT not because it's unhackable, but because they just don't know how to hack it, and hacking it is ultimately uninteresting compared to hacking Unix. I wouldn't depend on this obscurity to protect anything of real value though.
Why is network security so complicated in Linux as compared to Windows? My windows computer is connected 24x7 via aDSL, all I have to do is disable file/print sharing; one check box. If I enable sharing, I just have to use common sense and set a password.
Don't forget to disable your web browser and your email software. Er, wait... Why are you connected to the internet?;*)
If you wanted Linux to be more secure, you could try making it easier batten down the hatches.
Since WW2 it has been standard practice for field operatives sending and receiving traffic over totally insecure channels in this manner to use one time pads.
If it's just an endless stream of numbers I doubt it is a one time pad.
Think about it. This is probably used to communicate with many different agents, all of whom would use different codes. If it were a OTP, how do you know where your message begins except by attempting decoding at every point? Too tedious.
This is the first I've heard of numbers stations, but my guess would be that it's codebook based. That is, each agent would memorize a list of codes like this:
74123: Meet in the park at 4 PM 12486: Meet in the library at 10 AM 60789: Go to dropoff point 53726: Proceed with phase 2 83655: Disregard previous instructions 07991: Get the hell out of dodge
Then each agent would just listen for numbers that match one of his codes. Other numbers may be instructions for other agents, or may just be random cover traffic.
Easier to use than a OTP and no need to write down incriminating streams of numbers from the radio.
I seem to recall that something like this was used to communicate with the various resistance cells during WWII, though I think it was code words rather than numbers.
It didn't take long for this guy to fall into the mold. He wants to replace the GNU tools with "freely redistributable implementations". Last I checked the GNU tools were freely redistribable. Why in the world would anyone want to write a replacement grep?
I scan the freebsd-hackers list where the replacement grep thing came up.
The replacement grep was a fraction of the size of GNU grep, in both source code and binary size. This is important for PicoBSD and embedded systems. The code was also considered simpler and more readable. As I recall, the only problem was performance, which was getting close enough to GNU grep that the other advatages made it a net win.
Yes, there is an attitude in the BSD camp that as much of the code as possible should be available under the BSD license. But saying that "BSD Has a Lot of Wacko Users" just because a lot of them don't like the GPL sounds like the pot calling the kettle black. How much software has the GNU project re-written even though there were freely redistributable BSD versions available?
There's nothing "wacko" about rejecting a license you don't like.
I can understand that some people have a problem with the GNU definition of free software, but the BSD definition is something out of the realm of the bizarre.
First of all, don't assume that one authors words to be "the BSD definition".
Second, read the GPL. There are a number of conditions required for you to distribute GPLed software. Mainly, you must also make the source available. If you're unwilling or unable to redistribute the software in source form then you are not free to redistribute it at all. On top of this, if you make modifications that you don't want to GPL, you certainly can't redistribute the software because its very existence is a violation of the GPL.
Saying that GNU software isn't freely redistributable is a bit of a stretch, but not "bizzare". It just depends on what you consider redistribution. There are cases where redistribution means binary-only.
BSD is fragmented in the same sense UNIX is fragmented. UNIX started as one OS, and people began writing their own versions. *BSD began as one OS, and people began writing their own versions.
No, people didn't "begin writing their own versions" of BSD. The code forked. That's a very different thing from writing a whole new version.
Do all of the BSDs have common rc scripts, common libraries, common file locations? I don't know, but I'm fairly certain the answer is no.
There are some differences, but the answer is much closer to "yes" than to "no".
The rc scripts are different, but for the most part they have the same names and perform the same functions. The libraries are based on the same code so they are very close internally, and the API is practically identical between BSDs. Except for a few exceptions, file locations are very standard because it's based on "the BSD way".
Also, the bit about FreeBSD being a technically superior OS was pure FUD. Why is FreeBSD technically superior?
It just is.;^) The same "argument" could be made for Linux, of course. It depends on your religion.
I also don't think the cathedral-ish developement model makes any difference either. The author fails to mention is that Linux kernel patches go through much of the same procedure that *BSD patches do. People submit the patch to Linus, who then reviews and decides if the patch should become part of the official kernel.
Ah, but you're missing the point: There's more to an operating system than just the kernel.
That's why Linux (I'm referring to the OS, not the kernel) can be considered fragmented. Sure, all the distributions share a common kernel, but that's the only thing that all Linux distributions are guaranteed to have in common.
And for some reason, Tux also looks more dangerous.
Dangerous? What're you talking about???
Chuck may look more friendly than mean, but Tux just sits there looking vegitative. Seriously, take a good look at Tux. He just sort of sits there, staring off into space.
There is no question that Chuck could kick Tux's ass.
Tux is a large flightless bird who is totally unarmed. Even if he had a weapon he has no hands in which to hold it.
Chuck is a supernatural creature. He has horns on his head, which presumably are very sharp. As if that weren't enough, Chuck is armed with a pitchfork. In some drawings the pitchfork even has magical energy at the prongs, and in still others Chuck has wings with which he can fly.
I'd bet my money on Chuck. First round, total slaughter.
It seems that linux has a wider hardware support base than BSD.
In general this is true, but there are exceptions. For example, FreeBSD has USB support (originally from NetBSD I think) whereas USB in Linux is still non-functional last I heard.
My understanding of the situation is that the guy was identified by the Word ID on the most common melissa-infected document that circulating the internet, and that there are records of him posting the infected document to usenet.
What a lot of people have overlooked is that this does not necessarily mean he created the virus.
This is a Word macro virus and like other Word macro viruses it infects the system such that all new documents created are infected with the virus. The new infected documents don't automatically get mailed out, unless you send the document to people who are not already infected, in which case they will automatically mail out YOUR document, not the document that originally infected you.
Such is the nature of viruses: they get spread by people other than the person who created it.
It is conceivable that a person could unknowingly contract the virus from someone else and then simply be the first infected person to post to such a widely accessable location as alt.sex.whatever, thus causing their infected document to spread exponentially faster than any other infected document. If you create a new document it would have your ID. If you are infected it would have the virus. This is not the same thing as creating the virus.
I'm not saying the guy didn't create the virus (they say he confessed) I'm just saying that finding the person who created the most widely spread infected file and assuming that they created the virus is a dangerous precedent. If the Word ID and upload records is sufficient to convict a person of creating a virus, then anyone who's ever been infected and unintentionally spread a virus can be charged for creating it, if their infected file gets enough distribution.
I am not aware of crypto systems based on NP complete problems. Even these might turn out to be breakable, if P=NP or if P=NP when you have a quantum computer. If anyone knows of a crypto system based on an NP complete problem (rather than just one that is NP hard) I'd like to take a look at it.
There are quite a few... One of the first PK systems was based on the knapsack algorithm. Most of these are easily broken. Just because a cryptosystem is based on an NP-complete problem doesn't mean the cryptosystem itself is NP-complete.
I think IBM filed a patent a year or two ago for a PK algorithm that was NP-complete and had a proof that all instances were equally hard. I don't recall the details.
The are zero-knowledge proofs for NP-complete problems. You can prove you have a hamiltonian cycle for a graph without revealing any information about the hamiltonian cycle. I'm pretty sure this can be used as an identification scheme: The graph is the public part of your ID, the hamiltonian cycle is the private part. I think it's possible to turn any such identification scheme into a general PK algorithm but I'm not sure.
In any case NP-complete cryptosystems are not likely to replace RSA until large quantum computers really become practical, because RSA is so much simpler to implement.
As for the possibility that P=NP with a quantum computer, I thought Grover's algorithm was proven to be the most efficient algorithm possible?
A Pure Math Major I once knew explained to me that Quantum Computers could factor large numbers in polynomial time (a fact the article confirmed). This means RSA would be transparent to anyone with a QC. It seems that any current cryptographic system would suddenly become obsolete, as the computer could simultaneously check every key/password and give you the correct one. This is almost like proving P=NP (for those of you who don't know any Complexity Theory, encryption and 'one-way' algorithms are possible because we think P=NP is untrue; but it has never been proven). But it's a little bit different.
Factoring is not an NP time problem. Nobody has ever claimed it was. It just seems hard in practice.
Cryptosystems that are based on NP problems are safe even with quantum computers, so long as you square the complexity (like, double the key size).
Would you even need to write code for quantum computers ? Couldn't they just run every possible program simultaneously and see which one came up with the right answer ?
Seems a lot of slashdotters think quantum computers can solve any problem instantly. Not so. Read the paper!
MOST SEARCHES, OF COURSE, WOULD SCAN a list longer than four items. To do so, the algorithm might repeat the three quantum operations many times, nudging the system toward the desired state with every pass through the loop. What makes quantum searching so powerful is that, for a list of N items, the algorithm requires only about the square root of N steps to find its quarry-not the N/2 steps of the classical trial-and-error search. Thus a quantum computer could search a million-name phone book in 1,000 tries instead of half a million. The longer the list, the more dramatically the quantum algorithm will outpace its classical rival.
For those who have asked "how do you return", a few people have pointed out that you can slingshot around a planet to change your direction. But in practice, you don't bother: With most (all?) deep space probes the only things that get sent back are radio signals.
It's still way too slow for interstellar travel, but this technology might be used to more cheaply explore our own solar system. But given the slow acceleration rate, I wonder if regular chemical propellant would still be better for nearby planets.
Does anyone know at what distance this would become faster and/or more cost-effective than chemical propellant? Could it be used for an unmanned trip to Mars, or would chemical propellant still be the better choice? What about Jupiter?
1 Full disclosure does not apply to instantiated data Instantiated data - the data used by specific instances of an algorithm - do not fall within the scope of full disclosure. Were this not so, then even the simplest password would violate the ban on security through obscurity.
The simplest passwords (the ones that assume nobody will guess your mother's maiden name, or the DOB of your firstborn, etc) are security through obscurity.
But if you choose a password of a good length consisting of truely random alphanumeric characters, it's not obscurity because you can accurately calculate the odds of an attacker guessing it.
The whole problem of security-through-obscurity is that obscurity looks better than it really is, and its true value is impossible to calculate (Except in the negative. As in, after you've been "owned"). This leads people to overestimate the effectiveness of the obscurity, which in turn leads to a false sense of security.
2 Full disclosure does not apply to time-limited secrets Secrets that expire after a short lifetime can be protected by a wider array of techniques than long-standing secrets. The defense of information that will be irrelevant in a matter of hours or days may not warrant fully peer-reviewed security. Consider the famous Navajo code-talkers of World War II. Among the Americans coordinating the at tack against Japanese-held islands in the Pacific were a number of Navajo Indians, who spoke a slangy version of the complex Navajo tongue. Commands from HQ were issued through these code-talkers, who encrypted and decrypted with an alacrity that belittled the automated methods of the day.
I think it's important to note that the Navajo translations were never sent out plaintext. After being translated into Navajo, the messages were still encrypted before they were sent.
Being a computer person, I'm not familiar enough with "ancient" practices to know whether or not to classify the use of code-talkers as security or obscurity. In any case, using a code-talker with a modern cipher would actually be detremental, reducing encryption speed by a factor of about a billion. Modern ciphers are designed to be secure for decades regardless of the language used in the plaintext. The code-talker element of this item is completely irrelevant today.
As for the argument about time-limited secrets, there's no obscurity involved (at least, not anymore). If you can figure that an adversary can try 2**72 keys before the secret becomes useless due to time, and you have a 128-bit key, then there is only a 1 in 2**56 chance of them guessing the key before the data expires. A "one in 72 quadrillion" chance is security, not obscurity.
3 Obscurity serves as a tripwire [...] Imagine that our same admin had also invoked a tripwire script and set it to listen on one or more unused ports. When the tripwire is probed with a SYN packet from a cracker trying to locate the web server, instantly the system goes to full alert. The packet is logged and the admin's pager sounds like an alarm.
First of all, if the attacker uses one of the various stealth scanning techniques, the system you've described is completely worthless. Some scanners don't complete the three-way handshake and your script would never be run. Others don't even send a SYN at all.
Second, if you can detect the scan, what are you going to do about it? You could block the IP, but the attacker could always attack you from another location. And there's no guarantee that the attacker is at the IP the scan originates from, as packets can be forged (to make you block the wrong hosts), and there are even a couple of ways to bounce a port scan off an innocent machine.
Third, if your web server is vulnerable, the alarm isn't going to save you. By the time you intervene your box would probably have been owned and used to scan hundreds of other innocent hosts. All because you overestimated the effectiveness of obscurity, leading to a false sense of security.
4 Asymmetric cryptography exhibits traits of STO Despite the notion that asymmetric cryptography such as RSA is 'real' security, in some aspects these methods resemble STO. Indeed, this entire class of cryptography is founded on the hopeful guess that a certain mathematical problem is intractable. The back door into cryptographic methods that rely on multiplying primes is, quite simply, to develop a swift means of factoring those multiples. This NP-time problem must be solved before a private key can be derived from its corresponding public key, and the notorious difficulty of NP problems leads some supporters to characterize asymmetric cryptography as 'prova bly secure'.
The only cryptographic systems that are "provably secure" are the One Time Pad and certain other secret splitting algorithms. These cannot be broken no matter what mathematical problems you solve and no matter how much computing power you have. This is for information-theoretic reasons that I won't go in to here.
More common are systems that are provably equivalent to some hard problem. That is, if you can break the system, you can also do something else that is very hard (and vice versa).
The whole point of proving something is equivalent to a hard problem is so that you can better estimate the difficulty breaking the system. If the best minds in the world have worked for centuries trying to figure out how to factor large numbers, and progress is at a fairly constant (slow) rate, you can get a pretty accurate estimate of how hard it is to factor a number of a given size. And if your cryptosystem is provably equivalent to factoring, the same estimate applies to your cryptosystem.
Most cryptosystems depend on symmetric algorithms (like 3DES) that aren't provably equivalent to anything. This is why so much study is done on ciphers, trying to find weaknesses, before a cipher can be considered "secure". The more study is done, the better the estimate of the security of the cipher. Most cryptologists would tell you NOT to use the AES candidates yet, because they aren't well-studied enough. Most cryptologists, when their data is on the line, would prefer to see it encrypted with Triple-DES because it is such a well-studied cipher. If the best cryptographic minds in the world have studied a cipher for over two decades and have not found any major weaknesses then you can be pretty sure that there aren't going to be any suprises.
5 Conclusions Security in the absence of obscurity is not strictly possible, but good systems both localize and advertise their points of obscurity.
In practice there is no such thing as perfect security. The best a person can hope for is to make a realistic estimate of the difficulty of breaking the system. In the case of obscurity, realistic estimates are impossible, or simply not attempted. In the case of obscurity the best a person can do is make an optimistic estimate in order to justify the effort of obscuring a system. Such optimistic estimates tend to be wrong.
Because of people blindly blocking all ICMP, PMTUD (path maximum transmission unit discovery) is horribly broken for a large percentage of the internet.
The problem appears when you have a link between yourself and the destination that uses an MTU less than or not equal to (I can't remember which) the common 1500. What usually happens is small transfers work ok, but large transfers don't. So, you may be able to (for example) log in and get a directory listing from FTP sites, and even download small files, but trying to download large files just doesn't work properly. This has frustrated many people, as the problem is not easy to figure out. And once you do figure it out, the only way to fix things is to complain to the offending firewall operator, who will usually give a response like "Everything works fine for me. Must be a problem with your system.", or something similar.
"You're violating RFC xxxx" is just no match for "It works fine for me."
Slashdot Mirror
I'm located on Canada's west coast, and we get a lot of TV stations from Washington state. Most of the newscasts from that area were about as pro-MS as possible under the circumstances.
They talked about how MS brings in more money than Boeing, about how so many people own stock in MS and would be affected by this... Sort of a "local boy makes good but now the fedz are gonna ruin it" type of slant.
And of course, the "informal polls" where they ask the people on the street what they think. As expected, it was all "I think MS is great", etc. One person who appeared to be in a cybercafe said something to the effect, "When you think of PCs, you think Microsoft. What's wrong with that?"
But I guess being Washington State that sort of falls under the "MS employees" bit. :)
Outside of the Washington State area I'm sure there are a lot of people who just take the "no government interference, ever" stance, which might explain the rest of the vote.
And then there are the unwashed masses of AOLusers and other clueless folk who think MS is a great innovator because "If it weren't for Microsoft we'd all still be using DOS!" and all that ignorant crap.
Mozilla, once completed, should provide us with a stable and efficient web browser. But many of the problems described will remain.
There will still be Windows-only plugins, IE HTML extensions, polluted Java, etc.
The only way to solve this is to convince everyone that "cross-platform" is good, and that Microsoft is completely proprietary (read: bad) and not a "standard" the way many people like to think MS is.
Yes, especially when the robotic flies get caught by an ordinary spider. :)
We saw a "SlugBot" article on Slashdot today... When these robotic flies become more common, maybe people who don't like being watched will have robotic spiders that feed on robotic flies.
I know an old lady who swallowed a robotic spider
She swallowed the robotic spider to catch the robotic fly
But I don't know why she swallowed the robotic fly
Perhaps she'll be deactivated
CGI programs are usually accessable to the world which makes them easy targets for hax0rs. If you want to write your program in C you have to either double-check every line of code to make sure there are no buffer overflows, or put it up as-is and keep your fingers crossed.
With Perl's automatic bounds checking, along with the "-wT" option and "use strict", you can avoid most stupid mistakes that people make with C.
Performance isn't much of an issue, as mod_perl can make Perl CGI programs work faster than the compiled C equivalent by eliminating the overhead of starting another process.
What type of beer was it?
I've been told by a British friend that beer in Europe is different from beer in North America. European beer is full of vitamins (mostly B vitamins from the yeast), but the North American beer makers filter all the "good stuff" out.
What is the difference between Apache-SSL and mod_ssl? Pros/cons?
I don't mean to start a religious war; I'm really interested in what the difference is. I have to set up an SSL server soon so I'll need info to decide.
I'm not in the USA so the RSA patent is a non-issue.
Yet another promise in a long line of promises.
Most of the past promises have been "kept", sort of. The export regs have been changed but never enough to actually free strong crypto.
The government always has, and still does, consider widespread strong encryption to be their enemy. That's something very fundamental, folks. They're not going to free crypto until there is a fundamental change in their thinking.
We're going to see many more promises of relaxed regulations before we see any real change.
Personally, I think that when 100% of the world's communications are strongly encrypted, we'll still be hearing promises of relaxed export regs.
File this one under "vaporware".
Obviously the gov can't stop everyone from using crypto. They know that. They just want to stop most people from using crypto. And they've done that very effectively so far.
Only about one percent of email traffic is encrypted. Most people don't even know that web browsers come in "domestic" and "international" flavours, let alone what version they have. Cellphone traffic is encrypted weakly, if at all. Landline telephone traffic is almost completely unencrypted.
To accomplish this the feds have done everything they can to discourage the free flow of cryptographic software. The export controls have been one of the most effective means for this, as it gives them a sort of veto over what products can be sold. In theory they can only stop export, but in practice most companies want to sell one product globally, and that means government-approved crypto. The feds are going to do everything they can to maintain this status quo.
Bernstein argued that source code was speech because it expresses an intellectual construct. The gov argued that it was a functional device because it can be compiled to perform a function. They're both right of course, and it's up to the courts to decide how to resolve the issue.
It's conceivable that the government will manage to convince the court to sit on the fence. I'm no legal expert, but this is what I think will happen:
-- The courts will rule that source code is speech if it is intended to express an idea, but a functional export-restricted device if it is just intended to be compiled into object code. The intent will be the deciding factor.
-- The feds will interpret the ruling as meaning that you have to prove that your source code will not be compiled by some foreigner. If you can't accomplish this impossible task, they won't let you export the software. Anyone who exports unapproved crypto will face the possibility of criminal charges for violating export regs. Even if such charges are totally bogus, it would mean a long and drawn-out court battle. Most hardware and software companies won't take the chance. This type of government FUD has worked very well to date.
-- End result: Bernstein can export the Snuffle source, but the export restrictions remain fundamentally unchanged.
Check out this link for some interesting wiretap info.
Doesn't the English languages use only a few dozen sounds ("phonems" or something)?
Once you can recognize those sounds I'm pretty sure it's easy convert a list of those sounds to a written sentence. I'd bet it could be done in under 200 lines of Perl. :)
But I'm no speech recognition expert.
<Obligatory NT whipping>
Why should Exchange users be the only ones to enjoy the pretty blue user interface? Now even Sendmail admins can benefit from revolutionary new error messages!
The BSOD was the only thing missing from Unix sendmail. Well, that and a Navajo code talker to translate the .cf files.
You have new mail. You will have to restart your computer for this change to take effect.
</Obligatory NT whipping>
FreeBSD already uses a database system for information from /etc/passwd to improve performance on sites with a large number of users. Parsing a ten thousand line file every time you want to login, print username for ls/ps/etc. is not very efficient design. Databases solve that problem.
The /etc/passwd and /etc/master.passwd (shadow passwords) are there as usual, but there are also /etc/pwd.db and /etc/spwd.db. You make your changes to the regular password file and then run pwd_mkdb. Vipw, chsh, etc. handle this automatically. The getpwuid and getpwname functions in libc read the database version, providing a real improvement on systems with a large number of users.
I haven't heard of any reliability problems with this system, probably because vipw does proper locking of the database, and if the database ever did get corrupted it's easy to run pwd_mkdb to rebuild the thing from the traditional text files. The regular /etc/passwd files also provide backwards compatability for programs that don't call the database-using libc functions.
FreeBSD (and probably other BSDs as well) made this change a long time ago and haven't looked back. It really does work well.
Yes, and the Micro$ofties are equally one-sided. Anyone truely impartial probably doesn't care enough one way or the other to state an opinion.
I think the Linux PPC box is still running unhacked.
Agreed, that seems to me to be a cop out. I think the Unix advocates know too little about NT to actually make an attempt. I think the reverse is probably true as well, the NT advocates don't know enough about Unix, which is why they have these "hacking contests" (which seem to be mostly promoted by Windows people) to get the Unix folks to do the Unix cracking for them.
Really, I think the main reason Unix gets more attention from hackers than NT is because Unix is just more interesting to hack. There have been decades of real-world experience to understand the security issues associated with Unix. And once you're in, you actually have a rich remotely-accessable environment to play in.
NT on the other hand is a different beast. Being a closed system and relatively new, the security issues are not nearly as well understood, even by NT "experts". And everyone seems to acknowledge than NT is not as good a system to access remotely, which makes a successful crack less fruitfull.
Ultimately I think it's more a security vs. obscurity thing. People don't hack NT not because it's unhackable, but because they just don't know how to hack it, and hacking it is ultimately uninteresting compared to hacking Unix. I wouldn't depend on this obscurity to protect anything of real value though.
Don't forget to disable your web browser and your email software. Er, wait... Why are you connected to the internet? ;*)
It's not that hard to disable services... Is it?
If it's just an endless stream of numbers I doubt it is a one time pad.
Think about it. This is probably used to communicate with many different agents, all of whom would use different codes. If it were a OTP, how do you know where your message begins except by attempting decoding at every point? Too tedious.
This is the first I've heard of numbers stations, but my guess would be that it's codebook based. That is, each agent would memorize a list of codes like this:
74123: Meet in the park at 4 PM
12486: Meet in the library at 10 AM
60789: Go to dropoff point
53726: Proceed with phase 2
83655: Disregard previous instructions
07991: Get the hell out of dodge
Then each agent would just listen for numbers that match one of his codes. Other numbers may be instructions for other agents, or may just be random cover traffic.
Easier to use than a OTP and no need to write down incriminating streams of numbers from the radio.
I seem to recall that something like this was used to communicate with the various resistance cells during WWII, though I think it was code words rather than numbers.
I followed that link, and hit the "Hobbes' Internet Timeline" link...
It lists the first node at UCLA as being a SDS SIGMA 7.
Running an operating system called "SEX".
Is is possible that they know even back then that the net would be used for downloading porn? The foresight of these people amazes me.
I scan the freebsd-hackers list where the replacement grep thing came up.
The replacement grep was a fraction of the size of GNU grep, in both source code and binary size. This is important for PicoBSD and embedded systems. The code was also considered simpler and more readable. As I recall, the only problem was performance, which was getting close enough to GNU grep that the other advatages made it a net win.
Yes, there is an attitude in the BSD camp that as much of the code as possible should be available under the BSD license. But saying that "BSD Has a Lot of Wacko Users" just because a lot of them don't like the GPL sounds like the pot calling the kettle black. How much software has the GNU project re-written even though there were freely redistributable BSD versions available?
There's nothing "wacko" about rejecting a license you don't like.
First of all, don't assume that one authors words to be "the BSD definition".
Second, read the GPL. There are a number of conditions required for you to distribute GPLed software. Mainly, you must also make the source available. If you're unwilling or unable to redistribute the software in source form then you are not free to redistribute it at all. On top of this, if you make modifications that you don't want to GPL, you certainly can't redistribute the software because its very existence is a violation of the GPL.
Saying that GNU software isn't freely redistributable is a bit of a stretch, but not "bizzare". It just depends on what you consider redistribution. There are cases where redistribution means binary-only.
No, people didn't "begin writing their own versions" of BSD. The code forked. That's a very different thing from writing a whole new version.
There are some differences, but the answer is much closer to "yes" than to "no".
The rc scripts are different, but for the most part they have the same names and perform the same functions. The libraries are based on the same code so they are very close internally, and the API is practically identical between BSDs. Except for a few exceptions, file locations are very standard because it's based on "the BSD way".
It just is. ;^) The same "argument" could be made for Linux, of course. It depends on your religion.
Ah, but you're missing the point: There's more to an operating system than just the kernel.
That's why Linux (I'm referring to the OS, not the kernel) can be considered fragmented. Sure, all the distributions share a common kernel, but that's the only thing that all Linux distributions are guaranteed to have in common.
Dangerous? What're you talking about???
Chuck may look more friendly than mean, but Tux just sits there looking vegitative. Seriously, take a good look at Tux. He just sort of sits there, staring off into space.
There is no question that Chuck could kick Tux's ass.
Tux is a large flightless bird who is totally unarmed. Even if he had a weapon he has no hands in which to hold it.
Chuck is a supernatural creature. He has horns on his head, which presumably are very sharp. As if that weren't enough, Chuck is armed with a pitchfork. In some drawings the pitchfork even has magical energy at the prongs, and in still others Chuck has wings with which he can fly.
I'd bet my money on Chuck. First round, total slaughter.
In general this is true, but there are exceptions. For example, FreeBSD has USB support (originally from NetBSD I think) whereas USB in Linux is still non-functional last I heard.
My understanding of the situation is that the guy was identified by the Word ID on the most common melissa-infected document that circulating the internet, and that there are records of him posting the infected document to usenet.
What a lot of people have overlooked is that this does not necessarily mean he created the virus.
This is a Word macro virus and like other Word macro viruses it infects the system such that all new documents created are infected with the virus. The new infected documents don't automatically get mailed out, unless you send the document to people who are not already infected, in which case they will automatically mail out YOUR document, not the document that originally infected you.
Such is the nature of viruses: they get spread by people other than the person who created it.
It is conceivable that a person could unknowingly contract the virus from someone else and then simply be the first infected person to post to such a widely accessable location as alt.sex.whatever, thus causing their infected document to spread exponentially faster than any other infected document. If you create a new document it would have your ID. If you are infected it would have the virus. This is not the same thing as creating the virus.
I'm not saying the guy didn't create the virus (they say he confessed) I'm just saying that finding the person who created the most widely spread infected file and assuming that they created the virus is a dangerous precedent. If the Word ID and upload records is sufficient to convict a person of creating a virus, then anyone who's ever been infected and unintentionally spread a virus can be charged for creating it, if their infected file gets enough distribution.
There are quite a few... One of the first PK systems was based on the knapsack algorithm. Most of these are easily broken. Just because a cryptosystem is based on an NP-complete problem doesn't mean the cryptosystem itself is NP-complete.
I think IBM filed a patent a year or two ago for a PK algorithm that was NP-complete and had a proof that all instances were equally hard. I don't recall the details.
The are zero-knowledge proofs for NP-complete problems. You can prove you have a hamiltonian cycle for a graph without revealing any information about the hamiltonian cycle. I'm pretty sure this can be used as an identification scheme: The graph is the public part of your ID, the hamiltonian cycle is the private part. I think it's possible to turn any such identification scheme into a general PK algorithm but I'm not sure.
In any case NP-complete cryptosystems are not likely to replace RSA until large quantum computers really become practical, because RSA is so much simpler to implement.
As for the possibility that P=NP with a quantum computer, I thought Grover's algorithm was proven to be the most efficient algorithm possible?
Factoring is not an NP time problem. Nobody has ever claimed it was. It just seems hard in practice.
Cryptosystems that are based on NP problems are safe even with quantum computers, so long as you square the complexity (like, double the key size).
Seems a lot of slashdotters think quantum computers can solve any problem instantly. Not so. Read the paper!
MOST SEARCHES, OF COURSE, WOULD SCAN a list longer than four items. To do so, the algorithm might repeat the three quantum operations many times, nudging the system toward the desired state with every pass through the loop. What makes quantum searching so powerful is that, for a list of N items, the algorithm requires only about the square root of N steps to find its quarry-not the N/2 steps of the classical trial-and-error search. Thus a quantum computer could search a million-name phone book in 1,000 tries instead of half a million. The longer the list, the more dramatically the quantum algorithm will outpace its classical rival.
For those who have asked "how do you return", a few people have pointed out that you can slingshot around a planet to change your direction. But in practice, you don't bother: With most (all?) deep space probes the only things that get sent back are radio signals.
It's still way too slow for interstellar travel, but this technology might be used to more cheaply explore our own solar system. But given the slow acceleration rate, I wonder if regular chemical propellant would still be better for nearby planets.
Does anyone know at what distance this would become faster and/or more cost-effective than chemical propellant? Could it be used for an unmanned trip to Mars, or would chemical propellant still be the better choice? What about Jupiter?
The simplest passwords (the ones that assume nobody will guess your mother's maiden name, or the DOB of your firstborn, etc) are security through obscurity.
But if you choose a password of a good length consisting of truely random alphanumeric characters, it's not obscurity because you can accurately calculate the odds of an attacker guessing it.
The whole problem of security-through-obscurity is that obscurity looks better than it really is, and its true value is impossible to calculate (Except in the negative. As in, after you've been "owned"). This leads people to overestimate the effectiveness of the obscurity, which in turn leads to a false sense of security.
I think it's important to note that the Navajo translations were never sent out plaintext. After being translated into Navajo, the messages were still encrypted before they were sent.
Being a computer person, I'm not familiar enough with "ancient" practices to know whether or not to classify the use of code-talkers as security or obscurity. In any case, using a code-talker with a modern cipher would actually be detremental, reducing encryption speed by a factor of about a billion. Modern ciphers are designed to be secure for decades regardless of the language used in the plaintext. The code-talker element of this item is completely irrelevant today.
As for the argument about time-limited secrets, there's no obscurity involved (at least, not anymore). If you can figure that an adversary can try 2**72 keys before the secret becomes useless due to time, and you have a 128-bit key, then there is only a 1 in 2**56 chance of them guessing the key before the data expires. A "one in 72 quadrillion" chance is security, not obscurity.
First of all, if the attacker uses one of the various stealth scanning techniques, the system you've described is completely worthless. Some scanners don't complete the three-way handshake and your script would never be run. Others don't even send a SYN at all.
Second, if you can detect the scan, what are you going to do about it? You could block the IP, but the attacker could always attack you from another location. And there's no guarantee that the attacker is at the IP the scan originates from, as packets can be forged (to make you block the wrong hosts), and there are even a couple of ways to bounce a port scan off an innocent machine.
Third, if your web server is vulnerable, the alarm isn't going to save you. By the time you intervene your box would probably have been owned and used to scan hundreds of other innocent hosts. All because you overestimated the effectiveness of obscurity, leading to a false sense of security.
The only cryptographic systems that are "provably secure" are the One Time Pad and certain other secret splitting algorithms. These cannot be broken no matter what mathematical problems you solve and no matter how much computing power you have. This is for information-theoretic reasons that I won't go in to here.
More common are systems that are provably equivalent to some hard problem. That is, if you can break the system, you can also do something else that is very hard (and vice versa).
The whole point of proving something is equivalent to a hard problem is so that you can better estimate the difficulty breaking the system. If the best minds in the world have worked for centuries trying to figure out how to factor large numbers, and progress is at a fairly constant (slow) rate, you can get a pretty accurate estimate of how hard it is to factor a number of a given size. And if your cryptosystem is provably equivalent to factoring, the same estimate applies to your cryptosystem.
Most cryptosystems depend on symmetric algorithms (like 3DES) that aren't provably equivalent to anything. This is why so much study is done on ciphers, trying to find weaknesses, before a cipher can be considered "secure". The more study is done, the better the estimate of the security of the cipher. Most cryptologists would tell you NOT to use the AES candidates yet, because they aren't well-studied enough. Most cryptologists, when their data is on the line, would prefer to see it encrypted with Triple-DES because it is such a well-studied cipher. If the best cryptographic minds in the world have studied a cipher for over two decades and have not found any major weaknesses then you can be pretty sure that there aren't going to be any suprises.
In practice there is no such thing as perfect security. The best a person can hope for is to make a realistic estimate of the difficulty of breaking the system. In the case of obscurity, realistic estimates are impossible, or simply not attempted. In the case of obscurity the best a person can do is make an optimistic estimate in order to justify the effort of obscuring a system. Such optimistic estimates tend to be wrong.
Someone, please! Moderate these posts up!
Because of people blindly blocking all ICMP, PMTUD (path maximum transmission unit discovery) is horribly broken for a large percentage of the internet.
The problem appears when you have a link between yourself and the destination that uses an MTU less than or not equal to (I can't remember which) the common 1500. What usually happens is small transfers work ok, but large transfers don't. So, you may be able to (for example) log in and get a directory listing from FTP sites, and even download small files, but trying to download large files just doesn't work properly. This has frustrated many people, as the problem is not easy to figure out. And once you do figure it out, the only way to fix things is to complain to the offending firewall operator, who will usually give a response like "Everything works fine for me. Must be a problem with your system.", or something similar.
"You're violating RFC xxxx" is just no match for "It works fine for me."
The only real solution is education.
So spread the word. Save the net.