In today’s post, I look back on the developments of ecommerce and my role in covering this technology. I was recently reminded of this history after writing last week about Paypal — this motivated one of you to recall events that happened in the early 2000s, back when the “internet bubble” was rising and then bursting.

I last took a long look back at ecommerce in 2014 with this blog post. In it I highlighted a series of other works:

• Back in the late 1990s, I tested many ecommerce products and also lectured at conferences around the world on the topic. One piece was an op-ed that I wrote for ComputerWorld back in 1999 here.
• In 2010, I looked at how hard it was to take credit card payments online in my blog.
• Then for ITworld in 2011, looking at the crop of mobile payment apps such as Square.
• And in 2013, I looked at the frustrations surrounding eWallet technology.

While the web came of age in the 1990s, it took a while for ecommerce to get into gear. The technologies were bare-bones: back then, you could learn basic HTML coding in a couple of days and easily put together a static series of web pages. The key operative words in that sentence were “static” and “basic.” The 1990s era of HTML was waiting for the language to catch up with what we wanted to do with it, but eventually the standards process got there. The real stumbling block was making a site dynamic and being able to support online inventories that were accurate, checkout pages that were secure, and having access to software interfaces that were pretty crude and simplistic. All of that required other tools outside of HTML, which is somewhat ironic. Now if you look at the code behind the average webpage, it is almost impossible to parse its logic at first glance.

Yet, here we are today with ecommerce being a very sophisticated beast. HTML is no longer as important as the accompanying and supporting constellation of web programming languages and development frameworks that require lots of study to be competent and useful. Connecting various databases and using a web front-end is both easier and more complex: the APIs are richer, but how they are implemented will require a deft touch to pull off successfully. Payment processing has numerous vendors that occupy sub-markets. (Stripe, Bill.com, and Klarna are three such examples of companies that are all involved in payments but have taken different pieces of the market.)

You might not have heard about Klarna: they are one of more than a dozen “buy now, pay later” services that pop up at checkout. No purchase is too small to be spread across a payment plan. Back in the pre-internet times, we had layaway plans that had one important aspect: you didn’t get the item until you completely paid for it. Now items arrive in days, but attached to a stream of loan payments stretching out several months. The downside is that there are potential late fees and 30% annualized interest charges too.

And then there is Amazon and Google. The former has both made it easier and more complex to do online shopping. It used to be both free and easy to return merchandise purchased on Amazon. Now it is neither. If you don’t pay attention when you are purchasing something, you could end up using one of their contract sellers, which complicates the returns process. And the cost of Prime continues to climb.

Google’s Lens technology has also transformed online shopping. If you have a picture of what you want to buy, you can quickly view what websites are selling the product with a couple of clicks on any Android or iPhone. My interior designer wife uses this tech all the time for her clients.

Before I go, I want to mention that Cris Thomas, known by his hacker handle Space Rogue, has a new book out that chronicles his rise into infosec security, including his time as one of the founders of the hacking collective L0pht. Its early days were wild by today’s standards: the members would often prowl the streets of Boston and dumpster dive in search of used computer parts. They would then clean them up and sell them at the monthly MIT electronics flea market. Dead hard drives were one of their specialties — “guaranteed to be dead or your money back if you could get them working.” None of their customers took them up on this offer, however. There are other chapters about the purchase of L0pht by @stake and Thomas’ eventual firing from the company, then taking eight years to get a college degree at age 40, along with the temporary rebirth of the Hacker News Network and going to work for Tenable and now at IBM. I review the book in this post, and highly recommend it if you are looking at reliving those early infosec days.

I am not so sure. For those of you keeping score at home, web v1 was the early days where we had web servers delivering static pages of mostly text, starting in the early 1990s and lasting until about 2003 or 2004. The next version was the dynamic web where we created our own content, and where we freely gave away our privacy and data so that we could post cat memes and dance videos to the now giants of Facebook /Apple/Amazon/Netflix/Google, otherwise called FAANG. (Facebook and Google have renamed themselves, but the acronym has stuck.)

But now it is time for a new iteration, and v3 attempts to create a more egalitarian internet, protected by encrypted tokens that can keep everyone’s identity and data private and secure. Say what? At least, that is the plan.

Whether or not you agree with this vision, it has largely been unrealized. Yes, there is a Web 3 Foundation, and you can see at that link a very complex tech stack that will consist of multiple protocol layers, much still TBD. For those of us that cut our teeth on HTML, CSS, and HTTPS, these protocols are pretty much unknown.

Scott Carey writes in Infoworld summing things up this way: “To access most Web3 applications, users will need a crypto wallet, most likely a new browser, an understanding of a whole new world of terminology, and a willingness to pay the volatile gas fees required to perform actions on the Ethereum blockchain. Those are significant barriers to entry for the average internet user.” I’ll say. If you have never had a crypto wallet, never used Rust or Solidity and don’t know what a gas fee is, you need to go to web3 study hall. You may not understand the tech behind it — I don’t fully understand all of these items — but that is the point. The decentralized web is being built on a series of protocols and there are a lot of gaps.

But let’s put aside all the new tech and answer a few basic questions.

What is the role of clients and servers? One of the first things you come to is needing to understand the difference between clients and servers. In the web1 and web2 worlds, there were browsers, and there were various servers (web, database, applications, payments, and so forth). It was a pretty clean separation of powers. Some of us were happy to never touch any kind of server, something that leads off Moxie Marlinspike’s “first impressions” blog post. I don’t agree with this position. I have been running my own web server for more than 25 years. I wouldn’t have it any other way. I like being “master of my domain” (which is more than just running my own server, such as being able to move it from one place to another across the internet, which I had to do last year when my ISP went out of business).

I think what Moxie meant to say is that most people don’t like configuring and maintaining their own servers. But that is why we have ISPs.

But look at the tech stack that we are promised with web3: that is a lot of tech to deal with. If we had resistance to configuring HTML and HTTP, imagine what amount of pain we will be faced when all this new stuff comes to fruition?

Lance Ulanoff writes that the vision for web3 is “more a combination of edgy new technology and a reaction to centralized control.” He goes on to discuss some of the early descriptions before the web3 term came into the popular lexicon, such as the semantic web that was tossed around back in 2006. He describes web3 being when we can control our interactions and have a universal identity across all systems. That’s nice, but so much of the current vision about web3 doesn’t really fill in the blanks about how this control will happen or how we can create these universal identities. Moxie says that we need to use cryptography rather than infrastructure to distribute trust. I completely agree. Ignoring the trust issues is dangerous — look how long it has taken us to resolve email trust issues, and those protocols were created decades ago.

But how this infrastructure play out brings us to my next question:

What is the role of peer-to-peer (p2p) technology? Remember Napster and peer file sharing of music and videos? Back then (roughly 2000-2005), everyone was digitizing their CDs, or stealing music from others, or both. Napster and LimeWire and the other apps created peer file servers on your hard disk, and you then shared your digitized content with the world. Sharing wasn’t caring, and lawsuits ensued. Now we just pay Netflix et al. and stream the content when we want to listen or watch something. Who needs possession of the actual bits?

But see what has happened here: we went from this idealized p2p world to today where just a few centralized businesses (like FAANG) run the show. This could be the fate of web3, and all this talk about a decentralized, egalitarian web could fall apart. Today’s crypto/NFT world depends on just a few centralized service providers, and the distinction between client and server in a fully decentralized p2p blockchain isn’t all that clear, as one of the Ethereum founders Vitaly Buterin points out. He says that there are various gaps in web3 which are bridged with the various API suppliers, such as Infura and Opensea. The issue that Moxie has is that many NFT and crypto advocates have just accepted the role of these API vendors without much thought about the implications. Moxie is worried that these vendors have a lot of control over things, and that there is the potential for the decentralized web3 to turn into a less efficient and less private version of today’s internet. Think of one nightmare scenario, where Facebook (or one of the other giants) has its own web3 servers, APIs, and alt-coins. The horror!

But you think crypto is cool, and there is money to be made. Now we get to the real meat of the matter. Forget about a more equal internet and singing kumbaya off into the sunset. Let’s talk about how high the various alt-coins are trading at – or not, depending on when you entered the market. Remember the internet bubble of 1999-2000, when domains were being bought and sold on little more than a pitch deck. That was Gold Rush v1, and all you had to do to participate was to buy a domain and flip it. (I am guilty of this, but I didn’t buy my domain to flip it. I just got lucky.)  You could argue that all you need now is to hold a basket of crypto coins — as some of you have done. But look at all the knowledge you have to collect to participate in this gold rush. Nevertheless, there is some cool stuff that is being built, as this blogger documents. This post basically rebuts a few of Moxie’s complaints while making Moxie’s point that this is very early stuff.

So go cautiously into the web3 night, and good luck learning about all the requisite tech that will be needed. And for those of you complaining about the decentralized and private web of the future, you might want to spend some time doing the basic blocking and tackling and eliminating duplicate passwords and implementing MFA logins now, because you’ll need something like them to get on the blockchain train. Or at least protect all those crypto funds in your wallet from being lost or stolen.

How often do you comment on how slow the Internet is? Now you have a chance to do something to speed it up. Before I tell you, I have to backtrack a bit.

Most of us don’t give a second thought about the Domain Name System (DNS) or how it works to translate “google.com” into its numerical IP address. But that work behind the scenes can make a difference between you having and hot having access to your favorite websites. I explain how the DNS works in this article I wrote ten years ago for PC World.

Back when I wrote that article, there was a growing need for providing better DNS services that were more secure and more private than the default one that comes with your broadband provider. But one of the great things about the Internet is that you usually have lots of choices for something that you are trying to do. Don’t like your hosting provider? Nowadays there are hundreds. Want to find a better server for some particular task? Now everything is in the cloud, and you have your choice of clouds. And so forth.

And now there are various ways to get DNS to your little patch of cyberspace, with the introduction of a free service from Cloudflare. If you haven’t heard of them before, Cloudflare has built an impressive collection of Internet infrastructure around the world, to deliver webpages and other content as quickly as possible, no matter where you are and where the website you are trying to reach is located. If you think about that for a moment, you will realize how difficult a job that is. Given the global reach of the Internet, and how many people are trying to block particular pieces of it (think China, Saudi Arabia, and so forth), you begin to see the scope and achievement of what they have done.

I wanted to test the new 1.1.1.1 DNS service, but I didn’t have the time to do a thorough job.  Now Nykolas has done it for me in this post on Medium. He has somewhat of a DNS testing fetish, which is good because he has collected a lot of great information that can help you make a decision to switch to another DNS provider.

There are these five “legacy” DNS providers that have been operating for years:

• Google 8.8.8.8: Private and unfiltered. Most popular option and until now the easiest DNS to remember. Their IP address was spray-painted on Turkish buildings (as shown above) during one attempt by their government to block Internet access.
• OpenDNS 208.67.222.222: Bought by Cisco, they supposedly block malicious domains and offer the option to block adult content.
• Norton DNS 199.85.126.20: They supposedly block malicious domains and integrate with their Antivirus.
• Yandex DNS 77.88.8.7: A Russian service that supposedly blocks malicious domains.
• Comodo DNS 8.26.56.26: They supposedly block malicious domains.

I have used Google, OpenDNS and Comodo over the years in various places and on various pieces of equipment. As an early tester of OpenDNS, I had some problems that I document here on my blog back in 2012.

Then there are the new kids on the block:

• CleanBrowsing 228.168.168: Private and security aware. Supposedly blocks access to adult content.
• CloudFlare 1.1.1.1: Private and unfiltered, and just recently announced.
• Quad9 9.9.9.9: Private and security aware. Supposedly blocks access to malicious domains, based in NYC and part of the NYCSecure project.

How do they all stack up? Nykolas put together this handy feature chart, and you can read his post with the details:

As I mentioned earlier, he did a very thorough job testing the DNS providers from around the globe, using VPNs to connect to their service from 17 different locations. He found that all of the providers performed well across North America and Europe, but elsewhere in the world there were differences. Overall though, CloudFlare was the fastest DNS for 72% of all the locations. It had an amazing low average of 5 ms across the globe. When you think about that figure, it is pretty darn fast. I have seen network latency from one end of my cable network to the other many times that.

So why in my commentary above do I say “supposedly”? Well, because they don’t really block malware. In another Medium post, he compared the various DNS providers’ security filters and found that many of the malware-infested sites he tested weren’t blocked by any of the providers. Granted, he couldn’t test every piece of malware but did test dozens of samples, some new and some old. But he found that the Google “safe browsing” feature did a better job at block malicious content at the individual browser than any of these DNS providers did at the network level.

Given these results, I will probably use the Cloudflare 1.1.1.1 DNS going forward. After all, it is an easy IP address to remember (they worked with one of the regional Internet authorities who have owned that address since the dawn of time), it works well, and plus I like the motivation behind it, as they stated on their blog: “We don’t want to know what you do on the Internet—it’s none of our business—and we’ve taken the technical steps to ensure we can’t.”

One final caveat: speeding up DNS isn’t the only thing you can do to surf the web more quickly. There are many other roadblocks or speed bumps that can delay packets getting to your computer or phone. But it is a very easy way to gain performance, particularly if you rely on a solid infrastructure such as what Cloudflare is providing.