Home (public) All Posts

Towards Data Freedom

tl;dr Defining data freedom and the .json manifest that goes with it. (Part of a series of posts.)

Data is born free but everywhere it is in chains. 
            Paraphrasing JJ Rousseau

The prevalent web-services paradigm allows application creators to lock our data into their proprietary platforms. In contrast, personal servers can free this data by disaggregating apps from their underlying data. 

Data can indeed by free - not free as in “beer”, nor free as in “I’ll give you my data for free if you let me visit your web site”, but free as in free speech, free as in mobile, free as in autonomous and free as in accessible:

  • free speech: You are free to do what you like with your data (the overarching principle.)
  • mobile: Your data is fully portable (as are all apps), so you are free to easily export a copy in electronic format and to use it on another server or device. And you can choose to delete any and all parts of it as you please. In practice this means you should be able to get a copy of your data from your servers by clicking a couple of easily accessible buttons.
  • autonomous: Your data is neither dependent on the application that created it nor on the server environment in which it resides. So, there is no vendor lock-in at any level, nor any lock-in to any underlying operating system or other software infrastructure. You are free to allow other apps to use the same data and thus expand functionality by treating the data as an autonomous entity.
  • accessible: This does not mean that everyone is free to access your data, but that you are free to choose who can access your data and under what conditions and using which apps. In practice, this means that your server needs to help manage and control authorised access, and to get the requisite permissions from you to do so.

I suggest we think of data freedom among these principles, and to ensure that personal servers adhere to them. 

Of course, autonomy does not imply that our data should be isolated in an inaccessibly private database. It is consistent with these principles to allow apps and their data to be accessed by other people and by other apps.

An app which adheres to these principles needs to have a common convention for telling the server the kinds of permissions it is seeking from users. And the personal server software needs to manage those permissions. So each app package (ie the zip file of html/css/js files discussed above) needs a configuration file (like a manifest) which lays out its data scheme and permission requests. When you install an app, your personal server asks you if you would like to grant these permissions (much like smart-phone apps do), and you can choose to do so, if you like.

Of course, apps wouldn’t need permission to be able to read and write data related to the app itself for any user of that app. In other words, if you install a game app on your personal server, it should be able to record your score to your personal database without asking for your permission. But if you want to see other people’s scores for the same app, they need to grant permissions for you to access their scores. Or if you install a leaderboard app that aggregates all the scores from different apps to show you how you are doing in all games, you would need to grant permission to the leaderboard app to access your score in all the other game apps on your server. If you want to publicize your score in a public leaderboard, you should also be able to make it public. And if your game app allows you to upload a video of you playing the game, you should be able to grant access to friends you have validated, so they can watch the video (or to make it public.)

A preliminary specification for the configuration file can be found here. Specifically, the “permissions” key can be used by apps to define what permissions the application is seeking. 

Here is an example of what the permissions requests might look like: 

"permissions": {
"top_scores": {
"description":"Player Top Scores", // description appears to users when they are asked to grant permissions
"collection":"scores", // the database table you are giving access to
"return_fields":"score","_creator","_date_created"],// the fields that can be shared
"type":"db_query", // the type of permission – in this case, the permissions allows a collection to be queried under specific circumstances.
"sort_fields":{"score":-1}, "max_count":1, // specific to the “db_query” type permissions
"requestee_app": null, // apps can also ask permission to access other apps here – defaults to the same app.
"sharable_groups":["public"] // defines who can access this.
},
"selfie_share": {
"description":"Share video of you paying game",
"type":"object_delegate", // the type of permission – in this case, giving access to the video file
"collection":"videos",
"sharable_groups":["logged_in"],// sharing with everyone logged in to your server.
}
}

Ultimately the goal is to give a maximum amount of functionality to the app, by defining a set of common interactions patterns with the back end. The configuration file is where each app can outline the back-end interactions it seeks. The file can also be used to provide optional meta-data about the app, and the data structure it uses and to define the css/js files associated with each html page.(More details here http://freezr.info/start/appconfig)

Specifically, the Permission schema in the configuration file serves to safeguard the freedoms stated earlier – specifically to ensure mobility and autonomy. It provides the basis for the mechanisms allowing an app developed by a new developer to replace an older app developed by someone else. 

This sets the level playing field.


Previous Post Next Post




posted by salman on: 6/9/2019, 2:20:10 PM
1560090010678