Redefining and Standardizing ‘Ownership’

Facebook, by virtue of its sheer size and scope, is often the first to run into issues that the rest of the social web will need to address sooner rather than later. To its credit, Facebook seems to be trying to address these issues in a way that protects their short and long term business while balancing the needs of the community.

By observing these actions the DataPortability project, and the wider community, can learn lessons on what works and what doesn’t so we can all adopt clear community endorsed best practices.

The latest Facebook step (misstep?) occurred last week when they made some changes to their Terms of Service and one of the items of contention by many is the following statement:

“You may remove your User Content from the Site at any time. If you choose to remove your User Content, the license granted above will automatically expire, however you acknowledge that the Company may retain archived copies of your User Content. “

“So Who Owns Your Data” is always a question that myself and other members of the DataPortability Project (DPP) have grappled with for some time. No doubt ‘ownership’ of data is top of mind to people who are interested in data portability.

We have said in the past that Ownership without Control is worthless. Scope of Control, however, seems to stem from ownership. That is, you should only be able to control what you own. So the fundamental question of Ownership is still important.

‘Ownership’, however, is tricky when you are talking about bits and bytes that are getting shared, indexed, replicated and mixed together by multiple services and participants.

Perhaps Ownership is not the right metaphor at all? Late last year, fellow DPP co-founder Elias took the time to address some thoughts on ‘ownership’ of data with a post titled “You don’t nor need to own your data” that I would recommend reading. In it, Elias discusses traditional concepts of ownership and goes on to suggest that perhaps we need a new term to describe our relationship to social data.

Here is a large section from his post:

First of all, let’s define property ownership: “the ability to deny use of an asset by another entity”. The reason you can claim status to owning your house, is because you can deny someone else access to your property. Most of us have a fence to separate our property from the public space; others like the hillbillies sit in their rocking chair with a shot gun ready to fire. Either way, it’s well understood if someone else owns something, and if you trespass, the dogs will chase after you.

The characteristics of ownership can be described as follows:

1. You have legal title recognising in your legal jurisdiction that you own it.
2. You have the ability to enforce your right of ownership in your legal jurisdiction
3. You can get benefits from the property.

The third point is key. When people cry out loud “I own my data”, that’s essentially the reason (when you take out the Neanderthal emotionally-driven reasoning out of the equation). Where we get a little lost though, is when we define those benefits. It could be said, that you want to be able to control your data so that you can use it somewhere else, and so you can make sure someone else doesn’t use it in a way that causes you harm.

Whilst that might sound like ownership to you, that’s where the house of cards collapses. The reason being, unless you can prove the ability to deny use by another entity, you do not have ownership. It’s a trap, because data is not like a physical good which cannot be easily copied. It’s like a butterfly locked in a safe: the moment you open that safe up, you can say good bye. If data can only satisfy the ownership definition when you hide it from the world, that means when it’s public to the world, you no longer own it. And that sucks, because data by nature is used for public consumption. But what if you could get the same benefits of ownership – or rather, receive benefits of usage and regulate usage – without actually ‘owning’ it?

Property and data – same same, but different
Both property and data are assets. They create value for those who use them. But that’s where the similarity’s end.

Property gains value through scarcity. The more unique, the more valuable. Data on the other hand, gains value through reuse. The more derivative works off it, means the more information generated (as information is simply data connected with other data). The more information, the more knowledge, the more value created – working its way along the information value chain. If data is isolated, and not reused, it has little value. For example, if a company has a piece of data but is not allowed to ever use it – there is no value to it.

Data gains value through use, and additional value through reuse and derivative creations. If no one reads this blog, it’s a waste of space; if thousands of people read it, its value increases – as these ideas are decimated. To give one perspective on this, when people create their own posts reusing the data I’ve created, I generate value through them linking back to me. No linking, no value realised. Of course, I get a lot more value out of it beyond page rank juice, but hopefully you realise if you “steal” my content (with at least some acknowledgement to me the person), then you are actually doing me a favour.

Ignore the above!
Talking about all this ownership stuff doesn’t actually matter; it’s not ownership that we want. Let’s take a step back, and look at this from a broader, philosophical view.

Property ownership is based on the concept that you get value from holding something for an extended period of time. But in an age of rapid change, do you still get value from that? Let’s say, we lose the Holy War for people being able to ‘own’ their data. Facebook – you win – you now ‘own’ me. This is because it owns the data about me – my identity, it would appear, is under the control of Facebook – it now owns, that “I am in a relationship”. However, the Holy War might have been lost but I don’t care. Because Facebook owns crap – as six months ago, I was in a relationship. Now I’m single and haven’t updated my status. The value for Facebook, is not in owning me in a period of time: it’s in having access to me all the time – because one way they translate that data into value is advertising, and targeting ads is pointless if you have the wrong information to base your targetting on. Probably the only data that can be static in my profile, is birth-date and gender – but with some tampering and cosmetics, even those can be altered now!

With their change of terms, Facebook is essentially saying that they will ‘forever own’ a copy of your data as part of their archives to do with what they wish. I will go so far as to sympathize personally with the team there and give them an approving nod for some of Zuckerberg’s comments especially acknowledging that they are indeed trying to address some serious questions around how we live our digital lives. It’s not easy and they certainly don’t have to go it alone.

I would invite them, and anyone else interested in the topic, to join one of our most recent TaskForces – the EULA & ToS Taskforce.

Following the example of  Creative Commons, the goal of our task force is to identify and name key concepts that help users and service providers understand what each other expects . The intended output will be a set of documents that can be referenced or included in EULA and TOS agreements and simple descriptions for users to understand what it means when they upload and share data with services providers.

As part of this taskforce, we seek to provide a standard way of describing the relationship between the user and site that is easy to understand and provides both sides with the control that they need.

If you are interested in the subject – now is the time to join us and help define some basic principles that services providers should support by joining and supporting the work that the EULA & ToS Taskforce is conducting.

And another kudos to Facebook for starting a discussion topic immediately on the “People Against the new Terms of Service (TOS)” Facebook Group. Some real use cases and concerns are being captured in that discussion that will help us all as we work towards our common goal.

Some additional posts on the subject of Facebooks New Terms of Service:

• Where the buzz started on the Consumerist Blog (a consumer advocacy blog) Facebook’s New Terms Of Service: “We Can Do Anything We Want With Your Content. Forever.”
• Caroline McCarthy CNET: Facebook: Relax, we won’t sell your photos
• An interesting overview of the various terms of service out there by Amanda French : Facebook terms of service compared with MySpace, Flickr, Picasa, YouTube, LinkedIn, and Twitter
• web.tech.law What Facebook’s revised terms of use mean for your content
• There are plenty of other posts and suspect more to come so here is a link to posts via Techmeme
• Comparing the Terms and Conditions of Facebook, Myspace, Flickr, Picasa, YouTube, LinkedIn and Twitter.

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.

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.