SAMBA versus SMB: Adversarial interoperability is judo for network effects

Before there was Big Tech, there was "adversarial interoperability": when someone decides to compete with a dominant company by creating a product or service that "interoperates" (works with) its offerings.

In tech, "network effects" can be a powerful force to maintain market dominance: if everyone is using Facebook, then your Facebook replacement doesn't just have to be better than Facebook, it has to be so much better than Facebook that it's worth using, even though all the people you want to talk to are still on Facebook. That's a tall order.

Adversarial interoperability is judo for network effects, using incumbents' dominance against them. To see how that works, let's look at a historical example of adversarial interoperability role in helping to unseat a monopolist's dominance.

The first skirmishes of the PC wars were fought with incompatible file formats and even data-storage formats: Apple users couldn't open files made by Microsoft users, and vice-versa. Even when file formats were (more or less) harmonized, there was still the problems of storage media: the SCSI drive you plugged into your Mac needed a special add-on and flaky driver software to work on your Windows machine; the ZIP cartridge you formatted for your PC wouldn't play nice with Macs.

But as office networking spread, the battle moved to a new front: networking compatibility. AppleTalk, Apple's proprietary protocol for connecting up Macs and networked devices like printers, pretty much Just Worked, providing you were using a Mac. If you were using a Windows PC, you had to install special, buggy, unreliable software.

And for Apple users hoping to fit in at Windows shops, the problems were even worse: Windows machines used the SMB protocol for file-sharing and printers, and Microsoft's support for MacOS was patchy at best, nonexistent at worst, and costly besides. Businesses sorted themselves into Mac-only and PC-only silos, and if a Mac shop needed a PC (for the accounting software, say), it was often cheaper and easier just to get the accountant their own printer and backup tape-drive, rather than try to get that PC to talk to the network. Likewise, all PC-shops with a single graphic designer on a Mac-that person would often live offline, disconnected from the office network, tethered to their own printer, with their own stack of Mac-formatted ZIP cartridges or CD-ROMs.

All that started to change in 1993: that was the year that an Australian PhD candidate named Andrew Tridgell licensed his SAMBA package as free/open source software and exposed it to the wide community of developers looking to connect their non-Microsoft computers-Unix and GNU/Linux servers, MacOS workstations-to the dominant Microsoft LANs.

SAMBA was created by using a "packet sniffer" to ingest raw SMB packets as they traversed a local network; these intercepted packets gave Tridgell the insight he needed to reverse-engineer Microsoft's proprietary networking protocol. Tridgell prioritized compatibility with LAN Manager, a proprietary Network Operating System that enterprise networks made heavy use of. If SAMBA could be made to work in LAN Manager networks, then you could connect a Mac to a PC network-or vice-versa-and add some Unix servers and use a mix of SAMBA and SMB to get them all to play nice with one another.

The timing of Tridgell's invention was crucial: in 1993, Microsoft had just weathered the Federal Trade Commission's antitrust investigation of its monopoly tactics, squeaking through thanks to a 2-2 deadlock among the commissioners, and was facing down a monopoly investigation by the Department of Justice.

The growth of local-area networks greatly accelerated Microsoft's dominance. It's one thing to dominate the desktop, another entirely to leverage that dominance so that no one else can make an operating system that connects to networks that include computers running that dominant system. Network administrators of the day were ready to throw in the towel and go all-Microsoft for everything from design workstations to servers.

SAMBA changed all that. What's more, as Microsoft updated SMB, SAMBA matched them, relying on a growing cadre of software authors who relied on SAMBA to keep their own networks running.

The emergence of SAMBA in the period when Microsoft's dominance was at its peak, the same year that the US government tried and failed to address that dominance, was one of the most salutary bits of timing in computing history, carving out a new niche for Microsoft's operating system rivals that gave them space to breathe and grow. It's certainly possible that without SAMBA, Microsoft could have leveraged its operating system, LAN and application dominance to crush all rivals.

We don't see a lot of SAMBA-style stories anymore, despite increased concentration of various sectors of the tech market and a world crying out for adversarial interoperability judo throws.

Indeed, investors seem to have lost their appetite for funding companies that might disrupt the spectacularly profitable Internet monopolists of 2019, ceding them those margins and deeming their territory to be a "kill zone."

VCs have not lost their appetite for making money, and toolsmiths have not lost the urge to puncture the supposedly airtight bubbles around the Big Tech incumbents, so why is it so hard to find a modern David with the stomach to face off against 2019's Goliaths?

To find the answer, look to the law. As monopolists have conquered more and more of the digital realm, they have invested some of those supernormal profits in law and policy that lets them fend off adversarial interoperators.

One legal weapon is "Terms of Service": both Facebook and Blizzard have secured judgments giving their fine print the force of law, and now tech giants use clickthrough agreements that amount to, "By clicking here, you promise that you won't try to adversarially interoperate with us."

A modern SAMBA project would have to contend with this liability, and Microsoft would argue that anyone who took the step of installing SMB had already agreed that they wouldn't try to reverse-engineer it to make a compatible product.

Then there's "anti-circumvention," a feature of 1998's Digital Millennium Copyright Act (DMCA). Under Section 1201 of the DMCA, bypassing a "copyright access control" can put you in both criminal and civil jeopardy, regardless of whether there's any copyright infringement. DMCA 1201 was originally used to stop companies from making region-free DVD players or modding game consoles to play unofficial games (neither of which is a copyright violation!).

But today, DMCA 1201 is used to control competitors, critics, and customers. Any device with software in it contains a "copyrighted work," so manufacturers need only set up an "access control" and they can exert legal control over all kinds of uses of the product.

Their customers can only use the product in ways that don't involve bypassing the "access control," and that can be used to force you to buy only one brand of ink or use apps from only one app store.

Their critics-security researchers auditing their cybersecurity-can't publish proof-of-concept to back up their claims about vulnerabilities in the systems.

And competitors can't bypass access controls to make compatible products: third party app stores, compatible inks, or a feature-for-feature duplicate of a dominant company's networking protocol.

Someone attempting to replicate the SAMBA creation feat in 2019 would likely come up against an access control that needed to be bypassed in order to peer inside the protocol's encrypted outer layer in order to create a feature-compatible tool to use in competing products.

Another thing that's changed (for the worse) since 1993 is the proliferation of software patents. Software patenting went into high gear around 1994 and consistently gained speed until 2014, when Alice v. CLS Bank put the brakes on (today, Alice is under threat). After decades of low-quality patents issuing from the US Patent and Trademark Office, there are so many trivial, obvious and overlapping software patents in play that anyone trying to make a SAMBA-like product would run a real risk of being threatened with expensive litigation for patent infringement.

This thicket of legal anti-adversarial-interoperability dangers has been a driver of market concentration, and the beneficiaries of market concentration have also spent lavishly to expand and strengthen the thicket. It's gotten so bad that even some "open standards organizations" have standardized easy-to-use ways of legally prohibiting adversarial interoperability, locking in the dominance of the largest browser vendors.

The idea that wildly profitable businesses would be viewed as unassailable threats by investors and entrepreneurs (rather than as irresistible targets) tells you everything you need to know about the state of competition today. As we look to cut the Big Tech giants down to size, let's not forget that tech once thronged with Davids eager to do battle with Goliaths, and that this throng would be ours to command again, if only we would re-arm it.

(Crossposted from EFF Deeplinks)