r-button

You are currently browsing articles tagged r-button.

Let’s use the ‘No Track’ button we already have

February 23, 2012 in Berkman, Business, Law, problems, VRM | 3 comments

(Cross-posted from the ProjectVRM blog.)

left r-buttonright r-buttonFor as long as we’ve had economies, demand and supply have been attracted to each other like a pair of magnets. Ideally, they should match up evenly and produce good outcomes. But sometimes one side comes to dominate the other, with bad effects along with good ones.

Such has been the case on the Web ever since it went commercial with the invention of the cookie in 1995, resulting in a  in which the demand side — that’s you and me — plays the submissive role of mere “users,” who pretty much have to put up with whatever rules websites set on the supply side.

Consistent with  (“Power corrupts; absolute power corrupts absolutely”) the near absolute power of website cows over user calves has resulted in near-absolute corruption of website ethics in respect to personal privacy.

This has been a subject of productive obsession by  and her team of reporters at The Wall Street Journal, which have been producing the  series (shortcut: http://wsj.com/wtk) since July 30, 2010, when Julia by-lined . The next day I called that piece a turning point. And I still believe that.

Today came another one, again in the Journal, in Julia’s latest, titled Web Firms to Adopt ‘No Track’ Button. She begins,

A coalition of Internet giants including Google Inc. has agreed to support a do-not-track button to be embedded in most Web browsers—a move that the industry had been resisting for more than a year.

The reversal is being announced as part of the White House’s call for Congress to pass a “privacy bill of rights,” that will give people greater control over the personal data collected about them.

The long White House press release headline reads,

We Can’t Wait: Obama Administration Unveils Blueprint for a “Privacy Bill of Rights” to Protect Consumers Online

Internet Advertising Networks Announces Commitment to “Do-Not-Track” Technology to Allow Consumers to Control Online Tracking

Obviously, government and industry have been working together on this one. Which is good, as far as it goes. Toward that point, Julia adds,

The new do-not-track button isn’t going to stop all Web tracking. The companies have agreed to stop using the data about people’s Web browsing habits to customize ads, and have agreed not to use the data for employment, credit, health-care or insurance purposes. But the data can still be used for some purposes such as “market research” and “product development” and can still be obtained by law enforcement officers.

The do-not-track button also wouldn’t block companies such as Facebook Inc. from tracking their members through “Like” buttons and other functions.

“It’s a good start,” said Christopher Calabrese, legislative counsel at the American Civil Liberties Union. “But we want you to be able to not be tracked at all if you so choose.”

In the New York Times’ White House, Consumers in Mind, Offers Online Privacy Guidelines Edward Wyatt writes,

The framework for a new privacy code moves electronic commerce closer to a one-click, one-touch process by which users can tell Internet companies whether they want their online activity tracked.

Much remains to be done before consumers can click on a button in their Web browser to set their privacy standards. Congress will probably have to write legislation governing the collection and use of personal data, officials said, something that is unlikely to occur this year. And the companies that make browsers — Google, Microsoft, Apple and others — will have to agree to the new standards.

No they won’t. Buttons can be plug-ins to existing browsers. And work has already been done. VRM developers are on the case, and their ranks are growing. We have dozens of developers (at that last link) working on equipping both the demand and the supply side with tools for engaging as independent and respectful parties. In fact we already have a button that can say “Don’t track me,” plus much more — for both sides. Its calle the R-button, and it looks like this: ⊂ ⊃. (And yes, those symbols are real characters. Took a long time to find them, but they do exist.)

Yours — the user’s — is on the left. The website’s is on the right. On a browser it might look like this:

r-button in a browser

Underneath both those buttons can go many things, including preferences, policies, terms, offers, or anything else — on both sides. One of those terms can be “do not track me.” It might point to a fourth party (see explanations here and here) which, on behalf of the user or customer, maintains settings that control sharing of personal data, including the conditions that must be met. A number of development projects and companies are already on this case. Some have personal data stores (PDSes), also called “lockers” or “vaults.” These include:

Three of those are in the U.S., one in Austria, one in France, one in South Africa, and three in the U.K. (All helping drive the Midata project by the U.K. government, by the way.) And those are just companies with PDSes. There are many others working on allied technologies, standards, protocols and much more. They’re all just flying below media radar because media like to look at what big suppliers and governments are doing. Speaking of which… 🙂

Here’s Julia again:

Google is expected to enable do-not-track in its Chrome Web browser by the end of this year.

Susan Wojcicki, senior vice president of advertising at Google, said the company is pleased to join “a broad industry agreement to respect the ‘Do Not Track’ header in a consistent and meaningful way that offers users choice and clearly explained browser controls.”

White House Deputy Chief Technology Officer Daniel Weitzner said the do-not-track option should clear up confusion among consumers who “think they are expressing a preference and it ends up, for a set of technical reasons, that they are not.”

Some critics said the industry’s move could throw a wrench in a separate year-long effort by the World Wide Web consortium to set an international standard for do-not-track. But Mr. Ingis said he hopes the consortium could “build off of” the industry’s approach.

So here’s an invitation to the White House, Google, the 3wC, interested BigCos (including CRM companies), developers of all sizes and journalists who are interested in building out genuine and cooperative relationships between demand and supply::::

Join us at IIW — the Internet Identity Workshop — in Mountain View, May 1-3. This is the unconference where developers and other helpful parties gather to talk things over and move development forward. No speakers, no panels, no BS. Just good conversation and productive work. It’s our fourteenth one, and they’ve all been highly productive.

As for the r-button, take it and run with it. It’s there for the development. It’s meaningful. We’re past square one. We’d love to have all the participation we can get, from the big guys as well as the little ones listed above and here.

To help get your thinking started, visit this presentation of one r-button scenario, by Adam Marcus of MIT. Here’s another view of the same work, which came of of a Google Summer of Code project through ProjectVRM and the Berkman Center:

(Props to Oshani Seneviratne and David Karger, also both of MIT, and Ahmad Bakhiet, of Kings College London, for work on that project.)

If we leave fixing the calf-cow problem entirely up to the BigCos and BigGov, it won’t get fixed. We have to work from the demand side as well. In economies, customers are the 100%.

Here are some other stories, mostly gathered by Zemanta:

All look at the symptoms, and supply-side cures. Time for the demand side to demand answers from itself. Fortunately, we’ve been listening, and the answers are coming.

Tags: , , , , , , , ,

EmanciPay

July 19, 2010 in Business, Future, Life, music, Technology, VRM | 8 comments

At ProjectVRM we call EmanciPay “a relationship management and voluntary payment framework in which buyers and sellers can present to each other the requirements and options by which they are willing to engage, or are already engaging”. These include preferences, policies and choices about what to pay and how. (Actual payment would be carried out by PayPal, Google Checkout or some other system built for the purpose.)

All of this is new stuff for buyers, and we’re not building it all out at once. In fact, we’re starting with a small piece of code for the seller’s side, so they can signal willingness to engage with buyers in the free and open marketplace, rather than only in the sellers’ own silos. If they want to signal that willingness (which we might call “VRM-friendliness”), they’ll include a bit of RDFa code in their Web pages. If that code is present, the seller’s r-button goes from a default gray to red. If the user already has a relationship (or has had some other interaction) with the seller, the buyer’s side r-button also turns red. So, in this mocked-up example —

— I can see that KQED is VRM-friendly, and that I already have had some kind of dealings with the station.

Right now the code for both sides is in the works, and is also a Google Summer of Code (GSoC) project. It builds to a large extent on Tipsy, described as a “a framework for voluntary donations to bloggers, musicians, and other content creators on the web”. Tipsy is the creation of Oshani Seneviratne and Adam Marcus, both grad students at the MIT Computer Science and Artificial Intelligence Laboratory (CSAIL), whom I got to know through David Karger, a professor at CSAIL, whom I got to know through Keith Hopper, who fathered ListenLog. Our GSoC programmer is Ahmad Bakhiet, a student at Kings College London.

When we’re through with the current stage, we’ll be ready to test out the seller’s side code with stations (or with anybody), which will include means for deciding what happens when the user clicks on the right-side r-button. What matters most at the first stage is the signal of VRM-friendliness, which is a huge state-change form the old silo’d business-as-usual. What it says is “I’m open to what you bring to the market space between us, and to a potential relationship.”

We have this in the real brick-and-mortar commercial world, but not in the e-commerce world, for the simple reason that we have lacked mechanisms for creating the open market spaces between buyers and sellers — the space in the middle here:

Phil Windley of Kynetx gives a perfect “History of E-Commerce” slide in his talks. It goes,

1995: Invention of the cookie.

The End.

Cookies are bits of code that sites put in your browser to help them remember stuff about you. These are handy in many ways, but they also put all responsibility in the hands of those sites — of the sellers.

And if you want to do serious shopping, you can’t just put down cash or a credit card, do your business and walk away. No, you have to register. And to do that you need to accept terms of service that are known in the legal trade as contracts of adhesion. These are usually not read by users for several reasons, the most important of which is that they are not negotiable. Whether or not they are unconscionable, or enforceable, is beside the point. If you want to do business, you have to agree.

Where contracts of adhesion apply, markets are not conversations.
Needing to accept these contracts is a big source of friction in the online marketplace. It’s one of those areas where things are slower online than off. It is also therefore one of those areas where the better model is the familiar offline brick-and-mortar one. (In fact, one could argue that loyalty cards bring to the brick-and-mortar world one of the more annoying inventions of online retailing.)

So that’s a big part of EmanciPay’s challenge, and something we’ve been working on at ProjectVRM. What we’re working to create is a two-sided approach to eliminating the need for users to accept one-sided contracts. We’re creating code with easily-understood wording and symbols, which can be read by lawyers, ordinary users, and machines (ideals first articulated by Creative Commons.) This code can be used for expressing preferences, policies and bases on which each side can trust the other. There’s much more that can go on both sides, but those are a start.

When you click on the seller’s r-button in EmanciPay, you might see a pop-down menu that looks like this:

The new item there is the symbol I’ve labeled “terms”. It’s one half of the iconic “scales of justice.” A similar one might be on the buyer’s drop-down menu as well. Also there might be preferences, standing requests for products or services, links to personal data stores, or whatever we feel like putting in there.

We see the r-buttons and their affordances as places where both the buyer and the seller (or the individual and any organization — this needn’t be limited to commercial settings) can offer, selectively, means of engagement and the data required.

But one of the first jobs here is to get the paranoid lawyers out of the room and the engagement-oriented ones in the room, to help describe new terms of engagement that yield little or nothing in real protection, while offering means for engagement that reduce or eliminate the frictions to which we have become too accustomed over the last fifteen years.

While we’re still baking EmanciPay, I want to visit some questions about what my actual or potential interactions with KQED, WBUR, WWOZ and other stations on my ListenLog might be. There are many possibilities here. One might be to take a budget that I pay down proportionately through time. Another might be to just throw some money now and then at sources of programs that I’ve found especially good — or that I like right now, for that matter. We can be real-time about this. Another might be to pledge money to stations where which I spend more than X amount of time. The list can go on.

I can also, at my discretion, also share some or all of my data with stations and other parties (such as program hosts or producers).

And I can also open myself to programmatic approaches, created by other parties, that work inside the EmanciPay framework. The possibilities are endless here, and suggestions are welcome.

At this stage we plan to test out and play with EmanciPay at first by using Tipsy‘s lottery model. In this one, listeners pay one source, on (say) a monthly basis, with the source being chosen as the winner of a lottery. In other words, if you look at the list of stations on my ListenLog, I would budget $X per month to pay out to some lucky public radio station. Code on the station’s side (the same code that lights up the seller’s r-button) would make them eligible for winning my monthly lottery. At the end of the month, the lucky station gets paid. Get enough listeners and stations involved, and we can have some fun with it.

But that’s just a small first step. The ones that follow will shake down richer and more symmetrical, involved and cross-informative relationships between stations and listeners — and then expand out into other territory, I hope starting with the music industry. From there we can move on to other content industries, and then to the broader marketplace in general.

If all goes according to plan, r-buttons will be commonly used and well-understood symbols. Of course, plans can change. Alternative ideas are sure to emerge, along with many improvements to this one, which is among many others in the VRM movement. It just happens to be the one I’ve been working on most.

Meanwhile, big thanks to to Vince Stehle (who has moved on from Surdna, but made the grant happen when we needed it most), to Keith Hopper and NPR, to Jake Shapiro and the crew at PRX, to many other friends in public radio (and to ones in free commercial radio as well, such as Bill Goldsmith of Radio Paradise), to Daniel Choi, Oshani Seneviratne, Adam Marcus, Ahmad Bakhiet and other helpful programmers, to the VRM community, and to the Berkman Center, which has kept faith with me and with ProjectVRM through the years required to get things off the ground.

We’re still getting started here. But we’ve come a long way too.

Tags: , ,