It's not news that more-or-less legitimate news sites like to surround their articles with enticing links to somewhat-less-legitimate news sites: 20 reasons your dog may be considering a new career ... You'll never believe this simple secret for removing egg yolk from pine trees ... Read this before you buy a moose ... you know, those sorts of things.
Click through on one of those and there's a good chance there will be some sort of slide show surrounded by a minefield of garish ads. Sure, why not? Putting together pictures of whatever sort of fluff for people to page through is somewhere around neutral on my personal scale of good or bad ways to make a living.
Except, when you lay out the page with a large ad at the top with an arrow icon next to it, and white space between, looking for all the world like it's going to take you to the article you're really interested in (well, at least maybe kinda interested in). Except that arrow icon takes you to the advertiser's page. That tilts ever so slightly toward "bad" in my book. For the reader, it's a straight-up bait and switch. For the advertiser, it's a steady stream of annoyed readers and, if it's a pay-per-click model, they get to pay for the privilege. True, there's not supposed to be any such thing as bad publicity, but still.
Friday, June 12, 2015
Sunday, May 10, 2015
OK, this is cool, and it's on the web:
Hyrodium is the pseudonym (presumably) of a Japanese student who has put together a really neat blog of visualizations of mathematical proofs and objects. Exactly the kind of thing the Web was originally supposed to be good for, and sometimes still is.
Monday, March 30, 2015
Sunday, March 22, 2015
Now available on its own domain
At least for the next year, more or less, you'll be able to reach this blog not only at fieldnotesontheweb.blogger.com, but at plain old fieldnotesontheweb.com. I doubt this will really affect anyone's life greatly, but hey, why not?
Monday, March 16, 2015
Protocol basics: Packets and connections
Not so long ago, the easiest way, and in some cases the only practical way, to get in touch with someone a long distance away was to send a message by mail. Physical mail, that is. I found it handy when traveling in Europe, um a while ago, for example. Rather than hunt down a payphone (really, spell check, you don't recognize "payphone"?), double-check that the other person was likely to be awake, buy a card or assemble the right pile of coins, dial, wait to see if the other person was actually home, and then worry about cramming a conversation into an alarmingly small number of minutes, it was often easier and more fun to buy a few postcards, scrawl "Having a lovely time, wish you were" on them, address them, stamp them and throw them in the nearest post box.
It's not that one couldn't make an international phone call, or that it was never worth it, just that it was often cheaper and easier not to.
Mail and the telephone are canonical examples of two basic ways of sending information. These two ways have gone by various names, but the two that stick in my head are "packet-switched" (mail) vs. "circuit-switched" (phone), and "connection-oriented" (phone) vs. "connectionless" (mail). Each approach has its own pros and cons and neither is perfect for every situation, which is why both are still going strong.
Connection-oriented protocols require time to set up the connection. In the case of the telephone, this means identifying the other party (dialing the number) and establishing a connection (whatever the phone company does, plus waiting for the other party to pick up). Both parties must participate in the connection at the same time. Once this is done, however, communication is efficient. I say something to you and you can reply immediately. Depending on the exact protocol, we may even be able to both talk at once ("full-duplex") or we may have to take turns ("half-duplex"), but this distinction is more important in computer protocols than human conversations (human conversations are effectively half-duplex, as anyone who's ever said "no, you go ahead" at the same time as the other person will realize).
Connectionless protocols are the mirror image of this. Setup is minimal. You only have to identify the other party and send the message. Depending on the protocol, your party may or may not have to be present to receive the message when it arrives. On the other hand, you generally don't know whether your message arrived at all, and if you send two messages to the same person, they may or may not arrive in the order you sent them, and in some cases the same message might get sent more than once (though this is not likely to happen through the mails).
Of the common ways we exchange information as people, some are connection-oriented, for example, phone calls and video conferences, and some are connectionless, such as texting and email.
The underlying protocol of most of the internet, IP (for ... wait for it ... Internet Protocol) is connectionless. You build a packet of data, slap an address on it, send it and hope for the best. Generally there is no specific connection involved, though it used to be more common (in the days of dedicated T1 lines, PLIP and such) for IP to run on top of something that happened to us a point-to-point connection at a lower level.
However, most actual applications of the internet are connection-oriented. When you browse a web page, for example, your browser uses a connection to the server serving the page. That way it doesn't care whether the page fits in a single packet (which it almost certainly doesn't) and it knows for sure when it's retrieved the entire page. Likewise, when you send mail, your mail client makes a connection to a mail server, when you join a videoconference your device makes a connection to the videoconference server, and so forth.
To bridge this gap, we use what is hands-down one of the most successful inventions in the field of computing: the Transmission Control Protocol, or TCP. TCP assumes that you have some way -- it doesn't much care what -- to deliver packets of information -- it doesn't care what's in them and doesn't much care how big they are -- to a given address. IP is one way of doing this, so you'll see the term TCP/IP for TCP using IP to transport packets, but it's not the only way.
From these basic assumptions, TCP allows you to pretend you have a direct connection to another party. If you send a series of messages to that other party, you know that either they will all arrive, in order, or the whole connection will fail and you will know it failed.
This is a big improvement over simply sending messages and hoping they arrive. The cost is that it takes time to set up a TCP connection, TCP adds extra traffic, particularly ACK (acknowledgement) messages to be sure that messages have arrived, it may have to re-send messages, and it requires each side of the connection to remember a certain amount of previous traffic. For example, if I'm sending you a bunch of data, TCP will break that down into packets, and then keep track of which packets have and haven't been acknowledged. If too many haven't been acknowledged, it will stop sending new data, slowing things down. Each side also has to keep around any packets that it's sent but hasn't had acknowledged yet, since it may have to resend them.
Since setting up connections is expensive, we try to avoid it. The worst case is establishing a fresh connection for each message to be sent. In the early days of the web, HTTP/1.0 required a fresh connection for each object retrieved. If your web page included an image, the browser would have to set up one connection to get the text of the web page, tear it down, and then set up a fresh connection to get the image, even if it was stored on the same server. HTTP/1.1 fixed this with its "keep-alive" mechanism, but the same problem comes up in other contexts, with the same solution: re-use connections where possible.
A great many "application layer" protocols are built on TCP. They all start by making a connection to a remote host and then sending messages back and forth on that connection. These include
It's not that one couldn't make an international phone call, or that it was never worth it, just that it was often cheaper and easier not to.
Mail and the telephone are canonical examples of two basic ways of sending information. These two ways have gone by various names, but the two that stick in my head are "packet-switched" (mail) vs. "circuit-switched" (phone), and "connection-oriented" (phone) vs. "connectionless" (mail). Each approach has its own pros and cons and neither is perfect for every situation, which is why both are still going strong.
Connection-oriented protocols require time to set up the connection. In the case of the telephone, this means identifying the other party (dialing the number) and establishing a connection (whatever the phone company does, plus waiting for the other party to pick up). Both parties must participate in the connection at the same time. Once this is done, however, communication is efficient. I say something to you and you can reply immediately. Depending on the exact protocol, we may even be able to both talk at once ("full-duplex") or we may have to take turns ("half-duplex"), but this distinction is more important in computer protocols than human conversations (human conversations are effectively half-duplex, as anyone who's ever said "no, you go ahead" at the same time as the other person will realize).
Connectionless protocols are the mirror image of this. Setup is minimal. You only have to identify the other party and send the message. Depending on the protocol, your party may or may not have to be present to receive the message when it arrives. On the other hand, you generally don't know whether your message arrived at all, and if you send two messages to the same person, they may or may not arrive in the order you sent them, and in some cases the same message might get sent more than once (though this is not likely to happen through the mails).
Of the common ways we exchange information as people, some are connection-oriented, for example, phone calls and video conferences, and some are connectionless, such as texting and email.
The underlying protocol of most of the internet, IP (for ... wait for it ... Internet Protocol) is connectionless. You build a packet of data, slap an address on it, send it and hope for the best. Generally there is no specific connection involved, though it used to be more common (in the days of dedicated T1 lines, PLIP and such) for IP to run on top of something that happened to us a point-to-point connection at a lower level.
However, most actual applications of the internet are connection-oriented. When you browse a web page, for example, your browser uses a connection to the server serving the page. That way it doesn't care whether the page fits in a single packet (which it almost certainly doesn't) and it knows for sure when it's retrieved the entire page. Likewise, when you send mail, your mail client makes a connection to a mail server, when you join a videoconference your device makes a connection to the videoconference server, and so forth.
To bridge this gap, we use what is hands-down one of the most successful inventions in the field of computing: the Transmission Control Protocol, or TCP. TCP assumes that you have some way -- it doesn't much care what -- to deliver packets of information -- it doesn't care what's in them and doesn't much care how big they are -- to a given address. IP is one way of doing this, so you'll see the term TCP/IP for TCP using IP to transport packets, but it's not the only way.
From these basic assumptions, TCP allows you to pretend you have a direct connection to another party. If you send a series of messages to that other party, you know that either they will all arrive, in order, or the whole connection will fail and you will know it failed.
This is a big improvement over simply sending messages and hoping they arrive. The cost is that it takes time to set up a TCP connection, TCP adds extra traffic, particularly ACK (acknowledgement) messages to be sure that messages have arrived, it may have to re-send messages, and it requires each side of the connection to remember a certain amount of previous traffic. For example, if I'm sending you a bunch of data, TCP will break that down into packets, and then keep track of which packets have and haven't been acknowledged. If too many haven't been acknowledged, it will stop sending new data, slowing things down. Each side also has to keep around any packets that it's sent but hasn't had acknowledged yet, since it may have to resend them.
Since setting up connections is expensive, we try to avoid it. The worst case is establishing a fresh connection for each message to be sent. In the early days of the web, HTTP/1.0 required a fresh connection for each object retrieved. If your web page included an image, the browser would have to set up one connection to get the text of the web page, tear it down, and then set up a fresh connection to get the image, even if it was stored on the same server. HTTP/1.1 fixed this with its "keep-alive" mechanism, but the same problem comes up in other contexts, with the same solution: re-use connections where possible.
A great many "application layer" protocols are built on TCP. They all start by making a connection to a remote host and then sending messages back and forth on that connection. These include
- HTTP and HTTPS, the fundamental protocols of the web
- SMTP, POP and IMAP, used for email
- SSL/TLS, for making secure connections to other hosts (HTTPS is essentially HTTP using SSL/TLS)
- SSH, also used for making secure connections to other hosts
- FTP, SFTP and FTPS, used for transferring files (technically, SFTP is built on SSH, which is in turn built on TCP)
- XMPP, one way of sending short messages like texts
- Any number of special purpose protocols developed over the years
Several of these (particularly SSH and HTTP) allow for "tunneling" of TCP, meaning you can establish a TCP connection on top of SSH or TCP, which will in turn be using a different TCP connection. There are actually legitimate reasons to do this.
To bring things full circle, email protocols and file transfer protocols are essentially packet protocols, just with nicer addresses and bigger packets. You could, in principle, use them as an underlying protocol for TCP. This would be hugely inefficient for a number of reasons. Among others, you'd generally be paying the cost of setting up a connection for each "packet", which is pretty much the worst of both worlds ... but it's certainly possible. In a more abstract way, an email thread is essentially an ad-hoc connection on top of email (packets), which in turn is delivered via TCP (connection), which in turn (generally) uses IP (packets).
Thursday, January 1, 2015
Bitcoin: Volume matters
It's easy to get fixated on prices, particularly if the price you're interested in keeps going up and up and up (or down and down and down). In early December of 2013, for example, when Bitcoin was trading over $1000 with no limit in sight, the only logical conclusion was that it would soon take over the world.
Since then, the dollar price of BTC has fallen into the 300s. Considering that the famous 10,000 BTC pizza would be $3 million at today's prices (if just a bit stale), that's still pretty good. On the other hand, it's around a quarter of the peak price.
The exact exchange rate between BTC and reserve currencies shouldn't really matter greatly, though, so long as it's reasonably stable and there's enough money supply to handle whatever it is BTC is being used for. But what about volume? How much BTC is changing hands on a given day? How much Bitcoin, measured in dollars or some other reserve currency, is there in all?
As an aside, there's a whole body of established techniques for using volume in conjunction with price to make buying and selling decisions. I won't even pretend to know much about that. I'm more interested in how Bitcoin stacks up against other currencies (if you consider it a currency) and money transfer networks (if you consider it that).
According to bitcoincharts.com, around half a million Bitcoins are "sent" daily, or about $150 million worth at current prices. I believe this is taken from the blockchain that records all Bitcoin transactions, and so would include activity on the various exchanges, miners collecting and redeeming their bounties, direct transfers of BTC to and from long-term holdings (the "pure" Bitcoin economy) and whatever else.
If I buy a Bitcoin for $320 or whatever, that would show up as one Bitcoin sent to me from the exchange, and if I use that Bitcoin to pay you for some good or service, that would in turn show up as one Bitcoin sent to you, and if you turn around and sell that Bitcoin for $320, that's another Bitcoin sent, to the exchange from you. In other words, a typical transaction using Bitcoin as an intermediary between reserve currencies will be counted three times. If we want to consider Bitcoin as a money transfer network, we should probably allow for some amount of non money-transfer activity, then divide by three, but in what follows let's count all $150 million, if only because it's simpler.
The Bitcoin money supply is deliberately easy to calculate. While there are several measures of "how many dollars are there?", the total number of Bitcoins at any given time is a known parameter of the protocol. Currently, the BTC money supply is about 14 million, or $4 billion.
By contrast:
Since then, the dollar price of BTC has fallen into the 300s. Considering that the famous 10,000 BTC pizza would be $3 million at today's prices (if just a bit stale), that's still pretty good. On the other hand, it's around a quarter of the peak price.
The exact exchange rate between BTC and reserve currencies shouldn't really matter greatly, though, so long as it's reasonably stable and there's enough money supply to handle whatever it is BTC is being used for. But what about volume? How much BTC is changing hands on a given day? How much Bitcoin, measured in dollars or some other reserve currency, is there in all?
As an aside, there's a whole body of established techniques for using volume in conjunction with price to make buying and selling decisions. I won't even pretend to know much about that. I'm more interested in how Bitcoin stacks up against other currencies (if you consider it a currency) and money transfer networks (if you consider it that).
According to bitcoincharts.com, around half a million Bitcoins are "sent" daily, or about $150 million worth at current prices. I believe this is taken from the blockchain that records all Bitcoin transactions, and so would include activity on the various exchanges, miners collecting and redeeming their bounties, direct transfers of BTC to and from long-term holdings (the "pure" Bitcoin economy) and whatever else.
If I buy a Bitcoin for $320 or whatever, that would show up as one Bitcoin sent to me from the exchange, and if I use that Bitcoin to pay you for some good or service, that would in turn show up as one Bitcoin sent to you, and if you turn around and sell that Bitcoin for $320, that's another Bitcoin sent, to the exchange from you. In other words, a typical transaction using Bitcoin as an intermediary between reserve currencies will be counted three times. If we want to consider Bitcoin as a money transfer network, we should probably allow for some amount of non money-transfer activity, then divide by three, but in what follows let's count all $150 million, if only because it's simpler.
The Bitcoin money supply is deliberately easy to calculate. While there are several measures of "how many dollars are there?", the total number of Bitcoins at any given time is a known parameter of the protocol. Currently, the BTC money supply is about 14 million, or $4 billion.
By contrast:
- About 100 nations have more than $4 billion in currency
- The US M1 money supply is around $2 trillion, or about 500 times the Bitcoin money supply
- The US M2 money supply is around $12 trillion, or about 3000 times the Bitcoin money supply
- The US GDP is close to $50 billion per day, or about 300 times total Bitcoin activity (1000 times or more if you buy the triple-counting argument above)
- VISA processes about $9 billion in transactions every day, or about 60 times total Bitcoin activity (or about 200+ with triple-counting)
and so forth.
I'm actually struck that the Bitcoin economy, or whatever you want to call it, is as big as it is. There may be 100 countries with more money, but there are also 50 or so with less. You could literally run a small country on Bitcoin. I'm not saying it would be good policy, but in some sense the numbers are there. A small fraction of US GDP is still a fair bit, as is a small fraction of Visa. For a while Bitcoin was arguably bigger than Western Union. Your call whether that's a matter of Bitcoin being big, WU being small, or some of both.
The main point remains: If you want to get an idea of how important Bitcoin might be, don't look at the price alone. Look at volume as well.
Tuesday, December 30, 2014
That CAPTCHA moved!
While recovering a password for a site -- that is, my real password was whatever information the recovery page needed -- I noticed a new wrinkle on CAPTCHA: Moving CAPTCHA. Instead of the usual smeared-out or obscured letters, three plainly readable letters, somewhat tilted, on a clearly contrasting background, but wiggling slightly back and forth.
Seems like an interesting step in the whole OCR arms race, except ...
The problem for an attacker to solve here isn't recognizing a moving character, which might or might not be harder than recognizing a still one. It's grabbing a frame of the animation to examine. If you can do that at all, then recognizing one particular arrangement of the letters is no harder than recognizing any other CAPTCHA. Easier, in fact, since you have nice, legible letters, and you can re-run the OCR on each frame and go with the consensus.
Again, I haven't looked at this in detail, but there would seem to be two main ways of putting the moving image up in the first place: A .gif or other animated image format, which is no problem to decode into its images, or some sort of JavaScript animation. That might be harder to grab, but not because of the animation. You can just as well use JavaScript to put up a still image, and in either case the answer is to render the JavaScript and then grab the pixels.
In other words, it seems unlikely that the moving image adds any real difficulty for an attacker. It does look harder, intuitively, to the human eye, but the attacker isn't using a human eye -- that's the whole point of the exercise to begin with.
Seems like an interesting step in the whole OCR arms race, except ...
The problem for an attacker to solve here isn't recognizing a moving character, which might or might not be harder than recognizing a still one. It's grabbing a frame of the animation to examine. If you can do that at all, then recognizing one particular arrangement of the letters is no harder than recognizing any other CAPTCHA. Easier, in fact, since you have nice, legible letters, and you can re-run the OCR on each frame and go with the consensus.
Again, I haven't looked at this in detail, but there would seem to be two main ways of putting the moving image up in the first place: A .gif or other animated image format, which is no problem to decode into its images, or some sort of JavaScript animation. That might be harder to grab, but not because of the animation. You can just as well use JavaScript to put up a still image, and in either case the answer is to render the JavaScript and then grab the pixels.
In other words, it seems unlikely that the moving image adds any real difficulty for an attacker. It does look harder, intuitively, to the human eye, but the attacker isn't using a human eye -- that's the whole point of the exercise to begin with.
Tuesday, September 30, 2014
Heartbleed, Shellshock and Raymond's Linus's Law
You have probably heard by now that bash, one of the basic tools in the Linux/GNU toolkit, has had a glaring vulnerability for the last, oh, twenty-plus years, now deemed Shellshock. You've probably also heard of the Heartbleed vulnerability in OpenSSL. Apart from making international press and raising serious questions about computer security, these two bugs have a number of features in common:
In any case, despite bash and OpenSSL being two of the most widely used tools in the software world, these basic and serious bugs don't seem to have been flushed out quickly at all. Now, it is possible that multiple people noticed the problems, shrugged and went on with their lives, or that some entity or another discovered the bugs and exploited them very quietly, but that's not how Raymond's Linus's law is supposed to work.
I think there are two reasons for this.
First, as many have pointed out, there's no convincing evidence that more eyeballs really do mean more bugs found. Rather, it seems that you quickly hit diminishing returns. Four people may or may not find about twice as many bugs as two people, but forty people probably won't find twice as many bugs as twenty. Forty people may not even find twice as many bugs as two.
Exactly why this might be is a good research topic, but I'd guess that a lot of it is because some bugs are easy to find, some aren't, and once you've found the easy bugs throwing more eyeballs at the problem (now there's an image) won't necessarily help find the hard bugs.
One of the sobering implications of Shellshock and Heartbleed is that even simple bugs can be hard to find, but that's not news to anyone who's done much coding.
I think there's a second reason, though, more subtle than the first but worth noting: There probably aren't really that many eyeballs on the source code to begin with.
In theory, millions of people could have found either of these two bugs. If you've installed Linux, you have the bash and OpenSSL source code, or if you didn't copy it, you can easily get at it. Odds are you didn't, though, unless you were actively developing one of those packages. Why would you? I use Linux systems all the time. I don't want to study the source code. I just want it to work. I have looked at various parts of the Linux/GNU source, but generally just to see how it worked, not with a particular eye toward finding bugs. Maybe that makes me a bad net.citizen, but if so, I'm pretty sure I'm in good company.
OK, but there have still been hundreds of contributors to each of those projects. Surely one of them would have seen the problem code and fixed it? Not necessarily. A tool like bash consists of a large number of modules (more or less), and the whole point of breaking things down into modules is that you can work on one without caring (much) about (many of) the others. Someone who worked on job control in bash would not necessarily have even looked at the environment variable parsing, which is where the problem actually was.
In other words, there might only have been a handful of people who even had the opportunity to find Shellshock or Heartbleed in the source code, and they didn't happen to spot the problems, probably because they were trying to get something else done at the time.
There's another kind of eyeball, though: testers. Even if only a few people were looking closely at the source, lots of people actually use bash, OpenSSL and other open-source tools.
Fair enough, but again, their attention is not necessarily focused where the bugs are. Most people logging into a Linux box and using bash are not going to be defining functions in environment variables. Most script writers aren't either (though git, headed by Linus himself, seems to like to). It's a moderately tricky thing to do. Likewise, almost no one using OpenSSL is even going to be in a position to look at heartbeat packets. Most of us don't even know if we're using OpenSSL or not, though if you've visited an https:// URL, you probably have.
In short, Raymond's implicit assumption that bug-finding is a matter of many independent trials, in the statistical sense, evenly distributed over the space of all possible bugs, looks to be wrong on both counts: "many" and "independent".
[The current Wikipedia article on Linus's law cites Robert Glass's Facts and Fallacies about Software Engineering, which made similar observations in 2003, over a decade before this was posted. It also no longer seems to mention any version of Linus's law due to Linus himself. That was removed in this edit --D.H. Oct 2018]
- They're implementation bugs. Bash, as defined in its documentation, does not allow the sort of behavior that Shellshock allows, and likewise for SSL (the protocol) and OpenSSL (an implementation of SSL). In both cases, the implementations were doing things they shouldn't have.
- They're basic implementation bugs. In Shellshock, text which should be ignored or discarded is instead interpreted as a command. In Heartbleed, a reply message which is supposed to have a given length instead has another.
- No one noticed them for a long time. In the case of shellshock, a very long time. Or at least, no one seems to have visibly exploited them.
In any case, despite bash and OpenSSL being two of the most widely used tools in the software world, these basic and serious bugs don't seem to have been flushed out quickly at all. Now, it is possible that multiple people noticed the problems, shrugged and went on with their lives, or that some entity or another discovered the bugs and exploited them very quietly, but that's not how Raymond's Linus's law is supposed to work.
I think there are two reasons for this.
First, as many have pointed out, there's no convincing evidence that more eyeballs really do mean more bugs found. Rather, it seems that you quickly hit diminishing returns. Four people may or may not find about twice as many bugs as two people, but forty people probably won't find twice as many bugs as twenty. Forty people may not even find twice as many bugs as two.
Exactly why this might be is a good research topic, but I'd guess that a lot of it is because some bugs are easy to find, some aren't, and once you've found the easy bugs throwing more eyeballs at the problem (now there's an image) won't necessarily help find the hard bugs.
One of the sobering implications of Shellshock and Heartbleed is that even simple bugs can be hard to find, but that's not news to anyone who's done much coding.
I think there's a second reason, though, more subtle than the first but worth noting: There probably aren't really that many eyeballs on the source code to begin with.
In theory, millions of people could have found either of these two bugs. If you've installed Linux, you have the bash and OpenSSL source code, or if you didn't copy it, you can easily get at it. Odds are you didn't, though, unless you were actively developing one of those packages. Why would you? I use Linux systems all the time. I don't want to study the source code. I just want it to work. I have looked at various parts of the Linux/GNU source, but generally just to see how it worked, not with a particular eye toward finding bugs. Maybe that makes me a bad net.citizen, but if so, I'm pretty sure I'm in good company.
OK, but there have still been hundreds of contributors to each of those projects. Surely one of them would have seen the problem code and fixed it? Not necessarily. A tool like bash consists of a large number of modules (more or less), and the whole point of breaking things down into modules is that you can work on one without caring (much) about (many of) the others. Someone who worked on job control in bash would not necessarily have even looked at the environment variable parsing, which is where the problem actually was.
In other words, there might only have been a handful of people who even had the opportunity to find Shellshock or Heartbleed in the source code, and they didn't happen to spot the problems, probably because they were trying to get something else done at the time.
There's another kind of eyeball, though: testers. Even if only a few people were looking closely at the source, lots of people actually use bash, OpenSSL and other open-source tools.
Fair enough, but again, their attention is not necessarily focused where the bugs are. Most people logging into a Linux box and using bash are not going to be defining functions in environment variables. Most script writers aren't either (though git, headed by Linus himself, seems to like to). It's a moderately tricky thing to do. Likewise, almost no one using OpenSSL is even going to be in a position to look at heartbeat packets. Most of us don't even know if we're using OpenSSL or not, though if you've visited an https:// URL, you probably have.
In short, Raymond's implicit assumption that bug-finding is a matter of many independent trials, in the statistical sense, evenly distributed over the space of all possible bugs, looks to be wrong on both counts: "many" and "independent".
[The current Wikipedia article on Linus's law cites Robert Glass's Facts and Fallacies about Software Engineering, which made similar observations in 2003, over a decade before this was posted. It also no longer seems to mention any version of Linus's law due to Linus himself. That was removed in this edit --D.H. Oct 2018]
Wednesday, July 16, 2014
Protocol basics -- heartbeats, pings and acks
For no particular reason, I thought I'd start an occasional series on the basics of computer protocols such as those, like TCP and HTTP, that the web is built on. Also for no particular reason, the basic principle that came to mind first is the idea of heartbeats.
But first, what's a protocol?
The word itself derives from Greek protos (first) and kolla (glue), so that ought to be clear enough.
No?
The trail is something like: prōtokollon really refers to the first draft of an official agreement (the first one glued into a binding), and thence more generally to an official set of rules and procedures, and thence finally to the computing meaning: A set of rules for exchanging messages between computers (often called hosts).
One of the most basic problems in computer protocols is determining whether the other party is there or not. How hard can that be, right?
Unlike the physical world, you can't just look. All you have is some means of sending messages, typically a relay of several steps mixing wired and wireless transmission, high-volume and low-volume connections, and so forth. I'll go into deeper detail in some later post, but the point is that all you can do is send a message, and any particular message might or might not arrive at its destination in any particular amount of time.
One simple way to tell if the other party is there is just to ask. Send a message saying "If you get this, please send it back to me." You send that message, the other host sends back a reply and voila, you know they're there.
This is a perfectly good approach. The first message is generally called a ping, probably taken from SONAR terminology, and the reply packet is generally called an ack (or ACK), short for "acknowledgement". (There's also such a thing as a nack ( or NAK), short for "negative acknowledgement", which means "yes, I got that, but I couldn't understand it," or "yes, I got that, but you're sending me messages too fast, so please stop for a bit". I'll admit to occasionally having said "NAK" in response to an explanation that went over my head.)
But what if you don't get your ack? Is your connection bad? Has the other host crashed? Did it receive your ping but fail to reply? Did it reply, but the return connection was bad? How long should you wait before you decide that the ack isn't coming?
To help get around problems like this, you can send a series of pings and listen for a series of acks. To help tell what's going on, you can number them so you can match the acks to the pings. If the connection is flaky, you might miss an ack from time to time, but overall if the other host is there and you have at least some sort of connection, you'll get at least some acks back.
You might even have the other host tell you how many pings it's heard. That will give you some idea of whether any problems are on the outbound connection, inbound connection, or both. For example, if the return connection is bad but the outbound connection is fine, you'll hear something like "Ack for ping 1, I've heard 1 ping", "Ack for ping 3, I've heard 3 pings" ... If you hear "Ack for ping 3, I've heard 2 pings", you know that it missed ping 2. Most bad connections will affect both directions, but that doesn't have to always be the case -- the other host's network layer is part of the incoming connection, and it's possible that it's able to send messages but sometimes has trouble hearing them.
If the other host crashes and restarts, you might hear something like "Ack for ping 1, I've heard 1 ping", "Ack for ping 2, I've heard two pings", and then eventually, once the other host is up again,"Ack for ping 50, I've heard 1 ping". This may or may not be useful information. It's a basic principle of networking that during that eerie silence, there's no way to know whether the other host is crashing and restarting, the network is down, the other host is running slowly, there's a bug in whatever's handling the pings, the network is up but messages are being delayed, or whatever.
By the point you hear back that the rebooted host has only heard one ping, you may not greatly care. You can't begin to figure out what's going on until you get a message from the other host, and even then what you can deduce depends on the exact messages, that is, on the protocol. On the other hand, you can decide that if you haven't heard replies for N pings in a row, something is wrong. That's often a good bet, but you have to be prepared for the possibility that things are just slow and the other host was there all along.
In some kinds of network, messages are always sent to everyone who could be listening. In most such cases, the networking layer will filter out messages that aren't addressed to a particular system, but it's also possible to mark them "broadcast", meaning that everyone should listen. In such setups, a broadcast ping is a good way to find out who's on the network. This process is called discovery, and since not all networks have broadcasting built in, there are discovery protocols for networks that don't.
If you're having an actual conversation with another host, say, sending requests and getting replies, you're automatically pinging and acking. However, you may reach a point where you don't have anything to say at the moment, but you want the other host to know you're still there. In that case, you could send a ping, either as a do-nothing request or as a special kind of message. It doesn't much matter which, so long as you and the other host agree on the protocol. Such a message is generally called a keep-alive, since it's meant to keep the hosts from killing the connection (which basically means forgetting about it) on the assumption the other has gone away.
In some cases, only one host cares if the other is there. For example, imagine a weather station where the main host is listening for data coming from a bunch of sensors -- thermometer, anemometer, hygrometer, manometer, and so forth. It's fine for the sensors to blindly send out their information no matter what, but the main host would like to be able to report if a sensor is faulty. Or in an even simpler example, you just want to know if another host is there at all, without needing it to send you any particular information.
In such cases, you shouldn't have to ping (and you might not even be able to, for example if the sensors have transmitters but no receivers), but you want the things you're monitoring to send acks regularly as though you had. You can then decide that if you miss N messages, you'll report a problem. Since they're not actually acknowledging anything, such a message is generally called a heartbeat rather than an ack.
In fact, any series of regular messages meant to determine if a host is present or not can be called a heartbeat. The heartbeats in the famous heartbleed bug, for example, were a series of pings and acks. The bug was that a badly constructed ping would cause the ack to contain information that shouldn't have been there.
This post has turned out longer than I expected. I had expected to write a couple of paragraphs about heartbeats, but to get there I ended up delving a bit deeper. As is often the case, there's more to even the simple pieces than might meet the eye. I would like to make one last point, though. Heartbeats, pings, acks and indeed most of the basics of computer protocols, have been around much longer than computers. It would be interesting to hunt down early examples, but one that springs to mind is a team on an isolated, dangerous mission agreeing to send out regular radio messages. If some number don't arrive, send in the rescue squad (or just assume the mission has, sadly, failed).
The basic idea of "make a noise if you're still here" is, of course, considerably older than radio.
But first, what's a protocol?
The word itself derives from Greek protos (first) and kolla (glue), so that ought to be clear enough.
No?
The trail is something like: prōtokollon really refers to the first draft of an official agreement (the first one glued into a binding), and thence more generally to an official set of rules and procedures, and thence finally to the computing meaning: A set of rules for exchanging messages between computers (often called hosts).
One of the most basic problems in computer protocols is determining whether the other party is there or not. How hard can that be, right?
Unlike the physical world, you can't just look. All you have is some means of sending messages, typically a relay of several steps mixing wired and wireless transmission, high-volume and low-volume connections, and so forth. I'll go into deeper detail in some later post, but the point is that all you can do is send a message, and any particular message might or might not arrive at its destination in any particular amount of time.
One simple way to tell if the other party is there is just to ask. Send a message saying "If you get this, please send it back to me." You send that message, the other host sends back a reply and voila, you know they're there.
This is a perfectly good approach. The first message is generally called a ping, probably taken from SONAR terminology, and the reply packet is generally called an ack (or ACK), short for "acknowledgement". (There's also such a thing as a nack ( or NAK), short for "negative acknowledgement", which means "yes, I got that, but I couldn't understand it," or "yes, I got that, but you're sending me messages too fast, so please stop for a bit". I'll admit to occasionally having said "NAK" in response to an explanation that went over my head.)
But what if you don't get your ack? Is your connection bad? Has the other host crashed? Did it receive your ping but fail to reply? Did it reply, but the return connection was bad? How long should you wait before you decide that the ack isn't coming?
To help get around problems like this, you can send a series of pings and listen for a series of acks. To help tell what's going on, you can number them so you can match the acks to the pings. If the connection is flaky, you might miss an ack from time to time, but overall if the other host is there and you have at least some sort of connection, you'll get at least some acks back.
You might even have the other host tell you how many pings it's heard. That will give you some idea of whether any problems are on the outbound connection, inbound connection, or both. For example, if the return connection is bad but the outbound connection is fine, you'll hear something like "Ack for ping 1, I've heard 1 ping", "Ack for ping 3, I've heard 3 pings" ... If you hear "Ack for ping 3, I've heard 2 pings", you know that it missed ping 2. Most bad connections will affect both directions, but that doesn't have to always be the case -- the other host's network layer is part of the incoming connection, and it's possible that it's able to send messages but sometimes has trouble hearing them.
If the other host crashes and restarts, you might hear something like "Ack for ping 1, I've heard 1 ping", "Ack for ping 2, I've heard two pings", and then eventually, once the other host is up again,
In some kinds of network, messages are always sent to everyone who could be listening. In most such cases, the networking layer will filter out messages that aren't addressed to a particular system, but it's also possible to mark them "broadcast", meaning that everyone should listen. In such setups, a broadcast ping is a good way to find out who's on the network. This process is called discovery, and since not all networks have broadcasting built in, there are discovery protocols for networks that don't.
If you're having an actual conversation with another host, say, sending requests and getting replies, you're automatically pinging and acking. However, you may reach a point where you don't have anything to say at the moment, but you want the other host to know you're still there. In that case, you could send a ping, either as a do-nothing request or as a special kind of message. It doesn't much matter which, so long as you and the other host agree on the protocol. Such a message is generally called a keep-alive, since it's meant to keep the hosts from killing the connection (which basically means forgetting about it) on the assumption the other has gone away.
In some cases, only one host cares if the other is there. For example, imagine a weather station where the main host is listening for data coming from a bunch of sensors -- thermometer, anemometer, hygrometer, manometer, and so forth. It's fine for the sensors to blindly send out their information no matter what, but the main host would like to be able to report if a sensor is faulty. Or in an even simpler example, you just want to know if another host is there at all, without needing it to send you any particular information.
In such cases, you shouldn't have to ping (and you might not even be able to, for example if the sensors have transmitters but no receivers), but you want the things you're monitoring to send acks regularly as though you had. You can then decide that if you miss N messages, you'll report a problem. Since they're not actually acknowledging anything, such a message is generally called a heartbeat rather than an ack.
In fact, any series of regular messages meant to determine if a host is present or not can be called a heartbeat. The heartbeats in the famous heartbleed bug, for example, were a series of pings and acks. The bug was that a badly constructed ping would cause the ack to contain information that shouldn't have been there.
This post has turned out longer than I expected. I had expected to write a couple of paragraphs about heartbeats, but to get there I ended up delving a bit deeper. As is often the case, there's more to even the simple pieces than might meet the eye. I would like to make one last point, though. Heartbeats, pings, acks and indeed most of the basics of computer protocols, have been around much longer than computers. It would be interesting to hunt down early examples, but one that springs to mind is a team on an isolated, dangerous mission agreeing to send out regular radio messages. If some number don't arrive, send in the rescue squad (or just assume the mission has, sadly, failed).
The basic idea of "make a noise if you're still here" is, of course, considerably older than radio.
Saturday, June 21, 2014
The disappearing (and reappearing) profile photo
Recently I noticed that my profile photo was broken (I've since fixed it). "That's odd", I thought, "I uploaded it quite a while ago. Maybe there's some glitch in Blogger's servers." I kept checking, figuring it should come back before too long, but it didn't. So I went to my Blogger profile to see what had happened to the image, and discovered that the URL I had given was broken.
I don't remember why I'd given a URL instead of just uploading an image. Maybe I didn't have a copy of the image handy. Maybe I just thought it was "webbier" to give a URL, but never mind. Easily fixed. I hunted up another copy of the image and uploaded it ... and we're back!
What's interesting, though, was that the URL pointed at Technorati, whose probably-no-more-tangled-than-usual history I've touched on before. So I checked. Technorati is still a thing, albeit clearly not one I personally pay much attention to. Evidently they've redone their infrastructure a bit, or perhaps just cleaned out inactive accounts, causing the link to finally rot after however many years it's been since I first put it on my profile.
Links rot. That's just part of the web. In fact, it's a key architectural decision behind the web (as opposed to, say, Xanadu). It would be interesting, though, to study which links rot, and when, and why.
In the case of my profile photo, a link to an obscure corner of Technorati, linked to a completely inactive account associated with a little-read blog, remained stable for years until, one day, it disappeared. This is probably not too uncommon, but nonetheless I'd expect link rot to become less common over time.
In the old days, people would put up web sites on their personal computers, or on the workstation in their lab, and so forth. They would get tired of the hassle of hosting the site, or graduate, or whatever, and the site would go away. That's largely been replaced by web hosting services, but even then sites go away all the time as people get tired of paying for them and maintaining them.
However, a larger and larger portion of content is now being hosted by companies like Facebook, YouTube, Google, Twitter and so forth, or by major media outlets, which at least implicitly promise to maintain the content in perpetuity. "Perpetuity" is rather better defined in theory than in practice, but I have a high degree of confidence that links to this blog will still work ten years from now, probably twenty and quite possibly fifty.
Will someone living a thousand years from now be able to read Field Notes? I have no idea. The odds of Google (or any of the other present-day giants) still being around in a thousand years are fairly small, but the likelihood of it costing peanuts to maintain everything that's ever been published on Blogger are pretty good, so who knows?
What does seem likely is that the bulk of "user-created content" will remain accessible as long as there is a web more or less like the present one for it to be part of. If that's right, then the main sources of link rot will probably be companies folding and taking their sites down, or content owners deciding to take older content down or hide it behind paywalls or similar actions. In other words, links are probably less likely to rot due to inattention or Life Happening to the particular person who created them in the first place, and more likely to happen due to explicit decisions by corporate entities.
I don't remember why I'd given a URL instead of just uploading an image. Maybe I didn't have a copy of the image handy. Maybe I just thought it was "webbier" to give a URL, but never mind. Easily fixed. I hunted up another copy of the image and uploaded it ... and we're back!
What's interesting, though, was that the URL pointed at Technorati, whose probably-no-more-tangled-than-usual history I've touched on before. So I checked. Technorati is still a thing, albeit clearly not one I personally pay much attention to. Evidently they've redone their infrastructure a bit, or perhaps just cleaned out inactive accounts, causing the link to finally rot after however many years it's been since I first put it on my profile.
Links rot. That's just part of the web. In fact, it's a key architectural decision behind the web (as opposed to, say, Xanadu). It would be interesting, though, to study which links rot, and when, and why.
In the case of my profile photo, a link to an obscure corner of Technorati, linked to a completely inactive account associated with a little-read blog, remained stable for years until, one day, it disappeared. This is probably not too uncommon, but nonetheless I'd expect link rot to become less common over time.
In the old days, people would put up web sites on their personal computers, or on the workstation in their lab, and so forth. They would get tired of the hassle of hosting the site, or graduate, or whatever, and the site would go away. That's largely been replaced by web hosting services, but even then sites go away all the time as people get tired of paying for them and maintaining them.
However, a larger and larger portion of content is now being hosted by companies like Facebook, YouTube, Google, Twitter and so forth, or by major media outlets, which at least implicitly promise to maintain the content in perpetuity. "Perpetuity" is rather better defined in theory than in practice, but I have a high degree of confidence that links to this blog will still work ten years from now, probably twenty and quite possibly fifty.
Will someone living a thousand years from now be able to read Field Notes? I have no idea. The odds of Google (or any of the other present-day giants) still being around in a thousand years are fairly small, but the likelihood of it costing peanuts to maintain everything that's ever been published on Blogger are pretty good, so who knows?
What does seem likely is that the bulk of "user-created content" will remain accessible as long as there is a web more or less like the present one for it to be part of. If that's right, then the main sources of link rot will probably be companies folding and taking their sites down, or content owners deciding to take older content down or hide it behind paywalls or similar actions. In other words, links are probably less likely to rot due to inattention or Life Happening to the particular person who created them in the first place, and more likely to happen due to explicit decisions by corporate entities.
Return of the cow clicker
I've previously written about Cow Clicker, a Facebook game in which players would click on an image of a cow, and later just the space where a cow had once been, thereby sending a message to all their friends that they had done so. While not a runaway hit, Cow Clicker did manage to attract some 50,000 users, some portion of whom paid real money for the privilege of clicking more often, or on a fancier cow (Bling Cow could be yours for only $100).
The idea behind Cow Clicker was to reduce social gaming to its barest elements, partly as parody and partly as a study of social gaming behavior. Fast forward a few years, and someone has done the same thing for mobile phone apps. The Yo app will send a message to any of your contacts saying, simply "yo". Unlike Cow Clicker, Yo has attracted hundreds of thousands of users so far, who have already sent millions of yos.
This popularity has had two not-too-shocking consequences. On the one hand, it has attracted $1 million in funding. On the other hand, it has been hacked.
Actually, the hack doesn't seem so much a hack as a matter of the app leaking confidential information and someone noticing it. Three college students using the app were able to get the personal phone number of the founder, text him and get a call back.
What does it all mean? Anyone who thinks it means the end of civilization as we know it is forgetting that civilization as we know it produced the tulip mania, phone booth packing, pet rocks and any number of other major and minor follies. Nor can it possibly be surprising that an app, however trivial, that could gather hundreds of thousands of users in short order might attract investment money. Whether or not you believe that the attention economy is anything new or different, getting people's attention is potentially worth money ... "This Yo brought to you by Spümcø".
Somewhat more concerning, though still not surprising, is that even a simple app like Yo would leak confidential information. Security in applications of all kinds is still something you have to build in, or at least you can't assume that your app is secure just because you haven't done anything to make it insecure. To some extent this is a hard problem. Any useful app will involve some form of communication, and any communication exposes information, even if it's only who's communicating with whom (which can reveal much more than you might think).
It's been a couple of years since Cow Clicker's heyday. Most likely the ruckus about Yo will die down and in another few years another minimal app will take its place. Sic transit gloria mundi.
The idea behind Cow Clicker was to reduce social gaming to its barest elements, partly as parody and partly as a study of social gaming behavior. Fast forward a few years, and someone has done the same thing for mobile phone apps. The Yo app will send a message to any of your contacts saying, simply "yo". Unlike Cow Clicker, Yo has attracted hundreds of thousands of users so far, who have already sent millions of yos.
This popularity has had two not-too-shocking consequences. On the one hand, it has attracted $1 million in funding. On the other hand, it has been hacked.
Actually, the hack doesn't seem so much a hack as a matter of the app leaking confidential information and someone noticing it. Three college students using the app were able to get the personal phone number of the founder, text him and get a call back.
What does it all mean? Anyone who thinks it means the end of civilization as we know it is forgetting that civilization as we know it produced the tulip mania, phone booth packing, pet rocks and any number of other major and minor follies. Nor can it possibly be surprising that an app, however trivial, that could gather hundreds of thousands of users in short order might attract investment money. Whether or not you believe that the attention economy is anything new or different, getting people's attention is potentially worth money ... "This Yo brought to you by Spümcø".
Somewhat more concerning, though still not surprising, is that even a simple app like Yo would leak confidential information. Security in applications of all kinds is still something you have to build in, or at least you can't assume that your app is secure just because you haven't done anything to make it insecure. To some extent this is a hard problem. Any useful app will involve some form of communication, and any communication exposes information, even if it's only who's communicating with whom (which can reveal much more than you might think).
It's been a couple of years since Cow Clicker's heyday. Most likely the ruckus about Yo will die down and in another few years another minimal app will take its place. Sic transit gloria mundi.
Subscribe to:
Posts (Atom)
