=victor.grey weblog - Home

Single Sign-On Considered Harmful

2008-07-20T19:58:00Z

In the beginning, OpenID was created as a method for mitigating comment spam on blogs. It requires that you provide to the blog (the RP or Relying Party) a URL to which you can be redirected. At the node to which you are redirected is a process (an OP or OpenID Provider) which is capable of doing a little Diffie-Hellman dance with the RP, or an ordinary web page with an HTML tag delegating to another URL where such an OP resides.

This is just fine for the purpose of mitigating comment spam, which only requires that some friction be thrown into the commenting process that makes it too slow or effortful enough to not be worth it for the spammers, but relatively easy to set up for the legitimate commentators.

Where OpenID went off the rails imho, is when the OpenID community starting seeing OpenID as a form of single sign-on (SSO) authentication. First of all, it's not any kind of meaningful authentication. It's trivial to set up an OP that just verifies anyone or anything that applies, and there are a number of such "services" around, but in fact it would be just as trivial to set up an OP that verifies anything that is bounced off it without even any application process. (Since I first wrote these words, I'm informed that there already exists such a wide-open OpenID Provider.)

Worse, SSO even as practiced by other communities such as I-Names and Liberty Alliance where something like real authentication may be accomplished, has several fatal flaws:

Phishing - the end user is allowing themselves to be redirected somewhere and asked to provide their authentication credentials there. This is only safe if the user is sure about where they have been redirected. That surety depends on the user noticing some subtle cues. Phishing mitigators have concentrated on making these cues less subtle. But phishing, like direct mail, is a game of small but predictable percentages, and counts on the fact that some people will be too tired, distracted and/or in a hurry to notice that the cues are wrong. If you are never tired, distracted and/or in a hurry, you're OK.
Trust - in a system intended to be global or internet-scale, how do you know which OPs to trust? Current systems leave this as an exercise for the developer, who generally has no idea what to do. Since trusting no one is not that useful, most current implementations "trust" everyone.
Logout - an end user has a reasonable expectation that if they log in somewhere, that when they log out again they are, you know, logged out. SSO routes around this assumption because the login takes place at a different site than the logout. Even if the RP is responsible enough to redirect the user back to the original OP after logout, it is an entirely un-scalable notion that the OP would then initiate some protocol to log the user out everywhere else they might have used SSO.
Not as sexy as you think - engineers, coders and early-adopter types like the idea of SSO. "You don't have to create accounts all over the internet, it's all handled in one place!" But if you emerge from your den and go out and talk to "real-user" units, you'll find that they are for the most part indifferent. It's just not a killer app.

A small shift in thinking began to remove the scales from my eyes. Single sign-on is essentially third-party authentication, but it's *introductions* that we need from third parties, not authentication! Now, this is certainly not a new or original idea , but I want to share a bit of clarity that has descended on me.

Introductions are a fundamental aspect of our socialization as human beings, perhaps even archetypal. The Granovetter diagram is often used to represent them formally. In the diagram, Alice is connected to both Bob and Carol, and Alice introduces Carol to Bob. The fat arrow on the connection between Alice and Bob represents the introduction itself. It is the technical nature of that introduction that I am discussing here.

The advent of the XRDS standard, which ironically may turn out to be the most important (and not coincidentally the simplest) contribution of the OASIS XRI TC, makes possible a very simple introduction protocol using an SPKI system that might actually work. The rest of this discussion presupposes a familiarity with XRDS.

Here's how it goes: first, the connection between Alice and Bob means that Bob has already been introduced to Alice, either at some time in the past via the protocol we are about to describe, or a priori via configuration. This means that Alice knows how to get Bob's XRDS from a source she trusts. To proceed with an introduction, Bob must have made himself available by publishing an allow-me-to-introduce SEP in his XRDS. A two step process follows.

First, Alice POSTs to the URI in Bob's allow-me-to-introduce SEP with -her- name for Carol, Carol's CanonicalID, Alice's CanonicalID, and Alice's signature over both her and Carol's CanonicalIDs. Her name for Carol is a URI or an HXRI that dereferences to Carol's XRDS, something like "https://xri.example.com/*carol". (This form of an HXRI is admittedly a bit avant-garde, since it doesn't yet exist in the XRI spec, and is only being discussed off-line at the moment. But I'm going to go out on a limb and use it. It's not essential to the protocol and can be modified to match a spec for URI-hostname-based community roots in HXRIs, when there is one.)

Bob's allow-me-to-introduce URI is a "factory" resource - POSTing to it creates a new introduction if successful. Bob already has Alice's public key on record, and/or knows where to look up Alice's XRDS to get it. He should also look up Carol's XRDS to verify her CanonicalID and record her public key for future use. Bob then verifies Alice's signature, and creates the new introduction resource, initially in "expecting" state. He returns a 201 (created) HTTP status, along with a Location header for the new introduction.

So far, all this has taken place server to server, in the background. It could probably be combined with the next step to make a "one click" experience for the user, but as a rule I think it will be better to keep the process as two steps, to facilitate asynchronicity and agent-on-both-sides possibilities, as well as to shield the user from high-latency processes.

In step two, Alice makes the new "expecting introduction" resource available to Carol in the UI as a form button. In the best of all possible worlds, Alice would make the raw introduction URI available to Carol, and Carol would be able to sign and deliver her own response to it from desktop software. But until that happy day, I'm going to assume that Alice is acting as an introduction agent, and has the ability to sign stuff with Carol's private key on her behalf.

Since clicking on the "complete-introduction" button is going to change the state of the introduction resource from "expecting" to "consummated", it should trigger an HTTP PUT, but alas browsers don't do PUT in the early years of the 21st century, so we'll use an overloaded POST. The POST body contains Carol's CanonicalID and her signature over it, so that Bob knows this is really Carol. Bob can now begin his relationship with Carol, which will probably begin with returning a UI to establish a local account for her so that she can authenticate locally with Bob from then on.

Both of the steps are idempotent, i.e. they only work once and further attempts to access them don't change anything. So we don't have to worry about replay attacks, and nonces are not necessary.

Since we are using URI-hostname-based community roots that are not privileging any particular registry, it will be useful to craft a CanonicalID that is globally unique. This can easily be done in a standard fashion by using a UUID. The XRDS will also contain a public key for its entity, in a <dsig:KeyInfo> block.

Now the HXRI dereferences to a globally unique CanonicalID and a public key, as well as a list of service endpoints. The public key can be given a short TTL, thus solving the PKI revocation list problem by totally distributing it.

As long as the HXRI dereferences to the same CanonicalID, it represents the same entity as the last time you saw it -- the fundamental meaning of identity.

Having been introduced to you, we know each other's CanonicalIDs and we each have a way to look up the other's public key. I can then give you access, on my terms, to any data that I control, by having my software agent craft a URI that contains an access key which becomes valid when signed with your private key. That access key thus gives you and you only, access to whatever it is programmed to enable, for some given duration. User-centric data sharing!

Coming next, a more complete description of an implementation of the introduction protocol, and then, working code :-)

Open source and non-profits

2007-05-14T18:42:00Z

Most leaders of non-profit organizations would intuitively understand why using say, recycled paper is a natural fit with their organization’s spirit, even if it has nothing to do with their mission directly. Here’s two representative comments on why non-profit organizations should support green technology and awareness:

“Nonprofit organizations are natural laboratories for learning, testing new ways to serve constituents, and modeling new approaches to existing problems. This is especially true of museums. As places of preservation and active learning, they are particularly well-suited to modeling “green” behavior and design for the public.” – Sarah S. Brophy

“Regardless of your non-profit’s purpose, your organization can probably afford to be a little greener. Being environmentally friendly is beneficial in several ways:

It helps your organization be a good steward in your community and in the world
It can make your organization more appealing to potential donors
It enables your organization to help ensure that future generations can enjoy a respectable quality of life.
While some green measures are costly, many are not – and some can even save or make money.” – Estela Kennen

The key points here are that a non-profit should be a natural laboratory for learning and it should be a good steward in its community and in the world. A non-profit lives via support from the community within which it exists, and it has a moral imperative not only to fulfill its specific mission but also to give back to the greater community in any way it can, but especially in ways that support mutual growth.

Open source software is a perfect fit for non-profits in exactly the same way that green technology is. Some people associate open source with no-cost and therefore low quality, but nothing could be further from the truth. Open source software is community created software. It is a gift to the world from a (sometimes small, sometimes quite large) community of programmers, who believe that by sharing and cooperating they can produce a better working environment for everyone, themselves included. What could be more in alignment with the spirit of most non-profits?

To quote opensource.org, open source “is a development method for software that harnesses the power of distributed peer review and transparency of process. The promise of open source is better quality, higher reliability, more flexibility, lower cost, and an end to predatory vendor lock-in.”

Some non-profits resist moving to open source software because they are naturally conservative and want to stick with the tried and true. But open source has been around for a generation now, and even some of the big software companies such as IBM, Apple, Novell and Sun have begun to find ways to support it.

What’s more, if the mission of your organization is in some way to change the world for the better, then what could make more sense than to align with and support the efforts of other communities who are also working to change the world for the better. After all, creating change may involve embracing change!

JSON forms

2007-03-01T16:03:00Z

I’ve been thinking about how to use JSON as a data interchange format using XRI identifiers and IRAs. You have to love a protocol that can be specified on one page, and there are some compelling reasons to use JSON as an alternative to XML for this purpose. Since XRI data interchange has been known as XDI, I’ll call this JXDI.

This will be a resource-oriented protocol (i.e. REST for the irreligious). Let’s assume that all interactions must be authenticated.

When we authenticate an HTML based interchange, we assume that the client has previously registered with the server, and possesses an identifier (user name) and password that will be recognized by the server. The client supplies these credentials, and if successful receives a header value (a cookie) that will be used to maintain authentication state on subsequent transactions.

JXDI authentication is somewhat analogous. There must be a pre-existing registration process. JXDI is a back-end process happening between two servers, generating an exchange of data that can then be processed for human consumption if desired. Since these are two servers talking to each other, the registration process will consist of the exchange and acceptance of public keys and corresponding XRI identifiers. We’ll worry about how that exchange happens later—it could be some manual administrative process, or possibly XRI trusted resolution or something like it but simpler. We’ll use OpenSSL X509 certs, since the means to generate those is well supported.

Authentication could then happen in several ways. The simplest is for the client to pass an XRI identifying itself, a timestamp, and a PK signature over those two values concatenated. The server, upon verifying that the signature validates with the cert on record for that XRI, issues an opaque session value which the client can use in the header of subsequent requests to authenticate itself for some limited period of time. This is analogous to logging in and receiving a session cookie, and should happen over HTTPS to protect the transaction and also authenticate the server to the client.

A more complex scheme would require as part of client registration that the client certificate be returned signed by the server, so that two-way SSL authentication could happen, passing off the session maintenance to the SSL protocol itself.

So having established a session, let’s do a GET request for the profile data of user with an i-number of ”!1234” and it looks something like this:

GET /profile/!1234.json

The “dot json” extension is a Rails-ism that can be understood in a Rails app to be a request for a response in JSON format. The same thing could be accomplished (less elegantly) with an Accept header.

The response is a JSON form, which unserializes to a data structure (hashes and arrays). It includes one or more fields for the IRAs under which all or various parts of the requested data are available—actually, the pointers (URIs) to those IRAs. The rest of the structure has leaf nodes which at this point are either empty strings (””), zeros for numbers, false for boolean values or null for untyped values. These leaf nodes are the placeholders for the actual data values to be transferred.

This gives the requester two things, the IRA under which the requested data is available, and the data structure and data types in which the data will be delivered—the schema.

To agree to the IRA and receive the data, the requester simply POSTs back to the same URL with the following in the body of the post—

data:JSON string
id:XRI
ts:timestamp
sig:"signature over data+id+ts"

This request, including the signature, is retained by the server to prove that the client agreed to the IRA.

The data is either the whole schema or whatever part of it is desired, but always includes the IRA that covers that part of the schema. The server then returns another JSON form which is the requested schema with the leaf nodes (the actual data) filled in and the IRAs that apply. This JSON form is of course returned as a JSON serialized string, and along with it is a timestamp and a signature with the server’s private key over the JSON string and the timestamp, which the client can retain as proof that the server provided this data under the enclosed IRA.

This should provide all of the elements necessary for a socially enforced data-exchange/reputation network and be simple and comprehensible to boot. No XML parsing (or <shudder>DSIG</shudder>) required! JSON is a very efficient serialization scheme, and unserializes directly into a data structure native to whatever programming language is being used on either end of the exchange.

Even more importantly, this is a highly evolvable procedure.

There's more than one way to GET some REST

2007-02-21T15:13:00Z

There was a heated discussion a while back between some members of the XDI TC about whether REST was worth pursuing, or whether it even meant anything meaningful in the XDI context. It’s clear that REST has its religious zealots (RESTafarians). and that purity is not possible or even desirable for the rest of us. But as a thought process, REST is seductively elegant—think of everything that your application exposes to the user as a resource rather than a service. It’s a subtle but powerful difference.

When I first heard DHH present the RESTful routing concept at the 2006 Ruby on Rails conference in Chicago, I have to admit I was skeptical. I thought the way that the PUT and DELETE verbs were faked into the process as automatically created parameters was ugly and problematical. Especially ugly was the insertion of verbs into a GET string with semi-colons (i.e. “GET /resource;edit”). I mean, yes it’s legal syntax, but if you are creating an app that’s meant to expose resources for all kinds of user agents running on a wide variety of platforms, who knows what that surprising usage will do? Had DHH finally gone off the rails?

Well no, of course it turns out to just be DHH being his usual quirky opinionated brilliant self. I read a bit more about RESTful routing on several Rails tech blogs, but they were written in typical HOWTO style, and weren’t very helpful. (HOWTO style is where the author goes into excruciating detail on the parts of the topic that any interested reader would already know, and then skips right over the essential details that would give the reader some context.) The light finally dawned when I read the section about RESTful routing in the new second edition of the excellent Agile Web Development with Rails.

RESTful routing in Rails is a way to get a whole set of predetermined routes from one simple routing statement. That’s it. If you agree with DHH’s opinion about how to do REST, you get a lot for a little. If you don’t, no problem. Just proceed to map your routes the (slightly) harder way. This exemplifies precisely what is meant when people say that Rails is “opinionated software”. For more on Rails RESTful routing, do read the post (a short article really) on the Ruby on Rails mailing list by Russ McBride’s dog Lelu.

RESTful resources are acted upon by the four HTTP verbs, GET, POST, PUT and DELETE. Except of course that browsers don’t support PUT and DELETE, so really just GET and POST. You immediately have to start cheating, doing things like “GET /resource;edit”. The preceding produces a form suitable for posting edited data to the resource. Lelu defends this as getting a resource under the “aspect” of edit, not sneaking in a verb, though she worries about it. Personally, I don’t see how ”/resource/edit” is any different, and much cleaner. When it comes to REST, it’s the thought (process) that counts ;-)

If you’re thinking about what you expose to the user in terms of resources, then GET ”/resource/edit” gives you a resource for editing (i.e. a form), and POST ”/resource/edit” submits the edited resource to the server, which knows what to do with it depending on the context. Here’s where things get really interesting. RESTafarians don’t seem to like context—they want each URL/verb combination to always produce the same result. That’s great if you’re a semantic webbie who just wants all data to be free and accessible. But what about access controls? What about users owning their own data, and being in control of who gets it and under what circumstances? When you’re talking about personal and/or sensitive data, flexible and robust access controls are the crucial thing.

This is about me not wanting you to be able to edit my personal profile without my permission, IRAs not DRMs. When you bring up access controls, RESTafarians tend to look away and mumble something about “if only the damn browsers…”

But back here in consensual reality, access controls are central to what I am trying to build. “User-centric” identity and reputation networks have a primary dependency on flexible and robust access controls, and things quickly get crazy if you can’t maintain state on a user session. Is it possible to do this and still think resources, not services? Of course.

First of all, let’s dispense with the hang-up about cookies. They’re just HTTP header info, and are as well established and de-facto standardized as anything else about HTTP. RESTafarians bless basic and digest auth but not cookies, on the academic distinction that REST is supposed to be stateless, and cookies maintain state on the server, while HTTP auth maintains state on the client, so from a protocol point of view it’s more pure. But if you use the more secure digest auth, the client and the server have to share a memory of a nonce and the distinction starts to get a little silly, imho.

A cookie should carry no information except state—an opaque string. It is much more flexible than HTTP auth, allowing the developer to, among other things, use SSL for transmitting credentials, but then drop out of SSL to save overhead for subsequent requests. It allows the user to log out! It’s just not practical for the server to not maintain state/context on a complex series of authenticated and authorized transactions with a client, so let’s just get over it and move on. If it’s not pure REST, well we can still derive benefits from the resources-not-services way of modeling our applications, and purity is highly overrated.

Context is part of what defines a resource in my universe. In an application that stores and displays personal profiles for example, my profile has different properties than someone else’s profile. My profile may have a dependent resource called “my_profile/edit” whereas someone else’s profile, “profile/42”, has no such resource. On the other hand, if my authorization context includes say, “admin”, then in that context there may exist a resource called “profile/edit/42”.

This makes beautiful sense to me. I can organize my application into context dependent modules—under “app/controllers/my” is a controller class (My::InfoController) that has no instance methods, but does the authorization checking and model instantiation for those instances that apply to me. Then I can use inheriting controller classes for the various aspects of the profile, i.e. “My::ProfileController < My::InfoController” and “My::BioController < My::InfoController”, secure in the knowledge that their methods are always exposed under the correct authorization for the context.

The applications I’m working on are all about authentication and authorization, because those are the low-level building blocks of identity and reputation. There can be even finer grained distinctions within authorization realms, and trying to manage those within one flat controller hierarchy would lead to madness—I speak from experience on this. So, controller hierarchies will be based on authorization realms in these applications. Within each realm (for example admin or regular-user) there will be various actions that are possible, depending on authorization modifiers.

Even though this scheme doesn’t use the full-blown Rails RESTful routing, which you can probably tell I’m not that thrilled about anyway, Rails 1.2 does provide a little discussed but very nice new parameter to route mapping which I am planning to make extensive use of:

:conditions => {:method => :get}
:conditions => {:method => :post}

This allows a GET request to be mapped to a particular controller and action, and a POST request to the same URL to be mapped to a different action. So for example GET /my_profile/edit delivers a populated form, and POST /my_profile/edit delivers the form data to the action which does the updating. The distinction between creating a new resource and updating an existing one is handled by the context—if we are not referring to an existing resource in context then we are creating a new one. Thus we can do away with the need for PUT.

That leaves DELETE to deal with, which turns out to be even more fun. A GET request to /resource/delete accesses a “delete_confirm” action that produces an “are you sure” page, which contains a form with submit buttons that say “yes” and “no”. A POST to /resource/delete accesses a “delete” action which does the deletion if the parameter value is “yes” or otherwise redirects somewhere without acting.

And there we have a completely flexible RESTfully organized application (at least imho) using only GET and POST.

Phish Stories

2007-01-24T16:10:00Z

Many of the tech and crypto people working on phishing mitigation seem to think that the problem is “how can I connect with anyone in the world in a trustworthy way?” Personally I don’t think it’s all that compelling to be able to communicate with 6 billion strangers. It’s much more interesting to be able to communicate from anywhere with people whose identity and reputation within my circle of communities can be ascertained in a trustworthy way.

OpenID was originally created to mitigate comment spam on weblogs, and it remains excellent for that purpose. Having to prove that you are in control of some (any) website adds enough friction into the process to make robotic spamming less attractive.

The evolution of OpenID as a more general identifier, and the mutual adoption of support for i-names in OpenID and support for OpenID as the primary SSO protocol by the i-names community, has underlined some issues long understood in certain rarefied circles, but only now being discussed in the larger world of OpenID developers. See OpenID Phishing Brainstorm.

The reason that most of these suggestions amount to security theater is that phishing does not rely on snaring a large percentage of its potential victims. In fact a very tiny rate of success can be quite profitable for the attacker. If a small number of the potential victims are tired and/or in a hurry, and fail to notice or choose to ignore the discrepancies in the process, the attack will be successful from the attacker’s point of view. If there is anyone reading this who has never made a mistake on a computer because they were tired or impatient, feel free to exempt yourself from this analysis.

Perfect and unfailing vigilance is not a human trait. Instead we trust, meaning that we enter into a very familiar process with the expectation that it is in everyone’s self-interest to follow the rules and/or that if we encounter any actors who are not following the rules it will be immediately obvious. We drive down the street “trusting” every unknown driver passing in the opposite direction to stay on their side, mainly because there is no case where it is not in their self-interest to do so. (Many years ago, a co-worker of mine was driving home from work very late in the evening. His was the only vehicle on that stretch of the interstate. Imagine his shock, confusion, horror even, when he saw a big semi coming down the highway in the opposite direction on his side! He pulled way over to the right and let it go by, and we can only assume, since there were no reports of an accident in the news, that the truck driver realized his mistake and turned around or got off the next exit.)

The underlying vulnerability in the SSO process is that the principal is being asked to trust an RP, and the RP is being asked to trust an OP. To justify that trust, the RP must properly identify itself to the principal, and its self-interest must be known. The OP in turn must identify itself to the RP. In other words, we must not cross trust boundaries. If we are envisioning an open distributed system that will work for the principal whether they are using their home computer, their iPhone at the airport, or an internet cafe in Budapest, then we can’t depend on any browser plugin or local software. Instead we need to find a way for the principal to put bounds on an otherwise unbounded process, to stay within trust boundaries. All of the permitted actors must share some kind of self-interest for there to be trust.

There are two ways to create trust boundaries. The actors can all be part of some circle of trust, all known to each other. Or, if we wish to create a system in which strangers can interact, then we must have some kind of reputation and/or introduction system. Either way, we must always start at a known trusted location, and follow only trusted links from there. An OP must not accept requests for authentication from an unknown RP. Putting up a screen asking the user if she wants to accept an authentication request from an unknown RP does not work—Microsoft has spent years conditioning users to click “yes” to anything in a desperate attempt to get the damn computer to allow them to get on with their day.

Phishing, remember, is based on hooking the tired, distracted and harassed. A secure system must make it impossible or at least very difficult for the user to do the wrong thing, and not depend on the user to be paying attention.

Online communities can act as trust boundaries for their users. Online communities can affiliate with one another, creating expanding reputation and search networks. They must vet their users in some understood way, and that method of vetting is part of the community’s reputation. The user must only be able to enter the system through their home community’s gateway.

Ordinary phishing is not solved by this scheme—users still need to be educated about email scams and developers need to guard against cross-site scripting. But the big new vulnerability opened up by OpenID and other SSO schemes, caused by the promiscuous redirection of the user by potentially unknown RPs, can be prevented if it’s understood to be the result of violating trust boundaries.

Psychic birds

2007-01-07T15:40:00Z

I saw a presentation a few years ago, at the Institute of Noetic Sciences, which included a video of an investigation that Rupert Sheldrake conducted into a fascinating phenomenon involving an African Gray parrot.

African Grays are very large parrots that are remarkable in a number of ways. They can live to be more than one hundred years old, and are fiercely loyal to their owners. If you own an African Gray, you have a moral responsibility to ensure that it will be inherited by a good owner when you die, since it will very likely outlive you, and to arrange for a long and gradual introductory period between your parrot and its prospective new owner.

African Grays are also noted for their intelligence. They can learn to “speak” with large repertoires, and can learn to associate sounds with properties such as shape, color and composition, so that for instance when asked for a “red triangle” or a “brass circle” they will accurately pick it out of a collection of objects, not confusing it with a blue triangle or a plastic circle.

However all that pales in comparison to what this particular African Gray in the presentation could do. The experiment took place in the owner’s home, which was a two story structure. The bird was upstairs by itself, with a video camera recording what it did. Downstairs, the owner and a researcher sat at a table, with another video camera recording them. The researcher was showing the owner a series of cards with pictures on them. As the owner looked at the pictures, the bird – upstairs in another part of the house mind you – would speak what was on the picture!

Later they interviewed the owner, who said that she first noticed her parrots psychic abilities when she would wake up in the morning remembering a dream, and the parrot would speak some fragment of the dream. So she started leaving a tape recorder running by her bedside, and discovered that the parrot talked off and on all night, narrating her dreams as she had them.

I was walking in the deep woods one day, at a retreat center in Sonoma county, when three ravens started following me. They were not so much flying as hopping from tree to tree, sometimes with a slow powerful flap of the wings for extra thrust. They were “following in front” of me the way a cat will, anticipating where I would go, and they were making the most interesting noises. A soft low caw, like a crow caw played back at very slow speed, and another sound so unlike anything you would expect from a bird that for a while I wasn’t sure it was coming from them—a sound like water flowing over rocks.

Have you ever sat quietly with a close friend, and felt that you have had a deep and meaningful conversation, even though neither of you said a word? That was the experience I had with those ravens that day—hard to pin down, and yet very vivid in my memory even many years later. I learned something from those birds that day, something that I don’t have words for, that can’t be expressed in words. A connection.

There are other kinds of intelligences beside the one we big-brained apes have evolved. Ravens and African Gray parrots are among the most evolutionary recent birds. These descendants of the dinosaurs are, I’m convinced, evolving an intelligence that we mammals may find quite alien, although we have the seeds of it in us as well. It doesn’t depend on a big central nervous system processing unit, being a more distributed kind of system with trillions of cell membranes for nodes. (Do read The Biology of Belief by Bruce Lipton.)

I’ve identified in myself at least three different frequencies of thought. While some people speak of “higher vibrations” as being better, for me it’s just the opposite. The fastest thoughts are the self-talk thoughts, the worrying or planning ahead thoughts, the judging and having myself being judged thoughts. The same thought comes back around every few minutes, sometimes every few moments if there is a lot of emotion behind it. Like a hamster running in a wheel in its cage.

Then there are the creative thoughts. They have a frequency of days to weeks. I will be working on something, and stumped or blocked, I will let it go. A few days (or weeks) later I’ll stumble across something that is just the answer I was looking for. Or the answer will, unbidden, just spring into clarity for me at some random moment in my day.

The longest waves of all are the thoughts that happen over years to decades. These are the thoughts that shape my life. They have no words or images or emotion. They are raven thoughts, pure connection.

John Mack was a Harvard psychiatry professor who studied and tried to help people who believed that they had been abducted by UFOs. I met him once—he was a fascinating and gentle man. “I don’t know what happened to these people,” he told me, “but I know something happened to them. I’ve worked with psychotics for much of my career. These people are not psychotic, not delusional.”

I have my own conjecture about it. If there are other civilizations out there in the universe, and it seems almost certain that there must be, and equally certain that some of these must be millions of years older than our own, where might evolution have taken them? I think that the evolutionary step after (or before or in parallel with) what we are pleased to call “intelligence” is psychic connection. Perhaps these UFO beings are what we call “psychic” to an extent far beyond anything we have experienced, in the same way that we are intelligent in a way far beyond anything a chimpanzee has experienced.

In the presence of that much psychic power it may be that our minds become disorganized, that we aren’t capable of processing what we are experiencing. That what those who have had this experience therefore remember about it is a kind of dream imagery, a representation of the experience in subconscious symbology.

TATWD? WTF?

2007-01-03T16:47:00Z

“The world rests on the back of a giant turtle.” What does the turtle stand on? “Another turtle.” What does that turtle stand on? “It’s just turtles all the way down!”

If you Google the phrase, you get a lot of references to Stephen Hawking and Bertrand Russell. Great men these may be, but I find the setting up of a straw man by reasoning from a literal interpretation of a mystical concept a bit silly, and strangely akin to the claim some folks make to a belief in a “literal” interpretation of the (old English translation of the Latin translation of the Greek/Hebrew/Aramaic) bible. But then, science as an intolerant religion, and what it means to be truly rational… that’s a whole ‘nother post.

Dig a bit deeper, and you’ll find references to John Grinder and Gregory Bateson. Now you’re getting closer to what I mean. There is something deeply moving in the contemplation of infinite recursion. It is one way to come face to face with a mystery, that everything is a construct of my consciousness except right here, right now. That I don’t know where my consciousness came from, that it seems to stand on the back of the previous moment’s consciousness, which stands on the back…

“This statement is false.” Suppose that the preceeding statement is true, then it can’t be true because it says that it is false. OK then, supposing it is false, then it must be true because it says that it is false. While you’re thinking about that, someone kicks you in the shins.

Here’s a couple of quotes¹ from the truly mystical mathematician G. Spencer Brown:

“A mystic, if there is such a person, is not a person to whom everything is mysterious. He is a person to whom everything is perfectly plain.”

“Those of us who have gone back and remembered our births, remembered what we knew, and remembered the covenant we then made with those standing around our cradle, the realization that we now have to forget everything and live a life…”

¹ http://www.lawsofform.org/aum/