The 40 hour work week

Before 1900 the average American worker worked more than 60 hours a week. A standard schedule was ten-hour days, six days a week. The only structural limits to working were lighting and religion. You stopped working when it was too dark to see or to go to church. It was exhausting. It was often fatal. —Collaborative Fund

The 40 hour work week is foremost a result of the physical limits of the human body—but we often fail to take into account the mental limits, as well. Why was working for more than 40 hours a week on a railroad dangerous? It was not just because people were physically tired, but also because they were mentally tired. The resulting discussion among coders has been rampant and widespread (see, for instance, here).

First, the focus on time and the length of the work week may be a little misdirected. We are still a world focused on physical presence as a proxy for accomplishing work. I know a lot of companies prefer to have people in the office—ironically, this is a big deal with most of the companies in the world that aim to bring networks, and network based services, to the masses. Try to get a job at any of the large cloud providers, and even many of the network equipment vendors. Good luck if you do not live within a 50 mile circle drawn around Silicon Valley, or are not willing to move there.

But is physical presence really “all that?” Having been on both functional and dysfunctional teams that are physically collocated and physically disjoint, my experience is that it is the attitude and culture that counts, rather than the physical presence. If the entire team focuses on communicating (and learning to communicate) in ways that are non-linear, and keeping everyone involved, physically disjoint teams can work.

Second, I don’t find it’s always best to “do nothing” to think better thoughts. Rather, I find it better to switch tasks—to think about something else, whatever that something else might be. It is rare that I have any free time during any day at this point, but moving from writing about networks to reading about philosophy is tremendously helpful in recharging my ability to write about networking topics.

“Being a little bit underemployed” sounds ideal, of course—but I am not convinced it is a realistic alternative—or maybe we just live in a world where 40 hours a week is a “little bit unemployed” for most people.

OneLogin and Password Managers

An interesting incident this last week brings password managers back to the front of the pile—

OneLogin, an online service that lets users manage logins to sites and apps from a single platform, says it has suffered a security breach in which customer data was compromised, including the ability to decrypt encrypted data. —Krebs on Security

I used to use LastPass, but moved off of their product/service when LogMeIn bought them—my previous encounters with LogMeIn have all been negative, and I have no intention of using their service again in any form. During that move, I decided it was important to make another decision about the tradeoff between an online (cloud based) password manager, or one that keeps information in a local file. The key problem with cloud based services of this kind are they paint a huge target onto your passwords. The counter argument is that such cloud based services are more likely to protect your passwords than you are, because they focus their time and energy on doing so.

First lesson: moving to a cloud based application does not mean moving to a situation where the cloud provider actually knows what you are storing, nor how to access it. In some situations, storing the data in the cloud, and the data format and encryption someplace else, is a good way to build in more layers of security.

I settled on a compromise—a password manager that stores the file in a cloud based storage service, specifically Enpass. This still isn’t the perfect solution, of course—one thing I need to do is to move my cloud storage of my password file to a more secure cloud solution, something I am still thinking through. the biggest issue here is answering the question: how often do I really use my password vault on mobile devices? I am finding the answer to this question is not very often. Further, I still refuse to install any of the extensions on my browsers that will “autofill” anything. It only takes a second to copy/paste the needed fields.

Second lesson: convenience is nice, but you always give up something for convenience. In other words, everything is a tradeoff. If you haven’t found the tradeoff, you simply have not looked hard enough. There are many times where the convenience added is simply not worth the additional risks—but we rarely think in these terms.

Open Networking for Large-Scale Networks

Shawn Zandi and I recently recorded a new webinar for Ivan over at around open source and disaggregated networking. If you have ever wanted to find out about these topics, this webinar is a great place to start in understanding what options are available, and how easy/hard it is to get this kind of thing running.

The webinar is available here.

Ethereum: The “Next New Internet?”

According to this article, we now have a new Internet being developed: Ethereum (thanks to Chase Mitchell, one of my regular readers, for pointing this new development out). In fact, it’s called “web 3.0,” in a bid to become “The Next New Internet.” Given I tend to be a little concerned about the future of the Internet, I thought I’d look into this new one a bit to discover what it’s all about… Pardon the length of the ensuing investigation.

To begin to understand Ethereum, you have to understand block chainsbecause Ethereum is a type of block chain. To understand block chains, you must begin with the hash. A has is a simple concept that is actually quite difficult to implement in a useful way: a hash takes any a string of numbers of any size and returns a fixed length number, or hash, that (more or less) uniquely represents the original string. The simple to implement part is this—one rather naive hash is it simply add the numbers in a set of numbers until you reach a single digit, calling the result the hash. For instance…

2 + 3 + 5 + 2 + 3 == 15
1 + 5 == 6

Hence the number 23523 can be represented as 6. One curious property of the hash is there is no way to determine, from the hash, what the original number was—this is one of the essential observations of many uses for the hash. If I share a number with some third party, and they then share it with you, you can ask me for the hash of the number (without telling me what the actual number is!), and you can verify the number we have is the same by verifying the hash I give you matches the one you calculate.

The hash above is naive because it is too easy to obtain a collision. In other words, there are many different sets of numbers that will result in a hash of 6 given the same process, such as 222, 33, 111111, and (probably) an almost infinite number of others. The tricky part of building a hash, then, is in ensuring that collisions are rare or nonexistent.

Assuming you have developed such a hash (there are a number of them), you can then use hashes to build a Merkle Tree, as illustrated in the figure below.

In this illustration, four numbers have been processed through an algorithm that produces a hash: H1 through H4. H1 and H2 are, in turn, hashed to produce H5, and H3 and H4 are hashed to produce H6. H5 and H6 are, in turn, hashed to produce the root hash. There are a number of interesting things about Merkle trees; for instance, if you change the value of H1 for any reason, the value of the root hash also changes. Of course this “just makes sense,” but it means that you can validate the contents of any group of files or values by examining a single value. Further, you can verify which part of the tree the change has taken place on if you have access to all the hashes in the tree even though you do not know, or do not know if you can trust, the values themselves.

To get to a blockchain, you simply string the Merkle tree out, as shown below.

Here the hashes of H1 and H5 are hashed to form H2, the hashes of H2 and H6 are hashed to form H3, etc. What is interesting about a block chain is that you can tell if any step has been repeated twice, if work has not been done, or if any of the numbers in the previous part of the chain have been changed—hence its usefulness in forming digital currencies.

There is, in fact, more to a real blockchain than this—there is also a consensus process—but this is a radical simplification to get to the final point of this post.

What most cryptocurrencies do is to use very hard to calculate numbers as the root and “adders” on a single blockchain (or multiple blockchains). Ethereum goes beyond this one step by including code in the blocks that can be chained together. This means that a virtual machine can be given an Ethereum blockchain that not only contains data to operate on (such as move some amount of money from this account to that account), and some instructions about under what conditions the data should be acted on (when the receiver signs for the package). The operation could take place in full public view, but without information about the people involved, account numbers, etc., being exposed to the public view (because these can all be represented by hashes, instead of the real numbers, that can only be interpreted by the parties involved in the transaction).

At this point, you are probably sitting there scratching your head and thinking—what does any of this have to do with replacing the Internet? As it turns out, this is a very good question. Begin by scoping the question—what does the Internet consist of? Physical media, hardware, software implementations of various protocols, routing, transport protocols, and… well, a lot of things. Now what, among these things, could something like Ethereum replace?

It does not seem likely that something like Ethereum would be useful for point to point communications over a single link, so it does not seem likely that it will replace optical circuits, routers, switches, and other infrastructure of this kind. It might be possible to build a form of routing with something like Ethereum, but it is not going to be very fast, and it is not going to talk about hosts and devices, but rather only information, consumers, and producers (much like Named Data Networking, or NDN). Further, it is not likely to converge very quickly (oh, I know, the Internet never converges today, so let’s add in a lot of stuff that will slow down convergence from the order of minutes to the order of days—that should be entertaining).

Maybe for some form of name focused overlay routing focused on information, then, but not for routing for physical and logical devices. It might be a nice pipe dream to stop caring about physical and logical devices, of course, but I would like the see how such a thing could be wired, managed, and what sort of troubleshooting you might use when it does not work. What about DNS? Perhaps, but are you going to remember the hash rather than the domain name? I doubt it—so the most likely use here would be in terms of transporting DNS queries, and replacing the server system with something more distributed, etc. Speed will likely still be a real issue here, though.

What, then, is in view here? It seems like the primary target is transport and caching. Today transport is a mess of different protocols, such as TCP, UDOP, QUIC, et al, each of which contains their own security mechanisms, etc., and caching, well, do not get me started on caching. What Ethereum could do is fulfill the promise of NDN—putting information where it needs to be for quick access and wide replication, without worrying about someone who should not be reading it actually reading it, and tracking modifications to the data along the way.

The nice thing here is the object oriented approach, the ability to share applications that can later be used to act on data. In this model, a contract can be a bit of code attached to a block chain; when all the correct information is received, the contract can be executed on any node, the results distributed, all with the ability to prevent a second execution for this specific transaction against this specific contract.

The entire morass of overlaying applications could be radically altered if something like Ethereum takes off.

So, will it replace the entire Internet, as promised? It seems doubtful. Will it replace the entire ‘web as we know it? Probably not. Could this completely revolutionize the way information is transferred on top of the protocols we have now, and potentially any future ones?

The answer to this last question is a definite yes.. Maybe that’s not the entire Internet, but maybe that’s interesting enough to make this one worth watching.