PayPal et al: When your web site gets kicked in the SaaS
With the proliferation of easy-to-install Web sites and hosting providers, small business owners, nonprofit operators, and even departmental teams inside much bigger organizations are putting up sites and collecting a few bucks.
In fact, you can think of all the Web hosting service providers out there as the original SaaS -- Software-as-a-Service -- providers. As an example, cPanel (the tool the vast majority of Web hosting customers use to manage their sites) was launched a full eight years before Gmail.
Web hosting was SaaS before SaaS was cool.
Lowering the barrier of entry
Over the years, the barrier of entry to setting up a basic Web site has gotten lower and lower, and the capabilities and overall look and feel of those Web sites has gotten better and better. Wix promises a Web site that's "Just a click away." Squarespace promises "Perfect Web sites." And the open source WordPress, which lets you host your own Web site and modify it to your heart's content, promises their "famous 5-minute install."
The difference between Wix and Squarespace, and tools like WordPress, Joomla, and Drupal is that the first two are completely hosted solutions and you have very limited opportunity to modify functionality. WordPress, too, has a hosted solution at WordPress.com, and like Wix and Squarespace, you can't modify your sites all that much -- but the company handles everything.
Content management systems
By contrast, once you get into the world of content management systems or blogging software, which is where WordPress, Joomla, and Drupal fit, you can do everything from a simple 5-minute install to building incredibly deep and complex code and systems.
I got started with WordPress about seven years ago when I migrated the ZATZ sites to WordPress. They ran in another open source environment called UserLand Frontier, but it had been all but abandoned -- and a key piece of code was not open source, but compiled by a company that no longer existed. I wanted to get the ZATZ Archive containing almost 75,000 articles onto a platform that would have a future.
My transition to WordPress was not a 5-minute install. It took three years to write all the code that would replicate my proprietary ZENPRESS content management system and run it in WordPress. Like most platforms of its type, WordPress is extensible and supports plugins. I wrote a bunch of them to replicate the code I had in the original ZENPRESS.
And that's where we start to see the difference between the surface of some of these systems and the depth underneath the water. It used to be that to install a plugin, you had to FTP into a server, upload the files, and move them into the right directories. Heck, it used to be that to install WordPress, you had to do the same thing.
Now, most hosting users just click on Softaculous (or something similar) and the magic happens behind the scenes. Many hosting providers sell WordPress hosting accounts that are all set up without any configuration required.
The impact of this has not been inconsiderable. WordPress currently powers 26.2 percent of all Web sites. Of those using any sort of content management system, WordPress has 59.2 percent of the market.
In other words, it's a fair bet to assume that if someone is building a Web site, especially one where they're not hand-coding the HTML, the odds are they're building it in WordPress.
It's not IT, it's point-and-click
But "building it" is a stretch. Back before I adopted a bunch of unattended WordPress plugins, I thought those "building" WordPress had some technical skills. As I've come to find out, because the barrier of entry is so low, sites are being pointed-and-clicked into existence, and the operators who are making and relying on them often have pretty much zero technical knowledge.
You know how it is when you go to Thanksgiving dinner and the whole family has been looking forward to seeing you? Yeah, you know it's not because they love your personality. They want to get their gear fixed, and they know it's probably one of only two or three times during the year that you're making a house call.
Yep, most WordPress site operators are like your family. Most have no idea what CSS is. An inspector to them is French and bumbles around solving crimes. They wouldn't know how to set up iptables or edit Apache or Nginx configuration files, or heaven forbid, install an SSL certificate and update their Web site to route https requests properly.
Remember that last one. We'll come back to it in a few minutes.
The plumbing underneath
But despite their lack of mad IT skills, make no mistake about it. These folks are engaged in some pretty complex IT. They're building mashups, linking their sites to other SaaS service providers, and relying on data interconnections that they can't even describe.
They're sending mailing list data into MailChimp. They're posting tweets automatically to Twitter. They're latching into Google Analytics and Adwords for analytics and some side income. And they're using e-commerce providers and payment gateways to bring in cash.
All of this is horrifyingly fragile, dependent on protocols and interconnects between vendors that often don't even talk to each other.
A rant for the ages
One of the best examples of this fragility comes via a post-rant by Maciej Ceglowski, the creator of Pinboard. Not to be confused with Pinterest, Pinboard is kind of a next-generation Delicious, a bookmarking site of sorts. As social networking sites go, Pinboard isn't huge. But it's still got tens of thousands of users.
Pinboard is SaaS and many of Pinboard's users connect to other SaaS services using IFTTT, literally If-this-then-that. IFTTT is plumbing that reacts to events on some services and triggers events on others. It's glue -- but it's glue that needs ingredients in the form of some communications protocols that connect the services.
Apparently, out of the blue, IFTTT changed its protocol and then sent a demanding letter to Ceglowski, threatening him if he didn't make Pinboard compatible. His rant is priceless.
The point of this is that we're all more and more reliant on not just the SaaS services we are consciously signing into, but also on the hidden plumbing that connects these services. Oddly enough, it mostly works, even though most of the players don't know each other, and sometimes compete.
I'll paint you a picture. Have you ever blasted down a long stretch of highway, where the only thing between you and the cars going in the other direction was a thin yellow line? You don't know them and they don't know you, but everyone agrees to generally stay in their lanes. It shouldn't work, but it does.
That's our world of SaaS and interoperability.
PayPal and security
Not everyone gets into a newly classic snit like Pinboard's creator, but many companies that provide key services do struggle with the compatibility issue. And that brings us to PayPal.
I have a better insight into this than I might otherwise have had because one of the plugins I adopted a year ago turns out to connect to PayPal.
Okay. That's kind of an understatement. Seamless Donations is all about collecting donations for nonprofits and processing those donations through PayPal. This is no small thing. Seamless Donations is the most popular donations plugin for WordPress. More than 4,000 people downloaded it just last week.
Seamless Donations is small potatoes, though, compared to the big WordPress e-commerce systems, like Easy Digital Downloads and WooCommerce. WooCommerce, for example, is a WordPress plugin that runs nearly 30 percent of the entire Web's ecommerce sites. There's huge value in that. Automattic, the company behind WordPress, bought WooThemes (the company behind WooCommerce) for something in the neighborhood of $30 million.
Links in a chain
As you probably know, collecting money online is a multi-vendor proposition. The donation sites and e-commerce sites don't process the money. That's usually done through gateway systems that talk to the big credit card processing financial systems.
There are usually a bunch of links in the chain from the e-commerce site to the shopping cart software to the payment gateway to the credit card provider to the bank. Those linkages, all the "to the" items I mentioned in the previous sentence, are very attractive targets to hackers, organized crime, terrorist organizations, and rogue nation states.
In other words, on one end of the system you have Uncle Ralph who wants to sell baseball cards and at the other side, you have Kim Jung Un, who would really, really wants to drop a nuke on all of us, including Uncle Ralph.
Since Kim either hasn't been allowed to play with the big-boy toys (or they never seem to work), North Korea's leader has had to settle for ordering teams of hackers to break into not just corporate sites to steal money and secrets, but sites operated by folks like Uncle Ralph.
To be honest, most e-commerce solutions and gateways give me the willies, because they actually take credit card information in on public Web sites and then transmit that information to processors. Yes, those sites have to be secured with SSL, but as we've seen, SSL has its weaknesses.
SSL also adds complexity to Web site operations, requiring certificate requests, certificates, more options in conf files, and some expense. Up until recently, validated SSL certificates were rather costly. That's changing, which is good for the nonprofits I work with.
But PayPal has been different. First, it was one of the very first online monetary transaction processors, so it had quite a lot of first mover advantage. Its services have grown up over the years, but at its very basic, PayPal still offers a chunk of HTML you can paste into your page and get a Buy button.
One slight step up is building a form on your Web page that redirects the user to PayPal's servers to get account and financial information. This code has a number of benefits. It's relatively easy to set up, it's free (except for the percentage points PayPal skims off the top), and all the confidential information never lives on the original site.
For many getting into online commerce, that was the winner. Not only didn't they have to worry about storing confidential financial information, they also didn't have to know from SSL or complex security protocols.
That made the barrier of entry to collecting money about as easy as clicking a button. And so, almost all of the e-commerce solutions and donation solutions (mine included) provided PayPal as the entry point for e-commerce.
The coming PayPal-mageddon
But the folks at PayPal aren't stupid. They know that even though no real confidential information travels from originating sites to their servers, it's only a matter of time before the bad guys break something. So for the past year or so, PayPal has been warning of a transition to SSL.
Part of that transition hit users last week. Suddenly, it was impossible to use the sandbox without an https-based URL. Sandboxes are test environments most e-commerce providers set up so users can test their carts before going live.
While PayPal had been warning of the move, their guidance page said "Ready now" not "You better be ready now." A reading of the fine print does show that PayPal intended this transition to shut off non-SSL use of their sandbox, but it was fine print -- not the big block of warning for their next step, what I've taken to calling PayPal-mageddon.
That's in September. On September 30, 2016, PayPal will stop accepting Internet payment notifications from live sites that are not using SSL. From a security point of view, this is a good thing. But from an all-hell's-gonna-break-loose point of view, oh my.
In September, anyone using PayPal who hasn't transitioned to the new security protocols will no longer be able to take money. Period. Money won't change hands. For those who haven't updated their sites, the flow of money will come to a screeching halt. This may affect a large percentage of the Internet.
I'll use Seamless Donations as an example. When I adopted it, it was at version 3.x. I did a pile of mods and moved it up to 4.x. As of now, 77.2 percent are running one of 15 4.0.x releases. But that means that 22.8 percent haven't upgraded and probably haven't paid any attention to the operation of the site, except for letting the donations flow into their accounts.
For just my plugin alone, we're talking about thousands of active sites, all of whom will stop seeing donations process on September 30. And who do you think they're going to yell at? It won't be PayPal, at least at first. It will be me and all the others who provide a PayPal gateway.
Winter is coming
More great project ideas
Please dont take this as general bitching. Instead, take away the lesson that SaaS is somewhat fragile, especially as we start to take into account the fact that SaaS isn't really one thing, but a lot of services all interconnected in unique mashups.
We also need to take into account that our users most likely haven't thought this all through, or don't even have a concept of what's going on in the IT operations they've snapped together out of virtual Internet-based Lego blocks.
As we move more and more to the cloud, we become more and more reliant on Web-based SaaS services. Sure, it frees us up from hardware infrastructure, software maintenance, and even basic operational knowledge. But as SaaS services change their interfaces and their policies, or just shut down, expect breakage.
The big difference this time is that as IT systems fail, end-user managers will be on the front lines. The IT pros will get called in, of course, but not until things get very ugly and unsuspecting users/operators get very angry.
Hey, we in IT have always picked up the pieces. Why should this phase of user-managed mashups be any different?
By the way, I'm doing more updates on Twitter and Facebook than ever before. Be sure to follow me on Twitter at @DavidGewirtz and on Facebook at Facebook.com/DavidGewirtz.