Android Content Providers for the Web
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Müffke, Friedger
Inspired by the concept of sharing data between apps on Android devices through Content Providers, this talk explains how this can be achieved on the Web today using decentralized identity and storage (identity hubs). This talk has been accepted late to replace "Decentralized object storage An open source decentralized object storage" by Ivan Fraixedes. Due to health issues Ivan's talk had to be cancelled. We wish him a speedy recovery. On mobile devices, users got used to give apps permissions to access their personal data. This can be for example the address book, calendar, pictures or any other file. Re-entering or copying the data in different apps does not make sense. However, on the web, users do it every day. Contact details are re-imported, pictures transferred or videos copied. Some web apps support the integration of 3rd-party services that keep the data at one place. However, apps thereby imply that users have an account with these 3rd-party services. The apps and users depend on the terms and conditions of these services. This dependency can be removed With decentralized identity and storage. In this talk, two current projects are presented that offer APIs to use personal data across web apps: 3Box storage and Gaia storage. It is explained how apps can make use of this type of storage and how cryptographic keys (belonging to a decentralized identity) protect the users' data. While these projects are used today (as demonstrated with existing apps) it is exciting to see that the different projects are working towards a standard of these APIs. The current status is presented shortly at the end of the session.
 Thank you for the introduction. Where was it introduction? Sorry. For the talk before, because it was really great introduction for my talk, I want to build on top of that. So I'm Friedger Möfke. I'm the maintainer of the Android SDK of Blockstack, and I want to talk a bit how you can use decentralized identity in a way that, well, I'm really excited about. It's kind of new technology, decentralized, and everything. Society might not be ready, and if there's blockchain involved, this is not financial advice. So just disclaimer. I'm Android developer for many years, and the concept that really excites me is the Android content providers. The idea is that many apps can access the same data. This happens on Android device through this type component, this content provider, and it's backed by files, or also maybe by the cloud. But really the interesting idea is that your contacts, your images, your calendar sits at one place, and many applications can make use of them. You do not have to type them again and again and again. And now the question is, how can we get this to the web? And this is possible because we have now identities that are decentralized, identities that you can use to make, well, to associate your data with. So we heard decentralized identity. We have a W3 working group. It is self-soverant. Other people can verify it. We had a demo really here five minutes ago. Great. So it's really about cryptographic keys. Once we have a cryptographic key, then we can make work with the data. And there we have this authenticator that owns the private key, that manages your private keys. And application can ask this authenticator to give you some information, some piece that you can prove to, that you are the owner of the key. So I skipped this. We had the introduction. How this DID looks like. So you do not have to have a password anymore. You have 45 different ways how you can create your decentralized identity. And Blockzeg is one of them. We saw Ethereum version in the talk before. So the idea is, when you log in, when you authenticate to your device, you are creating with your cryptographic keys some kind of a proof that you own this key. And yeah. So for Ethereum, there's, for example, three boxes wall. They really have a nice concept where you associate, where your identity is represented with the profile. And this is the Ethereum address. And you get some information about the user. And Blockzeg, using more human-readable way to represent your identity. And it's really about that you can have a proof that you own this private key in the end. And the app wants to have this proof so that they can act on behalf of the user, interact with other users, exchange encrypted messages, talk to other services or other users. So once we have this proof, we might want to store our data at a place that where they know I'm the owner of this data. And that's where we come back to the Android content provider. So we want to have a concept where the user can access or give applications authority to access this data. And decentralized storage, there are different possibilities. The idea is that we don't want to have these honeypots anymore. We had a talk yesterday, Web 3, why this is really bad. And there are different possibilities. But the applications in the end, they don't want to manage all the data of all users. But the idea is that the user is managing their own data. So we want to get away from the state where we know that applications, databases, manage all the users several times for different applications, ABCD, Facebook, Google and so on. We want to move to a place where one user can manage their own data. So for the content provider, what does it mean on the device? So we have the authenticator and the user can now give proof to the application that they can act on behalf of the user and access, for example, the images. So there's one particular key that allows you to access your images somewhere in the cloud, probably. There's the concept of identity hub, but that's the standardization details. I just want to make sure that the idea is clear. You can give another key only to one application, and then this application is allowed to access your contact data. And so these are web applications. So they are served from the web, but they are sitting on your device, and they're working locally. And so, yeah, it's about, oh, let's see. We have the two examples to compare the authenticator, the block stack. You have a web app where you authenticate yourself, so they manage your keys on the web app running on your device. Threebox has the web three authenticators, so you have different browser extensions also on to manage your private keys. And then for the storage there, you have in Threebox, orbit DB, that is based on IPFS, and you have its key value based, and in block stack you have Gaia protocol that is based on existing cloud storage, so really fast and performance and cheap. It's FI based. And what is kind of missing for them that you have the data schema, and I'm gone. Thank you. Thank you.
 Thank you for the introduction.  Where was it introduction?  Sorry.  For the talk before, because it was really great introduction for my talk, I want to  build on top of that.  So I'm Friedger Möfke.  I'm the maintainer of the Android SDK of Blockstack, and I want to talk a bit how you  can use decentralized identity in a way that, well, I'm really excited about.  It's kind of new technology, decentralized, and everything.  Society might not be ready, and if there's blockchain involved, this is not financial  advice.  So just disclaimer.  I'm Android developer for many years, and the concept that really excites me is the  Android content providers.  The idea is that many apps can access the same data.  This happens on Android device through this type component, this content provider, and  it's backed by files, or also maybe by the cloud.  But really the interesting idea is that your contacts, your images, your calendar sits  at one place, and many applications can make use of them.  You do not have to type them again and again and again.  And now the question is, how can we get this to the web?  And this is possible because we have now identities that are decentralized, identities  that you can use to make, well, to associate your data with.  So we heard decentralized identity.  We have a W3 working group.  It is self-soverant.  Other people can verify it.  We had a demo really here five minutes ago.  Great.  So it's really about cryptographic keys.  Once we have a cryptographic key, then we can make work with the data.  And there we have this authenticator that owns the private key, that manages your private  keys.  And application can ask this authenticator to give you some information, some piece  that you can prove to, that you are the owner of the key.  So I skipped this.  We had the introduction.  How this DID looks like.  So you do not have to have a password anymore.  You have 45 different ways how you can create your decentralized identity.  And Blockzeg is one of them.  We saw Ethereum version in the talk before.  So the idea is, when you log in, when you authenticate to your device, you are creating  with your cryptographic keys some kind of a proof that you own this key.  And yeah.  So for Ethereum, there's, for example, three boxes wall.  They really have a nice concept where you associate, where your identity is represented  with the profile.  And this is the Ethereum address.  And you get some information about the user.  And Blockzeg, using more human-readable way to represent your identity.  And it's really about that you can have a proof that you own this private key in the  end.  And the app wants to have this proof so that they can act on behalf of the user, interact  with other users, exchange encrypted messages, talk to other services or other users.  So once we have this proof, we might want to store our data at a place that where they  know I'm the owner of this data.  And that's where we come back to the Android content provider.  So we want to have a concept where the user can access or give applications authority  to access this data.  And decentralized storage, there are different possibilities.  The idea is that we don't want to have these honeypots anymore.  We had a talk yesterday, Web 3, why this is really bad.  And there are different possibilities.  But the applications in the end, they don't want to manage all the data of all users.  But the idea is that the user is managing their own data.  So we want to get away from the state where we know that applications, databases, manage  all the users several times for different applications, ABCD, Facebook, Google and so  on.  We want to move to a place where one user can manage their own data.  So for the content provider, what does it mean on the device?  So we have the authenticator and the user can now give proof to the application that  they can act on behalf of the user and access, for example, the images.  So there's one particular key that allows you to access your images somewhere in the  cloud, probably.  There's the concept of identity hub, but that's the standardization details.  I just want to make sure that the idea is clear.  You can give another key only to one application, and then this application is allowed to access  your contact data.  And so these are web applications.  So they are served from the web, but they are sitting on your device, and they're working  locally.  And so, yeah, it's about, oh, let's see.  We have the two examples to compare the authenticator, the block stack.  You have a web app where you authenticate yourself, so they manage your keys on the web  app running on your device.  Threebox has the web three authenticators, so you have different browser extensions also  on to manage your private keys.  And then for the storage there, you have in Threebox, orbit DB, that is based on IPFS,  and you have its key value based, and in block stack you have Gaia protocol that is based  on existing cloud storage, so really fast and performance and cheap.  It's FI based.  And what is kind of missing for them that you have the data schema, and I'm gone.  Thank you.  Thank you.
dip_android_0_155.png dip_android_156_479.png dip_android_480_839.png dip_android_840_1103.png dip_android_1104_2123.png dip_android_2124_4367.png dip_android_4368_5363.png dip_android_5364_7775.png dip_android_7776_7895.png dip_android_7896_9275.png dip_android_9276_10607.png dip_android_10608_10732.png