Brad Ideas - Data Deposit Box instead of data portability - Comments

Skype and servers

brad — Sun, 26 Dec 2010 07:04:41 -0800

The Skype trick has some merit, though some people are a bit bothered by it. In order to be superior to Facebook, it has to work from your mobile phone and laptop and desktop even when the others are off or disconnected from the net, just as Facebook and the rest do.

The question is, can you do that with the Skype supernode approach? With Skype, the calls go through the supernodes (and failed last week because of this) but they are encrypted end to end so the supernodes can’t listen. If you want to rely on the servers of random people to provide hosting and processing for your data, then they could possibly look at the data and publish strange things they find — a non-starter I think. You can’t do it all with zero knowledge operations.

Yes and no

Bjarni Rúnar Einarsson — Sat, 25 Dec 2010 11:21:07 -0800

Yes, for anything to take down Facebook et al, it has to actually be better, not just free-er.

However, I do disagree with the installing a server bit. It just has to be really easy.

People install software all the time - games, apps, networking tools like Skype. If anything, things like the Android and iPhone app stores are making this easier and more common.

The complexity of server software is not necessarily any higher than the complexity of something like a web browser or a word processing tool - making a server of some sort equally easy to install, use and keep secure/up-to-date is in no way impossible. Hard yes, but not impossible.

Arguably, companies like Skype are doing it already. They just don't tell people it's a server. :-P

A good step

brad — Thu, 23 Dec 2010 11:00:45 -0800

Though I remain convinced that to get adoption beyond the true believers, the final result must match or exceed what people get from facebook and similar sites in terms of ease of use, performance, abilities, and initially cost — ie. free.

Down the road I suspect people will pay for their own hosting to get better that what is offered free or free-with-ads. But it must be as easy to sign up as it is to sign up for facebook, which is a high bar but one that must be overcome. Having to set up a server yourself is a non-starter.

A step in this direction?

Bjarni Rúnar Einarsson — Thu, 23 Dec 2010 04:54:07 -0800

I just shared this article with the guys at the Unhosted project, figured I might as well spread the link both ways.

Unhosted (www.unhosted.org) aims to realize a somewhat simplified version of this vision, creating a standard way to separate data storage from application logic in Javascript web-apps. It's a small step, but it's in the right direction.

As I mentioned to you in an e-mail a couple of months back, I'm working on a lower segment of the stack (www.pagekite.net), trying to give people a realistic way to run globally reachable servers on personal hardware, so they can actually self-host their sites (or just data) if they so choose.

Both projects would obviously benefit from advice, testing, advocacy or all three. :-)

Building libraries

brad — Wed, 08 Dec 2010 23:10:00 -0800

One thing I envision is that when an application starts storing data about you on your own server, they might not just store the data but offer classes which can be used to work with the data, and abstract it. In fact, one can imagine arranging it so that the only way to get at most data is through the official interfaces of the classes, with a security model that prevents other approaches. This can allow things like logging access to data and so on. I don’t know if Javascript can do this, perhaps it can.

Of course, just as there are translators from other languages to JS, there are implementations of JS for the JVM, though I don’t know if they have fully caught up with everything in modern server side javascript.

Overall the goal is to provide important data access and sandbox features, but otherwise restrict the language choice of coders as little as possible.

Javascript anyone???

GWBasic — Wed, 08 Dec 2010 15:00:18 -0800

I experiment with some of these concepts in ObjectCloud, my web server that's designed like an operating system. It acts as a form of a personal data store.

One way that I could accomplish running untrusted 3rd party code is with a simple in-browser Javascript sandbox and XHTML. There could be a way for my server to grab XHTML and Javascript from an untrusted source and filter it to a subset of trusted tags and scripts. I could then pass it various APIs for limited access to the users' data. (ObjectCloud has a rich Javascript API for many kinds of data.) The biggest challenge is some way to prevent malicious Javascript from generating script tags that let it communicate with APIs outside of the sandbox; thus leaking the users' data. (I know Yahoo has done some work in this area, but I don't know if it's applicable.)

Lots of good work here

brad — Mon, 22 Sep 2008 11:44:06 -0700

But it doesn’t resolve — perhaps nothing can — the almost tautology that making it easier for outside programs to get at the data makes it easier for the data to flow outside. The challenge is how to serve two masters:

Making it easy to program applications that use the data
Keeping the data close to your vest

To contact me

brad — Fri, 16 May 2008 20:03:25 -0700

Send me an email!

We Should Talk

Allan Sabo — Fri, 16 May 2008 18:02:02 -0700

Brad,

Read your post at Scoble's blog after posting my own - your must have come in about the same time.

I had to read (ok, quickly scanned) your post here, and find you and I are very much on the same page.

I am working with a group that wants to develop what it believes is the answer - perhaps we should talk.

Please contact me at your convenience,

Allan Sabo
Alti Success Strategies
Experts at Integrating Social Media and Internet Marketing

Data Spaces in the Clouds

Kingsley Idehen — Thu, 08 May 2008 13:55:39 -0700

Brad,

What you describe is what I've referred to as Data Spaces in the Clouds (Fourth Platform) for a while :-)

Yes, there is some confusion about the literal interpretation of the phrase: Data Portability (free movement of data across platforms). We don't necessarily want free movement of data across realms (unless we explicity enable it in our space). Instead, I believe we seek Open Access to our Data Spaces with access control granularity.

To conclued, we do need Data Access by Reference facilitated by portable Data Containers (Data Spaces) in the Clouds. Of course, these containers can move themselves, or data from the clouds to other locations, wholesale or via replication and synchronixation. In all cases using standard protocols and existing infrastructure such as the Internet and Web.

Links:

1. OpenLink Data Space Wikipedia Page
2. OpenLink Data Spaces (Open Source Edition) Home Page
3. My Data Space Profile Page
4. EC2 installation Guide
5. How to get a Gateway into your Data Space (i.e a URI for Your Data Space) in 5 minutes or less
6. Recent WWW2008 Presentation about Data Portability and Data Accessibility (PPT)

FoF apps

brad — Wed, 07 May 2008 11:26:57 -0700

As I’ve noted, FoF apps turn out to be much less interesting than people thought at first. Do you really look at the photos of your FoFs? The main FoF app that seems to be useful is LinkedIn’s “search your network” which can answer questions like, “Who can I contact at Company X” and dating introductions. FoFoF turns out to be surprisingly non-useful.

However, I won’t proclaim that nobody can think of useful apps (or simply entertaining) apps here. So there need to be solutions, even if it turns out to be that those apps get access to large networks, but are the only ones that do. (Remember, our alternative today is zillions of apps getting access to this data.)

I don’t expect home PCs to be required here. Everybody wants an always on host for many functions. You don’t need it in the sense that I don’t think “Ask 100 hosts to search for a query” is a good implementation, but I would use the local hosts just as a way to do things efficiently for the user when the user is signed on. The cloud host would do things for others. Client data hosts and cloud data hosts would sync.

Your particular app, and other FoF apps, could be implemented, somewhat less efficiently, with data updates. That is to say, if you are using an FoF app, you would send changes to your friends, and they would forward those changes on to their friends as part of the update stream. In this case everybody is storing all the basic data (not big things like photos, just smaller stuff, including the URLs/access tokens of the photos) on their own host, and apps can operate on it. This is why it does not scale to FoFoF, but I think it could handle FoF if the updates are not large.

Of course, you, your Fs and your FoFs must be running the same application, but that is the same as saying they are all members of Flickr. To implement Flickr you need more though, and it may not even be possible to implement all apps in this manner. Still better than implementing them all in a central repository manner, though.

Interesting approach

brad — Wed, 07 May 2008 11:16:17 -0700

But I haven’t studied the underlying systems proposed enough to judge if they can do it. One concern I see immediately regards whether developers can be talked into it. Part of the sex appeal of web 2.0 (meaning apps in the cloud) is that developers get free reign to write and maintain their apps using whatever platforms and tools they like. They are no longer limited to even the constraints and problems of writing code for a user’s PC. Users at the same time love not having to install software, having somebody else maintain it all, and having to roam.

My own proposals face this problem too. These abilities are very attractive to users and developers, and as long as they can get the functionality (which javascript has now given) they will rush to them.

It is for this reason that I have decided that some compromises will be needed, that we won’t get to the level where we can run a malicious app on our data. That’s because the programming hoops required to use a system that bars malicious apps may be too involved. Happy to be proven wrong, though. I would be happy just to reach the level where apps don’t end up taking more data than they need, and don’t end up storing copies of it.

W5 Project at MIT

Evan Jones — Wed, 07 May 2008 04:51:52 -0700

The W5 project at MIT is looking at ways to solve these issues:

http://pdos.csail.mit.edu/~max/docs/w5.pdf

Searches

Radovan Semancik — Wed, 07 May 2008 01:14:33 -0700

I really wonder how you can efficiently implement this use case:

"Show me the flickr photos that my friends and the friends of my friends faved in last 2 weeks, sorted by the total number of favs", while the photos are still stored on flickr.

I can see you can implemente that with "agent" that will crawl to the hosting sites of your friends and their friends, collect the data and come back. But that would be slow, especially if some of your friends host their data in PCs that are currently offline (remember The Eight Fallacies of Distributed Computing?). Do you have any solution for that in mind?

BTW, creating a Virtual Machine you still provide API to the applications. But it is quite broad, which means it is difficult to control security.

Finding the host

brad — Tue, 06 May 2008 14:48:00 -0700

Well, in the past we have used DNS as a way to name hosts and move them around. This could be used here, but not a high level domain. I might get bradsdata.datadns.com as a subdomain that I can point at whatever data host I like. However, there could be other indirection or discovery protocols.

Typically I see a main site providing your interface to social data apps. That site would embed other web pages which are served from your data host, running code provided by app providers. The DNS would direct your own browser at your own data host of choice. (In fact, this architecture allows the data host to be your own PC, if you don’t need to roam. Your own pc at localhost:port would see a request for a social app window. The data host program on your PC would connect to the specified remote application’s server for any code updates or special data, download them if it doesn’t have them cached, execute the code and return the results to the iframe in the browser page.)

I think I’ll update about that.

Now as for the central repository: This is complex. People are saying, it seems, that they don’t want their data scattered around everywhere, both because of lack of control, but more commonly because the UI to give apps access to it is too complex. If we can develop a good UI so that it is easy to give apps just the data they need, and no more, then scattering can be good. The data hosting model does not dictate about scattering or centralization, but I agree that users will tend to centralize, just for ease of control. A central server contracted to me may be better than 30 servers with only loose bonds to me, such as 30 different social app companies each knowing different subsets of my data.

Data Deposit Box instead of data portability

brad — Mon, 05 May 2008 20:08:19 -0700

I’ve been ranting of late about the dangers inherent in “Data Portability” which I would like to rename as BEPSI to avoid the motherhood word “portability” for something that really has a strong dark side as well as its light side.

But it’s also important to come up with an alternative. I think the best alternative may lie in what I would call a “data deposit box” (formerly “data hosting.”) It’s a layered system, with a data layer and an application layer on top. Instead of copying the data to the applications, bring the applications to the data.

A data deposit box approach has your personal data stored on a server chosen by you. That server’s duty is not to exploit your data, but rather to protect it. That’s what you’re paying for. Legally, you “own” it, either directly, or in the same sense as you have legal rights when renting an apartment — or a safety deposit box.

Your data box’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.

As such, you don’t join a site like Facebook or LinkedIn. Rather, companies like those build applications and application containers which can run on your data. They don’t get the data, rather they write code that works with the data and runs in a protected sandbox on your data host — and then displays the results directly to you.

To take a simple example, imagine a social application wishes to send a message to all your friends who live within 100 miles of you. Using permission tokens provided by you, it is able to connect to your data host and ask it to create that subset of your friend network, and then e-mail a message to that subset. It never sees the friend network at all.