Why we can't trust NGSCB

Microsoft is working hard to secure computing, but their approach is one of total lockdown... and doesn't handle one very big problem in the world of software... bugs.

While it's possible that they will be able to attest with a degree of certainty that a given computer is running with known hardware and known software in a known state... it doesn't handle the unknown... bugs in "trusted" applications that haven't been disclosed.

Even the most paranoid software authors make mistakes and bad assumptions, bugs will always be with us. All it takes is one small crack in the code, it your "trusted application" gets compromised. The all or nothing approach doesn't limit the actions of the code, just access to it.

Capabilities allow even malicious code to be run because you don't have to trust it. You limit your trust to the operating system kernel. This is a much smaller attack surface to defend, and one that would be common to all users, and thus get the most eyeball - hours.

Who ever wins the race to get capabilities built into a real-world system first will get to set the direction of computing for the next 10 years.

Mobile code and Security

I was searching around for a quote about things... and found this gem from Arnold J. Toynbee:

Apathy can be overcome by enthusiasm, and enthusiasm can only be aroused by two things: first, an ideal, with takes the imagination by storm, and second, a definite intelligible plan for carrying that ideal into practice.

Now, it's clear to me that we're dealing with apathy when it comes to security. Nobody really wants to have to do the massive amount of work it takes to replace a security model, and we're all willing to put up with "good enough", because we're overwhelmed with stuff to do.

I will keep trying to push both parts of the above equation... talking about the ideal, and helping to author the plan to carry it into practice. This blog is a tool in that process. I thank Doc for the linkage, it's got me charged up... and I thank my lovely bride for her support.

How to recognize to a secure OS

Definition

A secure OS is one which is immune to the threat of mobile code. - me, just now

The need for mobile code

Exposition
We live in a networked world, one that we hope will remain open and unrestricted. It is necessary to secure the ends of the Internet, if we are to have any hope of discouraging the filtering of the middle as necessary for security. Thus, in order to secure a future without censorship and severe limits on innovation and freedom, it is crucial to get a foundation built which we can actually trust.

According to the DoD memo:

Mobile code is a powerful software tool that enhances cross-platform capabilities, sharing of resources, and web-based solutions. Its use is widespread and increasing in both commercial and government applications. In DoD, mobile code is employed in systems supporting functional areas ranging from acquisition to intelligence to transportation. Mobile code, unfortunately, has the potential to severely degrade DoD operations if improperly used or controlled.

Software is the distillation of Knowledge into Executable form. Thus, the sharing of software is the sharing of knowledge. We MUST be able to run other peoples programs without fear of ill consequences. This requires a Secure OS.

It's said that the only secure computer is one that is entirely unusable. I've repeated the story that the only way to secure a computer is

Disconnect it, crate it up, bury it 6 feet down in a concrete vault, and post armed guards... even then it might be secure.

Now, I know that physical access to a machine trumps any software measures, OS, etc... and thus I'm leaving this out of the scope. A typical user doesn't want to destroy is machine, he just wants to use it as a tool, run whatever programs, view whatever documents, and just get on with things. It's our job to make it happen.

Capabilities

A capability explicit permission to do a specific task. Jonathan Shappiro points the way:

The term capability was introduced by Dennis and Van Horn in 1966 in a paper entitled Programming Semantics for Multiprogrammed Computations. The basic idea is this: suppose we design a computer system so that in order to access an object, a program must have a special token. This token designates an object and gives the program the authority to perform a specific set of actions (such as reading or writing) on that object. Such a token is known as a capability.

The concept of capabilities has been around for a very long time, but it's not been chosen as the basis of a security model in a modern OS. The tradeoffs made during the design of our current crop of OSs didn't need to take mobile code into account, obviously things need to be reconsidered.

There's a whole lot more writing and editing to do... I'll cut it off here, and thank you for your time... here are some of the links I used to write this post:

• Arnold J. Toynbee - Wikiquote
• Mobile Code Memorandum - November 7, 2000 - Defenselink.mil
• Google define: exposition
• Google search: eros capability
• OS News - The Reasons Nobody Gets Any Help - Eli Gottleib
• What is a Capability, Anyway? - Jonathan Shapiro
• Google search: Programming Semantics for Multiprogrammed Computations. - locating the 1966 paper

Imagining a secure OS

I have a dream... the following will happen on or before January 1, 2010.

Bill Gates (or Linus) takes the stage, and announces a new Secure operating system. He talks about it's features, how much work it took, etc., etc. Then he does something which would currently be insane... he challenges the world to crash the machine...

He explains that to demonstrate the security of this new OS, they will run ANY program you care to submit to it via the internet, with no questions asked, and report back the results. If you do happen to manage to crash it, you'll get $1000,000, and your 15 minutes of fame.

The site goes live at the demo, and keeps running for years...

And we never worry about applications taking out the OS again.

Free the Photons!

Bruce Schneier points to a scheme by Laszlo Kish to use noise and some good solid electrical engineering to replace quantum wierdness to build an "absolutely secure" communications link. Bruce points out

Generally, if you can eavesdrop you can also mount active attacks. But this scheme only defends against passive eavesdropping.

So, here's my idea for an active attack:

• Survey they surrounding environment for a convinient carrier source, such as a local AM radio station
• If necessary, inject a similar signal into the cable using a passive coupling (crosstalk)
• Insert a pair of directional couplers to cross correlate the source signal and the resultant mismatch returns from each end of the line to measure the resistances.

I'm sure that given sufficient resources, this idea could be modified to use an injected wideband noise source to make it sufficiently undetectable.

I'm intrigued by the efforts of Dr Kish, and I wonder how they'll hold up to this, and other attacks... let the vetting begin!

Capabilities in 2010, or bust

Musings at 3:45 AM...

I'm sitting here, wondering just what it takes to change the world. My goal is simple, to get a secure operating system written by 2010. I'm firmly convinced that Capabilities is the way to get there...

Just how much effort does it take to change the world? I've heard that it's as simple as refusing to go along with indifference, which I suppose is possible if you happen to be right at a tipping point. If you're not that lucky, I assume it takes more work. Maybe you have to find the tipping in progress and help it out a bit...

My challenge is to overcome my own bad habits, work within my limitations, and muster the forces required to research and develop a capabilities based security model layer to replace the access control lists that currently handle the security needs of pretty much every computer out there.

I'm willing to make some tradeoffs, of course...
#1. I don't expect to be able to boil the ocean, so I just want to make something available, and let the market decide if it's a good idea
#1a. So I have to make something that's usable by the leading edge
#1b. I have to justify the effort required to switch

#2. I don't expect to write this myself, because I'm just one guy... and I'm not a programmer

#3. I'm willing to accept help from everyone


Now... here's why this stuff is being written instead of me getting some sleep.

We've had yet another hole in Windows, which threatens everything... we'll do what it takes to patch the hole, and go back to sleep... a reactive behavior pattern which doesn't actually fix the problem. This drives me nuts!

Its a tragedy, and we're all players... it's time to get off the merry go round, and actually do something different... we need to be proactive, and explore real solutions.

How do you know you've got a secure OS?

Simple...

When you can run ANYTHING on it, at ANY time, with NO FEAR.

If you've got a secure OS, you'd be willing to take a CD from any random person on the street, stick it in, and run the damned thing because you know your OS will only allow it to do exactly what you've specified, and nothing else.

If you've got a secure OS, you know that NO application can ever take over the OS, unless you explicitly given it the capability to do so, and haven't revoked it.

If you've got a secure OS, you never have to run a virus scan again, EVER.

If you've got a secure OS, you can just get your work done, and get on with life.

The operating systems we're all using including Windows, Mac OSX, and Linux all are based on some form of username/password with access control lists... which was great 20 years ago, but it's time to move on. We need to put forth the effort to get Capabilities out of the lab, and on to our servers and desktops.

We need to LEAD the world, and make a quantum leap forward (ouch... cliche') in security... and this, I think, is the way forward.

I ask every one of you for whatever help you can give to make this happen. I'll do what I can in return.

Thanks for your time and attention.

--Mike--

Security gets another 15 minutes of attention

They've found yet another hole in the current leading OS. (Windows in this case, but that doesn't really matter in the meta) We're going to give security it's 15 minutes of fame... then promptly go back to sleep again.

We all have short attention spans, and some of us even know it. What's needed is a FIX for this problem... an honest to goodness SECURE operating system, one that withstand even the onslaught of the brightest hackers with millions of funding, because that's the only thing that will actually end this mess.

I've read (and believe) that Capabilities based systems have been mathematically proven to be unbreakable. This is exactly what's needed in the long term. I know it'll take years to get it out of the lab and into our PCs... but damnit... we need it!

I hope this sinks into at least one other person's head.... we need Capabilities based OSs.

Thanks for your time and attention.
--Mike--

It's the Ends, not the Means

I recently wrote a about the nature of the internet. There's a middle ground between too much emotional reflex and too much analysis... and it's an unhappy valley in the middle... where that post landed.

Bob Betcalf wrote in 1998 to respond to the "Death" of the Internet:

As I tried to explain in New York, the Internet is distributed in several dimensions. And one of the Internet's beauties is that it can evolve separately at many points along these dimensions. And evolve it does.

As with any complex system, there are tradeoffs made. Those tradeoffs may become unacceptable with time as the costs that were balanced shift with economies of scale, new technologies, etc. Most of the problems people associate with the Internet are actually problems at the ends of the network, not the means.

Email, for example, was created to allow Academics to send documents to each other. The cost of authenticating the source of a message was considered prohibitive, so it was left out of the SMTP protocol. Now that we have an Internet that is no longer limited to an enthusiast audience, the cost of authenticating the sender is probably far less than allowing the protocol to remain unmodified. I expect some form of authentication to take hold in the next few years. This is one of the many facets of life touched on by the Indentity thread that Doc and others talk about on a regular basis.

The underlying network doesn't need to change to allow a new Email protocol. Just as with most other "problems" with the internet, it won't take a complete replacement to fix things, just work on the affected components.

Internet 2, and Web 2.0 might be nice labels for collecting innovations, but they are generalizations at best. A set of tags to help associate things with, but not specific enough to warrant being a standard.

Technology keeps getting better... if we can keep the uninformed away from policy, we're going to get more and more value from the Internet for many years to come.

Thank you for your time and attention.

--Mike--

The Internet isn't broken, but it is misunderstood.

The folks at MIT's Technology Review assert that The Internet Is Broken and proceed to tell all about the wonders of the MIT project to create a new, better internet. Since I'm suitably offended, and have the free time, I will now proceed to pick this apart as my own way of calling bullshit.

The Internet is a set of applications on top of some well defined layers.
The tone of the article is that the Internet is a monolithic whole, and must be completely replaced. This is a Boil The Ocean view of things, and completely misses the point. The entity commonly know as The Internet is actually a simmering pot of stew on top of a few well engineered layers. The strength of the Internet as a whole is that nobody owns it, and anyone can improve it. It's important to know which layers are responsible for which actions if you want to have an intellegent discussion about making changes, which most pundits seem to lack, or are willing to gloss over to support their cause de jure.

IP - the Internet Protocol
A lot of people think of the Internet as a place, a pipe or other things... it's really just a protocol.
A well engineered protocol that has stood the test of time. The base philosophy is one of doing as little as possible, but no less. The ONLY job of the IP layer is to get a packet from its source to its intended destination address. Just as when you drop a single postcard in the mail, you have a reasonable expectation it will arrive, but no guarantee, the same is said for Internet Protocol packets.

Note: There are some safeguards built into IP based on the lessons of experience. They help avert most of the stupid meltdowns that can occur. For example, because IP is a forwarding protocol, one of the most basic problems is that of an infinite loop. To prevent this, all routers (computer nodes that process IP packets) are required to decrement the TTL counter that exists in every IP packet. If the value of the TTL counter reaches zero, the packet is discarded. It's a simple and very effective means to prevent infinite loops.

Now I could continute into a long dissertation about the other layers... but we'll skip that.

It turns out that Bob Metcalf has already done the work for this post.... back in 1998 he wrote Is the Internet Dead go read it.

Software is never done, either

Doc points out speechs and products aren't ever "finished" in the traditional sense. This is due to the contracting timeframes available. Back in the days of vellum (made from animal skin, literally "the word made flesh"), you had to VERY carfully consider what you were going to do, with almost no chance for correction. Years to produce a work were common, as well as some things that were to be published only after the death of the author. It's a far different world we now live in, with blogs read daily, which even outpaces the heroic efforts of the victorian era Post Office for correspondence.

We just don't have time to "finish" something. The era of having one acknowledged genious per topic has passed on with the increasing specialization and amateurization of knowledge. There are many who can now be an expert in a field outside of their profession. Blogs and the live web make this possible on a scale previously impossible (or impractical). Because the knowledge is distributed in this manner, it's necessary to spread out the consideration and editing, which is what we're all doing these days.

In the world of programming, this is reflected in the trend towards open source, and the recent emphasis on making everything available online, even the currently untested buggy development version just as it comes back in to the SVN revision system. Things will be less polished, less "professional", but of far better quality overall than they have in the past.

Change is the one constant in the universe, and we're all learning to deal with its new ramifications as things get more interconnected.

Thanks for your time and attention.
--Mike--

Useful Abstractions

Michael paraphrases Doc

The URL = an abstraction of...
The IP address = an abstraction of...
The MAC address.

The purpose of abstraction is to move dependencies. This allows specialization, which then allows economies of scale to do their work. When we use an abstraction, we're ceding some control, in order to simplify our lives.

It is important to keep in mind that the dependencies still exist, and need to be managed. We, the technicians and engineers of the world do just that, which is why we get paid the big bucks, right? We're part of the cost of abstraction, which everyone accepts as part of the bargain.

Now, in turn for paying the costs, lets look at the nature and benefits of the abstractions, in reverse order.

The MAC address

The MAC address of network adapters is a useful abstraction of a complete computer or hardware device, because things get moved or upgraded. Imagine if you had to have a wiring diagram for every single pin of every wire in your company in order to do anything. You'd always be using some form of wire tracer to track down problems. MAC addresses free us from the constraints of having to map and manage every physical connection.

The IP address is a useful abstraction of the MAC address, because connections shouldn't require a specific route or knowledge of the network.

You (or your computer) shouldn't need to know the exact circuit path necessary to get data to another computer. Just as a mail address allows anyone to send mail to any address in the world, an IP address serves as a unique identifier to allow a message to find its destination anywhere in the world.

Note: One thing people forget about mail is that there is no security when it comes to the source address of mail. (AKA the Return Address) This tradeoff has been accepted since the inception of public mail services, and is one of the driving forces behind mail fraud laws, etc. This fact is also true about IP packets, and I suspect it will always be true for any store and forward system for sending data.

The URL is useful an abstraction of The IP address, because content shouldn't be tied to a specific server or service.

Now this does skip a layer or two, but is very useful as well. The nature of the URL allows specification of a protocol, server and filespec by name. A uniform set of parameters allows one to access a document via across 3 namespaces in one fell swoop. It doesn't matter if its Gopher, FTP, WWW, RSS, or something completely new, it still can be used as the protocol. It doesn't matter where the server is, the server name leads the way. It can be buried 3 folders down, or can be part of a RESTful address, it doesn't matter... All of this glorious complexity can get put into one URL, and let the tech's worry about the rest.

This brings us to the focus of this posting, what's the next useful abstraction. How does the world work, or better yet, how do we want the world to work?

Here are a few themes and suggestions that come to mind:

Usernames are how computers abstract us, because computers shouldn't be tied to specific people or companies.

Think about it... if everyone had their own PC, and could never share them, there wouldn't be a need to have passwords. As computers moved out of the labs, and became multi-user, it was necessary to find was to abstract people so that the computer didn't have to track each capability for each and every possible person. It's the need to decide what capabilities are given to which people that resulted in the creation of usernames, passwords, and that whole level of abstraction.

When a person has only a handful of accounts, it is reasonable to assume they can manage them. With the growth of services on the internet, it's possible that users might need to have rights assigned to them on computers they don't even know about. It's time for another level of abstraction, which is what the identity folks are all talking about.

Indentity is how we want to abstract our relationships, because we shouldn't be tired to direct personal relationships with each and every server or service on the internet.

Anyone with a resource made available to the internet immediately hits the brick wall first encountered when computers made it out of the lab, the need for relationships. To limit use of the resource, a relationship is imposed, often carrying with it an assymentrical relationship of power, and frequent possibilities for abuse. The only identity we currently have on the internet is the one that we manage to assert through the filter all the imposed relationships.

When someone runs a service, such as a site that allows comments, spam rapidly rears its ugly head. To limit the spam, the usernames and registration get forced on users. Often the signup requires us to disclose far more than is really necessary, but is a tradeoff most make. All of this, just to really say to the service... yes... this person is real, and not a spammer.

There was a joke RFC in the past few years about adding an "Evil Bit" to packets on the internet. A working relationshop system is part of the way to implementing a "Good Bit" for the internet instead. It's a way of asserting identity, and preventing spam. Repudiation, reputation, and all sorts of other terms float into the discussion, but it's really all about trust. Trust that is, and always will, be destroyed by those who game any system.

Usernames worked for a while, but with throw-away email, and other contermeasures, they are rapidly losing their effectiveness. For this reason, the abstraction we'd like to define as "Identity" will happen, and our conversations will hopefully lead developers and the rest of society towards OUR version of this abstraction, and not some corporate DRM 1984 world that might otherwise evolve.

Tags are a general purpose abstraction for categorization, because we're not all reference librarians, and it's good enough.

There are some who have big problems with tags, because they're not specific enough, and they might overlap, and they tend to be a bit messy. What they do for us is allow us to categorize things for the task at hand. On Flickr, they help locate pictures of kittens, elsewhere they help categorize knowledge, websites, RSS feeds, etc. Tags are gritty and human, and just functional enough to get the job done. They serve as useful abstractions of the subject at hand.

Thank you, gentle reader, for your time and attention.

MoonRise at Navy Pier

moonrise2005
Originally uploaded by --Mike--.

I took this photo earlier this year at Navy Pier, here in Chicago. It's a sequence of pictures I took using a tripod, with the camera set to interval. I combined them in Paint Shop Pro to the image you see here.
It was a nice evening, with some pleasant conversations explaining to others what I was doing and why... I'm pleased with the end result.

The frames are about 3 minutes apart.

Wingnuts

Over at Bedazzled, the author states he's not going to filter his opinion out of his blog.... and I say AMEN!

He does indicate that he's on the left end of the scale... which is fine for him. I'm not on the scale myself. The linear scale of "Liberal" to "Conservative" doesn't work for me. I've got a vast range of opinions about things, that are always shifting as I learn and grow, and certainly can't be confined to measurement in any given dimension, let alone a single dimension.

I'm a believer in individual rights, for the most part, but not always.
I believe in limiting goverment, but not always.
I believe in separation of Church and State, but still think a prayer is a good thing.

It's not a black and white world, nor are the mere shades of grey between sides anywhere near enough room to even begin to talk about all these issues.

Cut all of the crap about Conservative/Liberal... it's an artificial dimension, with no depth. Consensus is what really matters, when many become one...

E Plurbus Unum

We're all many dimensional, and always growing. Let's cut the divisive red/blue crap and get back to doing what we really need to do to get this country going in a positive direction. Let's all talk, and converse, and learn to understand and share our many dimensions.

--Mike--

I got Flickr

Doc pushed me over the edge, and I've gotten a Flickr account. I uploaded 900 or so photos yesterday. It's a folder of pictures I gathered when I was getting ready for my first Around The Coyote art fair in 2003.

In the past 8 years I've taken well over 60,000 digital photos. People assume I do nothing but click the shutter all day long, but it's not really true. When it costs anywhere between 20 and 50 cents per exposure, you tend to think before you click... for me an addition exposure is essentially free, so I tend to take multiple views of things, and experiment quite a bit.

The real cost of a good set of pictures is the price of the metadata. The cameras all embed quite a bit of info in the photo, the kind of things Ansel Adams and his generation had to write down and keep track of by hand. It's only now beginng to dawn on me how nice it is to have this info, and the computers in the cameras have been doing it for me all along.

Flickr uses this metadata in a way I hadn't imagined... it grabs the original exposure date, and uses it to build a calendar of the photos I upload, automatically! It's VERY cool.

So, now I can refer to all of my online photos: http://www.flickr.com/photos/--mike--/ as well as the cool set of shots I got on September 3, 2001. There is also a calendar based on the upload date, which for me is far less important, but might not be for others.

It's amazing what $25 can buy these days. I'm very pleased with the results so far.

Now, to add more value, I need to add more tags, which will take a lot of time, but I expect to be worth every minute as well.

--Mike--

Happy Birthday(s)

I'm 42 today. I had a wonderful dinner and celebration with Noran and our friends. It was a VERY nice break after a stressful week.

When I got home, I found that Michael O'Connor Clarke had sent me the first draft of the KillSave Manifesto, which is going to get us off on a very good start in our campaign to kill one of the more offensive or relics from the past, the need to be a save slave. I consider it to be another nice birthday present.

Doc's been doing his web log for 6 years, so that's another birthday, of a sorts.

It's 2am.. time for sleep.

Thanks to friends and family, and you, gentle reader. This is a truly happy Birthday for me.

--Mike--

App 2.0, day 2

So, A co-worker lost an hour or two of work… and I’m ranting about it.

I find it completely unacceptable that we’ve got computers with processors capable of doing 2 BILLION operations per second, and Microsoft Word couldn’t be bothered to save about 20k of text every once in a while. It’s a design failure of the first order, resulting from a culture of good enough thinking, and settling for what’s available.

There is no technological impediment, which caused this loss. Even a humble MS-DOS program can handle things like saving in a background thread. We’re talking small amounts of text here, folks… why did this have to happen?

You could blame the user, because he didn’t happen to pick a file name BEFORE he knew what he was writing… but I’m not falling into that trap. It’s the applications responsibility to make sure it never loses the users work. It’s the Operating System’s responsibility to make sure it never loses the files entrusted to it by applications and users.

It’s pretty simple, we have a failure to fulfill an obligation, of the first order. Now, let’s see what steps could have been taken to prevent this.

User Training:

This is a “blame the victim” strategy. It’s unreasonable to expect the user to know where they want to save something before they begin to compose it. A compromise is to supply default names like, Document1, Document2, etc.

This approach works well, except when a user needs to close a multi-pane application, and is then asked if they want to save changes in Document1, Document2, etc… How are they supposed to know? The binary choice at a moment of stress is bad UI design.

Big Brother:

One could record everything the user types, and save it, as part of the operating system. In this case, it might have sufficed, because the work was pure text. The loss of context, means that this value of this strategy would probably be lost in most other cases.

Saving every step:

My personal favorite, save every keystroke, relevant clock tick, and file operation. This creates a tree of all states of the document, from the root when it is created, or loaded from somewhere without history, until the present, including all alternate futures. An alternate future can arise when you undo, then do something different. It would be quite interesting to have all the states of a document available in a Tree view, with the most recent versions on top. Most operations would have one child node, so the tree would be very deep and not very wide.

If a user gets a chance to undo, it’s merely selecting a different state from a tree.

There are a few ways to take it… blaming the user usually wins, though.

Conclusion:

Here we are in the year 2005, we’ve had interactive text editors for more than 35 years, and we’re still losing things. I’m going back to my text mode roots to explore this problem, though it’ll probably have a windows face on it.

Next steps:

On the Desktop front, I’m going to build an editor that saves all states, from scratch. I’ve got some other ideas about Rich Text which are going to be overlaid on it once the basics work.

I’m unsure of programming language to use. I’ve got Turbo Pascal 7, Delphi 5 Pro, which I’m quite comfortable with. I’m tempted to go with Python, but have to learn all the GUI stuff to do that. I’d like to go cross platform, now that I’ve got a Mac to play with, and Delphi doesn’t do that.

On the Web 2.0 front, I’m going to blog this. I’m also going to inquire with the folks at 37 signals, to see what they think can be done about a web form that uses AJAX to keep the server updated in real time.

In either case, the goals remain the same:

• Never lose the users work
• Always show the current save path
• Always autosave to a working folder, and alert when this fails
• Allow the user to pick up their context across invocations of the editor
• Focus on pure text, and get the fundamentals right
• Test the hell out of it
• Make it open source

Written on the train on the morning commute.

Mike Warot, November 9, 2005

What year is this again?

I was on the train today, trying to pay attention to Doc not paying attention, when I was, of course, distracted by events of yesterday. I had to tell one of the people I help with computers that, yes... he lost an hour or two of work because a certain Word processor allowed him to edit a document with no path....

The podcast goes on, and I'm distracted more than usual by the thought...
It's 2005 and we're still losing work due to bad UI design?

Someone on the podcast then notes that it's 2005, and a huge majority of all text entry on the internet is still done in a TextArea box on web pages.
It's 2005 and most Web isn't Wysiwyg?

So, with those thoughts in mind... here are Mike's challenges to Windows AND Web 2.0:

• Always show the path and status of the document
  
• NEVER permit a user to do work that can't get saved automatically in the background
  
• ASK a user if they want to allow work that can't be saved to the source path
• ALWAYS have a full path available in a RESTful manner
• Random disconnection is a fact of life, NEVER lose work because of it, EVER!

Always show the path and status of the document

The user is multi-tasking, they have a full plate of things to do. They need to know, at a glance, if their document has been saved back to the web server (if it's AJAX, etc) or the file server (Desktop). Provide this info, and keep it current.

NEVER permit a user to do work that can't get saved automatically in the background

Windows applications ALWAYS have a local drive or home folder to save things into, they have no excuse for losing things. AJAX software has the web server to write back to, if the link is down, it's a read-only copy, or some other reason, DON'T LET THE USER PROCEED.

ASK a user if they want to allow work that can't be saved to the source path

If you're going to allow the user to save the document into a namespace (file system on Desktop) and the destination is unavailable (connections get unreliable even in offices), ask the user if they want to proceed working until the resource becomes available, provided you have a secure store to autosave into while waiting.

ALWAYS have a full path available in a RESTful manner

The user should ALWAYS be able to bookmark a document to return to it later. Aside from possible User Authentication, no further hoop jumping should be required to get back to where they were, and keep working. This applies to Windows users as well.

The user should be able to copy this path, and type it into any reasonably competent workstation and pick up where they left off.

The user should be able to read this path over the phone to a co-worker, so they can pick up the same place as well.

Random disconnection is a fact of life, NEVER lose work because of it, EVER!

Years ago I was working on an application that used some ruggedized industrial handheld computers. During a demonstration of retrieving information from the unit, the client asked:

What happens if I disconnect this right now?

I stuttered, and realized I had never thought of that... I took it on faith that it wouldn't happen. It turns out that it deleted all of the users work and left things in a bad state. I rewrote the routines in such a way that the absolute last thing done, (after downloading, parsing, and verifying all of the users data and making sure it was in the database) was to delete the data off the handheld. I did this back in 1989... why can't we do that in 2005?

There has to be SOME way for a user to save their work locally if the original path disappears... plan for it, and test it.

Summary

The desktop and "web 2.0" both have to face the same challenges. The first one to meet ALL of my above conditions will win in more ways than one. The environments pose different challenges, but it's the applications that will make or break the winner.

Thanks for your time and attention.

I still don't get RSS

I don't understand the allure of RSS. I just tried Taskable and I got the impression that I had regressed 10 years or so to the days of Gopher. One gets the thing running (and it's REALLY easy to install)... and one gets real time menus nested arbitrarily deep from sources across the net. Technically it's a stunning achievement... but I don't understand WHY.

I have a set of bookmarks I try to read at least once per day, they are a stack of sets of bookmarks that I have FireFox "open in tabs" so I get about 20 at a time. At present there are Blogs-Blogs8, and "Tin Foil Hat". On a good day, I have time to read all of them in depth. On bad days, I only read a few things, just to keep an eye out for inbound disasters.

What I'm looking for is something that can watch all of these sites, and just download the lastest articles on each into one place so I can read them. It would be nice if I could read them offline on the train during my commute, but that's not essential. It would be very nice if it tracked which ones I actually read.

I thought that's what RSS was all about, but apparently not.

Confused...

--Mike--

The word of Blogs is spreading

Overheard in the middle of South Dakota: a conversation between the locals about how blogs are fact checking everyone.

The word is spreading. 8)

Bloggers are Post Factoid

The reason we love blogs is Context. Bloggers point to the original sources, we maintain all of the context. We don't cut out little factoids and sound bites to spin a situation. That's why we sound genuine. We're not hiding anything behind a well crafted sound bite. It's just that simple.

Welcome to the Post Factoid Era.

Destroying context a factoid at a time

Factoid of the day: No plan ever made to help New Orleans' most vulnerable

This thread first started with the link posted above. Various political games are now beginning to be played using it as a tool to try to shift the blame for the holocaust unfolding on the gulf coast. It's important to be able to follow back to the original resources, the most important of which, in the political context, is unavailable thanks to a paywall.

The New Orleans Times-Picayune on July 24, 2005 published an often quoted, but unavailable article, with the following quotes:

"City, state and federal emergency officials are preparing to give the poorest of New Orleans' poor a historically blunt message: In the event of a major hurricane, you're on your own."

"In scripted appearances being recorded now, officials such as Mayor Ray Nagin, local Red Cross Executive Director Kay Wilkins and City Council President Oliver Thomas drive home the word that the city does not have the resources to move out of harm's way an estimated 134,000 people without transportation."

I've done every concievable Google search, searched the archives, and done about everything I can to get a copy of the article in question via the usual channels. I've now written to the letters section of the paper to try to get the original article.

If this paper didn't have a paywall, and this information weren't hidden in a secret garden, it would be a simple matter to follow the links. Unfortunately, we're left with some dead pointers, and quotes without context, in other words, a Factoid.

Factiod - a wholly spurious "fact" invented to create or prolong public exposure or to manipulate public opinion.

I want to know the circumstances of this story, I want context... it's important to learn the painful lessons of Katrina, the price of ignoring them is too dear. We need all the context we can get in order to learn the correct lessons from this tragedy.


Welcome to the post factoid era. Sound bites will no longer be accepted.

Paranoid by Default

Capablities based systems are Paranoid by Default.

The ONLY things a program are allowed to do are specified by the capablities handed to it.

The main problem in making any point (including capabilties) is that you have to simplify things to the point where someone can grok an example. The downside is that it's deliberately trivialized, so the tendency is to poke holes in the example, and think they scale... which they don't.

Cases of this that I've seen in the past include the arguments for and against pretty much any new technology, including:

• Structured coding
• Object Oriented Coding
• Information Hiding
• Garbage Collection
• Strong Typing

All of these have been attacked at the example level. There are benefits to all of them, and yes... you could write in assembler, but it's more efficient for the programmer to write in a higher level structured manner. Etc, etc.

I need to make a better case for Capabilities (and for the BitGrid, for that matter), and I WILL do so.

--Mike--

Blogs for Dialogs?

Now for some meta-analysis (navel gazing?) of blogs as tools for dialog.

Byran makes a damned good point:

You're asking some pretty big questions, and it's a dialog I'd love to be a part of.

So, if you don't mind a little criticism, I'd like to humbly suggest that you're gonna need a better forum for the dialog; blogger ain't gonna cut it. Too easy to lose stuff as blog posts & their comments roll into the archives. We need something that allows threaded discussion! And a bigger commentbox, maybe with rudimentary WYSIWYG, would also be nice ...

Now, threaded discussions would be nice, but I think that Slashdot has show the model limitations of low cost commenting. Long term discussions tend not to happen there either. I like Doc's idea of subscribing to searches, but can't figure out just how I would search for the thread about capablities without getting every sales slick on the internet.

I think we're going to have to come of with a way of making blog postings into threaded discussion, because a blog (that isn't spam) is an assertion of identity that has a cost.

Ugh.. it's all back to the Identity issue... keeps creeping up, any time you step back and really think about things.

We all want a discussion without spam, and with some maturity, to arrive at the truth.

I'm listening for ideas (and I'm tired... too much news surfing last night)

--Mike--

Apocalypse Now - Version 0.02 (rambling)

I'm sorry for the lenght of this post, I haven't had time to make it shorter.

On Windows Bashing:
I started this conversation when I noticed things poking through the layers of security in my systems, which happen to be Windows based. It is my belief that Linux is no better, given sufficient market penetration.

Byran makes some very good criticisms of version 0.01 of this thread. I may be guilty of a bit of Chicken Little syndrome, or Crying Wolf, or Cassandra, or not... only time will tell.

Open source & Bugs:
When people point out that Open source should reduce the number of bugs in a program, I believe they are right. While fewer bugs are good, it's not going to drive the number to zero. Real security requires Zero exposed bugs, ever. (Which may well be impossible)

George Ou points out that progress is being made on many fronts, including the buffer overflow issues, and a lot of work is being put into tightening things up by many parties, and I applaud everyone's efforts.

I feel that the threat is going to continue to grow in terms of strength. I believe that one needs to be fairly paranoid these days, and that capabilities are just the right amount of paranoid thinking to be encoded into an operating system. ;-)

Byran makes the case that Capabilities can be emulated with the right combination of ACLs. The technical arguments surrounding this get very tricky, very quickly. I believe (and am willing to change my opinion based on the facts and/or good argument) that Capabilities embody a concept which is missing from the current crop of OSs:

Don't trust the code

In a capabilities based system, everything is essentially living in it's own sandbox. The only interactions possible are via the capabilities provided to a given piece of code. A capablities based system should be able to run mobile code without any risk of compromise. Think of capablities as the Java sandbox on steriods.

There are many marvelous programs and components out there, waiting to be written. Java gives a hint as to where this could go. The demo scene (DOS programs limited to 64k) points to the really cool things that can be done, if mobile code could be somehow run safely.

I believe that retrofitting the Capabilities model into the existing Windows and Linux code base is possible, but it'll be a large chunk of work in either case. I believe that efforts in both camps should be supported. It would be nice if they interoperated, or could somehow share code, but I realize that's not likely.

It's been an interesting thread, thanks to Doc Searls, David Berlind, George Ou, and Bryan from AdminFoo for all the support and constructive criticism.

The Tao of Doc

It occurs to me that the best way to ask Doc Searls a question is to merely read what he's already said about it.

A day of conversation (with some self analysis)

I belong to a computer club called APCU. We meet monthly to help solve each others problems though a part of the meeting called "Random Access". During Random Access, we have a moderated discussion (with a series of hand signals to make it easier on the moderator), in which we try to solve the technical issues which have arisen for us in the past month. We also address any other technological questions that may arise. We then usually have an hour of random access, followed by a presentation on a technical topic from one of the club members, or a vendor. We don't tollerate sales pitches, so the technical talks tend to be quite valuable to us.

Because of scheduling conflicts, we didn't have the presentation yesterday, and so we had extended random access. I used the opprotunity to bring my "windows apocalypse" thread into the conversation there. It was very enlightening, to say the least, and I found it quite valuable.

I managed to get some concensus from the group on the overall subject of security:

• ANY system is more secure in the hands of Proficient Technical users
  
• ANY system is less secure in the hands of an "average" user

Now, because we like to think of ourselves as technically proficient, we might be a bit biased, but I felt it quite rewarding to reach this agreement as we ran out of time.

Lunchtime conversation was quite interesting, as I solicited doomsday scenarios (which had crept up in various comments at the meeting). The Avian Flu Pandemic scenario is a new one to me... and given the reputation of the member who brought it up, is something worth worrying about. The Peak Oil scenero ended up being the topic of conversation, however.

As time went on, I found there were a few camps to which one could belong, but we didn't get to any concensus. I don't know if it was a limit of time, the less moderated nature of conversation over excellent food, or the overall nature of the topic, which prevented this.

After sleeping on it, and looking back in retrospect, I find myself wanting. I want to get to the truth in all of this. I want to participate in a dialog, and explore the idea space. It there truely is a problem, I want to be part of the solution. I wonder how well this blog, as well as all of the other means of conversation at my disposal (Phone, IM, Email, Letters, etc.) will work towards this goal.

All of this leads to this question:

• How do I best use this blog as a means of seeking and sharing truth?

I'll be listening,
--Mike--

Capabilities in the real world

Capabilities are the permissions to do some specific task. I wrote this on the train this morning, I hope it helps illuminate the area around security I've been talking about recently.

Imagine a network, where there are billions of accounts. Some of the users have multiple accounts. But in this system, the accounts have no passwords. The social penalties for using the wrong account is the basis of security, along with the usernames secret. (Security through obscurity). Once someone has your username, the only option is to get a different username, and watch the activity more closely.

This IS the situation we all face in the world of Credit Cards, and Social Security. Two factor authentication is seen as THE solution to this problem. In this case, it's like finally allowing the usernames to have a password as well. The only problem is that many sloppy implementations will simply require you to give out your username AND password to make a purchase. If you are given the ability to change the password, and do it frequently enough, you decrease (but don't eliminate) the odds of misuse of the account.

A better system is to use Capabilities. For instance, when you buy something on line, what you really want to do is to grant the permission to extract the amount you specify from your bank. Some vendors are now experimenting with this idea, known as a "one time" credit card number. This is also called a Capability.

When you give a program a capability, it is only good for that use, until revoked, for that one process. No other process can utilize it if they manage to acquire it. If it becomes necessary to distribute the capability to another process, that simply requires another capability, and the OS will then issue appopropriate capabilities to the recieving task.

(Technically, all Capabilities include a GUID, and are locked to a specific process.)

Back to the Credit Card analogy, if you put a capability to withdraw $100 into a message, and someone managed to intercept it, it will be useless to them because it's locked into the recipients identity.

So, I've laid out a practical set of analogies and examples to help demystify capabilities. I've assumed a lot, but I've got a programming background, and I'd welcome discussion on the technical aspects of pulling all of this hand waving off, in a secure manner.

Thought for the day

Capitalism sees Capitolism as damage, and routes around it

New look and feel

I noticed that there were no links to other posts in the old template, so I updated it, and republished everything. Sitemeter is addictive, though I'm sure I'll eventually get over it. Won't I?

Marketing and Blogs

Over at Naked Conversations, Shel Israel answers the question Is Blogging Anti-Marketing? Doc then questions his blog being categorized as a PR blog, while pointing to the assertion that PR is becoming a management function.

What's really happening is that we're all learning the 4th R (along with Reading, wRiting, and aRithmetic) that got left out when mass education took hold in the 1900s... Rhetoric. We bloggers are getting quite good at sniffing out abuses of Rhetoric.

It's only the PR or Marketing or Advertising based on lies that has cause for concern. If your message is true, we'll welcome it. We just don't want to be lied to. It's pretty simple.

For example, the English Cut blog run by Thomas Mahon is marketing, and it's brilliant! It's a behind the scenes peek into a world that I would otherwise know nothing of. It's very effective marketing, and it's a blog.

Does anyone have good Threat Models?

Ian Grigg asks WYTH? (What's Your Threat Model?), and does a pretty good job of explaining the defacto threat model for the internet, the same threat model used in the design of SSL and TLS. Ian then proceeds to point out the bad assumptions, and the need for a better model.

I can't seem to find a good source for the threat model used in Unix or Windows. I can only assume, which I'd rather not do.

It's entirely possible there was no threat model for Unix, but just a common shared set of assumptions and a subconsious model in the heads of the developers.

I want to show how the nature of threats, and the various fudge factors used when guessing about the outcome of a threat tree have shifted drastically in the past 30 years. Once this is brought out into the open, we can discuss how to mitigate and better design future systems.

So, I'm looking for threat models for Unix, Linux and Windows to use in this analysis. Any help would be greatly appreciated.

--Mike--

MetaBlame Brain Dump

A short recap of the thread to date, followed by a brain dump (which I've tried to keep sane)

• I noticed things seeping through the filters, and worried aloud about security.
• Doc Searls suggested it's really Mono vs Poly
• David Berlind points out that Monoculture == Corporate standard, and starts to consider the implications, and the need for discussion
  
• Zotob hit CNN, making the headlines
  
• The Zotob blame game began

I want to get the discussion going again. It doesn't matter whose fault this particular worm gets assigned to, the answer is irrelevant to fixing the overall problem. What really matters is that we correct the bigger picture. (So, I'm doing a Meta-Blame game?)

Here's how I see it... and I'm more than willing to shift my views to fit the facts:

• All 3 major platforms (Windows, Mac, and Linux) have required patches in the last year
• It is safe to assume they all have remaining undiscovered (or undisclosed) vulnerablities
• It is impossible to eliminate all of the bugs in any system
  
• Evil is at work on new exploits, and getting better at it
  
• Day Zero exploits nullify automatic updates as an effective tool

This depressing picture leads naturally to the conclusion that there isn't a single system which will remain secure over time. If we keep using variations of the same strategy, we're going to get the same results.

My social/economic view of the overall driving forces looks like this:

• Evil people provide resources to seek out our vulnerabilities, in expectation of a return on investment (damage to infrastructure, validation of ego, extortion, etc)
• Evil people operate a bazaar (in the lines of the Global Guerrillas theory of John Robb), which distributes knowledge, and distributes the risks
• Offensive Tools which prove effective become commercialized (weaponized?) in this bazaar.
• Defensive Tools which prove effective become commercialized
• Good people also operate a bazaar, (in the lines of the Cathederal and the Bazaar theory of Eric S. Raymond)
• Good people provide resources to defend against attacks, in expectation of a return on their investment (improved productivity, better security, validation of ego, etc.)

You can see there is a mirror-like symmetry to all of this, and information leaks both ways.

When you get to the technical arena the picture includes these elements:

• Exploits must expend resources to search for targets (Time, Bandwidth, Risk of Exposure)
• Once found, attacking the target is a gamble for more resources
• The pool of targets is of finite size
• The cost of acquisition of targets increases as time goes on
• Not all identified targets yield success
• Attack programs are subject to reverse-engineering, and could review their source

On the technical level, it's reasonable and necessary to assume that a perfect defense remains unavailable. It becomes quite prudent (and urgent!) to pursue strategies to reduce the return on investment for a given exploit:

• Diversify our systems to reduce the absolute numbers of each specific vulnerability (as Doc pointed out in Mono vs Poly)
• Utilize IDS and Honeypot systems, along with other monitors, to increase the probability of interception, and decrease the time
• Automatic updates and scanners to block the leakage of resources from known holes eliminate the long term value of exploits as a possible resource base

On the social/economic front, the strategies include:

• support the white-hat community to promote the constructive disclosure of flaws
• stop the blame game which encourages vendors to hide flaws
• community discussion and cooperation in the search for better technologies and social strategies
• re-examination and re-evaluation of the engineering tradeoffs made in our current system designs.
  

The cost of C

We've all come to expect that any given computer program is going to have a bug or two. However, the nature of the cost of these bugs is changing. I feel it's time to re-examine our choice of languages for implementing Operating Systems.

{I'm biased... I admit it... but this isn't meant to be flame bait, and I hope it contributes to the discussion. I'd especially like to know which bits I'm wrong about}

A somewhat short history of programming

In the beginning was the Flying Spaghetti Monster. It was written in assembler, and could do many great and mysterious things with its noodley appendage. It's wrath was written in the core dumps of the devout few who were its followers.

The first programming environments allowed the user total freedom to use the machine as they saw fit. The machines were so expensive, it was well worth some extra time on the part of the programmer to wring out a few operations here and there in the name of efficiency. The hacker culture grew out of this need to wring the most possible work out of the fewest possible machine cycles.

As machines became more powerful, and lower in cost, the benefit of wringing out the extra few cycles decreased, as the programmers time became relatively more valuable. The growing complexity of programs, resulted in the appearance of procedural programming, which breaks programs down to a set of procedures and funtions. C was one of these procedural progamming languages.

Structured programming relies on the concept of limited scope to reduce the coupling between portions of a program, in an effort to localize and reduce the resulting effects of logic errors, and other bugs. The benefits of structured programming are now an accepted fact in most corners of the software development world. Pascal was one of the first popular structured programming languages.

Over time, other improvements have made the scene, including:

• Type checking
• Bounds checking
• Object oriented programming
• Native strings
• Garbage Collection
• Functional Programming
• Aspect Oriented Programming
• Programming by Contract
  

All of these improvements are aimed at improving the productivity of the programmer, at the expense of run time. As computers continute to become faster and less expensive, this appears to be a worthwhile tradeoff.

Why C?

The Unix operating system became widespread in academic circles, and was the first widely ported to a large number of environments. Liberal licensing terms and access to the source code helped spread the popularity of the C language among it's users.

Meanwhile, the computer science community developed a strong interest in the Pascal programming language. UCSD Pascal was widely distributed, but had its share of problems mostly due to the interpreted nature of the UCSD implementation.

The movement towards structured programming in the 1970's met head on with this large body of C programmers. Because programs in UCSD Pascal ran many times slower than those written in C, the C programmers won the battle. This is especially true in terms of Operating Systems design, where speed is more important than programmer time.

C remains the implementation language of choice for operating systems, even in 2005.

The cost of C

We've come to accept that if a given program fails in some fashion, we can track down the bug to a specific piece of code, and just fix it. The costs are limited to the inconvenience and lost work of the user, along with the costs of incorrect outputs. Structured programming limits the action of a bug to its immediate module and those calling it.

However, when pointers are involved, any bug can invalidate the scope limits of everything, including the operating system. Thus pointer bugs can result in seeming random crashes. The debugging of pointer errors is one of the toughest jobs facing a programmer. It is this fact which lead to the introduction of largely pointer-free programming languages.

The C language as utilized today still forces the programmer to deal directly with pointers. Unlike other variables, when a pointer has an incorrect value, the scope of the error immediately becomes unlimited. A single pointer error in any line of C code has the capacity to effect any other variable or result. Thus pointer errors are a special danger.

The C language also does not deal well with complex data types, and buffers for data must be manually allocated and removed. The problem of buffer overflows has been dramatically demonstrated in the various worms that exploited them to great cost in the last few years.

All of this results in C programs tending to have buffer overflow issues, as well as pointer handling problems.

Conclusion

The choice of the C language for implementation of operating systems made sense in the 1970s, but is no longer appropriate as it currently is utilized. The buffer and stack overflows that are more prevalent in C programs provide more targets for exploitation, and reduce our collective security. It's time for an alternative.



I'm just one guy... with an opinion... which might be wrong...

Thanks for your time and attention

--Mike--

Update 5/3/2007 - A commenter left this

A good article describing overflow exploits in a basic language


http://www.loranbase.com/idx/142/1921/article/Writing-Buffer-Overflow-Exploits-for-Beginners.html

You can find the original article (as near as I can tell) here.

Second source software

Doc says that it's not really Good vs Evil, but Mono vs Poly. Doc lays out the case for diversity in our networks, especially in the form of compatible, but different, implementations.

I'll talk more about Evil in another post. Here is yet another set of ideas to add to the pot:

Second source semiconductors

The "Poly" concept that Doc refers to is widely present in the semiconductor industry -- second source.

The nature of semiconductors is that a specialized design is produced in sufficiently large quantities to recover both the design, and the production costs. There are high barriers to entry in the production end of this market, with recent chip fabrication facilities have price tags in the billions of dollars. It is the low incremental costs of mass production that drive the profits of this industry.

Because of the large set-up costs, chips are usually produced in a single large batch sufficient to meet market demand as deemed appropriate by the producer. All of this combines to result in a market which tries to limit the number of designs to the ones that turn out to be most profitiable.

The nature of the market automatically brings the availabilty of any chip into doubt. Other factors which can make things even worse incude fiscal failure of the producers, excessive market demand (competing buyers driving the price too high), and outright disaster.

To reduce the risks for customers, and thus to help sell chips, Suppliers of chips often make legal agreements with other suppliers to provide a backup source of chips of a given design. This then become a good selling point for vendors to use, often explicitly stating where to find the second source. (Usually at the same price)

When the chips are purchased as components to be built into some product, the costs of any changes to the final product makes them very expensive to substitute. If any component can't be acquired, large costs are incurred while seeking a suitable replacement. It is thus natural that a significant portion of the design cost of a new product goes into making sure that all of the components will be available in a timely and cost-effective manner. Engineers thus tend to seek and specify chips with second sources.

The second source then helps to insure availability of a given component. It also helps in another way which is not quite as obvious, troubleshooting. If a given design is found to work well with one suppliers chips, it becomes possible to track down exactly where the fault lies, saving time and energy.

As the semiconductor industry matured, vendors recognized the benefits of second sources, and the value they gave to their customers. It became (and remains) commonplace to see the term "second source" in sales literature, and specification sheets.

Second source software

In the computing world, there are very few second sources. The barrier to production is essentially zero, as anyone can make another copy of a program. Thus, unlike the hardware world, a second source software is that of a second design, as opposed to a second producer.

There are good reasons to avoid second sourcing, and it's cousin "forking". The costs of software are all in development, thus a second source is twice as much work. It is highly unlikely that someone will branch off from a project (fork) in order to produce different code, with the same set of features. It's entirely rational that we would all want to single source as much as possible... until the resulting monoculture brought certain risks with it.

The number one driver for this discussion (from my limited perspective) is the vulnerable nature of our computing infrastructure. Most of our systems all come from a few sources. It's not uncommon to find that a flaw in a widely used library may result in a vunerabilities across a vast number of systems.

So, the incentives are beginning to appear for second sources of software. It's going to take a long time before things start to show up. It's even possible that another solution to the problem can be found which doesn't require such an investment.

Open source

The open source movement plays a part in this picture as well. Open source projects result in a product with NO production costs. The design costs have all been absorbed by the contributors to a given project. The availabilty of source means that literally anyone (even the user) can be considered a second source. In terms of debugging, the user can then delve into parts of the picture that would otherwise be hidden, fix problems, and become a new, and source. So, in this fashion, Open Source is partially equivalent to a software second source.


Prospects for the future

As the market learns, it may eventually make business sense for even the biggest vendors to have some form of second sourcing, but I see this as unlikely soon. (However, if there is money in it, businesses can spin on a dime)

For some users, Linux is a suitable second source. If you're not constrained to Windows-only applications, then you can swap operating systems, and go on with life. The rest of us will bear the costs, and as a result the market as a whole will seek out second sources in the long run.

So, you can see... I agree with Doc, mono is bad, poly is good.

Thanks for your patience, and attention

--Mike--

Secure Computing done right

I worry about security, it's just good sense to be aware of the true nature of the systems we all rely on heavily to get our jobs done, to play, etc. The current crop of Operating Systems all share the same flaws:

• Poor security model
• Poor choice of implementation languages
• Bugs

Windows, OS-X, and Linux all utilize the same security model from Multics, which dates back to the 1970's. It's fine for a cooperative environment, but falls down flat in today's environment. The assumption is that the user knows what they are doing, and can trust all the code they need to run... both of which are obviously false in the present.

The battle between C and Pascal was won by the C++ camp, and as a result we're trying to build operating systems which can't pass strings around, let alone complex objects, as native types. This leads to the buffer overflows, and a whole host of issues that would not be present in a Pascal based environment. (Note that I'm a Pascal fan, so I might be biased and/or wrong here!)

Bugs are a given in software development. The more use and testing of software, the more likely a bug is to be found. It makes sense to re-use working code (which contains the distilled experience of the authors and users), instead of re-inventing it. The price is that a flaw anywhere is a flaw everywhere.

The combination of these three factors combines to present a "perfect storm" in which insecurity is the inevitable result, as follows:

• some error somewhere in the manual code to deal with a pointer and a buffer fails to check the size of a buffer
• data gets copied from an input to the program into the variable after buffer (or into the stack space)
• the program flow can now be captured through careful study of the result of the bug and the engineering of an exploit
• the exploit can then inject code to run as the user (or system process) on a targeted machine
• because the code IS the user as far as the OS is concerned, the bug now becomes a trojan horse, and can open the gates to any desired action

It's the combination of all of these factors, which results in the current vulnerable state of computering as we know it. I started talking about this with Windows, because I'm most familar with it, but make no mistake, Linux and OS-X machines also contain bugs, and the same security model, so in the long run, they are just as vulnerable.

The situation will remain bleak until this trifecta of doom is defeated by concerted action on everyone's part:

• Add Strings and other complex types NATIVELY to C/C++
• OR switch to Pascal ;-) {no I don't expect this to actually happen -- Mike}
  
• Make bounds checking the default
• OR find a code model that makes bounds overflows IMPOSSIBLE (Compile time type checking?)
  
• Ditch the old ACL model in favor of something modern such as Capability based security

Note that this does require work. I believe it's a fairly realistic approach, but it requires leadership from a few places. The GNU Compiler crew should work with everyone to make the required changes to C/C++. If the Microsoft and other compiler vendors went along, the new builds would have fewer holes to exploit, which helps us all.

The other big hurdle (which is NOT optional) is to move from ACL (Access Control List) based security to Capabilities. This is going to force a lot of assumptions built into everything to be re-evaluated, and it won't be trivial. It'll force the drivers out of the Kernel and into User space, which will be a performance hit, but necessary. It'll mean a lot of work for Linus and crew (as well as the folks in the closed source world).

Education as to the details of Capabilities, and the adaptation of them into the scripts and service code will take time, but the benefits will be enormous. Once all of this work is done, we'll have no less than honest to goodness Secure Computers!

• bugs still exist in programs, but are now limited to implementation errors, and variables no longer are subject to random scope violations, resulting in much more deterministic results. (fewer crashes)
• strings and objects can be passed via a native set of operations, reducing the impedance mismatch, and the chance of error handing such items (fewer crashes)
• in the event that some code does turn evil, the extent of the damage is strictly limited to its present runtime capabilities list.

I believe this is the direction we need to take to make things better for us all.

Thanks for your time and attention.
Comments and questions welcome.

--Mike--

Secure computing

Computing in the 21st Century requires participating in an arms race. The virus scanners, automatic updates, spyware scanners, etc. are defensive weapons.

The opposing side has an array of toolkits for writing worms and trojans, a growing network of financial and logistical support from all manner of sources, not to mention the ill directed energy of millions of adolescent males out to prove themselves.

We've become reliant on the patchwork of fixes that has evolved over time.. While encoraging some diversity is a wise and practical step to take to help bolster our defenses, I believe their is an underlying issue needs to be addressed.

Our goal should be secure computing. A secure computer is one which allows the user to trust that the computer operates as intended, and is free from any undesired outside influence. -- Note that this is contrary to definition used by certain OS and Media providers, their secure computer is one which is free from any undesired USER influence.

Windows, Mac OS, and Linux are all built on the same model. A trusted kernel supports a set of applications, using a series of access control lists (ACLs). There is a basic problem of granularity when using ACLs, it all comes down to granting permission per user account. If an application is run with a given account, it as full run to do anything that the specified user is allowed to do. There is no method of limiting a program to a specific set of actions, for example. This problem hasn't been solved in 30 years, nor is a fix for ACL based systems likely in the forseable future.


The alternative, well researched, but not on store shelves, is Capabilities based operating systems. In such a system, tokens are granted to a program to perform certain tasks, or capabilities. An application is thus limited to their available capablities, but no others. This means that services can be given tokens to access certain files, and perform certain actions on them, but no others. Even if an aversary subverts the code running a service, the capabilities limit the scope of action that can be taken by the adversary. The capablities model, if properly implemented (and the devil is always in the details) can be mathematically proven to be secure. (Which can't be done with ACLs)

If we can find and bring to market an open source, capabilities based OS, we gain a very large defensive weapon, though tere will still be other attack vectors. I had thought that capablities were coming soon via GNU Hurd, but a closer inspection of the online documentation seems to indicate they are going with user IDs ... oh well.

Well... the solution is out there... now we just have to find it, time is running out.

Or perhaps I'm just paranoid?

--Mike--

Doomsday planning for a small shop

Doc Searls correctly points out that the Windows monoculture of our computing systems is a weakness. I'm going to be taking his suggestion, and keeping it in play while planning IT strategy from now on.

However, for the present, I'm still going to seek low cost ways to help survive the doomsday scenario I laid out in my previous post, however. It might just be paranoia, but I like to have backup plans, just in case.

Data Lifeboats

In the past few years, the size of backups has increased at a faster pace than the tape drives. Backup to disk has become a relatively inexpensive, and fast way to do things. It occurs to me that it would be quite valuable to be able to read one of these backups while totally disconnected from the network (and any source of threat). A machine so configured could be considered to be a data lifeboat. Just as many small vessles save human lives in the event of a sinking ship, the data lifeboat would be adequate to allow a user to carry on the most essential tasks independent of all of your IT infrastructure. (Note the subtle assumption of multiple backups. If you don't have at least 2 complete backups on a shelf at any given time, you're rolling the dice.)

It should be fairly easy for even the smallest business to have at least one machine, with a complete load of the applications, and all the hardware necessary to directly read the backup drive, ready and tested, and most importantly, unplugged. We all tend to have a steady stream of older computers, and this is a perfect use for one or more of them. If the shit hits the fan, nobody is going to care much about the speed of the machine, just as long as they have something that works. This simple (simple?) measure could save a small business.

Scaling up

You might even want to consider having a set of workstations and a server, all ready to go if things get really bad. Be sure to test the heck out of it, using some spare old network hubs.

In the event of an emergency, you then pull everything infected off the network. Then disconnect from the internet and any VPN connections. Get a your backup server off the shelf, and get the restore going, meanwhile, replace all of the boxes with their older, slower, but clean and safe counterparts. By the time you've got the hardware hooked up, you should be able to let your co-workers have their systems for use. It'll be slower, but they'll definitely understand. You then can start searching for a fix, reformatting, or imagining, or whatever is required, with far less stress from your co-workers and management.

That's a cheap ($) way to deal with doomsday... ugly, but cheap.

I look forward to the discussion.

--Mike--

Windows Apocalypse Now - Version 0.01 (Verbose!)

A storm is brewing, and it's not going to be pretty.

Windows isn't secure. We all know it. We've gotten used to hiding our Windows boxes behind firewalls, running Windows Update on a regular basis. We've all installed and update our virus scanners on a regular basis as well. We've all grudgingly come to accept all of this as part of a normal IT environment.

My day job entails adding value to the hardware and software we've got installed on or corporate network. It can be broken into some components:

• Absorbing uncertainty (proactive and reactively)
  
• Keeping data secure
• Keeping data available

There are a lot of things that can go wrong with complex systems such as computers. IT professionals absorb the uncertainties, and hide the complexity from the users. The basic idea is to make it as much like an appliance as humanly possible. We do the tricky stuff so they don't have to.

History:

The value mix has traditionally been one of keeping the systems running, while trying to balance cost against performance. Data security as slowly crept in scope, but is mostly focused on limiting access to the correct mix of users.

Once upon a time, getting a computer virus was something handled on a case by case basis. It could usually be tracked back to the offending floppy diskette, or email. The damage was usually measured in the amount of time spend doing the cleanup. Virus issues were strictly limited to workstations, as you would never run an application on a server.

Server uptimes were measured in hundreds of days. One old 486box (NT 3.51) running as a backup domain controller ran for more than 400 days before I had to swap out the UPS powering it. Servers did one job, and did it well.

Then the virii started becomeing more frequent. Every workstation had a virus scanner on it to scan files before opening them. Eventually, the scanners ran full time, thow at considerable loss in performance. It eliminated the need to worry about virii for the end user.

As the tempo of virus development began to increase, the need for update mechanisms became apparent. We began telling our users that if the virus scanner was more than 6 months out of date, it was useless. Over time this window became smaller, and we got tired of manual updates, so the vendors solved it by offering automatic updates.

Buffer overflow exploits started showing up on the internet in the form of worms. We treated this threat in a similar fashion to the virus threat. Over time we went from case by case, to manual, to updated, to automatic updates.

Somewhere along the line, it became obvious that Windows wasn't tough enough to deploy directly on the internet. We start hiding our Windows Boxes behind firewalls. This introduced us to the joy of having to support VPNs, but it seemed to be good enough. The Firewall systems themselves also have automatic updates.

When the spam got too bad, we started using keyword filters, then Bayensian (sp?) filters, then we got spam filters as an add on to the virus scanner.


So, here it is in Mid-2005, we've got a continous stream of system patches, and a continous stream of virus definitions, most of our spam is gone, and we're behind a continously updated firewall.

This interlocking system of patches does a good job of hiding the complexity and plugging the holes so that the users can go about their business. However, it's not perfect, but hey, that's why we get paid the big bucks, right? We fix the little issues that pop up, then go back to doing our other work.

This system addresses the growing volume of threats in a fairly straightforward and efficient manner. It's not perfect, but it's amazing that it works as well as it does.

However, I'm not happy. In fact, I'm starting to get very worried. The chinks in the armor are showing up. The end users are starting to get distracted from work again, in a number of ways:

• spam
• phishing
• virii

It appears that these theats have already been dealt with, but my end users are still seeing them... and that worries me.

There is a problem here, widely known as the day zero problem. For practical purposes, there are an essentially infinite number of vulnerabilities in the computer systems we use. A growing number of tools are availble to automate the process of mining for a new flaw to exploit. Tools are usually included for creating a program to exploit the flaw. This new program is called an exploit.

To utilize an exploit, it is then necessary to find target systems which are vulnerable. This requires some form of scanning of the internet address space, and may also include sending emails, queries to DNS or Web servers, as well Google or other search engines. This activity is the first point at which it is possible to react to a threat, if detected.

Once targets have been found, the flaw is exploited, and the target system compromised. This is the second point at which the threat may be detected. Worms may then use the compromised system to futher search and compromise other systems. This is usually done as part of the exploit, and no human involvement is necessary once the exploit has been launched.

There are many complex factors that determine the extent and speed of which an exploit can then propagate across the internet. The discussion of these factors is outside my area of expertise. I am certain, however, that there are two opposing groups working on trying to shift these numbers to their advantage. I'll simplify it down to good, and evil.

It seems to me, based on ancedotal evidence, that the good guys are smart, but they have to be careful. They have to worry about niceties such as preventing false positives, testing, quality control, etc. Testing is good, and necessary, but it's also a delay, and it's got define lower limits.

The lower limit seems to be somewhere between 24 hours and 2 weeks, depending on who you ask, and how you measure. Meanwhile the bad guys can work on things at their leasure, and deploy at will. They are well aware of most of the efforts expended to keep our systems secure, and have worked to build ways around them. A well funded evil person can test his exploit against the latest detection methods commercially available, without fear of discovery.

As much as I want to avoid the analogy, it's a war. Both sides have to test their weapons, but the good guys have to do the testing while the clock is running. Unfortunately, they don't have 2 weeks like they used to. The window for testing is getting smaller, and will, at some point even become negative, due to the other delays inherent in the system.

The recent signs from my users tell me that time is running out. The virus signatures aren't keeping pace. We've not solved the issue, and it's going to come back to us, full force, very soon.

We live in interesting times.

--Mike--

Things that need to be free

Jimbo Wales asks for input trying to put together a list of things that need to be free (open) in the next century. Here are some of my nominations:

• Software - It's going to take a long time, but most software will be open source for practical reasons, including auditing, flexibility, and as an escrow against a proprietary vendor's demise. It will eventually be unacceptable to NOT get the source to programs. People will still pay for it, and Microsoft may even figure out how to dominate it, however.
• Protocols and Standards - TCP/IP, Ethernet, 802.11, and all of the other protocols will continue to be free and open, with competitive proposals working their way into public acceptance. As the manufacturing revolution forces hardware into the open (see below), the embedded standards such as DVD, CD-R, and others will be forced out into the open as well. When anyone can make an optical drive from scratch in their basement, nobody will build in region codes.
• Hardware Design / Firmware - Eventually everything from CPU processor designs all the way to the latest iPod-3D design will work there way into the open. Like software, some will be open source, and some will be the result of a commercial firm and a more traditional engineering process. Everything will have a URL printed on it somewhere, where you can see all of the specs, and find pointers to the user community dedicated to it.
• Manufacturing - Advances in manufacturing technology at the small end will allow you to turn out custom chips, and build your own gadgets in your garage, albeit for more cost than items that are mass produced.
• Patents - The need for the public to be able to review patent applications and derive advancement of the arts will eventually force the entire process out into the light of day. The USPTO will eventually have ALL of the patent application process online. The public will be an essential part of the review process for prior art, which is necessary to stem the tide of bad patents and fleeing patent clerks.
  
• Law - All of the laws will be available online, along with the discussions that lead to the adoption of them, similar to a Wiki. It will be quite practical to find out exactly what tradeoffs and considerations were made when a law is written, making it much easier to follow the spirit of a law, and stop worrying so much about the letter of it. Court decisions and the output of trial processes will also go into a public database. Companies which make their profits from locking up the law,will be forced to reconsider their business model.
• Copyright - If you believe the current "everything is a remix" meme , there is nothing truely original. It's the gathering together of ideas and expressing it as a new synthesis that is valuable, and that will continue to be rewarded and encouraged by Copyright. The extension of copyright as a tool for locking down culture will not last.
  
• Identity - All of our medical, financial, legal, and other information will be available to our guardians and us in an open format. We'll get to decide who gets to access which parts of it, and get an audit trail of everything.
• Culture - A great deal of our culture is tied up in the stories and shared beliefs that make a community. We will not tolerate commodification and lockdown of our culture by large corporate entities.
• Computing - Regardless of the current apparent progress of "Trusted" Computing, we will have general purpose computing for the long term.
• Data - Our stuff, including photographs, movies, writing, poems, music, and all of the other creative and logistical output of our lives will be available to use in an open, known format. The vision of a world locked down by DRM will not come to pass.

Well these things to me seem to be general enough to make a fair start at Jimbo's list.