Aetheric Research, Ltd.

Some folks may remember the HBGary debacle a short while ago, when HBGary Federal (a wholly-owned subsidiary of HBGary, specializing in government contracts) got themselves cracked by Anonymous after specifically calling them out.  The parent company, HBGary, have published an open letter making certain claims, which Ars Technica has examined.

There’s little surprise in the letter–it’s mostly a reiteration of previous claims about the leaked emails having been ‘altered’ and about how HBGary Federal was a completely separate company with no actual connection to the parent organization other than ownership.  Ars does a good job in dissecting these claims and pointing out which ones hold water and which ones don’t.

Publishing this letter in the first place was likely a bad idea, though.  Anyone who has the least bit of knowledge about Anonymous–which the head of HBGary Federal claimed to have–knows that resurrecting attention to a controversy causes the phenomenon known as “lulz” to occur.  For those unfamiliar with the term, it’s a sort of measurement of attention-worthiness of a particular topic or entity, based on the quality and quantity of reaction to be gained from any interaction with them.  Leaking the HBGary Federal documents produced an extensive amount of this–it gained mainstream media attention and increased the visibility of Anonymous in the public eye.  The Scientology protests were the same–shedding light on the known-bad Scientology organization’s policies and procedures with public protests (and their characteristic purple prose) caused extreme consternation amongst the organization and brought public attention to Anonymous.

Now, HBGary has, essentially, done the same thing that HBGary Federal did–call out Anonymous’ activities, claim to be invulnerable to their attentions, and bring public attention to Anonymous’ interactions with them.  This is the sort of thing that tends to be deemed “lulzy” by Anonymous, and generally tends to bring certain actions.

Westboro Baptist attempted to take advantage of this phenomenon by releasing a fake press release (that claimed to be on behalf of Anonymous) claiming a war against them followed by a press release under their own aegis calling out Anonymous.  The Anonymous collective rather quickly determined the illegitimacy of the first release–there may be no central organization, but there is a fairly distinct style, which Westboro did not emulate perfectly–and (correctly, as it turned out) determined that there were likely specific intentions to trap Anonymim who attempted to DDoS or otherwise infiltrate the servers provided via honeypot servers.  

As it happened, when Westboro pushed the issue, they were rather promptly taken down–just as HBGary is likely to be.  Westboro, like HBGary, made the key mistakes of assuming Anonymous is entirely disaffected teenagers with a modicum of computer skills and a coherent organization with limited membership.  These assumptions miss certain key points–Anonymous is, in essence, a nom de guerre that can be taken on by any person or entity, as is evidenced by th3j3st3r’s participation in the actions against Westboro following his specific attacks against Wikileaks; while not strictly an Anonymous action (as he did claim credit for it), the action against Westboro was compatible with Anonymous’ goals and views.

What HBGary fails to realize is that, by seeking to defend themselves against the ‘blog-o-sphere’, they’ve inadvertently invoked the Streisand effect and drawn specific attention to what they want to keep quiet.  Whether this release has produced enough ‘lulz’–that is, attention to the incident as a cause worthy of working on–remains to be seen, but if they do manage to get away with it without significant infiltration and exposure of more embarassing secrets, they should count themselves lucky.

Anonymous’ actions cannot be predicted specifically, but it’s fairly obvious that calling them out is, as a comedian recently opined, tantamount to inserting one’s genitals into a hornet’s nest–a bad idea, and likely to cause embarassing, painful problems.

Via Slashdot, tirania.org points out some weaknesses in the terms of service for Dropbox, a popular filestore for those who want to operate ‘in the cloud’ and store and transfer files online.  

One of the difficulties for those who want to make the case for performing business operations in the cloud is the possibility that non-authorized persons might be able to see the data stored and processed externally.  The revisions in the security policy for Dropbox highlight some of these difficulties–to wit, Dropbox, despite its claims of using fairly strong encryptions to protect user data, has advised that they will turn over any data stored on their system to the government on request.

Needless to say, if the data was stored securely enough to prevent the Dropbox employees from accessing it, they would not be able to do this.

It is likely that the change in policy is the result of pressure by government agencies–police, etc.–to turn over data related to some sort of official actions such as prosecution of a crime, but it is still concerning for any users of this or other services who wish to ensure that their business data (which may contain secret processes or formulas, for instance) doesn’t go walkabout and end up in some other place than where it ought to be.  

There is a simple, though somewhat less easy to implement, solution to ensure that the data remains confidential regardless of external conditions–encrypting the files before transmitting them definitionally reduces the possibility of disclosure from external services.  A careful sysadmin ought to be able to build such a provision into their backup script, though this makes use of cloud services for anything other than incremental backups rather more clumsy and less convenient than they might be otherwise.

In order for cloud computing to be more widely adopted, though, security and privacy policies need to be made clear to the users of the services, including exactly who is able to access the data (nobody other than the user, preferably) under what conditions and for what purpose.  Policies alone will not enforce this, mind; policies rely on the weakest link in any security chain–the users–to maintain any kind of security.  

On their “Naked Security” blog at Sophos (which, by the bye, tends to be blocked by the more paranoid sorts of web filter due to the presence of a keyword in the title that’s often used for other purposes), the authors recommend that Facebook implement three relatively simple practises in order to vastly increase the amount of security available to the users. 

From a security standpoint, the recommendations are eminently reasonable: when changing privacy policies, allow the users to opt-in to the new expanded ‘sharing’ roles, rather than having to go in and opt out.  Vet app developers more carefully to ensure only legitimate and ethical developers are allowed access to user information.  Force secure connections, rather than making a ‘best effort’.

These recommendations would go miles towards protecting the userbase of facebook.  By ensuring secured connections to protect against eavesdroppers, non-savvy users connecting from corporate or public networks that might be sniffed wouldn’t end up giving away all their information.  Vetting app developers to ensure that they’re publishing legitimate applications would help to prevent the dozens of scam applications that serve only to spread malware and the like.  Keeping users at their previous privacy settings until such time as they opt in to broader sharing agreements is a standard common-sense approach to security.

And Facebook will do none of this on their own.

Facebook is, first and foremost, a money-making enterprise.  They have found a very effective and useful (for them) model to collect and publish users’ demographic information, and get people invested into ensuring that their information is as accurate and up-to-date as possible.  They make their revenue from selling this information, so it’s in their best interests to ensure that as much of that information is available to the people who provide them with their money as possible.

Forcing secure connections will interfere with their customer base connecting to them on certain networks–corporate networks that have badly-configured proxies, for instance.  This results in less availability of the site to the users, and less information shared–not good for their corporate model.  Facebook wants users to access their page regardless of security settings, meaning that they will never insist on a secured connection if that will interfere with access to the page.  

Vetting app developers, as well, is not likely to happen in any sort of serious manner.  There’s no incentive for Facebook to block their revenue stream by making the barriers to entry any higher than filters out the most blatant and obvious scam artists; that would be an interruption of their revenue stream.  If vetting happens, it will almost certainly be due to specific regulation insisting on it from an outside agency, and will be to either the absolute minimum level required or–if the marketing department wishes to use the opportunity to boost the brand–to a slightly higher level.  It almost certainly will not be to any level that would filter out a significant number of scam artists.

Finally, Zuckerberg’s opinions on privacy aside, privacy settings will almost certainly remain ‘opt-out’ unless there is a significant rewrite of the codebase and a complete revision of the development process.  As it stands, code is deployed on a segment of the live userbase for testing; changing this would require either the use of simulated traffic on a simulated development database or requesting users to opt-in to testing the new features specifically.  Further, maintaining multiple privacy systems simultaneously would impact performance of the codebase (given that any request to a user’s information would have to determine which privacy setting system to go through) and would not automatically bring over ‘stale’ profiles; this further impacts revenues as those paying for the demographic information are not going to be interested in inconsistent results.

While Sophos’ recommendations are eminently reasonable (and could be implemented without too much actual cost–changing the privacy settings to be more atomic and making further revisions dependng on database timestamps or the like would not impact performance that much; allowing users to opt-in to beta testing would likely be met with enthusiastic response if it was presented properly; and vetting developers properly, while it would impact revenues in the short term, could be written off as a marketing campaign) they’re not likely to be implemented anytime soon.  Facebook’s current model works well for them (given the amount of money that they’ve been raking in) and they have no current incentive to change this, unless there is significant outcry and a tangible reduction in userbase–which, given the investment that many people have made in putting the bulk of their social life into the facebook domain, is not very likely to happen at all.

PGP and other associated PKI systems rely on a so-called ‘web of trust’ model in order to verify that two parties previously unknown to each other should be able to trust each other’s cryptographic signatures as valid.  If there are multiple continuous chains joining these two parties involving mutually trusted intermediaries, then each party knows that the other can be trusted to be who they say they are.

A potential problem is that, were someone’s credentials stolen, their signature could be forged on untrustworthy credentials, thus compromising the web.  Further, if one or more people were tricked into signing keys that were for entities other than who they said they were, the web could be compromised even further.

PGP and similiar PKI infrastructures have, built-in, a mechanism for accounting for these possibilities: certificate revocation.  Revoking the trust in a key can invalidate it to the rest of the web, and allows for damages of that kind to be mitigated.

A potential improvement to this system of trust and revocation would revolve around greatly reducing the usual length of use for an individual key; semi-automatically changing keys on, say, a weekly basis (and allowing for automatic replacement of known-trusted keys by their next iterations) would allow for both verification of use on the key (given user intervention in its renewal, it would verify that the user has the necessary credentials for the renewal method and that they’re actively participating) and also would allow for user revocation of ‘stale’ or otherwise undesired credentials.  During the refresh process, the user can choose whether to continue to sign and endorse or stop signing others’ credentials; this helps the dynamics of the web by helping to cull out untrusted persons more rapidly.

Further, providing the option for an anti-signature, to specifically call out a signature as untrusted to others, would significantly mitigate the effect of malicious persons such as spammers gaining access to a web of trust.  Allowing for this anti-signature could also form the basis of a sliding trust scale, with trust and anti-trust counting against each other and allowing for unconnected persons to see that a particular account may or may not be trustworthy.  Paths connecting persons would be deprecated by paths containing antisignatures; determining whether or not to trust someone with a significant number of antisignatures would be assisted by allowing short comments with the antisignatures similar to twitter messages (i.e. “this person is a spammer” or “this person kicks puppies”–if you had no objection to spamming or puppy-kicking, then you could choose to ignore certain antisignatures).

Distributing this credentialing system on a P2P basis would greatly assist the scaling, and if organizations bought into it, it would form a convenient adjunct to the SSL certification system, given that the SSL certificates could be signed into the web of trust as valid or invalid, thus significantly mitigating the effects of any erroneous or fraudulent certificates being issued by certifying authorities.

Further study is needed in order to determine how to automatically cull spam networks–applying network topology math here to determine which sub-webs are, essentially, self-signing would assist this greatly.

The spokesman for an outfit that puts out retro games, Good Old Games, has been quoted saying that DRM drives gamers to piracy.  The argument being made here is that the massive hassle involved in installing and maintaining the ‘authorized’ conditions to play the game legitimately form too high a barrier and that, at least for single-player or other local system games, it’s easier to install a cracked version of the game than to try to maintain the ‘authorized’ version.

Mr. Kukawski also makes an interesting point in his statement–much of the DRM that game manufacturers (and the manufacurers of other media) insist on installing could well count as malicious software.  Anyone recalling the Sony rootkit debacle–where Sony attempted to enforce DRM by crippling the functionality of the users’ systems without their consent–will easily see what happens when a company goes ‘too far’ in their quest to maintain control over content.

However, piracy is more or less inevitable, and by spending so much time and money ‘securing’ your media against theft, you’re more or less guaranteeing that others will take an interest in breaking it.

Insisting on the installation of malicious software–software that spies on the system’s activities to see if “forbidden” programs are installed or running, that “phones home” to a remote server, that cripples the functionality of your system unless certain conditions are met–is a tactic that even the mafia would hesitate at enforcing.  

DRM only serves to hurt legitimate users.

Pirates will pirate the media no matter what–if it’s sufficiently interesting to them, then it will be cracked and released on the internet, regardless of the technical obstacles put in the way.  The only pirate inconvenienced by the DRM is the first one–and if these media companies paid any attention to the psychology of the typical warez-head, they’d realize that by putting technical obstructions in the way, they’re only serving to glorify the exploits of those pirates who make available the content in the first place.

One might be excused for thinking that the pirate ecosystem was being deliberately cultivated, in a sort of perverse mockery of the open-source software world–many eyes finding and correcting ‘bugs’.  Ubisoft has rather blatantly stolen (in a perversely ironic way) the work of various pirates on a number of occasions, including as a method of circumventing onerous DRM put in place by an online marketplace.

Time and time again, DRM has served only to inconvenience the legitimate paying customers, who are painted as thieves and bandits by the media companies who take their money with one hand while denying them the functionality that they have paid for with the other.  This is not being limited to software, either; Intel has announced that their new line of ‘Sandy Bridge’ chips will have DRM built into them, attempting to enforce these ‘digital rights’ at the hardware level for streaming media.  This will only serve to hurt legitimate users; pirates will, in all likelihood, take about a week to circumvent these protections and the whole game will start again.

Content providers should take notice that this DRM nonsense does not work, and look at the example of studios who have made this realization.  Cut out DRM licensing and R&D from the budget, and accept piracy as part of the cost of doing business–write off the ‘losses’ from the advertising budget, given that piracy can lead to more sales.  Fighting the flow does nothing but waste energy; using the flow to your advantage helps you grow and thrive.

The Register has an excellent (if somewhat snarky, though that is the milieu of the publication) article on some of the recent breaks to SSL’s effectiveness as a platform for secure communications.

The basic problem behind this round of vulnerabilities is the reliability of the certifying organizations.  After the recent breakin to Comodo that resulted in the issuance of several fraudulent certificates, more attention has been paid to this particular flaw in the way in which traffic is secured.

SSL works by means of PKI: public key infrastructure.  This means that a large string of data, known as a ‘key’, is sent out into the public for use by anyone wishing to communicate with the server.  The key has a certain mathematical relationship with another key stored on the server (known as the private key); when data is encrypted with one, it can be decrypted with the other if the proper mathematical steps are taken.

These keys are used to negotiate a secured connection to a server, which serves two purposes–first, it assures the person connecting to the server that they are connecting to the genuine article; the fact that the connection can be made successfully proves that the server has the requisite private information associated with the key.  Secondly, it allows the entire connection to be encrypted so that people between the computer and the server will be unable to determine the content of the transaction.

This only works, however, if the key is trusted–if anyone has access to the private key other than the server in question, then there is no assurance that the connection is being made to the correct server, and no assurance that someone in the middle is unable to eavesdrop.

Cerifying Authorities such as Comodo, VeriSign, and others are supposed to guarantee that they issue certificates only to the organizations that they identify.  However, this is not always the case; especially in the case of their licensees–companies that issue certificates under license from the CA houses, and whose certificates are intended to be just as trusted–the requisite identification of the certificate request is not always accomplished properly, resulting in certificates being issued to incorrect persons.

One particular certificate that has been mentioned is one for ‘localhost’–that is, one’s own computer.  While most articles on this subject have noted that this is an essentially frivolous certificate and have paid much more attention to the ‘exchange’ domain certificates that could be used for intercepting corporate email, it’s worth noting that a live ‘localhost’ certificate along with a maliciously-installed local proxy could intercept all internet traffic that a user attempts, thus providing no overt sign (unless the user was very security-conscious and checked carefully the certificates of all the sites that they connected to) to the user that they were being compromised and, for instance, their bank account details were being stolen.

Certain alternatives to the SSL system have been proposed, but as yet they all suffer from the difficulties of limited adoption.  Until a significant movement arises–or at least some of the ‘big players’ get involved–eCommerce and the like will likely continue to be only partly secured.

(On a side note, a service that actively tracks and validates certificates issued by all authorities–like the automated one run by Google on page 3 of the article linked–could be made very profitable)

Apologies for the mangled French title.  The BBC reports that several companies are challenging a French law insisting that they keep a record of users’ real names, telephone numbers, addresses, and–most damningly–passwords, to be turned over to police on demand.

In a proper, competent system, passwords themselves are never stored.  Instead, when an account (and associated password) is created, the password is passed through a complex mathematical function to produce what is called a ‘hash’–much like how reconstructing an order of ham hash into the original ham and potatoes is more difficult than anyone can reasonably be expected to accomplish, reconstructing a password from a hash is intended to be next to impossible.

When the user logs in, their password is passed through the mathematical function again, and the result compared with the entry in the password table.  Since the function is tuned to produce a complex but unique result from each input, if the hashes match then the password has been entered properly.

The recent high-profile crack at Gawker, where the password database was compromised, was only possible because their hashing algorithm was weak and most users’ passwords were also weak.  Indeed, the algorithm itself was not actually reversed–instead, a database known as a ‘rainbow table’ was used, which is the result of passing a dictionary of common passwords through a known hashing algorithm.

This French law completely ignores best-practices.  Besides the obvious privacy concerns, it requires that the companies make passwords available to the police–which means that, rather than a database of the hashes, the companies will be required to keep a database of the actual passwords.

This is an unnecessary and badly thought-out requirement, as it lays every single person in France who uses any of these services open to theft of their accounts should anyone be successful at exfiltrating the associated databases.  Worse, given that real names and addresses are associated with these accounts, it provides very nearly one-stop shopping for any French identity that an attacker could wish to have.  

In essence, no company that engages in anything resembling standard security practises can operate in France unless they irreperably damage standard procedures in order to engage in traffic with that country.

This law is badly thought-out and will irreperably damage France’s status in the EU and on the world stage.  Anyone who wishes for security in their dealings should avoid any companies that provide this data, as these databases will be inherently insecure.

If you’re unfortunate enough not to have someone in your family or circle of friends who builds computer systems, you may have had the unfortunate experience of buying a new computer at a retail store and, on unboxing and setting it up, being confronted with a significant amount of preinstalled nonsense that you neither want nor need.  Usually, this includes such things as “trial versions” of games, “trial” versions of antivirus programs, “helpful” extensions to the web browser, assorted other “previews” of software, generally some sort of “maintenance” console from the system manufacturer, links to one or more ISPs setup procedures, etc., that require several hours’ cleaning in order to be rid of them.

If you have the misfortune of buying a system from Samsung, however, you may have found a little something more.  NetworkWorld broke a story yesterday where a security professional found a clear instance of spyware being preinstalled by the manufacturer.

Spyware, as the name implies, is the term for software intended to covertly gather information from a system and report it back to some other party without the user’s knowledge or consent.  In this case, it was a kind of program known as a keylogger: it intercepted keyboard input and logged it for transmission back to, apparently, Samsung–meaning that any documents, usernames, passwords, credit card numbers, social security numbers, names, addresses, or what have you that are entered on the keyboard, regardless of the context or location of the entering, would be logged by the system for inspection by Samsung.

Systems have been compromised by malicious software before being shipped in the past–Seagate had an incident in 2007 where some of its home-user Maxtor drives shipped with an outdated virus due to contamination at the drive manufacturing plant–but in this case the action appears to have been purposeful, as Samsung has admitted to purposely installing the software on the systems.

This recalls the Sony rootkit debacle from ’06–Sony had purposely built onto CDs a data track designed to be run by user’s computers that would install software specifically for the purpose of restricting music copying.  In this case, not only was the rootkit largely ineffective, but Sony was brought up before the FTC and restricted to such an extent that business refactoring was necessary in order to continue to operate in the United States.

The FTC stated at that time that installing software that creates a security risk to the consumer without the user’s consent is forbidden.  This apparently did not stop Samsung from violating, clearly, the letter and the spirit of that decision in installing malicious (to the user) software on the system.

Fortunately, there is a–relatively–easy fix for all of the problems above.  Installing an operating system onto the computer other than the one the manufacturer provided is a sure way to prevent both the installation of bloated advertising programs and vendor-provided malicious software.  

It’s an unfortunate extra step, but so long as vendors continue to prove they cannot be trusted with consumers’ information, it’s a necessary step.

A word of caution: the Windows license key printed on the case will likely not work with a regular Windows installation disk; that key is keyed to what’s known as the OEM version of the operating system–that is, the one that is distributed on the computer.  You will either have to purchase (or obtain by some other means) a license for Windows from another source, or choose a Linux distribution (such as Ubuntu or Fedora) that can be obtained without cost.

A post on the best ways to bribe the local computer geek into setting this up for you will be written shortly.

EDIT:

Several sources (engadget and Ars Technica, specifically) are now reporting that the keylogger detected was likely a false positive.  The statement by the customer support supervisor was, in this case, likely due to a misunderstanding of the question being asked. 

That being said, it is still a good idea to either build your own system or wipe and install your own OS on a vendor-supplied system, if only to keep off unnecessary bloat.

Here’s a bit of Monday morning fun: Slashdot reports that SQL.com was cracked via an SQL injection attack.  

SQL is a very prominent database schema used in thousands of installations around the globe.  An SQL injection is when an attacker bypasses the normal front-end for the database and finds a means of executing their own commands, usually with the aim of either stealing information or of corrupting or changing the database in some fashion.

Cross-site scripting, also mentioned in the article, is a means by which such attacks can take place.  This is a slightly more complex vulnerability–essentially, it occurs when the client, rather than the server, is used to validate requests against the server.  If that is the case, then a sufficiently competent attacker can craft a malicious version of the script produced by the webpage in question and serve that to users (via the usual social engineering methods) in an attempt to gain login credentials, session credentials, or other information about how the resources are generally accessed.

Combining the two can lead to a theft of credentials usable for gaining access to the whole of the database for whatever purpose the attacker wishes–the “pwnage” that many attackers seek to gain.

The vulnerability in the SQL databae was apparently, according to the articles linked above, discovered in January by some enterprising folks out of Romania.  Whether it was reported ahead of time is not known to this author at this time–the original resources are protected behind a policy setting at a Romanian exploit site, and the XSS (cross-site scripting) vulnerability has a publication date of April 1–though this could be January 4, and a dd/mm/yy rather than mm/dd/yy confusion.  

The vulnerability in question appears to be something rather obvious; the actual attack is caused via inserting a “script” html tag in the URL of the resource requested.  

The countermeasures to prevent this sort of thing happening are twofold:  first, of course, is never to click on a URL without knowing what it is you’re clicking on.  Think before you click.  There’s no reason to click on a link with an html tag embedded in it, normally; such uses are endemic for exploiting security flaws, but are not often used by legitimate sites.

Secondly, if you are designing a site, assume that any input coming from the client side is unsafe and must be validated–there’s no point putting the validation mechanism out where it could be changed.  Javascript is inherently open-source because the source must be served to the client machine in order to run; as such, any vulnerabilities present in it will be found eventually.  There’s no way to ensure that input coming to your servers is being sent by the same javascript that was served from them originally; take this into account when designing your sites, and you will not be vulnerable to this kind of attack.

There’s a quote from the early days of the internet that seems to show up fairly often when discussions of censorship, neutrality, and the like appear:”The Net interprets censorship as damage and routes around it.”

The internet was originally conceived by DARPA as a robust network capable of surviving immense disruptions caused by, specifically, nuclear war and other societal disruptions.  The whole point of all the protocols that underlie the internet as we know it today is to get data from point A to point B in as reliable a fashion as possible, and to make sure that the data at point B matches that at point A as closely as possible.  From a technical standpoint, any parts of the network between points A and B that filter out the data as objectionable will be avoided during the routing; even in a naive packet switched network, such a system that ‘damaged’ the transmission of the data would merely slow, rather than stop, transmission.  More intelligent networks with routers set to optimize the routing of their payloads will, in time, actively work to avoid such networks, as the dropping of packets containing censored payloads would be reported by the other endpoint and would, accordingly, count as a failed delivery.

However, the technical solutions aren’t always enough; some countries like, to pick a particularly large example, China, have sought to control their citizens’ access to the internet wholesale–they’ve split off their part of the internet as a sort of walled garden and have employed, to strain the metaphor, enormous guard dogs to examine all ingoing and outgoing traffic for subversive messages.

This is where another part of the network comes into play: the people who design and build communications technology.  While certainly there are any number of very competent hardware and software engineers working for the Chinese government to assist them in keeping their citizenry (and netizenry, as it were) with toes to the party line, there are just as many competent people within who want to know what goes on in the outside world–and even more people outside who have a dedication to ensuring that information be freely available to those within the firewall.  This layer of damage may cover layers one through seven of the networking model, but layer 8–the users–can always eventually find a way to route around a faulty connection.  

Several countries already consider internet access–that is, access to the full spectrum of information that the citizenry needs in order to make an educated and appropriate judgement about their affairs, and to participate in human society–as a fundamental human right.  It’s a required part of freedom of speech and of the press–two rights enshrined in the first amendment that recognize only through the free flow of information can an effective democracy exist.

It’s very telling that, during the recent unrest in Egypt, one of the first steps that the former government took to attempt to quash the protests against it was to shut down this information flow–all the ISPs were forbidden to route traffic out of the country, and Egypt more or less disappeared from the map.  Workarounds were available within hours, with network connections being routed to modems and the like; the damaged connections were bypassed–not in the most efficient manner, but bypassed nonetheless–and the flow of information resumed.  This same government that ordered the connections shut down (and, incidentally, harmed the economy of the country greatly, for no economy can exist today without significant information flow) was overturned.

As one means to combat censorship and the like, Google is spending a significant sum to develop a suite of tools that can help to detect various kinds of censorship, to enable layer 8 in making effective decisions about the lower layers of the network.  While Google’s motives may not be entirely altruistic–they’ll doubtless benefit from knowing what networks are most restrictive and the pressure that will be generated on them to open up–they are useful for the internet’s health at large; an undamaged network is an efficient–and useful–network for commerce, for entertainment, and for freedom.