You have just described the concept behind hibernate (suspend to disk) and sleep (suspend to memory). I have not "booted up" in over 6 months now; I updated my kernel 6 months ago. The time from opening the lid to being able to use it is under 5 seconds. There should be no reason why the same can't be done for desktops.
even his fundamental lack of understanding about what the internet is and how it works
Obviously the comment about receiving "an Internet" was referring to an email, and ofcourse the problem why it was delayed had nothing to do with network congestion most likely.
Nevertheless, his basic premise that the Internet is a bunch of tubes is very correct! Links on the Interenet are subject to capacity (100MB ethernet for example), much like a tube has a maximum flow capacity. Sure, you cannot "clog" the Internet as you can a tube by having some stationary junk get stuck in there for eternity, but you can still use up the capacity by sending tons of Bittorrent traffic for example and get horrible HTTP performance, just as you cannot flush things down the drains when the drains are overflowing with rain water or something -- congestion also is a concept common to both tubes and the Internet.
Granted the guy doesn't have his vocabulary right, but fundamentally he is correct.
I am all for net neutrality, but for the sake of argument...
They lay their cables on public property, with the consent of the government, on the condition that they provide a public service to all people equally... and now they're being ALLOWED to violate that?
Taxis and Limousines both drive on public roads; their owners can charge whatever they wish, whoever they wish, as long as the person who is charged agrees to pay.
The argument that network neutrality is fundamental becuase cables are on public property does not hold water.
To take the analogy further, there is _nothing wrong_ for a limo company refusing to take you somewhere because the destination hasn't entered into a deal with it -- it is the limo company's vehicle, the limo company's rules. Yes, the destination gets the short end of the stick, tough luck. This however becomes a problem when that limo company is the only limo company (i.e. has a monopoly) and can dictate whatever terms they wish on the destination.
Network neutrality isn't what we should be fearing IMHO -- their network, their rules. What we should be afraid of is the cable/phone companies banding together, colluding, establishing a monopoly, and holding the destination hostage. Where were you when they pulled the exact same play on television channels? Why are you not concerns that independent TV channels cannot get viewers because of cable providers? Why are you so interested in saving Google and Microsoft a coupld of billion dollars in contract agreements and not your local high-school TV channel?
The usefulness of this measurement is questionable
on
Can You Spoof IP Packets?
·
· Score: 5, Informative
The questions is not can an IP be spoofed (yes, it can always be spoofed from somewhere), but rather from where can it be spoofed and to where can it be spoofed to. You can spoof any IP address to another box on your local ethernet segment -- there are no routers en route that can drop the packet. You probably cannot spoof an IP to someone on the other side of the world, but your ISP or your ISP's ISP can. In fact, you can spoof any IP to almost everywhere if you have a connection to one of the few core Internet routers.
The project basically is saying that home users cannot spoof IPs to their measurement server. That's well and good, but useless.
Home users no longer need to spoof IPs to hide the source of the attack (as in days past). Home users now are simply trojan/zombie boxes that are hiding the true source of the attack by using their own IP -- no spoofing required. Back when zombies were not a problem, attackers used spoofing to hide their true location; it is no longer required now that boxes can be 0wned with relative ease.
While off-topic from the article perspective, I think this comment has some merit given that at the time of this comment, the tags for this article include 'gay', 'straight', 'bi'.
I suspect the 'straight' is to offset the 'gay' tag which appeared on all April 1 articles, and overflowed into April 2 articles. The system, I don't believe, knows that 'straight' is opposite of 'gay'. It does however know that '!gay' is opposite of 'gay', and will (likely) drop the tag that people vote against. Please use the '!word' tag to negate a word.
Since TFA doesn't mention anything about how his connection to iPods, I don't see how he helped the iPod any more than I did by not joining Apple and botching up the manufacturer's contract for producing crack-resistant LCD screens... oh wait.
> Anyway, running it from a read only memory is a way to avoid rootkits
Ah, but how do you write to read only memory (at creation time). Say you are burning a CD, can you trust the CD burning process? What if the host you are about to burn the CD on is already rooted and the rootkit intercepts your burn request, or the rootkit is hiding in your CDRom firmware? The rootkit can simply insert itself into the bootable CD then.
How do you securely prepare your readonly media in the first place?
To avoid rootkits, you need readonly memory. To create readonly memory, you need a secure computer. To create a secure computer, you need to avoid rootkits. Circular dependency.
> hook a logic analyzer up to the BIOS. Look at the nice bits go by. See if they match expectations.
Precisely. You need your hardware to verify that the software is in known-good state.
To make this approach feasibly, incorporate your logic analyzer into the CPU itself. Make the verification a hash function. And voila, you have just reinvented TCPA. Congrats.
The problem with TCPA is not that it is "inaccessbile (to the user)". The problem is that is does exactly what it is intended to do, and what you intend it to do. To stop code from running that is not trusted.
How you define what code is "trusted" depends on the application. Your nice application (bootloader in this case) may ask the user -- is this code trusted? That is a good use of TCPA. Microsoft's bootloader would not ask the user, and that is a bad use of TCPA.
Quick! Is a gun good or bad? TCPA is a gun. You can shoot the bad guys with it, or others can shoot you with it.
But my question stands -- can you win against rootkits without TCPA? (reinventing TCPA and calling it logic-analyzer-verifier doesn't count)
Do you trust that computer that you are using to burn that bootable CD? What if that computer is already rooted, and you don't know? What if the rootkit is hiding in the CDBurder firmware, or can intercept the burn request being sent out of the VM you are (unknowingly) running inside of?
The rootkit can ensure it gets onto that bootable CD in any number of ways.
You are thinking x86; there are other fully virtualizable architectures.
But fundamentally, can software attest to software state? Can software prove that it is correct (i.e. not under the influence of other software)? I suspect there may be a way to show that software cannot prove its own correctness along the lines of Gõdel's incompleteness theorem. That leaves only hardware that can attest to software state.
What sort of primitives would the hardware then need to provide to help the software convince itself that it is running in a safe environment? Would a simple am-I-running-in-ring-0 hardware command suffice? Presumably the software doesn't mind running inside a VM -- it just doesn't want to run inside a VM under malicious control. So a simple ring-0-or-not solves the rootkit problem by essentially curtailing the very functionality provided by VMs in the first place. Back to what primitives are needed from the hardware; the TCPA approach suddenly starts to make sense. It says the hardware will compute a secure hash of the runtime memory image and sign it. Software can then see what it is running inside of (whether the hash matches good VM controllers', or not).
The authors make an interesting point -- users and rootkits are about control. Whichever one controls the outer layer wins. If the user is in a protected environment, a rootkit running as root can win. If the user is root, then the rootkit must be a kernel-level root-kit and run in the kernel. If the user can control the kernel, the rootkit must control the machine, in this case, put the user kernel in a VM.
My take is: in this game of cat and mouse, you'll stop only at the hardware -- it is hard for a rootkit to control the hardware short of the rootkit script kidde being able to get physical control. So yes, the user can win this game, if he controls the hardware that controls the software. How does the hardware control software? You guessed it: trusted computing ala TCPA ala Palladium etc etc.
Can you think of a way to win against rootkits without TCPA?
Thats what they say their own policy is. There are no laws about certs that I am aware of.
> for a company that's incorporated in Bangledesh
Are you implying you are incapable of finding a trustworthy chain to verify someone is who they claim to be in Bangladesh? Go to your local Bangladesh embassy, find the phone number of their country's business registrar (or whatever that may be called), find out the regional registrars through them and so on.
> give you a cert for your domain no questions asked, just like they should.
I think you are confusing between a SSL certificate and a signed SSL certificate.
Both signed and unsigned can be used to secure traffic from eavesdroppers. A signed certificate says the person who signed it trusts that the person who has the cert is legitimate. It is the same as for PGP keys... any PGP key can be used to encrypt emails, but unless it is signed by someone you trust, you don't know whether the person who has the key really is who he claims to be or not.
Signed certificates are not a marketing scheme to extract money. The money aspect is to deter the drive-by phisher -- until you anchor any trust scheme in some consumable real-world item, the system will be vulnerable to a Sybil attack. In a Sybil attack, a person forges multiple identities for malicious intent -- when each identity costs you some, the Sybil attack becomes too expensive.
> signed CERT implies some level of confidence in the business. It does not, and never will.
A signed cert doesn not imply confidence in the "business". A signed cert implies confidence in anything that the signer took pains to verify. The cert authorities that are trusted by default are supposed to check the business (by their own admission), and therefore a cert signed by Verisign or Geotrust implies some level of confidence in the business. A cert signed by you implies nothing to me.
> There's plenty of similarly named legit businesses that all have certs issued to them.
The issue here is that the "business" was not legit, and GeoTrust did not detect that before issuing the cert. They (officially) require you to provide copies of business licenses, articles of incorporation, etc. They are supposed to check with the Secretary of State's Office in the state of incorporation, a requirement that the business be in good standing, etc. But they didn't do either in this particular case.
> it's about disallowing the machine from rejecting unsigned code.
What if you want to develop a secure operating system that will reject unsigned code?
Say company X were to manually verify drivers to ensure they don't have root-kits etc., and sign these verified drivers. The kernel is configured to allow only those drivers signed by company X.
GPL3 forces company X to release its keys so anyone can modify the driver, add a root-kit into it, sign it and have the kernel load it happily.
GPL3 is fundamentally against security. DRM is a content issue. Signed code is a security issue. Tackle DRM in Creative Commons. Security != DRM.
> Bittorrent is a completely legitimate use of the Internet! In fact, so is FTP. > And SMTP. And SSH. And freakin' gopher, for that matter! The network was engineered for all those things!
Legitimacy has nothing to do with how things are engineered. Actual use governs engineering, not potential use.
> You paid for that torrent traffic, and if they don't carry it that's as good as stealing.
Actually, it is the other way around. ISP's were around long before P2P, they engineered their network for web traffic. They engineered their network to give you a lot more downstream bandwidth than upstream bandwidth; that is what you paid for now, and that is what they cannot change when you pay now.
So when you run bittorrent (which forces you to upload nearly as much as you download), it is you are are (ab)using their network. Because of you, other people who are not using Bittorrent (i.e. using web etc like the network was engineered for) are suffering. If you run bittorrent, it is as good as you stealing from your neighbor.
The right solution, ofcourse, is for ISP's to reengineer their network for symmetric upload and download bandwidth if you want to run bittorrent. Sure, they can limit your download (which will throttle your upload in bittorrent), but that'll likely piss you off. The alternative is to increase your upload, and pass on the bandwidth charges they incur to you the user. You will likely not like that either if you had to pay more to use bittorrent than your neighbor does to use web, would you now?
Long story short, users are freeloading on ISPs when they use P2P and refuse to pick up the costs. ISPs will either kick these users off, charge them more, or clamp down on their usage. Pick your poison.
> Remember that Tiananmen is still an actual place... and 'Java' is coffee, and 'bush' is a big shrub. Try searching for 'Java' and 'bush' (not in the same search obviously) on google.cn. Even lacking context to disambiguate words that have multiple meanings, Google does a pretty good job of finding the one which is most relevent. If google clams that "Tiananmen" is a tourist destination first and foremost, that trivializes the massacare, that throws it in positive light saying the massacare was far less important/relevant/interesting than tourists drinking martinis. There is no arguing that this is censorship. The question is does selectively hiding relevant information, or misrepresenting it count as something evil; I maintain it does.
> Chinese citizens are probably better off with a censored Google rather than no Google at all.
Sensoring is one thing. Sugar-coating and biasing is another.
If Google were to censor all occurences of 'Tiananmen' and say that the search returned '0' results because of censoring, I'd be likely to agree with you. After all, '0' results doesn't say whether Tiananmen happened or didn't happen.
Precisely, but for a different reason. If BellSouth wanted to make money, it would be charging the 2nd place search engine:... "give us money and your pages will load faster than Google's". Google gets little benefit from being the first to pay up, and naturally, won't. Yahoo on the other hand would consider this more a "service" than "extortion". Of course, once Yahoo's pages load up much faster than Google's, Google may want to reconsider buying into the "service".
Parent quoth: > (a) Delegation of a New Top Level Domain. Delegation of a new top level domain requires the completion of a number of > procedures, including the identification of a TLD manager with the requisite skills and authority to operate the TLD > appropriately. The desires of the government of a country with regard to delegation of a ccTLD are taken very seriously. > The IANA will make them a major consideration in any TLD delegation/transfer discussions. Significantly interested > parties in the domain should agree that the proposed TLD manager is the appropriate party. The key requirement is that > for each domain there be a designated manager for supervising that domain's name space. (re-emphasized)
OP quoth: > ICANN then immediately used that 'precedent' to hand ownership of Iraq's internet over to another government-run body, > without accounting for any objections that the existing owners might have
I'd say the "existing owners" are a "significantly interested part(y) in the domain"
Slashdot Mirror
You have just described the concept behind hibernate (suspend to disk) and sleep (suspend to memory).
I have not "booted up" in over 6 months now; I updated my kernel 6 months ago.
The time from opening the lid to being able to use it is under 5 seconds.
There should be no reason why the same can't be done for desktops.
Obviously the comment about receiving "an Internet" was referring to an email, and ofcourse the problem why it was delayed had nothing to do with network congestion most likely.
Nevertheless, his basic premise that the Internet is a bunch of tubes is very correct! Links on the Interenet are subject to capacity (100MB ethernet for example), much like a tube has a maximum flow capacity. Sure, you cannot "clog" the Internet as you can a tube by having some stationary junk get stuck in there for eternity, but you can still use up the capacity by sending tons of Bittorrent traffic for example and get horrible HTTP performance, just as you cannot flush things down the drains when the drains are overflowing with rain water or something -- congestion also is a concept common to both tubes and the Internet.
Granted the guy doesn't have his vocabulary right, but fundamentally he is correct.
Taxis and Limousines both drive on public roads; their owners can charge whatever they wish, whoever they wish, as long as the person who is charged agrees to pay.
The argument that network neutrality is fundamental becuase cables are on public property does not hold water.
To take the analogy further, there is _nothing wrong_ for a limo company refusing to take you somewhere because the destination hasn't entered into a deal with it -- it is the limo company's vehicle, the limo company's rules. Yes, the destination gets the short end of the stick, tough luck. This however becomes a problem when that limo company is the only limo company (i.e. has a monopoly) and can dictate whatever terms they wish on the destination.
Network neutrality isn't what we should be fearing IMHO -- their network, their rules. What we should be afraid of is the cable/phone companies banding together, colluding, establishing a monopoly, and holding the destination hostage. Where were you when they pulled the exact same play on television channels? Why are you not concerns that independent TV channels cannot get viewers because of cable providers? Why are you so interested in saving Google and Microsoft a coupld of billion dollars in contract agreements and not your local high-school TV channel?
The questions is not can an IP be spoofed (yes, it can always be spoofed from somewhere), but rather from where can it be spoofed and to where can it be spoofed to. You can spoof any IP address to another box on your local ethernet segment -- there are no routers en route that can drop the packet. You probably cannot spoof an IP to someone on the other side of the world, but your ISP or your ISP's ISP can. In fact, you can spoof any IP to almost everywhere if you have a connection to one of the few core Internet routers.
The project basically is saying that home users cannot spoof IPs to their measurement server. That's well and good, but useless.
Home users no longer need to spoof IPs to hide the source of the attack (as in days past). Home users now are simply trojan/zombie boxes that are hiding the true source of the attack by using their own IP -- no spoofing required. Back when zombies were not a problem, attackers used spoofing to hide their true location; it is no longer required now that boxes can be 0wned with relative ease.
I don't see the point of this project.
Please use the !word to negate a tag.
While off-topic from the article perspective, I think this comment has some merit given that at the time of this comment, the tags for this article include 'gay', 'straight', 'bi'.
I suspect the 'straight' is to offset the 'gay' tag which appeared on all April 1 articles, and overflowed into April 2 articles. The system, I don't believe, knows that 'straight' is opposite of 'gay'. It does however know that '!gay' is opposite of 'gay', and will (likely) drop the tag that people vote against. Please use the '!word' tag to negate a word.
Just an FYI.
(don't mod me off-topic please. =] )
Since TFA doesn't mention anything about how his connection to iPods, I don't see how he helped the iPod any more than I did by not joining Apple and botching up the manufacturer's contract for producing crack-resistant LCD screens ... oh wait.
> Anyway, running it from a read only memory is a way to avoid rootkits
Ah, but how do you write to read only memory (at creation time). Say you are burning a CD, can you trust the CD burning process? What if the host you are about to burn the CD on is already rooted and the rootkit intercepts your burn request, or the rootkit is hiding in your CDRom firmware? The rootkit can simply insert itself into the bootable CD then.
How do you securely prepare your readonly media in the first place?
To avoid rootkits, you need readonly memory. To create readonly memory, you need a secure computer. To create a secure computer, you need to avoid rootkits. Circular dependency.
> hook a logic analyzer up to the BIOS. Look at the nice bits go by. See if they match expectations.
Precisely. You need your hardware to verify that the software is in known-good state.
To make this approach feasibly, incorporate your logic analyzer into the CPU itself. Make the verification a hash function. And voila, you have just reinvented TCPA. Congrats.
The problem with TCPA is not that it is "inaccessbile (to the user)". The problem is that is does exactly what it is intended to do, and what you intend it to do. To stop code from running that is not trusted.
How you define what code is "trusted" depends on the application. Your nice application (bootloader in this case) may ask the user -- is this code trusted? That is a good use of TCPA. Microsoft's bootloader would not ask the user, and that is a bad use of TCPA.
Quick! Is a gun good or bad? TCPA is a gun. You can shoot the bad guys with it, or others can shoot you with it.
But my question stands -- can you win against rootkits without TCPA? (reinventing TCPA and calling it logic-analyzer-verifier doesn't count)
Do you trust that computer that you are using to burn that bootable CD? What if that computer is already rooted, and you don't know? What if the rootkit is hiding in the CDBurder firmware, or can intercept the burn request being sent out of the VM you are (unknowingly) running inside of?
The rootkit can ensure it gets onto that bootable CD in any number of ways.
You are thinking x86; there are other fully virtualizable architectures.
But fundamentally, can software attest to software state? Can software prove that it is correct (i.e. not under the influence of other software)? I suspect there may be a way to show that software cannot prove its own correctness along the lines of Gõdel's incompleteness theorem. That leaves only hardware that can attest to software state.
What sort of primitives would the hardware then need to provide to help the software convince itself that it is running in a safe environment? Would a simple am-I-running-in-ring-0 hardware command suffice? Presumably the software doesn't mind running inside a VM -- it just doesn't want to run inside a VM under malicious control. So a simple ring-0-or-not solves the rootkit problem by essentially curtailing the very functionality provided by VMs in the first place. Back to what primitives are needed from the hardware; the TCPA approach suddenly starts to make sense. It says the hardware will compute a secure hash of the runtime memory image and sign it. Software can then see what it is running inside of (whether the hash matches good VM controllers', or not).
Here is a link to the actual paper the article references:d f
http://www.eecs.umich.edu/virtual/papers/king06.p
The authors make an interesting point -- users and rootkits are about control. Whichever one controls the outer layer wins. If the user is in a protected environment, a rootkit running as root can win. If the user is root, then the rootkit must be a kernel-level root-kit and run in the kernel. If the user can control the kernel, the rootkit must control the machine, in this case, put the user kernel in a VM.
My take is: in this game of cat and mouse, you'll stop only at the hardware -- it is hard for a rootkit to control the hardware short of the rootkit script kidde being able to get physical control. So yes, the user can win this game, if he controls the hardware that controls the software. How does the hardware control software? You guessed it: trusted computing ala TCPA ala Palladium etc etc.
Can you think of a way to win against rootkits without TCPA?
> demonstrate a "resource simulator" for our class
How do you know if the simulator is accurate?
> what law requires that?
... any PGP key can be used to encrypt emails, but unless it is signed by someone you trust, you don't know whether the person who has the key really is who he claims to be or not.
Thats what they say their own policy is. There are no laws about certs that I am aware of.
> for a company that's incorporated in Bangledesh
Are you implying you are incapable of finding a trustworthy chain to verify someone is who they claim to be in Bangladesh? Go to your local Bangladesh embassy, find the phone number of their country's business registrar (or whatever that may be called), find out the regional registrars through them and so on.
> give you a cert for your domain no questions asked, just like they should.
I think you are confusing between a SSL certificate and a signed SSL certificate.
Both signed and unsigned can be used to secure traffic from eavesdroppers. A signed certificate says the person who signed it trusts that the person who has the cert is legitimate. It is the same as for PGP keys
Signed certificates are not a marketing scheme to extract money. The money aspect is to deter the drive-by phisher -- until you anchor any trust scheme in some consumable real-world item, the system will be vulnerable to a Sybil attack. In a Sybil attack, a person forges multiple identities for malicious intent -- when each identity costs you some, the Sybil attack becomes too expensive.
> signed CERT implies some level of confidence in the business. It does not, and never will.
A signed cert doesn not imply confidence in the "business". A signed cert implies confidence in anything that the signer took pains to verify. The cert authorities that are trusted by default are supposed to check the business (by their own admission), and therefore a cert signed by Verisign or Geotrust implies some level of confidence in the business. A cert signed by you implies nothing to me.
> There's plenty of similarly named legit businesses that all have certs issued to them.
The issue here is that the "business" was not legit, and GeoTrust did not detect that before issuing the cert. They (officially) require you to provide copies of business licenses, articles of incorporation, etc. They are supposed to check with the Secretary of State's Office in the state of incorporation, a requirement that the business be in good standing, etc. But they didn't do either in this particular case.
More details here: http://isc.sans.org/
> it's about disallowing the machine from rejecting unsigned code.
What if you want to develop a secure operating system that will reject unsigned code?
Say company X were to manually verify drivers to ensure they don't have root-kits etc., and sign these verified drivers. The kernel is configured to allow only those drivers signed by company X.
GPL3 forces company X to release its keys so anyone can modify the driver, add a root-kit into it, sign it and have the kernel load it happily.
GPL3 is fundamentally against security. DRM is a content issue. Signed code is a security issue. Tackle DRM in Creative Commons. Security != DRM.
> Bittorrent is a completely legitimate use of the Internet! In fact, so is FTP.
> And SMTP. And SSH. And freakin' gopher, for that matter! The network was engineered for all those things!
Legitimacy has nothing to do with how things are engineered. Actual use governs engineering, not potential use.
> You paid for that torrent traffic, and if they don't carry it that's as good as stealing.
Actually, it is the other way around. ISP's were around long before P2P, they engineered their network for web traffic. They engineered their network to give you a lot more downstream bandwidth than upstream bandwidth; that is what you paid for now, and that is what they cannot change when you pay now.
So when you run bittorrent (which forces you to upload nearly as much as you download), it is you are are (ab)using their network. Because of you, other people who are not using Bittorrent (i.e. using web etc like the network was engineered for) are suffering. If you run bittorrent, it is as good as you stealing from your neighbor.
The right solution, ofcourse, is for ISP's to reengineer their network for symmetric upload and download bandwidth if you want to run bittorrent. Sure, they can limit your download (which will throttle your upload in bittorrent), but that'll likely piss you off. The alternative is to increase your upload, and pass on the bandwidth charges they incur to you the user. You will likely not like that either if you had to pay more to use bittorrent than your neighbor does to use web, would you now?
Long story short, users are freeloading on ISPs when they use P2P and refuse to pick up the costs. ISPs will either kick these users off, charge them more, or clamp down on their usage. Pick your poison.
I thought the courts did decide: http://www.eff.org/deeplinks/archives/004344.php
"A district court in Nevada has ruled that the Google Cache is a fair use."
Or does every industry want to file a separate suit asking the court to decide whether caching that industry's content is fair or not?
> Remember that Tiananmen is still an actual place ... and 'Java' is coffee, and 'bush' is a big shrub. Try searching for 'Java' and 'bush' (not in the same search obviously) on google.cn. Even lacking context to disambiguate words that have multiple meanings, Google does a pretty good job of finding the one which is most relevent. If google clams that "Tiananmen" is a tourist destination first and foremost, that trivializes the massacare, that throws it in positive light saying the massacare was far less important/relevant/interesting than tourists drinking martinis. There is no arguing that this is censorship. The question is does selectively hiding relevant information, or misrepresenting it count as something evil; I maintain it does.
I know ...
c) You jump in bed with said neighbour's wife and hope she'll pay you for it!
How about:
"Displaying Results 1 - 100 of about 8,300 for tiananmen. (Same As Results 3000 - 3200 of about 1,900,000 without Censoring)"
> Chinese citizens are probably better off with a censored Google rather than no Google at all.
... thats when Google spreads biased misinformation. This is what is evil.
Sensoring is one thing. Sugar-coating and biasing is another.
If Google were to censor all occurences of 'Tiananmen' and say that the search returned '0' results because of censoring, I'd be likely to agree with you. After all, '0' results doesn't say whether Tiananmen happened or didn't happen.
But Google is hiding the content that speaks negatively of it, and not what speaks positively of it. Compare:
World -- http://images.google.com/images?q=tiananmen
China -- http://images.google.cn/images?q=tiananmen
When all the serce results say Tianenmen didn't happen, and none say it did
> Why would Bellsouth charge Google?
... "give us money and your pages will load faster than Google's". Google gets little benefit from being the first to pay up, and naturally, won't. Yahoo on the other hand would consider this more a "service" than "extortion". Of course, once Yahoo's pages load up much faster than Google's, Google may want to reconsider buying into the "service".
Precisely, but for a different reason. If BellSouth wanted to make money, it would be charging the 2nd place search engine:
http://ftp.freshrpms.net/pub/freshrpms/fedora/linu x/testing/4/firefox/
Look for x86_64
Parent quoth:
> (a) Delegation of a New Top Level Domain. Delegation of a new top level domain requires the completion of a number of
> procedures, including the identification of a TLD manager with the requisite skills and authority to operate the TLD
> appropriately. The desires of the government of a country with regard to delegation of a ccTLD are taken very seriously.
> The IANA will make them a major consideration in any TLD delegation/transfer discussions. Significantly interested
> parties in the domain should agree that the proposed TLD manager is the appropriate party. The key requirement is that
> for each domain there be a designated manager for supervising that domain's name space.
(re-emphasized)
OP quoth:
> ICANN then immediately used that 'precedent' to hand ownership of Iraq's internet over to another government-run body,
> without accounting for any objections that the existing owners might have
I'd say the "existing owners" are a "significantly interested part(y) in the domain"