This blog was originally posted by me as part of the Breadcrumbs blog at MIT's Decentralized Information Group:

"Building accountability appliances involves a challenging intersection between business, law, and technology. In my first blog about how to satisfy the legal portion of the triad, I explained that - conceptually - the lawyer would want to know whether particular digital transactions had complied with one or more rules. Lawyers, used to having things their own way, want more... they want to get the answer to that question in a particular structure.

All legal cases are decided using the same structure. As first year law students, we spend a year with highlighter in hand, trying to pick out the pieces of that structure from within the torrent of words of court decisions. Over time, we become proficient and -- like the child who stops moving his lips when he reads -- the activity becomes internalized and instinctive. From then on, we only notice that something's not right by its absence.

The structure is as follows:

* ISSUE - the legal question that is being answered. Most typically it begins with the word "whether" "Whether the Privacy Act was violated?" Though the bigger question is whether an entire law was violated, because laws tend to have so many subparts and variables, we often frame a much narrower issue based upon a subpart that we think was violated, such as "Whether the computer matching prohibition of the Privacy Act was violated?"

* RULE - provides the words and the source of the legal requirement. This can be the statement of a particular law, such as "The US Copyright law permits unauthorized use of copyrighted work based upon four conditions - the nature of use, the the nature of the work, the amount of the work used, and the likely impact on the value of the work. 17 USC § 107." Or, it can be a rule created by a court to explain how the law is implemented in practical situations: "In our jurisdiction, there is no infringement of a copyrighted work when the original is distributed widely for free because there is no diminution of market value. Field v. Google, Inc., 412 F. Supp 2d. 1106 (D.Nev. 2006)." [Note: The explanation of the citation formats for the sources has filled books and blogs. Here's a good brief explanation from Cornell.]

* FACTS - the known or asserted facts that are relevant to the rule we are considering and the source of the information. In a Privacy Act computer matching case, there will be assertions like "the defendant's CIO admitted in deposition that he matched the deadbeat dads list against the welfare list and if there were matches he was to divert the benefits to the custodial parent." In a copyright case fair use case, a statement of facts might include "plaintiff admitted that he has posted the material on his website and has no limitations on access or copying the work."

* ANALYSIS - is where the facts are pattern-matched to the rule. "The rule does not permit US persons to lose benefits based upon computer matched data unless certain conditions are met. Our facts show that many people lost their welfare benefits after the deadbeat data was matched to the welfare rolls without any of the other conditions being met." Or "There can be no finding of copyright infringement where the original work was so widely distributed for free that it had no market value. Our facts show that Twinky Co. posted its original material on the web on its own site and every other site where it could gain access without any attempt to control copying or access."

* CONCLUSION - whether a violation has or has not occurred. "The computer matching provision of the Privacy Act was violated." or "The copyright was not infringed.

In light of this structure, we've been working on parsing the tremendous volume of words into their bare essentials so that they can be stored and computed to determine whether certain uses of data occurred in compliance with law. Most of our examples have focused on privacy.

Today, the number of sub-rules, elements of rules, and facts are often so voluminous that there is not enough time for a lawyer or team of lawyers to work through them all. So, the lawyer guesses what's likely to be a problem and works from there; the more experienced or talented the lawyer, the more likely that the guess leads to a productive result. Conversely, this likely means that many violations are never discovered. One of the great benefits of our proposed accountability appliance is that it could quickly reason over a massive volume of sub-rules, elements, and facts to identify the transactiions that appear to violate a rule or for which there's insufficient information to make a determination.

Although we haven't discussed it, I think there also will be a benefit to be derived from all of the reasoning that concludes that activities were compliant. I'm going to try to think of some high value examples.

Two additional blogs are coming:

Physically, what does the lawyer expect to see? At the simplest level, lawyers are expecting to see things in terms they recognize and without unfamiliar distractions; even the presence of things like curly brackets or metatags will cause most to insist that the output is unreadable. Because there is so much information, visualization tools present opportunities for presentations that will be intuitively understood.

And:

The 1st Lawyer to Programmer/Programmer to Lawyer Dictionary! Compliance, auditing, privacy, and a host of other topics now have lawyers and system developers interacting regularly. As we've worked on DIG, I've noticed how the same words (e.g., rules, binding, fact) have different meanings."

This blog was originally posted by me as part of the Breadcrumbs blog at MIT's Decentralized Information Group:

Just before the holidays, Tim suggested I blog about "what lawyers expect to see" in the context of our accountability appliances projects. Unfortunately, being half-lawyer, my first response is that maddening answer of all lawyers - "it depends." And, worse, my second answer is - "it depends upon what you mean by 'see'". Having had a couple of weeks to let this percolate, I think I can offer some useful answers.

Conceptually, what does the lawyer expect to see? The practice of law has a fundamental dichotomy. The law is a world of intense structure -- the minutae of sub-sub-sub-parts of legal code, the precise tracking of precedents through hundreds of years of court decisions, and so on. But, the lawyers valued most highly are not those who are most structured. Instead, it is those who are most creative at manipulating the structure -- conjuring compelling arguments for extending a concept or reading existing law with just enough of a different light to convince others that something unexpected supersedes something expected. In our discussions, we have concluded that an accountability appliance we build now should address the former and not the latter.

For example, a lawyer could ask our accountability appliance if a single sub-rule had been complied with: "Whether the federal Centers for Disease Control was allowed to pass John Doe's medical history from its Epidemic Investigations Case Records system to a private hospital under the Privacy Act Routine Use rules for that system?" Or, he could ask a question which requires reasoning over many rules. Asking "Whether the NSA's data mining of telephone records is compliant with the Privacy Act?" would require reasoning over the nearly thirty sub-rules contained within the Privacy Act and would be a significant technical accomplishment. Huge numbers of hours are spent to answer these sorts of questions and the automation of the more linear analysis would make it possible to audit vastly higher numbers of transactions and to do so in a consistent manner.

If the accountability appliance determined that a particular use was non-compliant, the lawyer could not ask the system to find a plausible exception somewhere in all of law. That would require reasoning, prioritizing, and de-conflicting over possibly millions of rules -- presenting challenges from transcribing all the rules into process-able structure and creating reasoning technology that can efficiently process such a volume. Perhaps the biggest challenge, though, is the ability to analogize. The great lawyer draws from everything he's ever seen or heard about to assimilate into the new situation to his client's benefit. I believe that some of the greatest potential of the semantic web is in the ability to make comparisons -- I've been thinking about a "what's it like?" engine -- but this sort of conceptual analogizing seems still a ways in the future.

Stay tuned for two additional blogs:

Structurally, what does the lawyer expect to see? The common law (used in the UK, most of its former colonies, including the US federal system, and most of US states) follows a standard structure for communicating. Whether a lawyer is writing a motion or a judge is writing a decision, there is a structure embedded within all of the verbiage. Each well-formed discussion includes five parts: issue, rule, fact, analysis, and conclusion.

Physically, what does the lawyer expect to see? At the simplest level, lawyers are expecting to see things in terms they recognize and without unfamiliar distractions; even the presence of things like curly brackets or metatags will cause most to insist that the output is unreadable. Because there is so much information, visualization tools present opportunities for presentations that will be intuitively understood.

And:

The 1st Lawyer to Programmer/Programmer to Lawyer Dictionary! Compliance, auditing, privacy, and a host of other topics now have lawyers and system developers interacting regularly. As we've worked on DIG, I've noticed how the same words (e.g., rules, binding, fact) have different meanings.

Music piracy, movie piracy, tv piracy ... we see it in the news all the time. Yesterday's New York Times carried another article about the long-standing battle between major media entities and customers, with the privacy advocacy community weighing in.

The standard arguments go like this:

Media - We own the copyrights. We're only selling you one copy. You're stealing royalties from the artist when you make a copy and give it to your friends and family.

Customer - I bought it. I own it. There are lots of times I can legally share it. No one stops me from copying or lending any book I've bought.

Privacy - We respect media's copyright, but they're overreaching and unnecessarily capturing personal information as part of their attempted solution.

The reality is somewhere in between:

Some of the media's efforts to solve their problem have involved a) locking down the technology to preclude any copying and b) affixing everyone's personal information to the item to facilitate making infringement cases later. Commonly known as "digital rights management" (DRM) they tend to be more "total control' than "management." And, typicaly, these solutions swing the pendulum well past the bounds of traditional copyright law.

The customers aren't entirely in bounds either. Every copy shop I've ever seen will ask for signed permission from the copyright holder if you try to copy chapters or more from a book. And, even the most honest-minded folks tend to forget about the copyright rules at times. Years ago, I was at a dinner where the most otherwise law abiding woman in her 70s asked who wanted her to make them copies of some recent popular movies. (And, I was working for the FBI at the time!) So, some sort of protective action isn't wholly unwarranted.

My proposed compromise:

That dinner has stayed in my mind as the debate has raged and, recently, I had to tackle the question for a small start-up. Since intensively technical solutions were beyond the scope of the budget, I decided to adopt a web analogy to the FBI seal and warning ... a little education, a little guilt, and a little fear.

When a customer purchases the start-up's audio recordings they will get a very short "terms and conditions" statement:

When you buy ONE copy:

PERMITTED
Copies on all your personal devices - your PC, your iPOD, etc.
OR
Giving it to ONE person and deleting your copy
OR
Anything permitted under copyright laws

NOT PERMITTED
Giving, loaning, selling, etc. to more than one person

If you violate copyright law, you could be convicted of a crime and/or ordered by a court to pay money for the damages caused.

This is short enough and in large enough font that more customers will read it and not just skip to the "I accept these terms" button.  If my beta tests show they're still not reading it, I'll probably code the window so it sits on the screen for 15 seconds, the time it would take to read it out loud.

For those with the massive budgets of the major media companies, the product could be embedded with or wrapped in code that forced a pop up of the terms and conditions each time a copy or transfer was directed.  For those who want more, the five traditionally permissible uses of copyright material could be explained and/or the the copy owner asked whether his reasons are among them.  

I know that this is not a perfect solution or a technically non-trivial one.  But, perhaps it swings the pendulum more to the center.  And, as the old adage says, a good compromise is one in which neither party is completely satisfied.  

What do software development and the Titanic have in common? They both hit icebergs! It sounds like a bad joke, but there's an important kernel of truth here.

The software development process, unfortunately, has a predictable pattern. You, as the business leader, meet with software developers and reach agreement on "system requirements." The programmers toil and arrive with the new software and both sides are immediately unhappy. Developers think you change your mind. You think developers don't listen.

What really happens is what I call "the iceberg" phenomenon. Both sides believe they have a meeting of the minds and don't realize that their agreement rests upon a tremendous number of assumptions. You and the developers each understand the words, phrases, and concepts of any requirements document in the context of your own experience and environment. Like an iceberg, the words that are used are the 10% that both sides can see; under the surface lies the 90% that defines their differences and creates the many risks that increase time and cost.

For example, programmers don't know if a particular design will have legal implications or will cause problems for someone in the supply chain. Business professionals are facing time pressures that keep them from providing the tiny details of date formats (12/31/2007 vs 31/12/2007) or country codes which may be critical to the business. On the other hand, I once discovered business professionals phrasing a requirement in a way that was about to cause ten weeks of programming, when the right question reduced the issue to a ten minute text change. That's an iceberg!

So, what's the "sonar" for this problem? Here are four alternatives:

1) Find a translator. If you can, find someone who has worked in both worlds and can serve as the "translator" for both sides.

2) Make everyone a translator. Assign someone to create a "lexicon" - a glossary of terms that are unknown to one side or the other. To avoid definitions filled with new inscrutable terms, ask contributors to check with a twelve year-old to see if the explanation is intelligible.

3) Create ambassadors. When possible,insist that a designer or programmer spend time at the side of the person(s) who will use the system. It's amazing how much the developers can learn through watching the workflow, overhearing an occasional conversation, or a chat at the coffee machine. If they are inalterably offsite, consider collaboration tools, giving people the ability to see and hear as much of the user's current business process as possible.

4) Require an "open" development environment. Remember that the vendor's work is not a surprise Christmas present. Consider the unorthodox approach of keeping the vendor's progress accessible at all times. Rather than waiting for benchmarks, assign someone to regularly view the developer's work. Developers using best practices will have wire diagrams, screen mock-ups, and functioning modules that will allow for course correction long before the code is finished.

I know that everyone is facing business pressure to be somewhere else, doing something else -- usually something that seems more directly relevant to the bottom line. But, I guarantee that time spent with developers while they work will save vastly greater amounts of time and money later.

When building or modifying a web business, consider two broad topics while deciding how to address consumer privacy: volition and culture. "Volition" addresses the voluntariness of the release of information. "Culture" addresses the general perceptions of information in a community.  These are considerations separate and apart from legal requirements or liability potential.

Culture

In our culture, there are norms about what is intended to be private from whom. As a general rule, you can think of information disseminated in concentric rings -- the inner ring is typically a spouse, the next is typically immediate family and closest friends, then business colleagues, acquaintances, and strangers. For example, in the case of pregnancy or serious illness, we tell those closest to us first, then the folks at work, and likely never discuss it with strangers. We do the same thing with our home address or phone number.

At the other end of the spectrum, there is information we'll give to anyone who asks -- "how tall are you?" "is that your bag?" "what's your favorite color?" Generally, this is information which we believe can't be used in any negative way, that won't reduce our competitive advantage in business or social settings.

Volition

The exception to the concentric rings is when we trade a bit of privacy in return for something we want or need. While we wouldn't usually detail our income and debts to a stranger, we'll give that information to a mortgage broker in order to get a home loan. We're conditioned to respond to the most intimate questions of our life to almost any doctor in order to get treatment. To get a job, we may give up information about others who don't even know we've done it -- for example, the home addresses and phone numbers of family members and references.

Privacy Management

When your business is in possession of information about individuals, considering culture and volition will help guide your decisions about what to make public through your website. And, pay attention to how your customer demographic is changing.

Sixteen year-olds and twenty-five year olds may want to publicly list their ages on MySpace because they don't want to socialize with each other, but Barbara Walters is one of a very small number of 78 year-old American women willing to publicly declare her age there. In another country, where age is revered, this might be different.

What someone self-published, on MySpace, their blog, or their professional site can be treated as publishable or share-able in almost all contexts. This is quite different from the care to be taken with information people gave in order to get their bills paid or insurance underwritten, even if they were induced to provide it through the Web. This is generally the information that creates the most controversy.

If you're not certain how your customers will react to something you're considering, imagine it outside a web context.  If you want to post information, imagine how your family member would react if the same information about him was posted on a bulletin board at work.  If you're considering selling customer information, imagine your reaction opening a letter from a company you didn't know that said this same information about you had been sold to them.  

I'm not suggesting that this is your only consideration.  You are in business to make money.  Remember, though, that goodwill is so real that it can be given an asset value and any negative impact to it should be balanced against the potential revenue stream.

A friend just sent me a blog which is a bit of a rant about some comments on privacy or lack thereof. It provides a good basis to discuss some concepts and misonceptions about privacy and technology.

What does privacy mean?

Donald Kerr, a Deputy Director of National Intelligence, said that our culture equates privacy and anonymity. Like the blog author, James Harper -- of the Cato Institute and other esteemed institutions-- I disagree that the terms are equivalent in the eyes of the general public. Webster's dictionary describes being anonymous as being unknown or not identified, while defining privacy as keeping oneself apart or free from intrusion. In our culture, volition appears to be a key differentiator. When I close the blinds, I'm choosing privacy. When no one notices me in a crowd, I'm anonymous.

Is it unrealistic to expect privacy?

Kerr asserts that privacy doesn't exist and cites the availability of personal information through MySpace, FaceBook and Google. From a volition standpoint, Kerr's statement is a mixed metaphor. MySpace and FaceBook are entirely voluntary, people deciding to post things about themselves for their friends or the world to see. Google, making great strides at "organizing the world's information", aggregates personal information that may not have been intended or expected to be shared. I recently showed a friend that in five minutes on Google I could find more than his professional profile -- I produced his home address, his parents, his religion, his political leanings, and something about his finances. This undercuts Harper's contrary assertion that people have retained the ability to provide their identifiers to some "without giving up this information to the world".

Can individuals control privacy?

Kerr and Harper are talking when/whether/how the federal government should have access to individual information, but the question extends farther. Anyone signing up for access to a newspaper or making a purchase on the web is giving bits of himself away. Most typically, the information is gathered in "cookies", established by the websites and stored on the individual's computer. This summer, one study concluded 85% of users were aware of cookies, but only about 28% were able to successfully delete them.

The public's misunderstanding about their control over personal information in cookies extends past their technical inabilities. The misunderstanding is exacerbated by a little legal wordplay. Nearly every "privacy statement" I've ever read on an e-commerce website says that the information may be shared with "afflilates" but then doesn't define that term. Each of these companies could call anyone, any company, or any government agency an "affiliate" and give them access to cookies or sell them the information in the cookies.

[Stay tuned for Part II, where I'll talk about what business leaders and system designers can do to offer more privacy and still meet their business goals.]

At least five years ago, a friend and I were imagining the computer of the future: some tiny little object that projected the "screen" into mid-air. Well, turns out we were close but had it backwards. Yesterday, I discovered the little gadget that projects the keyboard. ITech makes a 3.5 inch gadget that connects via bluetooth technology to a Blackberry and 9 other product groups. It projects a keyboard onto any flat, opaque surface. Cost seems to be around $170 (apparently there's some fluctuation due to currency changes). Reviews seem to be pretty high marks from those who are using it, though there are some pretty low grades from folks who can't get it set up.

Business owners and managers often see Information Technology as a bottomless expense and sometimes wonder aloud what IT professionals are really doing for them. The job descriptions are an alphabet soup of acronyms and sometimes those unknown abbreviations leak into increasingly incomprehensible presentations. Slavish chasing of flavor-of-the-year certifications, software, and trademarked processes overwhelms consideration of the fundamentals.

Why, then, does IT matter? What value does it bring to every business? A computer can calculate or process things faster than a human and can store vastly greater quantities of information. For most businesses, those traits were maximized a long time ago when manual labor and paper file cabinets were replaced. Today, IT's greatest vaue is its contributions to senior management decision making.

Every manager is faced with the same fundamental questions:

1) How do we propose to generate revenue?

2) How should I allocate resources to accomplish that?

3) How well did we meet the revenue goal? Why?

From the business' existing stores of data, IT can provide information to assist in answering these questions. In addition, when needed, IT professionals should know the best sources of data about the performance of the competition, the demographics of the potential customer base, and be first to offer meaningful enhancements to analytic techniques.

Executives should ask the relevance to the business of any IT activity.  Data is "cleansed", "harmonized", and "integrated" not because it makes data processing more efficient but because it provides more accurate answers to business questions which ask "how many?" "who?" "what are they doing?" Software applications and visualization tools should not be replaced simply because enhanced technology is available, but only when these tools change the prism on available information and can provide more relevant insight to a manager or line of business. Even system security should not be enhanced to protect IT, but rather to protect competitive advantage and support client retention. The best IT professionals can and should always address their work from the perspective of the value it provides to the business and the bottom line.