On Terms of Service and Privacy Policy

Elias Bizannes and some other folks from the DP project have started working on a way to unify network legal contracts.

A little over a year ago I set out on the same path, trying to bootstrap a “Social Media Standards” organization. We’ve both come to many of the same conclusions, some differences, and focused on some different areas — as he spent much time with networks, while I spent more time with startups and ad firms.

## Here are some key points

– I don’t think that a universal legal doc is possible, recommended, or even a good idea. All the portability concepts tie in very strongly to a company’s business operations — it’s both unrealistic and arrogant to mandate ‘you will do this!’. However I think clarity and guidelines are in order.

– I propose the following:

– a ‘legend’ of datapoints / concepts , where there is a menu of set options that network operators can choose from
– each datapoint and option has an iconic, easy to read, representation… very much like the CC licenses
– there are several recommended configurations of datapoints & options that have trademarked names
– operators may also create customized configurations that reference individual icons

This approach would gives users the ability to identify and easily read TOS agreements, while affording network operators flexibility. In other words — adopting this system could never conceivably hurt their business.

– Enforceability is an issue, as are the differences in legal concepts and wording between countries. Who can sue? How? Where? My idea has been to use SocialMediaStandards as a non-profit licensing group : networks would be able to say that their legal contracts are compatible with specific legal concepts or iconic configurations offered by the group ; in doing so and displaying the trademarked images , they would be liable to the group under contract law if they should make false claims. This would allow the group to litigate on behalf of end users who would be otherwise unable to do so, and greatly simplify enforcement as some other legal concepts get thrown into the mix. Users would still be able to sue for breach-of-contract, fraud, misrepresentation as well — this would give the group the ability to file suit as well.

– I identified common sets of datapoints , and broken them each into 2 categories : Content and Activity. I think each should be treated differently. Content is what a user directly enters into a network, Activity is the networks’ value-add. ie: I can upload a bio (content) and then there is the number of times that bio has been viewed (activity). For every datapoint, I believe there should be the same – but independant, options to regulate content and activity.

– Elias did something similar, breaking things down into ‘nouns’ and ‘verbs’. There is a bit of overlap on both our concepts, but they’re still quite a bit different.

You can see my concepts [by clicking here](http://www.destructuring.net/IdentityResearch/Essays/2008_06/2008-06-SocialMediaStandards-PrivacyAndTos-InitialThoughts/2008-06-SocialMediaStandards-PrivacyAndTos-InitialThoughts.html)

You can see Elias’s concepts [by clicking here](http://wiki.dataportability.org/display/work/Elias+conceptual+framework)

## On ownership of data

Elias and I fought on this for a while. Then we realized that we were both a little drunk, and talking about the same thing: that a user does, and always should own their content — as afforded by copyright law in most countries.

Where we differ a bit is as follows, and is a bit of a controversial topic:

I believe that it is more than reasonable – and should be required – for a user to enter in a contract with a network , that grants an irrevocable non-exclusive license for the network to use and redistribute uploaded content in the original context once it has been interacted with by others. I don’t beleive in this clause/point for the sake of the network , but for the sake of other users. This concept is akin to publishing a letter-to-the-editor in a newspaper or magazine: you can’t undo things once published; people still have the ability to make clippings of the content. It’s also like loaning a photo to a friend — they may return the original, but copies may have been made and are floating around.

I believe this doesn’t affect the concept or legality of ownership. The user still owns their content, and has all legal rights to it. There is simply a non-exclusive license granted to the network to keep content active… such as in the event that a photo is commented on or added to another’s virtual photobook; or a thread of discourse on a topic doesn’t have key sections missing.

Some people believe that this concept strips them of rights. I believe they are attempting to create rights where none existed before. Once something has become public, become shared, it is impossible to undo it — one cannot take back their own words once they have been heard by others. I believe proof of this exists in the simple virtue that other users could simply screencap or printscreen on this content, and that while technology can allow things to be ‘undone’ it doesn’t mean that it should.

That being said, I believe that networks should require users to enter into a covenant with one another , and the network , to agree that items should be forever published. I also stress that contracts like this are more important for the other users as they are for the network.

Why Portability ?

Last week I had the pleasure of meeting up with Elias Bizannes of the DataPortability.org project a few times.

One day he asked me: Why portability ?

This was my answer:

Data portability is a trick, and a really good one at that. It’s not the be-all/end-all solution some make it out to be; while it offers some groups important advantages, to others it is more than threatening to their business concerns. What makes the concept of portability incredibly interesting, and brilliant in some ways, is the necessary balance of all concerned parties to actually pull it off. At it’s core, portability is far less about the concepts of portability and than it is about the democratization and commodification of Social Networks.

Portability is presented as a good thing for users, which it undoubtedly is on the surface. But- and this is a huge “but”… there is the an all important sell-in to the networks — they who actually have to implement ways to users to port in and port out. This offering to networks is complicated, because while porting ‘in’ makes sense, porting ‘out’ is an entirely different matter — and one that may be detrimental to a business. More importantly, while open standards and ‘libraries’ may be free, there are real and serious costs with implementing portability:
– engineering and coding costs : using architects, developers and network engineers to integrate these libraries and APIs
– administrative costs : making sure portability works within current legal contracts, creating new contracts, etc

Small / Niche networks look towards portability as an amazing opportunity — with a few clicks they can import thousands of new users, and for small sites integration can be a matter of hours. Under this premise, it makes sense for smaller groups to abide by the democratic principles of portability, and allow for information to port-out as freely as it ports in. There is no real downside

For Medium networks, or Large networks that have lost their prime , portability is a chance to streamline customer retention methods. By keeping profiles up to date, these networks can seem more lively to new users ( i.e. no more messages that read “Last updated in 2004″ ) — and they offer existing users the ability to browse the same unified & standardized data in a comfortable environment.

The concept of unifying & standardizing data resonates very well with me — I first tried to convince people this would happen in 2006, and in 2009 it has finally started to catch on. It’s really amazing seeing this happen. Before the advent of social networking, networks competed with one another based on their userbase — people migrated from network to network because of who was on it, a mixture of critical mass and critical usage; popularity of online networking, portability and network integration efforts have completely shifted that. Users and content are now the same no matter where you go – and this is increasing at a faster rate. Networks now compete as a layer of user experience and user interface for this data.

For network operators this can — and should — be liberating. The emancipation of users allows networks to stop wasting resources on antagonistic retention methods that lock people into their network… freeing internal resources that can be spent on product improvements, making it easier and better for users to share , connect and interact with others.

Simplest put, networks should focus on making products that consumers WANT to use, not products that consumers dislike or despise yet are locked into using for some reason. Whether they’re pushing for portability or not, virtually every social network or other consumer website is doing this right now, and its sad.

The allure of portability to large networks is an entirely different story. On the surface, portability offers little or no advantage to large networks. As sheppards and herders of massive userbases, networks rightfully fear openness as a way to lose the attention of their users. In deliberate steps, and under carefully controlled conditions, large networks have begun to test the waters… dictating how people can use their network off-site through platforming and ‘connecting’, and offering incredibly limiting export options.

Pundits like to use the term ‘opening the gates’ or ‘tearing down the walls’. I liken this form of tempered portability to ‘testing the waters’ and ‘opening a window’. Large networks are not embracing portability, they’re trying to simulate it on their terms , in ways that best leverage their brand identity and commercial offerings to retain consumer loyalty.

I personally think this is great — but it shouldn’t be called portability or ‘opening up’; this is simply a relaxed posturing.

What I dislike are the grand PR and marketing initiatives around large-scale ‘portability’ efforts. The large firms are all stuck in a cyclical pattern where one group ‘opens up’ a bit more than the last, forcing another group to try and outdo the last. This behavior of metered and restrained openness, and the creation and advocating of new ‘open’ standards that primarily drive the creator’s brand instead of users… this isn’t portability, this is sportability.

Portability and the true Open isn’t about half-assed , ill-conceived standards and initiatives that were designed to create PR buzz and just be open-enough to seem like a viable option. Portability is about getting stuff done with the right product, and putting the user front and foremost. We’re unfortunately left with a market-driven approach, where the large networks are in competition to release the least open standards they can, while still outdoing their competition.

While all of this is happening ‘on the surface’, there is a seedy underbelly to all this. Large networks realized an opportunity that they have all been looking towards and investing in — one which may not be so user friendly. Increased portability and inter-connectedness mean an opportunity for better consumer profiling — one that translates to higher better audience measurements and targeting, offering the chance for significant improvements in advertising performance. Portability offers networks a diamond in the rough. I had spent several years through FindMeOn developing audience profiling/targeting concepts, and quantifying the market opportunity and potential effects — they are huge. This should be rather unsurprising — you may have noticed that the largest proponents of portability efforts over the past few months are subsidiaries or sister companies to some of the world’s largest advertising networks and inventories.

As a quick primer: Social Networks make their money (if ever) either through subscription or advertising models; most are forced into ad-supported models because consumers just won’t pay. Ad supported models are at an odd moment in history right now: users have become so accustomed to ads, that they tune them out completely — dropping CPMs sharply. The transactional model of ‘do a task, watch an ad, repeat’ was overused to much, that it became ‘ask do a task, ignore an ad, do the first phase, ignore another ad, do another phase, ignore another ad’; no matter what networks do, the previous over-advertising has made a generation of users wholly oblivious to advertising — sp some social networks can only get 5-10ยข to show 1k ads of remnant inventory, while others can charge $3 to show the same amount of targeted ads. While that might look like a decent improvement, online advertising elsewhere is doing far better. Behavioral networks can often charge $10 CPM if they hit a user on a content site, and niche sites or strongly branded properties where ads are purchased as a mixture of direct and endemic advertising can generate $40 or more per CPM.

Social networks are left at an odd crossroads today: once a network grows to millions of users, the brand simply isn’t focused enough to be to offer reputable or effective endemic advertising; nor is the property likely to be niche enough to command premium CPMs for placement next to highly relevant content. Networks are unfortunately left with behavioral advertising – which should (and would) be doing better right now, if it weren’t for the overexposure/fatigue that users feel. However, portability efforts offer networks the chance to greatly improve behavioral advertising relevance.

So to summize my answer to the original question posed by Elias…”why portability ?”

> 1. If you’re a small or medium network, you’re going to pick up users.
> 2. If you’re a larger network, having your standard/platform adopted can result in market domination
> 3. If you’re a larger network, you have the potential to improve advertising revenue

Perhaps more than a decade in online business and advertising have left me a bit jaded, but I see little that is particularly grand or noble in these efforts. We’re not talking about curing cancer… we’re talking about making it easier to share photos, comment on things, and improving advertising. For industry professionals like myself , these are really exciting times — but let’s do each other a favor and tone down the idealism a bit and admit to / talk about the factors that are really driving all this. Maybe then we can start taking some real strides, instead of all these tiny little baby steps.

Collecting my thoughts on data portability & open systems

Last week I had the pleasure of meeting up with Elias Bizannes of the DataPortability.org project a few times.

We got to nerd out about different concepts – and our positions – on the overarching theme of integrated networks… and I thought I’d use my photographic memory (even when drinking Bookers’ all night ) to share my thoughts and some of his comments. That didn’t work out too well — or perhaps it did, as my recollections were fueled with bourbon.

In all seriousness, I haven’t spoken with most people on any of these concepts in at least a year, so it was completely fun for me… and given all the recent developments in this area, its nice to see how some attitudes have changed and new concepts have begun to take shape.

Over the next 3 days I’ll release a section of my thoughts in different areas. I like planning out postings like this — it gives me something to look forward to in terms of writing !

Subversion Deployment Strategies

I’m wondering how people like to handle deployment of projects maintained in subversion.

After MUCH testing, I’ve developed the following method that seems to work well for me:

– Trunk is managed in /trunk
– Tags are in /tags; When I tag something, I ‘svn cp /trunk /tags/version-date’ like most people
– I maintain a special tag at ‘/tags/-current-deployed’ – I merge trunk into that whenever I deploy, then ‘svn up’ that tag on the server.

This methods does a few things:

– it allows me to make changes on the ‘current deployed’ on the server if something needs to be fixed there ASAP, then merge into trunk — without breaking the ‘sanctity’ of a tag
– I really just ‘svn up’ and ‘svn merge’ — i never have to ‘svn swtich’ then ‘svn up’ the project. i find that easier.

I’m sure others have good strategies. What’s yours?