apk zenonia 5

A couple of years ago I wrote:

My generation draws the Internet as a cloud that connects everyone; the younger generation experiences it as oxygen that supports their digital lives. The old generation sees this as a poisonous gas that has leaked out of their pipes, and they want to seal it up again.

Bill Thompson and Nick Carr are worried about governments interfering too:

In the real world national borders, commercial rivalries and political imperatives all come into play, turning the cloud into a miasma as heavy with menace as the fog over the Grimpen Mire that concealed the Hound of the Baskervilles in Arthur Conan Doyle's story.

Except, if you have read or listened to Steven Johnson's excellent The Ghost Map, you'll know that the miasma theory of disease was a fatal error for urban England in the 1840s - the real problem was not the bad smells in the air, but the diseases in the water. The fault, dear governments, lies not in our clouds but in your pipes.

Brad is calling for APIs, and even the NYT is proposing one, but there is a problem with APIs that goes beyond Dave's concern about availability.

When a site designs an API, what they usually do is take their internal data model and expose every nook and cranny in it in great detail. Obviously, this fits their view of the world, or they wouldn't have built it that way, so they want to share this with everyone. In one way this is like the form-fitting lycra that weekend cyclists are so enamoured of, but working with such APIs is like being a bespoke tailor - you have to measure them carefully, and cut your code exactly right to fit in with their shapes, and the effort is the same for every site you have to deal with (you get more skilled at it over time, but it is a craft nonetheless).

Conversely, when a site adopts a standard format for expressing their data, or how to interact with it, you can put your code together once, try it out on some conformance tests, and be sure it will work across a wide range of different sites - it's like designing a t-shirt for threadless instead.

Putting together such standards, like HTML5, OpenID, OAuth or OpenSocial or, for Dave's example of reviews, hReview, takes more thought and reflection than just replicating your own internal data structures, but the payoff is that implementations can interoperate without knowing of each others' existence, let alone having to have a business relationship.

I had this experience at work recently, when the developers of the Korean Social network idtail visited. I was expecting to talk to them about implementing OpenSocial on their site, but they said they had already implemented an OpenSocial container and apps using OpenID login, and built their own developer site for Korean OpenSocial developers from reading the specification docs.

I'm looking forward to more 'aha' moments like that this week at I/O.

I've been travelling a lot to conferences in recent months, and been interviewed by a lot of different journalists too. Here are a few links to them.

• Cloud computing with Joyent at Web 2.0(video)
• Chris Vallance of BBC Pods and Blogs (audio)
• Jemima Kiss of The Guardian (audio)
• Data Portability podcast (audio)
• Kimberley Dykeman of web2.0 TV (video)
• Christina Warren of Download Squad (video)
• Caroline McCarthy of CNET (text)

For more in-depth details on OpenSocial, come along to Google I/O on May 28th-29th in San Francisco

Brad Templeton has a post on Data Hosting not Data Portability that fits in neatly with the VRM proposal I discussed yesterday. In fact, what he describes is a great fit for OpenSocial.

He says:

Your data host’s job is to perform actions on your data. Rather than giving copies of your data out to a thousand companies (the Facebook and Data Portability approach) you host the data and perform actions on it, programmed by those companies who are developing useful social applications.

Which is exactly what an OpenSocial container does - mediate access to personal and friend data for 3rd party applications.

This environment has complete access to the data, and can do anything with it that you want to authorize. The developers provide little applets which run on your data host and provide the functionality. Inside the virtual machine is a Capability-based security environment which precisely controls what the applets can see and do with it.

This maps exactly on to Caja, the capability-based Javascript security model that is being used in OpenSocial.

Your database would store your own personal data, and the data your connections have decided to reveal to you. In addition, you would subscribe to a feed of changes from all friends on their data. This allows applications that just run on your immediate social network to run entirely in the data hosting server.

Again, a good match for OpenSocial's Activity Streams (and don't forget persistent app data on the server).

Currently, everybody is copying your data, just as a matter of course. That’s the default. They would have to work very hard not to keep a copy. In the data hosting model, they would have to work extra hard, and maliciously, and in violation of contract, to make a copy of your data. Changing it from implicit to overt act can make all the difference.

The situation is worse than that; asking people for their logins to other sites is widespread and dangerous. I'd hope Brad would support OAuth as a step along the way to his more secure model - especially combined with the REST APIs that are part of OpenSocial 0.8

If you're interested in these aspects of OpenSocial, do join in the linked mailing lists, and come along to the OpenSocial Summit on May 14th (just down the road from IIW).

At the Data Sharing Workshop the other day, we had a discussion about how to combine OAuth and Feeds, which I was reminded of by Tim Bray's discussion of Adriana and Alec's VRM proposal today.
The session was tersely summarized here, but let me recap the problem.

When you are browsing the web, you often encounter pages that show different things depending on who you are, such as blog, wikis, webmail or even banking sites. They do this by getting you to log in, and then using a client-side cookie to save you the bother of doing that every time. When you want to give a site access to another one's data (for example when letting Flickr check your Google Contacts for friends), you need to give it a URL to look things up at.

The easy case is public data - then the site can just fetch it, or use a service that caches public data from several places, like the Social Graph API. This is like a normal webpage, which is the same for everyone, returning a HTTP 200 response with the data.

The other common case is where the data is private. OAuth is a great way for you to delegate access to a web service for someone else, which is done by returning an HTTP 401 response with a WWW-Authenticate: OAuth header showing that authentication is needed. If the fetching site sends a valid Authorization header, it can have access to the data.

The tricky case is where there is useful data that can be returned to anyone with a 200, but additional information could be supplied to a caller with authentication (think of this like the social network case, where friends get to see your home phone number and address, but strangers just get your hometown). In this case, returning a 401 would be incorrect,as there is useful data there.

What struck me was that in this case, the server could return a 200, but include a WWW-Authenticate: OAuth header to indicate that more information is available if you authenticate correctly. This seems the minimal change that could support this duality, and much easier than requiring and signalling separate authenticated and unauthenticated endpoints through a HTML-level discovery model, or, worse, adding a new response to HTTP. What I'd like to know from people with deeper HTTP experience than me is whether this is viable, and is it likely to be benign for existing clients — will they choke on a 200 with a WWW-Authenticate header?

HTTP does have a 203 response meaning Non-Authoritative Data, but I suspect returning that is more likely to have side effects.

Last week, I left the Web 2.0 conference to listen to Mimi Ito, danah boyd and their colleagues talk about their research on Digital Publics.

Now if you haven't been paying attention, that plural of 'public' there may throw you. Surely things are either 'public' or 'private'? As danah explains:

Just as context is destabilized through networked publics, so is the meaning of public and private. What I learned from talked to teens is that they are living in a world where things are "public by default, private when necessary." Teens see public acts amongst peers as being key to status. Writing a public message to someone on their wall is a way of validating them amongst their peers. Likewise, teens make choices to go private to avoid humiliating one of their friends.

Yet, their idea of public is not about all people across all space and all time. They want publics of peers, not publics where creeps and parents lurk.

Bly Lauritano-Werner (17, Maine):

My mom always uses the excuse about the internet being 'public' when she defends herself. It's not like I do anything to be ashamed of, but a girl needs her privacy. I do online journals so I can communicate with my friends. Not so my mother could catch up on the latest gossip of my life.

Properties of technology have complicated what it means to be in public. We are all used to being in publics that don't include all people across all space and all time. Many of us grew up gossiping with friends out in public and stopping the moment that an adult walks over. This isn't possible when things are persistent. And it's really hard to be public to all peers and just keep certain people out. So teens are learning how to negotiate a world where the very meaning of public and private have changed. Again, this is a good thing. They're going to need these skills in the future.

The day before, at Web2Open, I had heard something similar in the Troll Whispering session. Christy Canida explained that when someone posts something trollish or otherwise dubious on her site, they get put in a state where only they can see their posts, but no-one else can (except Christy and the other conversation monitors). This damps down the flame responses until Christy and co have time to review, and maybe release them, but in their view the post is on the site, but no-one is responding.

This varying view of the web, depending on who you are, seems odd at first, but it is in fact a recognition in code of what actually exists in human attention. We don't all read the same web, we see our own reflections in what we seek through searches or filtered by our homophily-led reading.

Which is where Twitter comes in. Like Jeff, I've been twittering more than blogging recently, and while immediacy is part of it, a far stronger thing is that I have a sense of public there - a public of people I choose to follow and who chose to follow me. Everyone who uses Twitter sees a different, semi-overlapping public, which maps closer to our individual idea of the digital public we are speaking to, and listening to; one that maps more closely what the socialogist and theorists have been describing for a while.

Tomorrow, the FCC is holding a public hearing at Stanford on Broadband network management practices. With striking timing, Comcast today managed to announce a 'Internet Bill of Rights' without inviting any users, and simultaneously cut off Dave Winer's net connection for exceeding their secret usage limits. I can't link to Comcast's policy because their website mungs the text in via javascript - here's what they say:

Excessive use means data usage that is not characteristic of a typical residential user of the service as determined by Comcast.[...]Comcast currently identifies well less than 1% of Comcast High-Speed Internet customers as excessive users each month. [...]Many excessive users consume more data than a business-class T1 line running at full capacity in a month. [T1 is 1.5 Mbit/sec - Comcast claims to offer 12 Mbit/sec for PowerBoost, and 6/8 Mbit/sec standard] [...] Currently, each month Comcast identifies the top bandwidth users of its High-Speed Internet service by determining aggregate data usage across its entire customer base nationwide.

What they are saying is that they use a crude averaging model, and penalize you if you don't fit, for example by using the connection capacity they promise more than 10% of the time. Now, this could be called Procrustean, but it reminds me of The Producers, where Bialystock and Bloom sold a hundred people 10% shares of the show, assuming it would fail. Sadly for Comcast, people like Dave are finding new uses for the net's bandwidth, and not just checking email sporadically any more.

Conventional internet service user models are based on users downloading more then they upload, from common big media sites that can be easily cached. However, as Odlyzko pointed out, citing Lesk's now decade-old work, the dominant form of data creation is photographs. Now all these photographs are actually digital, and we want to share them so others can see them. Because we aren't allowed to run our own servers by the likes of Comcast, we have to upload them to Flickr or Photobucket or Picasa to share them. This gives us an 'upload more than you download' network flow, as we send them up at full multi-megapixel resolution, but browse a few of each others' at thumbnail or reduced size. And that's before we even consider video uploading (which I've noticed Comcast throttles at 0.4 Mbit/sec for me).

Comcast hit the news before by sabotaging Bittorrent transfers by faking reset packets, but what Bittorrent is really doing is arbitraging around the asymmetric network bandwidth delivered by these outdated user models.

Bob Briscoe recently wrote an interesting proposal on handling congestion by TCP signalling to reveal the costs of congestion. This was spun by George Ou as an attack on P2P protocols, but the underlying principle of penalising those who cause congestion is an interesting one. The question I'd like answered is that if I have a gigabit network at home, and the internet backbone is multi-terabit, when Comcast throttles my uploads to 400 kilobits, aren't they the ones causing the congestion?