Here’s how you can bring the ideas in our data portability policy to hundreds of millions of people. I’ll need your help in May and June to start. In short: build portability principles into boilerplate identity contracts.

What’s a trust framework? . . . → Read More: #portability4trust: How we will bring data portability to trust frameworks this quarter.]]>

Dial or Skype details for this Wednesday’s Conference Call to start before IIW.

Here’s how you can bring the ideas in our data portability policy to hundreds of millions of people. I’ll need your help in May and June to start. In short: build portability principles into boilerplate identity contracts.

What’s a trust framework?

Trust frameworks are the many contracts that say how all the parties who move your personal data should behave.

For example, there are contracts between you and organizations that hold and use your data. These can be a Facebook, a bank, a hospital, a phone company, a government agency, a school or a library. These organizations help you use your identity with them, like your Facebook ID, to prove who you are to third-parties.

Trust frameworks describe the contracts between you and each identity provider, between the identity provider and the relying parties who receive and change your data. Trust frameworks improve clarity and accountability and lower the cost and effort of sharing data well and safely.

These are the legal and policy counterparts to the technical protocols like OAuth used to sign you in among web sites and to move your data. There are a few trust frameworks live and more on the way. The contracts promise things like keeping your data safe or asking for permission before selling your data.

I believe they should include data portability practices among the promises made to users.

Why now?

NSTIC is an international program to encourage everyone to build and use trust frameworks. NSTIC is short for the National Strategy for Trusted Identity in Cyberspace. Here is the full text of the NSTIC strategy document. Last week the White House moved the NSTIC project office to the US Department of Commerce’s NIST, the National Institute of Standards and Technology. Corporate, startup and NGO interest are high.

The World Economic Forum launched a three year “Rethinking Personal Data” project, including data portability. Their first report, Personal Data: The Emergence of a New Asset Class, shows their directions.

The Personal Data Ecosystem Consortium is picking up members, traction, and launching three programs over the next few weeks.

What can we do as the DataPortability Project?

We can give organizations building trust frameworks the raw material they need to define data portability in practice and in enforceable contracts. They are writing standard language for millions of contracts right now.

Data Portability Trust Framework Documents

Teams building trust frameworks with data portability need our Project to draft, validate, refine, and publish these seven documents.

• A portability principles manifesto. Listing the principles of data portability and why they matter.
• A portability policy pledge. A short, direct promise to support the data portability principles.
• A portability policy template. Like the questions found at PortabilityPolicy.org, a structured way to assure all data portability principles are addressed and disclosed, whether they are supported or not.
• A portability policy minimum disclosure. Describe the least amount of disclosure required by a trust framework.
• A portability policy minimum practice. Describe required data portability practices. This is prescriptive.
• A portability policy recommended practice. Describe portability practices above and beyond the required. With time and support of the trust framework’s organization, recommended practices may become required.
• A portability glossary. Defining our terms.  

Some of these documents should and can be in simple, plain language. For example the manifesto should explain data portability persuasively.

Others should be sufficiently specific that a third-party could verify portability claims in practice. So if you say you delete all a user’s data on request, the minimum practice lists how that would be proved.

We’ll version these documents and bring them through stages of maturity, from proposed to draft to final, or a similar approach. This way everyone knows exactly what they sign up for.

The next 30 days.

Now through June. Project volunteers will write and edit the documents.

27 April. I’ll host a Portability for Trust Frameworks conference call Wednesday to get things started.

• 11:00 AM Pacific, 2:00 PM Eastern, 7:00 PM London, 20:00 Berlin, other local times.
• In the USA: +1-201-793-9022, access code 1719146#.
• Toll free via Skype:+9900827041719146.
• Skype IM backchannel: http://tinyurl.com/dpptrust.
• We will have weekly conference calls where they don’t conflict with other events.

3-5 May. The Internet Identity Workshop (IIW12). We will have data portability working sessions to scope, write, edit, and test the documents. See you there.

10-13 May. European Identity Conference. Munich. Not yet scheduled, but we’re hoping for a birds-of-a-feather session to discuss this work and recruit EU contributors. More than five hours of this EIC are on trust frameworks.

11-13 May. Telco 2 and Personal Data 5. London. I hope some of the Personal Data unconference attendees will schedule a working session on day three.

19-21 May. Privacy, Identity, Innovation 2011 conference (PII), with PrivacyCamp on Saturday. We’ll have working sessions during PrivacyCamp. Silicon Valley.

What you should do now.

1. Put time on your calendar for our events and conference calls. (5 minutes)
2. Join our low volume Google group (2 minutes).
   

   Subscribe to "Data Portability Trust Framework"

   Email:

   Visit this group

3. Re-read the 10 Questions on PortabilityPolicy.org so you are familiar with the baseline documents. (10 minutes)
4. Invite fellow authors to work on this.
5. #Portability4Trust is our hashtag. Spread the word that we need help, please.
6. Cash. Some of this work will involve travel and professional services. The DataPortability Project is a 501(c)3 California charitable corporation. Underwrite our work with donations and in-kind legal services.

As always, I’m available to talk in private. +1-510-316-9773, skype:evanwolf, @evanwolf. – Phil Wolff.

A draft of slides for IIW below…

The power landlords have over tenants is overwhelming, unless restricted by law. The argument: if they want to shut down a service, essentially evicting users, . . . → Read More: Graceful Exit: The Power to Fight Eviction]]> Online Eviction

Jason Scott’s Protection From Online Eviction? and his follow up post make the argument that services like AOL, MySpace, flickr, or Skype should be treated like landlords.

The power landlords have over tenants is overwhelming, unless restricted by law. The argument: if they want to shut down a service, essentially evicting users, they should be required to give notice and keep things running for a year.

This would allow people to safely migrate their digital objects like photos and videos and blog posts, renew relationships with people in their contacts and agree on where to move, file change of address notices for their businesses, and otherwise minimize the logistical, economic, political, emotional, and familial havoc forcible ejection can create.

Death and Taxes

Should Terms of Service (TOS) defend a user from data loss? from identity nullification? from contact list deletion? from history erasure?

The closure of the Skypecasts service is the example from Skype history that comes to mind. Skype could have given more notice, preserved the site for archival purposes, turned off commenting and new sessions, allowed people to extract contact lists.

Might Skype have designed Skypecasts services with “graceful exit” in mind?

Everything dies. Plants, animals, families, civilizations. Even businesses and web sites.

It’s wise to acknowledge mortality and plan for service end-of-life. And it’s prudent to build societal safeguards outside of company-issued boilerplate.

From a company’s view, it’s like setting aside resources for taxes you know you must pay later. Or contingency funds in a project budget.

Maybe this is green service design. Designing web products for recycling and reuse.

It was time for Skypecasts 1.0 to die. What was the right way for Skype to retire the service? How could they have preserved user equity in data and the social capital created through use of the Skypecasts services?

What is the moral thing to do?

The question is broader than the one product.

It goes to the tension between consumer rights, enterprise service rights, and the health of our society. For example, if a province decides to demolish your building, you have many rights under law to contest that decision. In the US, many cities have laws about protecting historic landmark buildings.

In my case, as a user of Google mail, I have no power over Google. If they decide to cancel my account, delete my email or spam all my contacts, that’s within their power. They don’t need to give notice, or offer me a chance to back everything up. Nobody outside Google will hear my appeal or listen to my concerns.

Societies, civilization and economies have an interest in protecting and preserving the intellectual work of individuals. Even family photos, business blogs, and the most idiotic of forums have value. Value to their creators, value as history, value even as part of the creative commons.

Action.

So what can be done to redress this imbalance of power? I’ll suggest six things, by no means a complete or even feasible list.

First, intervene. ArchiveTeam.org is a rapid response team. They will respond to a pending shutdown by backing up as much as they can. They are a volunteer team but just starting. I can easily imagine this being a not-for-profit or a government agency.

Second, prevent. Promote exit strategies in project and product design. This is an education program for product managers. Knowledge about the issues, checklists for planning and conducting a graceful exit, forums for getting help, directories of certified Graceful Exit professionals.

Third, commit. Write model language for EULAs and TOSs. After a company implements preventive measures, give them the language for making promises legally. Plain language, lawyer approved. Even a badge to show at registration to give that safe, comfortable feeling.

Fourth, insure. Create a mutual insurance fund. Put money into a pool to pay for recovery and distribution of digital assets if you should shut down a service. Coverage is proportional to the number of clients and the size of their assets. Risk factors include the health and activity of your business, how well you’ve engineered preventive measures (discounts for readiness). Money may be paid to outfits like ArchiveTeam.org. Insurance spreads risk, but proper tweaking of rates can incent better behavior; fire insurance led to fire codes (prevention) and fire departments (remediation).

Fifth, advocate. The cause needs a forceful voice for consumers. When companies, large or small, threaten to willfully destroy their customer’s digital works, they should be educated, persuaded, and publically shamed as needed. I’m thinking some cross between Electronic Frontier Foundation and Consumers Union.

Sixth, enforce. Teeth, if you will. I want laws that enshrine cherished principles and adapt to changing times and fluid technologies. Injunctive relief is a powerful incentive to do the right thing. Class actions in the public interest might convince the reluctant to do the right thing.

P.S. Dave Winer was the first person to bring this to my attention as an issue, eight or nine years’ ago. His response was to create a specification to hold your structured data from his manila blogging services and features that let you backup your blog in one step.  Thanks, Dave.

P.P.S. While I’m on DPP.org’s steering group, these are my words and may, or may not, be the official view of The DataPortability Project.

In case you’ve never heard of it, Twitter is a micro-blogging service that is doing to communications . . . → Read More: Time To Criminalize The Password Anti-pattern]]> Update: Twitter made another commitment today to adopting OAuth which is great! However they acknowledge that it won’t solve all problems (like we argue) – nevertheless these are positive steps to us eradicating the password anti-pattern

In case you’ve never heard of it, Twitter is a micro-blogging service that is doing to communications what search did to information. It has exploded in popularity, and whether they find a revenue model or not – their impact is permanent and is leading the way for a new era of communications. I am one of their biggest fans and want to help them succeed. But I feel with their growth, propelled by loyal users like myself, we ought to let them know there are things that concern us.

The biggest issue is that whilst they enable data portability, they are doing it in an insecure way. As Chris Messina said, lets make 2009 the year we see the end to the password anti-pattern. In this post, I will explain what that anti-pattern is and a way we can fix it. The biggest reason why Twitter is continuiing with this anti-pattern (from my eyes), is because it’s a usability issue. But as you will see me prove below through screenshots, it isn’t. Just think of having a PIN code on your bank card: that’s a usability issue as well, but y’know, one of those good usability issues.

Twitter and Security: all we’ve heard in 2009 so far
Twitter is used to constant free PR, but this year two separate events occurred that could have been non-events (if they do what we ask).

The first was a third-party that provided a feature people wanted. As Twitter has an Application Programming Interface (API), third-party’s can create mashups and therefore provide this functionality to Twitter users. However because Twitter does not support delegated authentication, you need to enter your username and password. There are hundreds of third-party applications like this, and most are safe (we hope), but this particular site within 24 hours had put itself up for sale! And people couldn’t turn off the service – they had to change their password to do so.

The second incident to occur this last week, was an attempted phishing. Apparently, some users were being sent private messages telling them to visit a certain site which compromised their security. It’s ironic that Twitter tells you to not “share your private info” but for you to get value out of their API for mash-ups and third-party tools, that’s exactly what you need to do – and it makes situations like this slightly more risky.

Fortunately, there are things that can be done to minimize the risk of your accounts getting hacked, and for you to never have to give up information about you that will compromise your security.

Delegated authorization
There is a solution to this situation. It’s free to support it, simple to use, and in fact – Twitter’s team inspired its creation the other year. It’s through the use of an Open Standard called OAuth. There is plenty of material you can read on the web about this and a good start is Eran Hammer-Lahav’s explanation of oAuth followed by his three-part series for beginners if you want to dig a little deeper.

The basic concept is that it allows you to delegate authorization for use of an API. Huh?

I’ll illustrate this with an example. Let’s say you come across a Cool Product that allows you to do something unique with your Twitter account (say, being able to stream your Tweets through your e-mail client rather you having to visit the Twitter website). As this Cool Product has no formal links to Twitter, for you to use it, it needs to pretend to be you. Therefore, it asks for your user name and password. It knocks on Twitter’s API door, pretending to be you, and the Cool Product then gets access to your account to do the stuff you want to do with this third-party application. The problem with this approach, however, is that they can knock on Twitter’s door anytime pretending to be you – even when you don’t want them to.

With OAuth, it would be very different. Instead of you needing to provide your username and password, this Cool Product will say “Hey dude, I need to get some permissions – click this link to give it to me”. Then a request will be sent to Twitter’s API and Twitter will send you to a screen saying “hey dude, these third party dudes want access to your account – you cool with that?”. Then, with a simple click of the button, you can approve or deny access. Once approved, the Cool Product can then function – and you didn’t have to give up any private information like your password.

Here are some screen shots between another innovative start-up called FriendFeed and Google (who supports OAuth).

In this scenario, I want to add some more friends on my FriendFeed account. So I click on the option to invite them

When I click on “import from Gmail”, instead of having to type in my username and password to access my contacts, I simply get redirected to a screen. And because I’m permanently logged into my Gmail account, I don’t need to do anything else other than read and click “grant access” (otherwise, I would need to enter my Google credentials).

.

Easy! Compare this to Facebook, another company that needs to think more proactively about its users security. If I want to add friends to my Facebook account, instead of redirecting me to the Google servers where I can grant access, it asks for my password.

Next steps
As people on the web using web services, we’ve been forced to give up confidential information to get the value out of a service. We’ve forced ourselves to be okay with it with the sites we trust, but there are plenty of brands out there we don’t know to trust. But the thing is, this isn’t something we need to trust anyone with. With our health records and financial records accessible online, this isn’t just a matter of reputation risk but one of genuine identity risk.

There is a solution to this problem, and now that you recognize it, demand web services to give you data portability in a secure way. Let’s make 2009 the year that we kill the password anti-pattern. While easier said than done, it’s a fix that will curb some of the security issues: we hope Twitter hurries up in changing their API to require OAuth.

Twitter – we know you’ve been meaning to do it, but hopefully you really mean it this time. Because quite frankly, we as users are fueling your growth and the promotion of your API without some sort of safe-guards like this, is irresponsible (especially as these attacks prove you are going all the more mainstream. I don’t want to tell you how to run your business – it doesn’t have to be OAuth – but for crying out loud, give us some security for our digital identity.

One final Big But
Twitter has strong arguments to not jump onto OAuth, some of which they’ve said publicly and some that I think might be issues. They certainly have a competent team, and whilst they know the benefits, they also understand the fact that jumping onto OAuth or any type of delegated authorization will not fix all problems. However it’s a start. Here are some issues:

1. OAuth is only good for services over web browsers. It is a real pain (or virtually impossible without some hacks) to use it for the client side (ie, on the desktop) and mobile sites – both of which Twitter has a lot of users that use it this way. The response to that is that some security is better than none – it’s not a big deal that users will have to authorize applications via the browser (and Twitter can just point a hairy finger at the standards community so they can fix it). At least give users the option to determine how secure they want to be.
2. Twitter will need to support multiple authentication systems due to the limitations of oAuth. This is a real issue, but not an impossible one to manage, and the community is certainly willing to help out. My main point is that this is actually a security issue that matters, and because the cost is borne by the users and not the company, it’s not given equal recognition.
3. The user experience will suffer for users. Well the reason users will “suffer” is because now, instead of just entering their password, they will now have to click a few buttons on different screens. As the screenshots show above, the user experience is not affected that much and I think while a valid point, it’s more a “different” user experience
4. The user experience will suffer for developers. Yes it will, because instead of the lazy option to just ask users to hand over their password, they actually have to write some code to get the appropriate permissions happening. But this is a core reason why the DataPortability Project supports widely-supported Open Standards, as it minimizes the costs to business: once a developer learns it once, they know it for all future application development.  And like I said above: a bank not puting a code on your bank card, is more painful for your bank, but better that pain than the option without which poses risks for users.
5. It will not prevent phishing.  Lachlan Hardy gives a useful explanation on why (notice all Australians give the best explanations ), as theoretically, people will be more prone to phishing attacks because of the ease. This is a valid point, as people potentially will just blindly click away to their doom, but let’s also remember there will also be a lot more control. A site can monitor suspect services to alert users, there is a full digital paper trail, and a user can revoke their authorization at any time. Certainly a bit of control is better than none, and by reducing the weak spots in the chain, more targeted efforts can be made to ensure users’ security is no compromised.