|
 |
 |
Nondiscretionary Controls: can't live with 'em, can't...
...can't get 'em right. In my quest to build real security into both Notes and Groove, I've repeatedly run into tough issues related to nondiscretionary controls and other challenges in the ex post facto control of released information. I'm well aware of the fact that this sounds, to most people, like a very geeky and obscure problem; something that they shouldn't have to deal with. But in fact it's an issue that's at the forefront of Hollywood's digital dilemma, and it's something that every PC user should really understand. And it's probably worth a rant. Let me first try to explain it in straightforward terms: 1) In order to view or use or otherwise consume information on your PC - regardless of whether it's text, or music, or numbers in a spreadsheet - the information must first be transmitted to your PC. It's there, on your PC. 2) The originator of that information sometimes wishes to exercise restrictive controls over how you may consume that information, even once it's resident on your PC. Perhaps they want to limit it to one listening, or one viewing. Maybe they don't want you to press the "Print Screen" key. Maybe they don't want you exporting it, or forwarding it to someone else, or taking it with you after you leave the company. Let's refer to this as "Digital Restrictions Management", or DRM. 3) Let's even go further and say that you are the original creator of content. But that you create it within the context of a DRM system. Thus, a party other than the creator can limit the creator's free will in exercising control over the content that they created. Welcome to the world of Nondiscretionary Controls. That is, controls that can involuntarily release you of your control. Why is this an issue? Well, people who are serious about security insist that, on principle, you shouldn't give people a false sense of security by creating products that protect information with a veneer that can trivially be stripped away by a competent programmer, engineer, or rocket scientist. The simple rule of thumb is as follows: if the data is on your PC and can be consumed even once, it's ultimately uncontrollable. Why? Because then it's just a matter of cleverness and time and cost before someone can "liberate" it from its controls. (Trusted Computing initiatives and efforts such as Palladium aim to close even these holes, but require hardware not present in today's PC.) But if everything can ultimately be liberated, then why bother trying to control it? For Big Media - which is most often associated with DRM, the situation is indeed tough: from a practical standpoint, DRM is only effective in protecting items of low value that also have narrow distribution. Anything of high value is of course likely worth the cost to break into, and anything distributed broadly will ultimately be cracked and digitally redistributed by someone. But even beyond Hollywood, most businesses, governments, and individual consumers have something digital that they'd like to control - whether it be a revenue projection spreadsheet, a Quicken or QuickBooks database, health records, love letters, or archived eMail. Regardless of one's position on Open Source and Copyright debates, anyone can draw some line within which they'd like to control their digital assets. Call it "intellectual property", or what you will .. it's yours, damn it. And that's why it's essential for PC users to understand that PC products are rife with many different types of controls - some strong, some illusionary, and some that actually yield control to others ... particularly when it's their own information/data that's at stake, and particularly now that most software products are in one form or another "forever tethered to the Mother Ship". As a designer and vendor, controls - real and illusionary, discretionary and nondiscretionary - are a tough issue. For years at Lotus, when working on Lotus Notes, customers kept asking for a feature that would enable the sender of an eMail message to "Prevent Copying or Forwarding" of a message. We kept explaining that there was no practical way to implement it. We could block the Print Screen key. We could disable the Forward and Reply and Export and Save As menu items. But because we couldn't block any programmer from writing a trivial add-in (using the API) to display or extract the email, we resisted implementing the feature for years. Ultimately, we relented due to the combination of competition and customer demand, and the feature exists in the product today. And even though it is indeed trivially defeated, and even though the documentation says that senders really can't control what recipients do, users - who don't know the in's and out's of technology, generally think that control is in their hands. The UI kind-of led them to believe this. As a systems designer, I don't feel great about this. Not at all. I wish that I could figure out a way to help users along in understanding issues of control ... ... but I don't have it figured out yet. At Groove we're still grappling with these very same issues. We've made huge investments in trying to build complacency-immune security into the product. That is, security that - through elegant use of crypto, through careful user interface design, through well thought out and user-tested choices of defaults - enables a user to achieve trustworthiness and confidentiality without needing to do unnatural acts. But in the user interface of Groove, there are still cases in which we need to do more e in order to help people to cope with the concepts behind discretionary and nondiscretionary controls. Groove is Desktop Collaboration Software, meaning, all of the data that you're working with resides "on your desktop", or "in your PC" - as opposed to "on a server". Quite convenient and empowering. But more than once, I've been shocked by a user who has been using Groove for months and months, and then points out "Do you mean that one of the other members of the Shared Space can copy & paste the shared data to a different shared space, sharing it with someone else, without my permission???" Of course, we can only look inward when someone asks such a question: it's our fault for not having communicated the concepts of "control" more effectively to the user. Another such issue arose just yesterday. At the request of a customer, we long ago implemented a feature in the product - a Groove Tool Permission called "View Tool" that enables a space's manager to selectively "disable" a tool - typically to keep others users from actively using that tool while the manager is doing some major work inside, e.g. doing bulk data import or reorganization of data, getting it ready for presentation, etc. But empirically our user interface hasn't helped the user to understand the difference between "tool access" and "data access", e.g. here's someone currently struggling with this issue - who thought that disabling the tool's UI also removed the data from his computer while it was disabled. That if you can't see it, it must not be there. And his point is very well taken: it's not his fault that our UI didn't make it clear that just the tool's UI was being disabled. We'll clearly be revisiting the Permissions user interface design in the next major release of the product. And in an effort to help people to understand the issue, we've updated the product's Web-based documentation, the release notes, the knowledge base, etc. As an industry, we've only seen the tip of the iceberg with regard to content control challenges. Today, most of us access Web sites through browsers. And those of us who are technologists are talking about the day when many or most Web sites offer up Web Services interfaces - so that we can build new forms of readers and information aggregators to conserve time and attention, so that we can implement networks of systems that call upon each other for transactions and services - reflecting the decentralized business environment within which those systems operate. But what happens when one site can more easily "crawl" or "bulk download" or "xml dump" a partner's information systems with ease and with high fidelity, enabled by those Web Services? Google currently has usage restrictions on its own Web Services interfaces, and for good reason. With rich and open access, will contractual controls on use of Web Services data be sufficient, or will we need technical means of use enforcement? How far will Digital Restrictions Management creep its way into the system-to-system realm? A fascinating, frustrating area indeed...
|
