Markets

Thinking Outside the Browser

Even if you’re on a phone, chances are you’re reading this in a browser.

Chances are also that most of what you do online is through a browser.

Hell, many—maybe even most—of the apps you use on your phone use the Webkit browser engine. Meaning they’re browsers too.

And, of course, I’m writing this in a browser.

Two problems with this:

  1. Browsers are clients, which are by design subordinate to servers.
  2. There is a lot that can’t be done with a browser.

So let’s start with subordination.

While the Internet at its base is a word-wide collection of peers, the Web that runs on it is a collection of servers to which we are mere clients. That’s because the Web was was built on an old mainframe model of computing called client-server. This is actually more of a calf-cow arrangement than a peer-to-peer one:

So, while we “go to” or “visit” a website, we actually don’t go anywhere. Instead we request a file. Even when you’re watching or listening to a stream, what’s actually happening is a file unfurling itself into your browser.

What you expect when you go to a website is typically the file called a page. You also expect that page will bring a payload of other files providing graphics, video clips or whatever. You might also expect the site to remember that you’ve been there before, or that you’re a subscriber to the site’s services.

You may also understand that the site remembers you because your browser carries a “cookie” the site put there, to helps the site remember what’s called “state,” so the browser and the site can renew their acquaintance. This is what Lou Montulli  meant the cookie to do when he invented it in 1994. Lou thought it up because the client-server design puts most agency on the server side, and in the dial-up world of the time, that made the most sense.

Alas, even though we now live in a world where there can be boundless intelligence on the individual’s side, and there is far more capacious communication bandwidth between network nodes, damn near everyone continues to presume a near-absolute power asymmetry between clients and servers, calves and cows, people and sites. It’s also why today when you go to a site and it asks you to accept its use of cookies, something unknown to you (presumably—you can’t tell) remembers that “agreement” and its settings, and you don’t—even though there is no reason why you shouldn’t or couldn’t. It doesn’t even occur to the inventors and maintainers of cookie acceptance systems that a mere “user” should have any way to record, revisit or audit the “agreement.” All they want is what the law now requires of them: your “consent.”

This near-absolute power asymmetry between the Web’s calves and cows is also why you typically get a vast payload of spyware when your browser simply asks to see whatever it is you actually want from the website.  To see how big that payload can be, I highly recommend a tool called PageXray, from Fou Analytics, run by Dr. Augustine Fou (aka @acfou). For a test run, try PageXray on the Daily Mail’s U.S. home page, and you’ll see that you’re also getting this huge payload of stuff you didn’t ask for:

Adserver Requests: 756
Tracking Requests: 492
Other Requests: 184

The visualization looks like this:

This is how, as Richard Whitt perfectly puts it, “the browser is actually browsing us.”

All those requests, most of which are for personal data of some kind, come in the form of cookies and similar files. The visual above shows how information about you fans out to a near countless number of third parties and dependents on those. And, while these cookies are stored by your browser, they are meant to be readable only by the server or one or more of its third parties.

This is the icky heart of the e-commerce “ecosystem” today.

By the way, and to be fair, two of the browsers in the graphic above—Epic and Tor—by default disclose as little as possible about you and your equipment to the sites you visit. Others have privacy features and settings. But getting past the whole calf-cow system is the real problem we need to solve.

Now let’s look at what can’t be done with a browser. If you think the answer is nothing, you’re stuck inside the browser box. If you think the answer is something, tell us what it is.

We have some ideas. But first we’d like to hear from you.


Cross-posted at the ProjectVRM blog, here.

0
Read More

The business problems only customers can solve

Customer Commons was created because there are many business and market problems that can only be solved from the customers’ side, under the customer’s control, and at scale, with #customertech.

In the absence of solutions that customers control, both customers and businesses are forced to use business-side-only solutions that limit customer power to what can be done within each business’s silo, or to await regulatory help, usually crafted by captive regulators who can’t even imagine full customer agency.

Here are some examples of vast dysfunctions that customers face today (and which hurt business and markets as well), in the absence of personal agency and scale:

  • Needing to “consent” to terms that can run more than 10,000 words long, and are different for every website and service provider
  • Dealing with privacy policies that can also run more than 10,000 words long, which are different for every website and service provider, and that the site or service can change whenever they want, and in practice don’t even need to obey
  • Dealing with personal identity systems that are different for every website or service provider
  • Dealing with subscription systems that are different for every website and service provider requiring them
  • Dealing with customer service and tech support systems that are different for every website or service provider
  • Dealing with login and password requirements that are as different, and numerous, as there are websites and service providers
  • Dealing with crippled services and/or higher prices for customers who aren’t “members” of a “loyalty” program, which involves high cognitive and operational overhead for customer and seller alike—and (again) work differently for every website and service provider
  • Dealing with an “Internet of Things” that’s really just an Amazon of things, an Apple of Things, and a Google of things.

And here are some examples of solutions customers can bring to business and markets:

  • Standardized terms that customers can proffer as first parties, and all the world’s sites and services can agree to, in ways where both parties have records of agreements
  • Privacy policies of customers’ own, which are easy for every website and service provider to see and respect 
  • Self-sovereign methods for customers to present only the identity credentials required to do business, relieving many websites and service providers of the need to maintain their own separate databases of personal identity data
  • Standard ways to initiate, change and terminate customers’ subscriptions—and to keep records of those subscriptions—greatly simplifying the way subscriptions are done, across all websites and service providers
  • Standard ways for customers to call for and engage customer service and tech support systems that work the same way across all of them
  • Standard ways for customers to relate, without logins and passwords, and to do that with every website and service provider
  • Standard ways to express loyalty that will work across every website, retailer and service provider
  • Standard ways for customers to “intentcast” an interest in buying, securely and safely, at scale, across whole categories of products and services
  • Standard ways for customers’ belongings to operate, safely and securely, in a true Internet of Things
  • Standardized dashboards on which customers can see their own commercially valuable data, control how it is used, and see who has shared it, how, and under what permissions, across all the entities the customer deals with

There are already many solutions in the works for most of the above. Our work at Customer Commons is to help all of those—and many more—come into the world.

 

0
Read More

Where there’s folk there’s fire

That headline was, far as I know, first uttered by Britt Blaser in a March 2007 blog post titled The people’s law trumps the power law. It was thirteen years ahead of its time.

Among many others, Britt was energized by  The Cluetrain Manifesto‘s 95 Theses, which David Weinberger, Chris Locke, Rick Levine and I nailed to the Web in April 1999. Today the one-liner most often quoted from Cluetrain is its the first of those theses: Markets are conversations, which then became the title of a chapter in the book version of the Manifesto, which appeared in January 2000 and quickly became a business bestseller. Today the word “cluetrain,” which didn’t exist before 1999, is tweeted daily by people all over the world and appears (says Google) on more than 1.3 million Web pages.

In the 10th Anniversary (2010) edition of the book, I explained that markets were actually three things:

  • transactions,
  • conversations, and
  • relationships

I learned that separately from two teachers, weeks apart in 2000. Both were responding to Cluetrain‘s markets are conversations line, which became a runaway marketing meme shortly after the book came out. One of those teachers was Eric S. Raymond, a devout atheist and libertarian who almost single-handedly made open source a thing, starting two years earlier. The other was Sayo Ajiboye, a Nigerian pastor I met on a plane.

Both suggested markets are relationships as a corollary to markets are conversations and markets are transactions; but it was Sayo who gave me the assignment I’m still working on here with Customer Commons: to make markets are relationships far more real than what customer relationship management (CRM) and related corporate functions imagined it was, because they were all too busy thinking markets are transactions. Seeing markets as conversations would be a step forward, Sayo said, but not a big enough step. Relationship was key to fully realizing free, open and productive markets in the industrial world, and it could only be fully achieved by working on solutions from the customers’ side.

That’s why I started ProjectVRM at Harvard’s Berkman (now Berkman Klein) Center in 2006, and why it’s still going strong today, both by itself and in the forms of Customer Commons (its one direct spin-off), the IEEE 7012 working group, and lately the Me2B Alliance as well. (The 2 in Me2B is about relationship, as I explain here.)

I’ve written about my encounter with Sayo in a number of places. But the most relevant to our work here is Mashing Up a Commons, published in the June 2006 issue of Linux Journal, three months before I became a fellow with the Berkman Center and started ProjectVRM. Without that encounter, there is a good chance neither would have happened.

Mashing up a commons is still our assignment. I believe it will be the most leveraged thing to happen to markets since the Internet showed up. I first explained why in Free Customers Make Free Markets, posted in November 2007. It closes with the headline above.

The time wasn’t right then, but it is now. Let’s do it.

0
Read More

Lorem ipsum

Recent Posts