073. **DO NOT FORWARD**

As readers of this chapter have seen, the theme of Office11 continues to be enterprise, though now it is turned up to 11 so to speak. Despite my concerns about end-users and reviewers, the unstoppable force at Microsoft remained enterprise customers and meeting their needs or the needs of our growing sales force serving them—whether those needs were technology, positioning, or strategy, as expressed by customers or the field sales teams. A key attribute of enterprise software strategy is connecting the dots and making sure one part of the full enterprise stack uses (or leverages) another part. A cynical view of this is that it encourages a form of lock-in relative to the Microsoft stack of software. A practical view is that customers appreciate this interconnectedness because they are buying everything in a bundle and broader usage of what is already owned offers a high return on that investment. A charitable view of such a strategy is how it makes for more elegant implementations where the various parts simply work together. Perhaps the story of Windows Rights Management (also called Information Rights Management within Office) generated a seemingly unachievable level of complexity while simultaneously facing an unrelenting technical buzzsaw of customer feedback.

This lesson from this section is not a one-off. Instead it is prototypical of the era but also what happens when a product pivots to enterprise customers and the enterprise relationship dynamic defines how products are built. It is a tale of caution.

Back to 072. Notes on Tablet PC Innovation

“I’d like to present to the witness Exhibit 6508, Bates number 0017811. Mr. Sinofsky, do you recognize this email that lists you as the sender?”

To anyone involved in modern litigation, especially being deposed, there’s a sinking feeling that comes with being presented an old email. A similar feeling arises when receiving a call from a reporter starting with, “I was just anonymously forwarded an email about . . .”

Email became ubiquitous across the corporate world by the early 2000s. With the rise of companies moving ever faster came “business at the speed of thought” (that was the name of Bill Gates’s second book from 1999) or “flattening organizational hierarchy,” to name two of the many touted benefits of email. In the early days, while senior managers at non-tech companies were still having email printed out for them and assistants transcribing email replies, not much thought was given to the permanence of email or the instant impact of an employee innocently (or not) forwarding email outside the company.

Every company that deployed email and embraced an email culture eventually wound up with a company policy on the use of email, likely explaining the ramifications if one were to be less than scrupulous in his or her use of email.

Born out of this were automatic disclaimers placed at the bottom of email, “THIS INFORMATION IS CONFIDENTIAL,” or my favorite, simply writing in red letters across the top of a message (perhaps the first use of rich email formatting) “CONFIDENTIAL.” We should not forget putting “**DO NOT FORWARD**” before the subject line of the email. We all knew that those emails were the important ones, and these warnings weren’t even worth the bytes they took up—copy/paste and printers still worked. Just in case there was a button on every keyboard since the first PC “Print Screen”.

Outlook featured commands that implied “Confidential” and “Do Not Forward,” though these did little more than offer a fancy version of red text and, worse, were invisible to recipients reading the mail on systems other than Outlook.

Maintaining the corporate confidentiality of email became the Achilles heel of the platform, except that email found such incredible product-market fit that there was no putting the toothpaste back in the tube. Customers wanted a solution that protected email misuse, or more clearly made Outlook enforce a company email policy or intent of the sender.

Over the previous several releases of Office, we steadily improved the ability to encrypt Office documents. Office always had the ability to add a password to documents, and for years a top call to customers calling PSS was trying to retrieve a lost password (Microsoft provided no help, but a search on the internet quickly led to a variety of tools that worked with trivial effort up until about Office 97, and incidentally those search results were a common way to spread malware). We eventually added true encryption that made it increasingly difficult to read a document that was not yours to read. This level of security eventually became minimal as the ability to break encryption techniques had steadily improved.

A peak effort and an early test of our platform capabilities for encryption was working to win approval for Outlook and Exchange to be used in the Defense Messaging System in the Department of Defense in the United States. Implementing the required encryption was useful only to the Defense Department but we eventually added it anyway. That was not before the head of North American sales, Orlando Ayala (OrlandoA) made his case to me by standing on top of a table in the briefing center begging for an update to support the DoD. I was terrified. The customers were impressed. We did the work.

The core of implementing encryption was an ongoing collaboration between Windows and Office, as well as Microsoft Research. Encryption was not exactly one single thing or feature, but a complex platform that required servers, user identity, and a lot of sophisticated math. It was exactly the kind of infrastructure that enterprise IT was gobbling up in the early 2000s. The old days of encryption were rapidly being supplanted by the need to encrypt information that flowed across the public internet and used public internet infrastructure. It was no longer as simple as a closed network with known proprietary endpoints.

Protecting files (and messages) with encryption was not without controversy, and without exaggeration for some technologists it was a line in the sand—crossing it put one squarely in the camp of the man. Encryption often collided head-on with the libertarian roots of the software field. Encryption was something of a third rail in the counter-culture elements of software.

The rise of the internet for online commerce created a brief moment where software vendors got caught up in the intricacies of import/export laws related to military products, specifically munitions. For a few years, the basic encryption algorithms—the results of widely-published academic research—were classified as munitions by US law and thus restricted for export. The hardcore technology advocates created a t-shirt featuring the code that implemented encryption with the implied threat that wearing such a shirt through a border crossing might subject the individual to law enforcement action of the highest order. The result was a headache for software vendors who maintained a secure version of products for the US market and a markedly less secure version for “export”. President Clinton signed an executive order ending this awkward situation and at least one type of encryption flourished.

Broader awareness of encryption came about because of the iPod, surprisingly, because of how Apple chose to protect digital music downloads from being copied or pirated. The music industry embraced digital rights as a way of protecting the world from another Napster, the online music service that institutionalized either digital distribution of music or mass-scale theft of music depending on which side one was on. Essentially, using digital rights management (DRM), Apple’s iTunes service ensured that the person who purchased a song was the only person who could listen to it and could only do so on devices authorized by Apple’s iTunes.

Such usage restrictions had shades of authoritarianism harkening back to the early days of commercial software. In the first years of MS-DOS, software vendors routinely encrypted software in such a way that only the licensed user could install it on a PC using serial numbers that would unlock the floppy disk and permanently assign it to a given user. Vendors also made it difficult to impossible to make copies of the software disks forcing buyers to be extra careful with their $500 purchases. So annoying was this to even legitimate buyers, that I spent several weeks one summer internship writing a low-level assembly language program to make copies of Lotus 1-2-3 disks for a huge defense contractor. Historically, Bill Gates was at least on the side of the honor system by and large though he believed strongly in active enforcement of legal ownership of software.

The industry collectively backed off from rights enforcement during the high-growth years, particularly at the urging of upstarts such as Borland, who used the absence of anti-piracy measures as a selling point. Then, as piracy of Office and Windows increased, so too did the use of serial numbers and activation codes, which were then labeled DRM by some, as if to further inflame consumers seeking legitimate use of their license. Thus, any feature using any software use restrictions was going to enter the maelstrom of tech enthusiast ire. BillG was particularly unphased by the pushback, widespread negative news coverage, and relentless hostility online in just about every language of the world taking place just after resolution of the antitrust saga.

For many in the tech community DRM in music was the devil’s technology. DRM prevented “fair use” of music and video all in the name of profit. The music and visual arts communities did not see it that way. Anything that looked like any combination of encryption or restricted use of digital information was labeled DRM. Anything called DRM came under intense scrutiny with the potential to backfire as features capitulating to authoritarian forces.

Nevertheless, enterprise customers were quite enthusiastic about a “Do Not Forward” button that worked. As one can imagine, in Microsoft’s top-down selling motion, it was the C-suite executives most interested in protecting the rights of their own email and documents. Even though we knew the idea of protecting email from being forwarded had all the makings of being labeled DRM and building the feature would utilize previously militarized technology, the allure of solving such a clearly articulated need was enough to overcome such resistance.

During the early days of building out the Microsoft enterprise infrastructure stack, customers were perhaps unknowingly open to enormous amounts of complexity to implement new features. Our sales force actively embraced complexity if it meant opportunities to link products together in a cross-selling motion, especially across Windows Server and Office. Office11 Information Rights Management (IRM) did not disappoint. We called it IRM as if to distinguish it from DRM, kind of. We knew we were walking straight into a messy feature. In an early nod to the complexity of the feature, the Windows infrastructure used by IRM was called the Windows Rights Management Service (RMS), thus implementing our DRM-like features called IRM used RMS (phew!).

Customers were already annoyed that they could lose a password to a document and Microsoft could not, or perhaps they thought would not, help them. IRM, in the eyes of detractors, implied that Microsoft held the keys, literally, to documents and somehow positioned themselves to become gatekeepers of email and documents. Or perhaps, as some customers thought, Microsoft did not hold the keys to documents and email and somehow a company’s own information would be subject to some sort of super-password that even they might not be able to unlock. What if there was a bug rendering the company information inaccessible? The questions were endless.

There was something inherently untrustworthy about the potential of using a content protection feature that could render the content unreadable. This was not theoretical. Many were already experiencing owning a library of rights-managed music, only to find it inaccessible when a company went out of business. Stories of lost music players and accounts disconnected from the rights were endlessly populating support sites. Whether these cases were real or not, they all contributed to a distrust of rights management. At this point in the company’s history, Microsoft was not always viewed with the most latitude in terms of doing the right thing for customers.

IRM proved to be one of the most complex features we ever shipped, perhaps overly complex, but in many ways it was symbolic of the overall complexity we were delivering to customers, whether it was IRM, SharePoint, or even the base infrastructure of Windows Server.

During vision planning for the release the feature was proposed so an Office shared team was created to tackle the implementation of IRM for Office11—the team aimed to implement the feature across the suite of products, not simply a one-off for just email. They had a bold vision for a future where companies could have much more control over their corporate information.

Lauren Antonoff (LaurenA) led program management, and with her prior experience on the Windows platform side she was great at navigating the extensive collaborations across the company to make this feature possible. Mark Walker (MarkWal), a veteran of several releases of Word as well as SharePoint and one of the most consistently smart and broad-thinking engineering managers, led development. Brian Wiese (BWiese) led testing, perhaps the most complex interoperability test responsibility we had created to date.

From the start, even when sketching out the original feature, IRM was a big feature. All we were aiming for was that “Do Not Forward” button, but to the surprise of many we overachieved.

IRM had to handle a plethora of edge cases, as testers called them. What if the users lost their PC? What if they wanted to read a message or documents on a rental PC in a hotel? What if they wanted to use IRM with a trusted partner who was on a different email system? What about access on a BlackBerry? What about wanting to open a file on an old version of Office? What if in the future someone needed to open a file on some not-yet-existing Office15? Then lawyers started asking if documents were part of legal discovery orders? How would screen readers used by the blind work? Or what if an employee was terminated? These what ifs went on and on. Every time I stopped by LaurenA’s office I learned about another case they were working on.

The strategic changes at the start of Office.NET seemed to be the kind that might reduce the complexity of this feature, because we no longer needed to worry about a parallel implementation of enterprise and outside the firewall, as we generally called it. The feature, however, needed to work outside the firewall if, for example, executives were to be able to read protected information on the road. The team took on the mission. We ended up doing much of the same work as we did for a hosted service but in bits and pieces, enabling IRM to work for customers using Hotmail in a browser, as long as the customer used the latest version of Internet Explorer.

As each development milestone progressed, M1, M2, M3 . . . the complexity continued to rise. IRM added code to Office, SharePoint, and Internet Explorer and required additions to Windows Server and to Active Directory. Administrators needed to learn to manage and distribute encryption keys, something that was making its way into enterprise infrastructure.

Along the way we experienced surprises that questioned the notion of Microsoft implementing IRM at all. Historically, many third parties—companies building products that relied on Office files or email—relied on being able to change documents or read them without launching the app by directly modifying files. Screen readers for the blind were one such example. Many document management systems relied on reading the contents of Word documents. Financial systems routinely read the contents of spreadsheets pulling out specific cells or data. Such behavior should have been impossible because the files were encrypted. Ultimately, the team designed capabilities to enable these “hooks” but at the expense of even more complexity. The depth of the feature was astounding.

The operational flowcharts created by the IRM team were legendary. The team rose to the occasion, producing untold volumes of written materials for corporate admins, partnering with all the teams at Microsoft, and coordinating the documentation across the writing teams that made this feature possible. Setting up IRM remained a monumental task.

IRM’s pièce de résistance was the addition of administrator-created rights management policy templates. It wasn’t enough that a message could be marked “Do Not Forward” or a document could only be opened by a fixed set of people. Office11 enabled IT to create new document policies that expired (like Snapchat, but 15 years earlier), or for documents to be forwardable but only within a company. Several combinations of permissions could be set via policy.

The keepers of secrets in enterprises, especially those sending mail on behalf of big bosses, were super happy. IRM was an enormous hit in the Executive Briefing Center. Emails on corporate reorgs or M&A PowerPoint decks could finally be shared worry-free.

Then came the debate to end all debates. In an early customer briefing about Office11 the details of IRM were discussed. With all the work going on to secure Windows XP SP2, marketing and the field thought it prudent to refer to IRM as a security feature. The problem is security features imply a promise of robustness in an absolute sense. Either a document or email message was secure, that is it could not be read or forwarded, or it was not. We had those nasty details to contend with such as the Print Screen key (or the more cryptic Prt Scr key on laptops). What if someone was reading a document and took a screen shot? That was a “security bug” according to the customer. The field sales reps were frustrated. The documents and emails were more secure because they were encrypted, but they were not absolutely secure from all forms of attack. Nothing is. After a scramble, work was done to disable screen capture involving the Windows team and marketing repositioned the feature away from security, we thought we were set. At least we thought so.

Once Office11 was available to Microsoft globally in pre-release, IRM quickly became an oft-used feature. Routinely the most interesting mails were rights protected. Re-org announcements, strategy changes, schedule shifts, anything to do with sales numbers, staffing adjustments, and more were reflexively rights protected. Employees started rights protecting snarky threads commenting on other rights protected threads. Along the way, many learned an inescapable workaround for capturing the text of a protected message. Using another new Windows feature that allowed one to remotely log on to another PC, all one needed was a second PC to remote into your primary PC. After connecting, just read the message normally on the remote PC while capturing the screen on the second PC where the session was started. This was not something we could address. Most people didn’t have a second PC so we felt reasonable about this and if administrators wanted, they could disable this capability, primarily used for servers anyway.

The feature, however, came just as mobile phones were gaining cameras and suddenly photos of screens were passed around with the latest news about a reorg or product schedule slip. Mobile phones would prove to be a huge challenge, especially non-Microsoft phones. Microsoft implemented support for protected content on Windows Mobile in a reasonably timely manner and released it to an anxious Microsoft workforce. Those of us still on Blackberry or Treo devices, however, would have no idea what juicy secrets were sitting in a protected message we received while at the movies or out to dinner. We’d rush home to check out the message on a full PC as soon as we could. The proliferation of mobile devices only amplified the complexity of rolling out IRM to an organization. Almost fifteen years later, I joked with the founder of Accompli, a company that Microsoft acquired in 2014 and rebranded as the mobile Outlook client for iOS and Android, that among his first Microsoft duties would be to add IRM support to his product. A request that quickly materialized.

IRM could in no way protect anyone from discovery and litigation. Administrators had all the requisite tools to comply with courts. It was the start of a new era of information control. The era at least in Microsoft, of mail that frustratingly could not be forwarded. A feature of IRM was not just that the mail could not be forwarded but even the attached documents in mail received the same protections as the mail message. Documents could be saved in SharePoint where entire document libraries could be protected against unauthorized sharing. In fact, long memos could be protected so they could not even be printed. Those email attachments had to be Office documents, however, as people quickly learned. Photos or PDF files that were attached to protected messages did not receive those same restrictions.

Office IRM gained many fans inside Microsoft especially with the sales team who simply loved the way it connected all the major company initiatives of Office, Windows, SharePoint, and Windows Server.

Customer usage, however, was far lower than we hoped. This was perhaps in part because most end-users didn’t want to invest the time and effort into dealing with the restrictions and no doubt IT departments could not absorb the complexity to deploy and manage the feature. It was likely that the only team that was able to run much of Microsoft’s mid-2000s era infrastructure correctly, securely, and reliably existed in the 425 area code and carried blue Microsoft badges. Setting up, deploying, and training end-users was beyond the reach of most customers who were struggling to keep PCs functioning and patched with all the latest updates.

Setting up and deploying IRM in a company was an enormous undertaking. Once Microsoft successfully deployed IRM, a Showcase IT whitepaper detailing how MSIT implemented the feature stretched over 40 pages. For an average company to deploy the feature, they would need to invest in hardware and skills training across the Microsoft product line. On top of the typical deployment for desktops with Office and Exchange email, a company needed the Windows RMS server (or several), a Windows Server running Microsoft SQL Server, an SSL Certificate server (the encryption infrastructure), as well as to configure numerous externally facing web addresses for access outside the company network. While these products could be covered by an extensive Enterprise Agreement, typically adding these components was an upsell.

We were creating features that were, for all practical purposes, impossible to consume. More than anything, this defined the era we were enabling. The problem was not that we created these features, but that customers and the sales force were embracing them—not so much deploying the features but embracing the underlying strategy of the features. Complexity was empowerment for the enterprise IT leaders, so it seemed. While there was continued backlash about bloat on the desktop and bloat within Office, the newness of servers and server infrastructure made features that relied on servers seem cool, and they were given a free pass regardless of complexity. The routineness with which IT succumbed to “standing up another server” was incredible. The enterprise account managers did not hesitate to push features that required more infrastructure—doing so was showing more value to customers and good for Microsoft’s bottom line.

IRM was an incredible collaboration across the company. Development teams including Office, Windows, Server, Research, and more contributed to building the feature, while sales, support, and Consulting contributed to selling and working to deploy the feature. It was an amazing sense of pride of execution capability, that I wish was met with as much enthusiasm to deploy and use the feature as routinely as we would have hoped. Today’s Microsoft 365 and Azure made the feature somewhat more accessible and perhaps more usable, though the decisions of an architecture from decades ago still linger in an underlying complexity that was probably good at the time in theory but not good relative to first principles.

Somehow, we had gone from simplicity as the guiding light to complexity as a sought-after competitive advantage. The story of IRM is both one of successful implementation and a cautionary tale of too much focus on customers to the exclusion of what is usable and desirable.

The world turned upside down, or sideways, or something.

On to 074. Outlook Pride, Finally

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit hardcoresoftware.learningbyshipping.com