So, let’s start with a beginner’s introduction. In the beginning, there were users, and users wanted to be able to log in because otherwise being a user was rather pointless indeed. Thus, the password is born, and forevermore it becomes the goal of clever crackers and security experts alike. The first problem someone encounters with passwords is how to store them, and that depends very much on a few key factors: Audience, Exposure, and Uniqueness. If you are running a “homegrown” application (shout out to MecTracker) for use only inside the company, containing (in general) zero sensitive data, and you intend to pick user’s passwords for them (preventing the loss of a life password, itself a bad-yet-unavoidable practice), then why not just store them in plain text? Certainly makes it easy to retrieve a password for someone without having to reset it (useful for someone away from their work machine with saved password who needs to log in).

Conversely, if you’re a bank, and you’re storing any of this in plain text, you will be razed to the ground by angry tech-savvy customers and auditors alike, hopefully BEFORE you get grandma and grandpa Jones to type in the password they use for everything else, too. Hopefully, if you’re a bank, you’re using some crazy method I’m not about to describe here.

Then, there’s the middle ground. I, for example, am not a bank (who would’ve guessed? Can someone please notify my ex-girlfriend?), so my needs are much more middle-of-the-road, which is why I’ve settled for hashing. When I started using PHP, I generally stuck to simple MD5 hashes; it was 10 years ago, and breaking MD5 seemed reasonably difficult. Then I was told not to use MD5 because, at 128 bits, it was too weak, and I should be using SHA-1, which was 160 bits. Then came the recommendation for SHA-256 (guess how many bits that one is!), and then whirlpool, and so on. If you’re using a proper password strategy then you’ve been salting all along (I’ll admit I wasn’t in the old days, but you’ve got to be a beginner sometime), but if you haven’t, allow me to give you a word on salt.

“Salting” a password hash is the practice of taking a piece of input data, adding in an extra piece of information (called “salt”; see where this is going?), and hashing that, instead of just hashing the raw input. In fact, with sites that act like a search engine for MD5 and SHA-1 hashes, not salting your input is, for general purpose storage, only one-degree of separation away from just storing the data in plain text. Furthermore, good salt will be ever-changing (in this practice, the salt is also known as a ‘nonce’), and can safely be stored without obfuscation, as having included it means that a table not accounting for the nonce is useless, and a table that accounts for the nonce is only good against one of the passwords in your database. Now you’ve just made an attack much more expensive, but that may not be as useful in reality as we’d like to believe.

MD5 and SHA-1 hashes can be calculated very, very quickly. In fact, it’s generally more expensive to include some data about the current time (for use in salting/as a nonce) than it is to calculate the actual hash. Here is some experimental code to prove my point:

define('ITERATIONS',5);
 
$tt = $th = 0;
for ($j = 0; $j < ITERATIONS; ++$j) {
	$start = microtime(true);
	for ($i = 0; microtime(true) - $start < 1; ++$i) {
		$k = md5($i);
	}
	$tt += (microtime(true) - $start);
	$th += $i;
}
 
var_dump($tt / ITERATIONS, $th / ITERATIONS);

Simply hashing the value of the counter averaged 320,000 hashes per second on my work machine, which is not very powerful, and is certainly not running this in a very optimized way. By changing what is being hashed to the current time to the microsecond, the number of hashes per second is reduced to an average of about 150,000 – in short, the hash is NOT the expensive part of what’s going on here. So, let’s say that, given a more optimized environment but a more expensive dictionary list to be hashed, that the average is 200,000 hashes per second, and the dictionary is about 50,000,000 common passwords. Simple math tells you that generating a hash list for this will take about 250 seconds, or less than 5 minutes. If it takes under 5 minutes to generate a table, and only a few seconds from there to query it, then even a database of 150,000 users can be fully cracked in just under a fortnight.

So how can this be combated? Well, strong password guidelines are a good start, but if you’re relying on users to implement password security for you, you’re probably doing it very, very wrong. I’d like to challenge one of the assumptions you’ve probably made that I’ve had to challenge recently, and that is the value of speed; speed is bad. Think about it: using a hash method that can generate a table of fifty million values in under 5 minutes sounds great from a performance perspective, but who are you really helping? Is your user going to notice that your hash method took under 1ms to calculate, or is this performance more likely to benefit someone trying to crack your passwords? Who would be more hurt if your passwords took closer to 12ms to generate and verify, your users or your would-be attacker?

If you haven’t heard of it yet, may I introduce you to Blowfish Encryption. Blowfish is designed to scale with Moore’s Law by allowing you, the programmer, to decide how long it takes to generate a hash. This is done by allowing you to specify a number which will be interpreted as a log-base-2 of how many iterations the hashing sequence should take; this metadata is then stored as part of the salt, prepended to the hash, and can be verified by the same function that created it since hashes are of fixed length and will be truncated or padded accordingly. By using a log-base-2 scale, every increment of that number (n) literally doubles the time required to calculate the hash, as it will have to undertake 2ⁿ iterations to generate the password. From what I can gather, a number like 7 or 8 is a fair industry standard at this time, and on my work machine limits the hashes-per-second to around 86.6 and 43.3, respectively.

Now, performance is a factor in real world applications, so let’s pick a number like 2⁷, which as I said allows about 87 hashes per second. At that rate, a single dictionary table (useful for only one user, since we are salting these passwords) takes about six and a half days to generate. For that same database of 150,000 users, it would take over 2,733 years to crack. Of course, computational power will get less expensive as time goes on, and the same number of operations can and will get faster, but with the blowfish algorithm you need only increment the log to double the computational cost, keeping the cracking of your database safely outside the realm of technical feasibility.

So how does one use the blowfish algorithm in PHP? The crypt() function is your friend! However, the manual is not entirely clear on the implementation details of blowfish, as it does not include one key part (which caused me to tear my hear out a little bit, since, as a Windows user, I was unable to check the man pages for crypt(3)) in any great detail, and that is the log base. When you generate the salt, you will need to prepend it with an instruction string that tells it what kind of hash to generate, and what parameters to use. Furthermore, the salt is not sixteen characters, but sixteen BYTES, and the characters in your hash will be read as a BASE64 encoded string, which means that using characters not allowed in a base64 string will cause the function to revert back to whatever the default is on your system, probably STD_DES or MD5.

All of that information might have seemed a bit hazy, so I’ll include the timing example I used before modified to suit crypt/blowfish. Note also that I am storing the microtime result on every iteration of the for-loop, as in order to give you worst-case scenarios on the cracker’s timetable, I had to give best-case timings on the hashing, and that means as few calls to microtime as possible.

define('ITERATIONS',5);
 
$tt = $th = 0;
for ($j = 0; $j < ITERATIONS; ++$j) {
	$start = microtime(true);
	for ($i = 0; ($z = microtime(true)) - $start < 1; ++$i) {
		$k = crypt($i, '$2a$07$' . (string)$z);
	}
	$tt += ($z - $start);
	$th += $i;
}
 
var_dump($tt / ITERATIONS, $th / ITERATIONS);

Of paramount importance is the literal string prepended to the stored value. The first four characters, $2a$, simply instruct crypt to use the blowfish algorithm. The next three, 07$, pass the number 7 as our log-base-2 argument, meaning the computation will run for 2⁷ iterations. After that, we concatenate our salt (values shorter than 22 characters will be padded in a predictable fashion, and longer than 22 will be truncated) to the argument string and send it off on its merry, 12ms way.

Do I think I’ve defeated all the clever crackers out there? Certainly not. However, I’m definitely in a better boat for having stood on the shoulders of giants and listened to people smarter than I am about security. In fact, don’t listen to me, check out these links for more info:

(Victor) Xi Wang talks about salt, nonces and rainbow tables

Matasano Security, LLC, talks about blowfish and why you shouldn’t design your own password protection scheme.

Linked earlier, explains blowfish encryption – very math/pseudocode heavy.

Also linked earlier, the PHP Manual Entry for Crypt()

Happy Hashing!

class foo {
	private $bar = array();
 
	public function __construct() {
		$this->bar[0] = new stdClass;
	}
 
	public function __get($n) {
		return $this->bar;
	}
}

So now we have a simple object with an array whose single element is an instance of PHP’s default object, stdClass. In reality you’d likely have more than just one element to the array, but it’s not necessary here to prove the point. Now, since objects are always returned by reference, accessing the first index of the array returned by __get when you try to access any member will allow you unfettered access to the contents of the object, to do with what you will (or rather, what the object will allow you to do).

With that in mind, let’s examine this:

$foo = new foo;
$foo->bar[0]->baz = 'I am a test';

This code is pretty easy to follow, and in fact does exactly what you’d expect: the stdClass object sitting in the first element of the “bar” array has a new member, “baz”, defined and assigned. Viewing the contents of the object will show that this is exactly what happened:

  ["bar":"foo":private]=> {
  array(1) {
    [0]=>
    object(stdClass)#2 (1) {
      ["baz"]=>
      string(11) "I am a test"
    }
  }
}

However, there’s a problem. Somewhere along the line, we generated a notice:

Notice: Indirect modification of overloaded property foo::$bar has no effect in …

While the notice certainly won’t halt the script’s execution, and the expected (and desired) action has taken place with no other apparent side effects, we are left with the conundrum of what to do with this notice (Note: While this issue has been brought to the attention of the PHP team, no word of a fix has yet surfaced). Since I am a firm believer that Notices and Warnings are potentially more dangerous than Fatal Errors, I won’t simply turn off error reporting; indeed, since the errors are still raised that doesn’t completely fix the small performance hit of generating the error, either.

In order to address this issue, it is important to understand what the notice is trying to tell us.  Once upon a time, __get was a return-by-reference function by default.  Of course, this doesn’t really help with wanting to prevent the modification of an object’s internal data, so __get was corrected to always return by value; in fact, even objects are “returned by value” in this case, since the value of the member variable is being returned (which just happens to also be a reference to an object), whereas the old __get would have returned a reference to the member variable itself; while the difference may seem subtle, it is monumental.  Since this change occurred, it was important to notify coders that if they attempted to modify the contents of an array element which came from an overloaded array, this action would have no effect, as the modified element would only exist in the copy returned from __get.

Armed with this knowledge of history, we have a few obvious options for solving this problem

1. public function & __get($n).  This will technically prevent the warning from coming up, but if you’re going to go this route you might as well just declare all your member variables as public anyway, as this is what it will effectively cause __get to do.  It opens the door to such dangerous situations as:

   $foo->bar = 3;

   That’s right, if you return by reference explicitly in __get, then you will circumvent any rules you’ve set for assignment via __set. Even objects are not immune to this, as a reference to the member variable (itself containing a reference) will be returned. This option removes the efficacy of even having visibility operators for anything you intend to provide overloaded access to.

2. Assign a variable to the contents of the array element. Again, technically, this works, but it is messy, inelegant, and is nowhere near the ideal. Here are two examples:

   $bar = $foo->bar;
   $bar[0]->baz = 'This works';
   ###
   $bar = $foo->bar[0];
   $bar->baz = 'This also works';

   Again, though, this is not the clean, simple approach we were looking for to begin with.

3. Just turn off notices. Nah, we ain’t doin’ that.

So what’s left to consider? After thinking about the problem for a little while, I realized that this problem wouldn’t even exist if I could just store the array as an object instead, but objects don’t allow numerical indices, so it would take a little jimmy-rigging to get it to work. Here was the first version:

class arrayReference {
	private $_ = array();
 
	public function __set($n, $v) {
		$this->_[$n] = $v;
	}
 
	public function __get($n) {
		if (array_key_exists($n, $this->_)) {
			return $this->_[$n];
		}
		$this->_[$n] = null;
		return $this->_[$n];
	}
 
	public function __call($n, $a) {
		if ($n == 'array') {
			return $this->_();
		}
	}
 
	public function _() {
		return $this->_;
	}
}
 
class foo {
	private $bar = null;
 
	public function __construct() {
		$this->bar = new arrayReference;
		$this->bar->{0} = new stdClass;
	}
 
	public function __get($n) {
		return $this->bar;
	}
}
 
$foo = new foo;
$foo->bar->{1} = $foo;
$foo->bar->{99} = new stdClass;
$foo->bar->{99}->baz = 33;

Which, for the adjusted syntax, actually worked out pretty well. It might take more than an instant glance from your average PHP coder for what’s going on to make sense, or even seem syntactically correct, but it certainly worked; it even allowed for loop-based iteration by doing something like so:

foreach($foo->bar->array() as $k => $v)

While that isn’t ideal, it’s fairly transparent about what it’s doing.

I wish there were a more climactic way to put this, but there isn’t: The next step involved me trying to combine the SPL’s ArrayObject built in class to allow natural array access to my wrapper class, and after a few minutes playing with my new hideous child-beast amalgamate and its Reflection, I finally settled on this for the final version of the class:

class foo {
	private $bar = null;
 
	public function __construct() {
		$this->bar = new arrayObject;
	}
 
	public function __get($n) {
		return $this->bar;
	}
}

No more messy syntax, no compromises, no hideous amalgamate beasts, and no figuring out how to mangle my behemoth class this lesson actually needed to be applied to in order to extend ArrayObject for the purposes of accessing just one property, as I saw advocated elsewhere during the googleing portion of my problem solving routine. The example I first gave? Works just fine, and no error since the property being returned is an object, not an array. Sometimes the best solution is fiendishly simple; the only real consideration I had to make here was that, in its actual application, the array in question was declared null so it could be lazy loaded, and since you can’t use the “new” keyword or even type-hinting in class member declarations, I had to be careful to make sure the lazy loading mechanism would still work, but I was never declaring a traditional array either: all in all, a 5 minute job to implement and test.

Five minutes that made the past day or so of work seem rather silly indeed.

I am going to use a very general analogy for how the internet works: a city.  Now, the city that is the internet is a very strange city indeed.  This city isn’t owned by any single country or government.  Just about anyone can come and go as they please.  Now, this city has three basic pieces, and they way they blend isn’t that different from how any city works:  you have content “Servers,” content “Consumers,” and a transit system.  The Servers could be anything from a tent someone just set up for a while to a huge mall, or a towering building, but it is basically somewhere you can get some content.  In Internet City, just about anybody can become a Server.  Then, there are the Consumers.  This is probably where you fit in to Internet City — when you use the internet, you are at home, or at work, or on your phone, but you are mostly-if-not-exclusively retrieving content from these Servers (this includes posting on social media sites, such as Twitter, Facebook, MySpace, et al).

The third part of the city is the transit system, which is your ISP.  At the top of the chain are the people who make all the roads, the asphalt, the car you will drive around the internet city, and pretty much everything you will need to get from point A to point ∞.  These are the Tier-1 Network Providers (and to some extent the larger Tier-2 providers, but this discussion is beyond the scope of this analogy); they are few, and they are powerful.  Of course, they generally don’t personally make every single road; who handles the road from there just depends on where it leads, who is willing to go there, and what services they intend to offer.  These are the Tier-2 and Tier3 Networks, and they are probably more familiar to you.

Now, how fast you can get somewhere depends on three things: What kind of car you bought (your specific internet package), what kind of road the journey takes (the quality of ALL the connections from you to your destination, and back), and how far you have to go.  If you have a mac-daddy broadband connection, and you are accessing a major site (major news networks, etc), you’ll spend most of your time on the metaphorical highway, and should get your data rather quickly, and the inverse is true as well.  Any further delving into how this works is also beyond the scope of this analogy, but you get the idea.

So what is Net(work) Neutrality?  The idea is that no matter from where or whom traffic comes, ISPs may not give preferential treatment to it.  As fast as the hardware will carry it must it go.  Groups and people who support this include small ISPs, who don’t want their customers to get abused by the larger and higher-tier internet providers, as well as Tim Berners-Lee, a man whom you may not have heard of but whom you are in contact with right now, as he practically invented the “World Wide Web” we have come to know.  Opposing this is the idea that an ISP should be allowed to decide to give (at their own, private, and in this writer’s opinion, dubious, whim) preferential treatment to some data, at the expense of other data.  On the relatively mild side of the spectrum, they could choose to allocate their network resources in such a way that, for example, their particular VoIP service received preference over competitors such as Vonage and Skype.  This is mild, and arguably benign in the grand scheme of things (so long as they advantage isn’t dialed to extreme levels, to the point that it is a detriment to competitors), and not what the issue is about.  Given total freedom of how data flows, they could route traffic in such a way that their own VoIP service takes precedence over their competitor’s VoIP service — they could even extort a fee to avoid this sort of “traffic shaping” — all without the consumer being able to defend against this action.  The customer would then be nearly forced to use that company’s VoIP service, or any service it chose, in order to get any semblance of quality.

A real-world example would be like allowing the government to create a lane of traffic in which only USPS vehicles could travel, and then forcing UPS and FedEx to use 1-lane dirt roads instead of the highways, since they are a competing service.  Or, in the analogy of Internet City, it would be like the powers-that-be on the roads checking to see where you are going (in Internet City, you have to announce where you’re going or you can’t get there), and then forcing you to use smaller, slower roads, or yield to indefinite amounts of other traffic, based on whether or not you were going to one of their in-house holdings.  Nightmarish.

Some of the points brought up against Net Neutrality are, quite frankly, absolutely ludicrous.  As someone posted on the PC World forums:

“What this article completely fails to state (talk about one-sided reporting!) is that Google has devoted far more money to lobbying for regulation of the Internet than the telcos have to defending itself against it. Google has given hundreds of millions of dollars to slimy DC “astroturf” groups — that is, groups that pretend to be acting in the “public interest” but in fact do what their contributors tell them to do — which are lobbying for “network neutrality” legislation and regulation. And if you look at the details of all of these regulations — which start with high-minded language that talks about “freedom” and “openness” — all of them would tie the hands of ISPs and of Google’s competitors, while giving Google free rein to do whatever it wants, including to serve as an Internet gatekeeper. The regulations would also raise the price of Internet service, lower the quality of that service, and reduce consumers’ competitive choices by putting small providers out of business.

Remember: corporations don’t act out of the goodness of their hearts. Monopolist Google wouldn’t be doing this if it weren’t seeking to maximize its profits at the expense of consumers. So, remember: “network neutrality” isn’t neutral. It is Google’s corporate agenda, and it strongly favors Google.”

Wow, that is a lot of Big Brother Meets Google conspiracy theorizing (Ballmer, is that you?)! Aside from that, the points this person raises are thus:

1. It will raise the price of internet service. How, exactly? One of the possibilities is that, after some time (maybe a few years) of ISPs shaping traffic however they please, they will offer a new “unshaped” plan for only $20.00 more per month, thereby allowing them to charge you more for the same service you’re getting at the time this article was written. However, if we are given true Net Neutrality, there is no reason for the price to go up (other than inflation, which doesn’t count). After all, if nothing changes, then there’s no new way to sell us back what we’re already getting.
2. It would lower the quality of internet service. Again, how? If you think that internet service means that all you do all day is browse your ISPs website and use their video service, their email service, their phone service, and so on, then maybe it would “lower” the quality from the standpoint that it would not be “increasing” the quality, which as previously mentioned would be at the expense of everyone else. Quality won’t degrade because we didn’t decide to let the ISPs tell us what is more valuable. To re-iterate the point, Net Neutrality basically means nothing changes.
3. It will reduce consumers’ competitive choices by putting small providers out of business. No, just no. Small ISPs in Canada came out strongly in favor of Net Neutrality before such legislation was passed anyway.  The larger wholesale (Tier-2) internet providers were shaping bandwidth to the point that it affected large numbers of users of the smaller Tier-3 providers, and the small providers resisted, but at the end of the day they are buying internet (albeit in larger increments than you or I) from the Tier-1 providers, and they are the ones against Net Neutrality.  Funny how the exact people who are against neutrality are feeding you the exact opposite of truth about what will happen to the “competition.”  And, to round out this bullet point, Tier-1 providers who are going to bat on this one (AT&T, Cogent, et al) just don’t care what the little guys are doing: they have the pipes in the middle, and everyone else needs them.

Of course, these are just the arguments on Net Neutrality that actually have something to do with the subject at hand!  Then there are the downright lies spread by, among others, Glenn Beck, such as:

1. Net Neutrality will bring the Fairness Doctrine to the internet, resulting in government censorship/control of the content on the internet. It is extremely important to remember that, above all, the Internet does not exist solely in America.  The internet is no longer any more an American thing than it is a Russian thing or any other location-based thing.  The internet is vast, it is (from the point of view of the average user) limitless, and no one country owns it.  America could try to censor the content located in America.  America might even try to create treaties with other nations to control what is hosted in their countries.  However, all this will do is open up a market for “regulation-free” hosts, in countries who wouldn’t sign any such treaty (maybe a nice time to wire-up some third-world African nations?), or something else like it.  Let me, again, put this in the simplest terms possible: NO SINGLE COUNTRY CAN CONTROL THE CONTENT OF THE INTERNET.  IN ALL LIKELIHOOD, NO COMBINATION OF COUNTRIES CAN CONTROL THE CONTENT OF THE INTERNET.The internet is not just one person, one company, or one country.
   
   And to think, I said all of that without even mentioning that NET NEUTRALITY DOES NOT IN ANY WAY, SHAPE OR FORM REFERENCE OR ATTEMPT TO INSTITUTE ANY SORT OF FAIRNESS DOCTRINE. This argument would be laughable if it weren’t given so much credence by lying morons like Glenn Beck who, like McCain (from whom I respectfully withhold the indictment of “lying moron”), really don’t know the first thing about the technology they are so passionately speaking about, and the credence it will be given by the people that listen to and trust them.  This issue is a Red Herring.
2. The government will be stepping in as a watchdog of the internet. No, the government would simply be stepping in to maintain the status quo so that Tier-1 providers don’t start exploiting their customers in unfair ways. Everybody, whether Servers or Consumers, pays for the “pipes in the middle” that is the transit system — why does the transit system then get to start deciding at what speed or priority I get to receive the content I’ve payed them good money to get?  This issue is a misunderstanding.
3. Net Neutrality is a ploy by left-wing liberals to socialize internet access. I don’t even have a diatribe for this one, I’ll just rest on saying that no, it’s not in the bill, it’s not on the table, no. Prominent liberals, such as “Van” Jones, have spoken about how we should be giving broadband access, for free, to everyone, like they do in some other countries, but this is a separate goal from the standpoints of the technology, the FCC, and the implementation, as well as the bill that is on the table.  These views are not encompassed by Net Neutrality, but are in fact a Red Herring.
4. Revolution!  Marxism!  Destroying Capitalism!  Rabble rabble! It is important to remember that you can hire someone to kill someone else, but this is considered an unfair, immoral, and reprehensible business practice and thus it is forbidden.  Regulations on how you can do business with respect to, quite frankly, not just plain crapping all over the environment, the public, and your own consumers, are commonplace in our legal system; you really, really wouldn’t want to live in a world where companies could do whatever they wanted any time as long as it turned a buck.  And as for all the talks of people somehow magically using Net Neutrality for revolutionary and/or Marxist goals?  These are, you guessed it, Red Herrings!  And a special breed of Ad Hominem Red Herrings at that!  In fact, given the blatantly untrue and often unfounded accusations that Beck has made against his opponents, I’d say this also qualifies as a Straw Man Fallacy.
5. The government will be controlling content. No, see argument 1.
6. The internet won’t work as well, things will load slowly, etc. The reason given here is/was that there won’t be enough competition and so on.  Again, Network Neutrality advocates the status quo — that is, just because you have the traffic before you sell it doesn’t mean you can decide how it’s used once you’ve sold it to me.  This is an Outright Lie.
7. Net Neutrality does not help innovate business. You’re right, it doesn’t. It protects the little guy from having big businesses “innovate” more money out of his wallet. Next.
8. The government will take over the internet. Again, see argument 1 — the American government can no more regulate the internet than it can nail Jell-O to a tree.  The long and the short of it is that, even if the government suddenly decided it wanted to own all hosting services (remember, content is DISTINCT from transport), anyone can set up a server on any computer connected to the internet, and suddenly they are content providers.  The internet is a vast, untamed, wild environment.  THE GOVERNMENT CANNOT CONTROL IT.

Mark Lloyd said something very important that bears quoting:

“Unfortunately, the powerful cable and telecom industry doesn’t value the Internet for its public interest benefits. Instead, these companies too often believe that to safeguard their profits … they must control what content you see and how you get it. Their plans could have dire consequences for those whose voices are often marginalized by our nation’s media system.” -Mark Lloyd, Federal Communications Commission.

Beck’s guest then attacked him, specifically saying “they turn things inside out,” then going on to imply that Lloyd wanted to use Net Neutrality as a means to Government Control and a re-introduction of the fairness doctrine, and that he would use this new government brand internet to give voices to the “marginalized people” a la the fairness doctrine. He not only completely misconstrued (I’d say misunderstood except I believe that he is an evil little man) the quote but, in fact, turned it as inside out as he claimed the Net Neutrality proponents are doing.

TL;DR Net Neutrality, though technically regulation, is very mild and serves only to prevent the ISPs and Telecoms from regulating how the traffic you pay for gets shaped; it provides no slippery slope nor sets any precedent for the government to control the internet. Supporting Net Neutrality (and opposing Sen. McCain’s bill) is supporting the status quo, and supporting the rights of the consumer. The government cannot, and will not, control the content of the internet; not only is not that even on the table here, it is fundamentally impossible, and outside the scope of even the FCC. Before you overreact, learn what’s actually going on. Please.

P.S., for another well-thought-ought viewpoint on net neutrality, check out this post on Brad Ideas.  He believes that we don’t need to codify Net Neutrality into law, but I think he would also support the not coding into law of the exact opposite.  I disagree with him, and think that we should make it law, if only because this is the second time that opposition has arisen loudly in government, but his opinion is worth reading nonetheless.

Additional Link: http://www.ethioplanet.com/news/2009/10/25/google-verizon-join-forces-to-support-net-neutrality/

The problem I have with XML, my “beef” if you will, is certainly not XML’s fault; it’s the fault of the overzealous developer who wants to use XML as a way to transmit pixel data over the network.  If you look at that post and your first thought is something like:

Well, duh, of course that’s the wrong way to do it, I’d use something like:

<signature>
	<pixel x="127" y="90" />
	<pixel x="128" y="91" />
	<!-- ... -->
</signature>

Well, you’re probably already too far gone; this post isn’t for you.

Of course, you still have to send your data somehow, and since raw bytestreams are out this fall, why not look into an alternative format? May I recommend some JSON?  Let’s take a look at a simple and realistic (ish) case of JSON -vs- XML: representing an order in a format that a person and a computer can read.

For this experiment, I will be placing order number 233 on behalf of customer number 971.  Said customer would like 2 each of item number 2751 and item number 1765, “beef brats” and “brat buns” respectively.  Said customer would also like the buns warmed but not toasted, and the brats to be of the “Beer Basted” variety, but not filled with cheese.  Here we go.

JSON:

var order = {
	orderId: 233,
	customerId: 971,
	items: [
		{
			itemId: 2751,
			name: "Beef Brats",
			quantity: 2,
			options: [
				{
					name: "beerbasted",
					value: true
				},
				{
					name: "cheesefilled",
					value: false
				}
			]
		},
		{
			itemId: 1765,
			name: "Brat Buns",
			quanity: 2,
			options: [
				{
					name: "warmed",
					value: true
				},
				{
					name: "toasted",
					value: false
				}
			]
		}
	]
};

EDIT: I noticed the objects weren’t exactly semantically similar; I fixed this because fair’s fair (and it only increases the size of the JSON by about 20 bytes, whereas the equivalent XML correction might have taken triple that

Versus the contender, XML:

<?xml version="1.0" encoding="UTF-8"?>
<order>
	<id>233</id>
	<customerId>971</customerId>
	<item>
		<id>2751</id>
		<name>beef brats</name>
		<quantity>2</quantity>
		<option>
			<name>beer basted</name>
			<value>true</value>
		</option>
		<option>
			<name>cheese filled</name>
			<value>false</value>
		</option>
	</item>
	<item>
		<id>1765</id>
		<name>brat buns</name>
		<quantity>2</quantity>
		<option>
			<name>warmed</name>
			<value>true</value>
		</option>
		<option>
			<name>toasted</name>
			<value>false</value>
		</option>
	</item>
</order>

Now, XML proponents likely will not take this one lying down. They’ll look at that document and accuse me of being the worst, most evil, vile, baby-eating slanderer ever to take a crack at their beloved XML. After all, one could just as easily use documents with more concise structure, something that doesn’t just look so gigantic, like one of these:

<?xml version="1.0" encoding="UTF-8"?>
<order id="233">
	<customer id="971" />
	<item id="2751">
		<name>beef brats</name>
		<quantity>2</quantity>
		<option name="beerbasted">true</option>
		<option name="cheesefilled">false</option>
	</item>
	<item id="1765">
		<name>brat buns</name>
		<quantity>2</quantity>
		<option name="warmed">true</option>
		<option name="toasted">false</option>
	</item>
</order>

<?xml version="1.0" encoding="UTF-8"?>
<order id="233" customerid="971">
	<item id="2751" name="beef brats" quantity="2">
		<option name="beerbasted" value="true" />
		<option name="cheesefilled" value="false" />
	</item>
	<item id="1765" name="brat buns" quantity="2">
		<option name="warmed" value="true" />
		<option name="toasted" value="false" />
	</item>
</order>

<?xml version="1.0" encoding="UTF-8"?>
<order id="233" customerid="971">
	<item id="2751" name="beef brats" quantity="2" beerbasted="true" cheesefilled="false" />
	<item id="1765" name="brat buns" quantity="2" warmed="true" toasted="false" />
</order>

The reason I don’t list these as the primary contention against JSON, even though that’s what the advocates would probably have written? Simple. Those representations don’t match, when treated as a representation of an object, the order I started out with. They are close, yes, and they convey the same information, but the syntax is entirely different, and therefore the parsing is not only more complex, especially when it comes to converting the XML back into an objectm, not to mention that you start to lose the “human readable”-ness of the document by trying to cram it into less and less space.

Furthermore, with JSON, exporting objects, arrays, or both, is extremely easy to do — in PHP, for instance, it’s actually native since version 5.2, and json.org has plenty of easy-to-use implementations in most languages in common use.

In order to arrive at the XML I chose as a contender, I did a google search for “array to XML PHP” and checked the top result, which was a function (for some unknown reason static-inside-a-class-as-the-only-member, maybe written by a namespace-nazi?) that seemed to do a more-or-less standardized conversion. Now, again, we could argue all day about whether or not that is even a worthy implementation, but before that argument starts let me squash it by saying this: whether or not any of those syntaxes is correct or not is less important than the simple point that any and all of them are technically correct.

Semantics aside, all of those XML versions of the same “object” are valid and well-formed XML documents, and they, depending on your method of “serialization” into and out of XML, all describe the same order. And that, ladies and gentlemen, is a problem I consider to be worst of all. Which one of those is right? Is it the smallest, the one that’s most clear, the one that is most loyal to the original order object?

Because of XML’s loose specification, which is a good thing in cases where XML is appropriate, there isn’t really a consistent way to represent these objects as XML that everyone agrees on. Some people, as in the last example, would put everything into an attribute=value pair, while many automated methods for de/serialization would use almost no attributes, instead favoring raw tags.

Before this gets too far away from me, let me draw it to a close. Because of the standard’s, if you’ll pardon the sub-pun, lack of standardization, I propose we stop, for the love of all that is good and pure, using XML to represent every single object and data-fragment we come across. It’s time to let go. There are just too many ways to do it, and we’re running out of patience…