If they don't work, he'll have slowed down to low-altitude terminal velocity. But if everything works, he'll be landing at normal parachute-landing speed, so he may bounce a bit when he first touches down.
So many network examples out there use 1.1.1.1 and 2.2.2.2 as addresses - I hope the APNIC has the sense to make 1.1.1.0/24 reserved.
1.0.0.0/8 isn't publicly routable - it was reserved, and ISPs don't route it, though they'll be starting now. 1.0.0.0/8 was temporarily safe to use *because* it wasn't routable or used for real Internet sites.
The original purpose of whois was to provide contact info so that you can reach a domain administrator if their DNS is broken or there was a problem with their bill. The ICANN folks have tried to make it much more than that, because the "IP" that they care about is "Intellectual Property", in particular protecting trademark owners from people who might infringe on them. Providing a contact service that's more reliable (or less reliable) than "Admin Contact, example-dot-com-admin@hotmail.com" doesn't assert anything in particular about ownership or liability.
Of course, if the registrar's ripping off their customers by providing administrative access for a domain that the registrar rented instead of providing the domain that the buyer thought they were buying, that can be a problem and using the registrar's privacy service makes it harder to prove that your side of the story is the correct one, but you knew the job was dangerous when you took it.
And of course, even complete correct ICBM-capable subpoena-capable True Names And Addresses, which is what the ICANN/WIPO types wanted whois information to be, doesn't always guarantee anything useful. I once tracked a spammer's registration info and found that they were a basic Delaware Corporation, so their assets may be no more than a couple sheets of paper in a file drawer in Greenville and the domain name, and that doesn't let you find or punish the miscreants behind the spamming.
The Feds spent the 90s trying to block public use of encryption anywhere in the world, but especially in the US. The excuse they used was that it would weaken their ability to eavesdrop on Commies (not that there was still a Soviet Union around by then), but they were able to interfere with the development and release of a lot of open-source software by claiming that releasing it on a public server would be export and therefore covered by the ITAR munitions export laws. They even withheld approval for "bones" versions of security software that only had hooks for crypto routines and not the crypto code itself, and for signature-only systems that had crypto code that could potentially be adapted to do encryption (i.e. anything with RSA.)
So here it is a decade or more later, and the National Information Infrastructure is less secure because they wanted to eavesdrop on Americans.
I'm guessing you probably looked on Google for references to robots.txt and HTML META - if SEO scum are any good, they should be among the first references you'll find, because that is one thing they know about, and they'll use that as part of their self-promotion.
It was probably true at one of them once, and if you're building a new campus today it's not a bad approach, but it's not clear where or when it actually originated.
And if you've been around Frank Lloyd Wright buildings much, you'll hear lots of stories about how they leak unless you're really aggressive about maintenance, and if you're over about 5'6"" (167cm), you'll rapidly notice that the dude was short and didn't mind forcing taller people to duck in buildings he designed...
The ones that really matter are AdBlock and NoScript - if they're not ready I'm not switching.
I also use a few others, like Ghostery, and I'm assuming the restore-most-recently-deleted-tab button will still work, but it's the basic safety ones that matter.
Search engines try to tell humans what web sites would have interesting contents based on their queries. They use robots and content models to approximate that so they can produce results quickly and economically. SEOs try to get the robots to tell the humans "my page is really interesting", when it usually isn't, which is scummy lying, and you shouldn't encourage such people.
They've really got three things to offer:
Telling the web site owner how to structure their content so that the robots can find it. That's legitimate and useful, but that's also something that can be covered in 1-2 pages of documentation. On the other hand, sometimes less-technical web site owners find it worthwhile to hire consultants to do that for them, which is fine, but usually the consultants they really need call themselves "web designers".
Telling web site owners how to make their content look more interesting (keeping it up to date, adding new material, etc.) To the extent that it's making the content actually more interesting to human readers, cool, but if the consultant is just adding features to make it look attractive to robots so humans will look at it and generate advertising revenue, and not to make it actually interesting to actual humans, it's still sleazy. If you want to hire somebody to make your site actually interesting to humans, the consultants you should hire usually call themselves "editors" or "authors" or "web designers", not "SEOs".
Lying to robots so the robots will lie to the humans, using whatever tricks still work, whether that's link farms or astroturfing popular discussion sites or blog comment spam or whatever. This is sleazy scum behaviour that makes search engine results less useful to humans, and at best it's done because of ignorance and greed, though it's increasingly often done to distribute malware. And yes, if you want to hire somebody to lie to robots to boost your search engine position, the consultant you're looking for will call probably themselves an SEO.
The primary reason for robots.txt was to protect small slow web servers from being swamped by Altavista's big fast web crawlers. Dynamic pages weren't a problem back then. On the other hand, after robots.txt became common, setting up dynamic pages to trap crawlers that ignored it into infinite loops became common also, because most of them were run by spammers of various sorts.
It'll just keep them from bothering you, and you're (almost by definition) too small for them to care that they're not indexing your site.
Advertising their IP address block with BGP, if your ISP is careless enough to let you do that, now *that* would get their attention:-)
As an intermediate level of annoyance, you could set up your DNS server to respond to queries from Microsoftland to return entertaining IP addresses, such as 127.0.0.2 or bing's IP addresses or whatever.
If you remember the history of robots.txt because you were there are the time, rather than because you read it in some history book somewhere, the purpose was to protect small web servers from being trashed by big search robots, initially altavista, and secondarily to protect them from other well-behaved web crawlers of whatever sorts. There were no script-generated pages back then, or at least hardly any; just handing out static html could be difficult enough if you had a small pipe and a slow server, though serving images to a robot obviously a waste of time back then.
Tarpits of various sorts existed soon after robots.txt, as a way of trapping spammer-run crawlers that ignored robots.txt, but that was as much for fun as for necessity:-)
And yes, people did have/private/ directories back then and still do now, thinking that because Google's polite about not looking in directories robots.txt says not to that there aren't humans or impolite robots that won't look there.
Actually, the Bush/Cheney administration were "chaotic evil"... just because they talked about "the Rule of Law" in accents resembling Bismark talking about "Blood and Iron" doesn't mean they intended it to apply to themselves.
No - that part means that the US and the southern states have no requirements to pay back Confederate debts, so anybody who lent money to the Confederacy loses. Congress still isn't allowed to cancel debts made by the US itself.
And if it did, because we didn't have enough tax base to pay the government's debts, fat chance on borrowing more money from the still-solvent parts of the world. Unfortunately, given the spending habits of the US government from Reagan on, borrowing money instead of saving it while spending the Social Security surplus when the Baby Boom and post-boom birthrate declines are setting us up for a workers-to-retirees ratio that can't sustain itself, we may get to find that out a few years after I retire.
Apparently it's a Macintosh font, which is why I didn't get the joke:-) However, it's designed by Kris Holmes (who did Lucida), so I assume there may be some licensing or cost requirements. Is it available for either free-as-in-speech or at least free-as-in-beer? It's possible to download from various places around the web, but I don't know whether that's legitimate or not.
Something unusual? There was a young guy wearing a suit and tie who didn't look like he was going to a job interview. Oh, wait, you're probably wondering if I saw the clown on the unicycle. He wasn't juggling knives and flaming torches like the kid who's usually here at lunchtime, so I just assumed he was headed somewhere else to work.
1a - If your email is encrypted with IPSEC, then there's a per-packet overhead from the extra packet header; it's not really a percentage, though you could think of it that way for average packet sizes. It's not significant for most applications except VOIP, which typically has very small data wrapped in lots of RTP/UDP/IPSEC/IP headers.
1b - If your email is encrypted at or above the transport layer, there's typically minimal overhead. The data encryption doesn't take extra space, except sometimes for the last packet of a session which might not contain a full block of plaintext so it gets padded by a few bytes.
1c - There's typically some setup overhead for key exchange. It doesn't take much transmission time unless you're on some funky very-low-bit-rate transmission medium, but there can be a couple of RTTs and some public-key math calculation time. So maybe it takes an extra second for you to start Gmail - big deal.
2 - That's why you compress the data *before* encrypting. Not many people use compressed transmission systems these days (e.g. fancy WAN optimizer tricks), and if anybody's still using SLIP or PPP with header compression, it doesn't care about HTTPS vs HTTP because that's not a Layer 1/2/3 problem.
The basic Elliptic Curve Crypto math was published in 1986 and isn't patented, but there have been a lot of implementation techniques that let you use the stuff efficiently which have been patented. However, even many of those patents have expired already or will soon (plus some of them have problems with prior art that could sink them, but the prime example of that is the Apple/NeXT patent which expires Real Soon.) There are a bunch of patents that issued in 2001 that may be a problem, but even those expire in 2021 unless the US does a Disney and extends them.
The good news is that effective Quantum Cryptography is a ways off - it's unlikely that the next decade will give us widespread effective QC that can reliably factor big numbers, so we aren't likely to need wholesale replacement of free crypto with patented crypto before then.
On the other hand, if QC can also crack ECC, that'd be annoying.
It's generally believed that if you can attack factoring, you can attack discrete logarithms, so Diffie-Hellman in integer prime-number bases is still risky, so if Quantum Computers ever get good enough to bother RSA, they'll be a real pain. On the other hand, Elliptic Curves may still be safe. Nobody's sure quite how safe (right now EC keys can be significantly shorter than factoring-based RSA or DH, but that may fall if there are theoretical breakthroughs, which is much less likely with factoring), but they may be enough, and at least the patents will have run out before Quantum Computers get good enough to factor numbers more interesting than 15.
But otherwise you're stuck with secret-key symmetric cryptography, or One-Time Pads. Remember Kerberos and the various other systems that depend on a Master Key locked safely in a Key Distribution Center? Remember couriers with briefcases handcuffed to their arms? Yuk! There were good reasons to use public keys instead!
There has been some work done on quantum-computer attacks on symmetric key systems, but AFAIK the best that it looks like they'll do in general is to effectively halve the key length, so that's easy enough to work around.
This isn't just brute force - the algorithm research has meant that our ability to factor large numbers has been growing a *lot* faster than Moore's law. That doesn't directly apply to breaking DH, except to the extent that factoring is useful in breaking discrete logarithms or the algorithms used are useful for it.
The catch is that you usually keep an RSA key around for a while; DH is often used with ephemeral parameters as well as ephemeral keys, so even if you had a year-long DH crack, it might only let you steal one message. On the other hand, cracking RSA signatures lets you do a man-in-the-middle attack where you substitute your forged DH parameters (which you know) for the target's supposedly-securely-signed parameters.
No, that's not the problem. Yeah, one time in a million or billion you might have RSA key parts that aren't really primes, but you can decide how paranoid you want to be, and that's not a practical attack. This factoring is taking the RSA public key n=pq and using a combination of good algorithms and lots of brute force to find p and q, and works even when p and q are genuine primes. If p were a fake prime, it might take less horsepower to find it, but this is cracking the hard problem, not just the occasionally-lucky case.
There are potentially three sets of crypto used - RSA, optional ephemeral Diffie-Hellman for more secure key exchange, and the symmetric crypto for message body encryption (typically 3DES or AES.) Symmetric crypto uses relatively short keys, typically 128 or equivalent-to-112 bits; the public-key algorithms use longer keys, but they have special forms so they _need_ to be longer.
Diffie-Hellman key exchange is roughly similar in strength to RSA encryption or signatures.
More importantly, if the Bad Guy can crack your RSA keys, then the Bad Guy can impersonate you in Diffie-Hellman key exchanges by doing a man-in-the-middle attack and forging signatures on the DH key parts.
So if you're using a 768-bit certificate for some reason, or a 1024-bit certificate and the NSA is out to get you, you're vulnerable. (If the KGB is out to get you, it's moot, because they'll sneak into your house or data center and put a keylogger in your keyboard. And if the Mafia's out to get you, they'll just threaten to break your kneecaps.)
Got it - that makes sense, unfortunately. However, I'm currently using more than 1GB of RAM for Mozilla (on Windows), and I doubt it'd be much smaller on Linux. At least they could do something to work around it, like providing an appropriate flavor of flash for swapping to?
Slashdot Mirror
If they don't work, he'll have slowed down to low-altitude terminal velocity. But if everything works, he'll be landing at normal parachute-landing speed, so he may bounce a bit when he first touches down.
So many network examples out there use 1.1.1.1 and 2.2.2.2 as addresses - I hope the APNIC has the sense to make 1.1.1.0/24 reserved.
1.0.0.0/8 isn't publicly routable - it was reserved, and ISPs don't route it, though they'll be starting now. 1.0.0.0/8 was temporarily safe to use *because* it wasn't routable or used for real Internet sites.
The original purpose of whois was to provide contact info so that you can reach a domain administrator if their DNS is broken or there was a problem with their bill. The ICANN folks have tried to make it much more than that, because the "IP" that they care about is "Intellectual Property", in particular protecting trademark owners from people who might infringe on them. Providing a contact service that's more reliable (or less reliable) than "Admin Contact, example-dot-com-admin@hotmail.com" doesn't assert anything in particular about ownership or liability.
Of course, if the registrar's ripping off their customers by providing administrative access for a domain that the registrar rented instead of providing the domain that the buyer thought they were buying, that can be a problem and using the registrar's privacy service makes it harder to prove that your side of the story is the correct one, but you knew the job was dangerous when you took it.
And of course, even complete correct ICBM-capable subpoena-capable True Names And Addresses, which is what the ICANN/WIPO types wanted whois information to be, doesn't always guarantee anything useful. I once tracked a spammer's registration info and found that they were a basic Delaware Corporation, so their assets may be no more than a couple sheets of paper in a file drawer in Greenville and the domain name, and that doesn't let you find or punish the miscreants behind the spamming.
A decade or more ago, "Libertarianism vs. Socialism" was the default discussion sink that all internet discussions eventually fell into.
But "Spam" has now replaced that - stick with the program.
Unless, of course, you were just coming here for abuse, in which case we can dredge up plenty of it for you :-)
The Feds spent the 90s trying to block public use of encryption anywhere in the world, but especially in the US. The excuse they used was that it would weaken their ability to eavesdrop on Commies (not that there was still a Soviet Union around by then), but they were able to interfere with the development and release of a lot of open-source software by claiming that releasing it on a public server would be export and therefore covered by the ITAR munitions export laws. They even withheld approval for "bones" versions of security software that only had hooks for crypto routines and not the crypto code itself, and for signature-only systems that had crypto code that could potentially be adapted to do encryption (i.e. anything with RSA.)
So here it is a decade or more later, and the National Information Infrastructure is less secure because they wanted to eavesdrop on Americans.
I'm guessing you probably looked on Google for references to robots.txt and HTML META - if SEO scum are any good, they should be among the first references you'll find, because that is one thing they know about, and they'll use that as part of their self-promotion.
It was probably true at one of them once, and if you're building a new campus today it's not a bad approach, but it's not clear where or when it actually originated.
And if you've been around Frank Lloyd Wright buildings much, you'll hear lots of stories about how they leak unless you're really aggressive about maintenance, and if you're over about 5'6"" (167cm), you'll rapidly notice that the dude was short and didn't mind forcing taller people to duck in buildings he designed...
The ones that really matter are AdBlock and NoScript - if they're not ready I'm not switching.
I also use a few others, like Ghostery, and I'm assuming the restore-most-recently-deleted-tab button will still work, but it's the basic safety ones that matter.
Search engines try to tell humans what web sites would have interesting contents based on their queries. They use robots and content models to approximate that so they can produce results quickly and economically. SEOs try to get the robots to tell the humans "my page is really interesting", when it usually isn't, which is scummy lying, and you shouldn't encourage such people.
They've really got three things to offer:
The primary reason for robots.txt was to protect small slow web servers from being swamped by Altavista's big fast web crawlers. Dynamic pages weren't a problem back then. On the other hand, after robots.txt became common, setting up dynamic pages to trap crawlers that ignored it into infinite loops became common also, because most of them were run by spammers of various sorts.
It'll just keep them from bothering you, and you're (almost by definition) too small for them to care that they're not indexing your site.
Advertising their IP address block with BGP, if your ISP is careless enough to let you do that, now *that* would get their attention :-)
As an intermediate level of annoyance, you could set up your DNS server to respond to queries from Microsoftland to return entertaining IP addresses, such as 127.0.0.2 or bing's IP addresses or whatever.
If you remember the history of robots.txt because you were there are the time, rather than because you read it in some history book somewhere, the purpose was to protect small web servers from being trashed by big search robots, initially altavista, and secondarily to protect them from other well-behaved web crawlers of whatever sorts. There were no script-generated pages back then, or at least hardly any; just handing out static html could be difficult enough if you had a small pipe and a slow server, though serving images to a robot obviously a waste of time back then.
Tarpits of various sorts existed soon after robots.txt, as a way of trapping spammer-run crawlers that ignored robots.txt, but that was as much for fun as for necessity :-)
And yes, people did have /private/ directories back then and still do now, thinking that because Google's polite about not looking in directories robots.txt says not to that there aren't humans or impolite robots that won't look there.
well somebody had to say it...
Actually, the Bush/Cheney administration were "chaotic evil"... just because they talked about "the Rule of Law" in accents resembling Bismark talking about "Blood and Iron" doesn't mean they intended it to apply to themselves.
No - that part means that the US and the southern states have no requirements to pay back Confederate debts, so anybody who lent money to the Confederacy loses. Congress still isn't allowed to cancel debts made by the US itself.
And if it did, because we didn't have enough tax base to pay the government's debts, fat chance on borrowing more money from the still-solvent parts of the world. Unfortunately, given the spending habits of the US government from Reagan on, borrowing money instead of saving it while spending the Social Security surplus when the Baby Boom and post-boom birthrate declines are setting us up for a workers-to-retirees ratio that can't sustain itself, we may get to find that out a few years after I retire.
Apparently it's a Macintosh font, which is why I didn't get the joke :-) However, it's designed by Kris Holmes (who did Lucida), so I assume there may be some licensing or cost requirements. Is it available for either free-as-in-speech or at least free-as-in-beer? It's possible to download from various places around the web, but I don't know whether that's legitimate or not.
Something unusual? There was a young guy wearing a suit and tie who didn't look like he was going to a job interview. Oh, wait, you're probably wondering if I saw the clown on the unicycle. He wasn't juggling knives and flaming torches like the kid who's usually here at lunchtime, so I just assumed he was headed somewhere else to work.
1a - If your email is encrypted with IPSEC, then there's a per-packet overhead from the extra packet header; it's not really a percentage, though you could think of it that way for average packet sizes. It's not significant for most applications except VOIP, which typically has very small data wrapped in lots of RTP/UDP/IPSEC/IP headers.
1b - If your email is encrypted at or above the transport layer, there's typically minimal overhead. The data encryption doesn't take extra space, except sometimes for the last packet of a session which might not contain a full block of plaintext so it gets padded by a few bytes.
1c - There's typically some setup overhead for key exchange. It doesn't take much transmission time unless you're on some funky very-low-bit-rate transmission medium, but there can be a couple of RTTs and some public-key math calculation time. So maybe it takes an extra second for you to start Gmail - big deal.
2 - That's why you compress the data *before* encrypting. Not many people use compressed transmission systems these days (e.g. fancy WAN optimizer tricks), and if anybody's still using SLIP or PPP with header compression, it doesn't care about HTTPS vs HTTP because that's not a Layer 1/2/3 problem.
If you can get past Customs, the rest of the country will be just fine for you...
The basic Elliptic Curve Crypto math was published in 1986 and isn't patented, but there have been a lot of implementation techniques that let you use the stuff efficiently which have been patented. However, even many of those patents have expired already or will soon (plus some of them have problems with prior art that could sink them, but the prime example of that is the Apple/NeXT patent which expires Real Soon.) There are a bunch of patents that issued in 2001 that may be a problem, but even those expire in 2021 unless the US does a Disney and extends them.
The good news is that effective Quantum Cryptography is a ways off - it's unlikely that the next decade will give us widespread effective QC that can reliably factor big numbers, so we aren't likely to need wholesale replacement of free crypto with patented crypto before then.
On the other hand, if QC can also crack ECC, that'd be annoying.
It's generally believed that if you can attack factoring, you can attack discrete logarithms, so Diffie-Hellman in integer prime-number bases is still risky, so if Quantum Computers ever get good enough to bother RSA, they'll be a real pain. On the other hand, Elliptic Curves may still be safe. Nobody's sure quite how safe (right now EC keys can be significantly shorter than factoring-based RSA or DH, but that may fall if there are theoretical breakthroughs, which is much less likely with factoring), but they may be enough, and at least the patents will have run out before Quantum Computers get good enough to factor numbers more interesting than 15.
But otherwise you're stuck with secret-key symmetric cryptography, or One-Time Pads. Remember Kerberos and the various other systems that depend on a Master Key locked safely in a Key Distribution Center? Remember couriers with briefcases handcuffed to their arms? Yuk! There were good reasons to use public keys instead!
There has been some work done on quantum-computer attacks on symmetric key systems, but AFAIK the best that it looks like they'll do in general is to effectively halve the key length, so that's easy enough to work around.
This isn't just brute force - the algorithm research has meant that our ability to factor large numbers has been growing a *lot* faster than Moore's law. That doesn't directly apply to breaking DH, except to the extent that factoring is useful in breaking discrete logarithms or the algorithms used are useful for it.
The catch is that you usually keep an RSA key around for a while; DH is often used with ephemeral parameters as well as ephemeral keys, so even if you had a year-long DH crack, it might only let you steal one message. On the other hand, cracking RSA signatures lets you do a man-in-the-middle attack where you substitute your forged DH parameters (which you know) for the target's supposedly-securely-signed parameters.
No, that's not the problem. Yeah, one time in a million or billion you might have RSA key parts that aren't really primes, but you can decide how paranoid you want to be, and that's not a practical attack. This factoring is taking the RSA public key n=pq and using a combination of good algorithms and lots of brute force to find p and q, and works even when p and q are genuine primes. If p were a fake prime, it might take less horsepower to find it, but this is cracking the hard problem, not just the occasionally-lucky case.
There are potentially three sets of crypto used - RSA, optional ephemeral Diffie-Hellman for more secure key exchange, and the symmetric crypto for message body encryption (typically 3DES or AES.) Symmetric crypto uses relatively short keys, typically 128 or equivalent-to-112 bits; the public-key algorithms use longer keys, but they have special forms so they _need_ to be longer.
Diffie-Hellman key exchange is roughly similar in strength to RSA encryption or signatures.
More importantly, if the Bad Guy can crack your RSA keys, then the Bad Guy can impersonate you in Diffie-Hellman key exchanges by doing a man-in-the-middle attack and forging signatures on the DH key parts.
So if you're using a 768-bit certificate for some reason, or a 1024-bit certificate and the NSA is out to get you, you're vulnerable. (If the KGB is out to get you, it's moot, because they'll sneak into your house or data center and put a keylogger in your keyboard. And if the Mafia's out to get you, they'll just threaten to break your kneecaps.)
Got it - that makes sense, unfortunately. However, I'm currently using more than 1GB of RAM for Mozilla (on Windows), and I doubt it'd be much smaller on Linux. At least they could do something to work around it, like providing an appropriate flavor of flash for swapping to?