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).
1 comment:
This is pretty much exactly what we've done with iPages on top of OpenSocial... With one twist...
Our implementation is based on the belief that most pieces of data have natural 'authoritative' sources and that the data should be consumed from that source. So our OpenSocial container has a data abstraction behind it (xdi) instead of a data store.
Data portability in as much as authoritative sources only need to provide access to a single 'highly trusted' third party.
Virtual data hosting in as much as the functionality is brought to the data for delivery of useful services.
More on my blog .
Post a Comment