Concepts for apps in a decentralised web

Cool cool, sounds great! Let me breakdown some of my thinking then, and try and explain some of the differences in approach we’ve had, so we can compare notes…

Data Access Controls vs Data Sharing Controls

The main thing that occurred to me when digesting the solutions in your thesis was the difference in approach we’re taking to controls over access to data. Certainly worth some discussion. There is some subtlety here, so let me try and lay out solution we’re proposing.

While it’s often touted as a selling point of the decentralised web that users with have fine grained control over access to their data, this is very much a double edged sword, and if we don’t take advantage of some of the inherent data security features of something like SAFE, and simply provide more controls over existing clearnet mental models, then we will end up with quite a painful experience for users. A continuous stream of authorisation requests, decisions, alerts, and ultimately permission fatigue resulting in increased risk; the opposite of what we want.

It’s for this reason, after a great deal of discussion, our starting point for how to tackle these controls was based on putting deliberate controls in the places where there is most risk to a users data: when it is to be Shared or Published.

I noted that you haven’t dealt with granting permissions to Apps within your solution, only access controls for other humans/organisations. Is that to do with a Solid implementation, or some other reason?

While it is absolutely true that apps are much much more like software of old: a user is simply using software to manipulate her own data—an app is merely a view, or window over a set of data—there still remains some potential for malicious apps to do malicious things, like stealing or leaking personal information, or publishing things when I don’t want them to be published. Hence the need for some controls over what an app can do, and when.

We’ve taken the view that by default (I’ll come on to some of the nuance of this later), a user should be able to have an app freely create, view, and edit private data, without any intervention required, but explicit authorisation would be needed before the app could be used to share data with other people (or send anywhere outside of the users private space), or publish it.

So this means that if a user wants to Publish any data, share any data with a 3rd party (e.g. allowing a friend to access a photo I’ve uploaded) , or ‘send’ any data anywhere (e.g. sending an email) then they would need to specifically allow this via the Authenticator.

You could see all this as a users Private, Unpublished data space on the network being like hard drive on their old-skool air-gapped desktop computer. They can insert a floppy disk and install some software, and use that software happily to read, create, edit any of their data on the machine, without ‘granting the app permission’ for them to do it. It’s a given.

The risk comes (and therefore the explicit authentication) when they connect that computer to the Internet and want to send that data somewhere, or publish it, or share it with someone else. That’s opt-in, and driven through deliberate consent.

Varying degrees of intervention

So, in order to give a low friction, understandable experience when placing permissions controls where the risks are presented, we’re proposing varying degrees of intervention into the user’s journey, or flow. This is all just what we a sensible default (a user could choose to to configure these levels of intervention to suit their needs), a balance between control and usability. Let me lay them out:

No Intervention: Authorisation granted without notifying the user.

This would be used for actions that carry low, or no risk to the user’s security, or privacy.

For example, an App could be granted Read and Write access to private data that the user has created via that app, without the user being notified in real time, nor providing up-front consent. (This is enabled via ‘data labels’ which I’ll explain more on later, as it’s handy for other things too.)

Passive Intervention: A user is alerted or otherwise made aware that an authorisation has been granted, but does not need to take a specific action.

These interventions can be used in circumstances where the risk to data security is low, but there is still the possibility for bad or malicious app to cause inconvenience or moderate expense.

For example, writing private data somewhere is low risk to the user’s security, but incurs a data storage cost.

So, if for example, there are per-App and Global spending limits, giving a soft, self dismissing alert to the user when a new App begins incurring this data storage cost the user is kept informed and able to make a direct intervention, without the need to interrupt their flow. Like this…

A passive intervention such as this would be expected and cause no alarm if you’ve just hit the edit button in a new app, but if you’re working away on something else, and suddenly a dozen new app notifications flash before you, then you know you have a problem.

Explicit, Just In Time Interventions: App usage is blocked until the user takes action.

This is for the actions where the risk is high, such as Publishing or Sharing data, or when an action might incur a significant expense.

A user is interrupted and asked to make a decision before they can proceed.

Here are some screens to give you an idea of how that is intended to work:

What you see above there, is a device we’re calling (internally, as it’s a useful metaphor) a ‘permissions manifest’. It’s something that’ll reappear a fair amount, and also the same device we’re exploring for granting access to other users.

I have actually made a YouTube Video walk-though on this that might be helpful, if you can put up with my monotone ramblings that is!

Upfront Permissions: Allowing a user to make decisions on what permissions an app has, ahead of time.

As I mentioned earlier, the in the interests of balancing total control, with experience friction, we think a sensible approach is with a mix of passive notifications and Just-in-time consent. However, some users might prefer (and indeed have requested) to be able to set, or just check, permissions for an app upfront, before it’s used the first time.

Or indeed a user might want to do this only for a specific set of data.

So that’s where a user could opt-in to upfront permissions. And then it would work thusly:



As I said, this sort of upfront intervention is unlikely to form part of the experience by default, as simply giving users lots of choices upfront may appear to give them more control, when in reality it may reduce it, due to ‘pop-up’ fatigue and choice paralysis. We should be aiming for a secure, low friction experience that gives users meaningful choices, so while upfront permissions could be part of the overall suite of tools available, they need to be treated with care in their deployment.

Setting Rules for Permissions

Something I go into on that video, but I notice is not something you’ve proposed in your thesis (unless missed it) was setting specific rules, for example a duration, to permissions. Is that down to a limitation of Solid, or out of scope?

Let me explain what I mean, and we can discuss its merits, and if it might also be useful when considering access for other users as well as apps.

When I’m granting a set of permissions for some data, naturally I can choose what actions the other user, or an app, are able to perform over for a specific set of data.

But at the same time for each, I’m able to specify rules, like so:

Here, I’m about to add a permission to Publish to this manifest, but I’m including the rule Ask Every Time which means I’ll be given a Just In Time permission request each time this app is used to publish any of my data.

Which would then look like this:

The rules we are working with for the moment are Always, Ask every time (as above) Check first time, Until I log out, or a specific duration like ‘3 hours’ etc.

This is for a user’s own app access, but the same kinds of patterns and rules could be extended to access for other users. For example, I give a friend permission to edit a file, but I have to give explicit consent each time they want to publish the revisions they’ve made.

Righty, I’m getting close to the character limit one replies here… so let me break things up into separate posts, more to on user permissions and data structures.

Love to hear your thoughts so far though. Did you consider any of these kinds of ideas, or test any?

21 Likes

As a wee side note on terminology, and mental models around what “Apps” are, and how the user perceives them in the age of the ‘platform’. I note you say:

From Sharing on Platforms to Sharing with Contacts
In the current system users share their content on a particular platform with users on that platform. The decentralised web changes this paradigm. User share directly with other users or groups which can then access the data regardless of the application view they’re using. This is necessary to allow users to exchange one application with another and still being able to view the data they already have been granted access to. It is important that this paradigm shift is communicated to users.

I totally agree. And this is something I think we need to work on through design and language guidelines when constructing these systems.

What a language can be used to indicate this difference?

For example, when designing the UX for SAFE, we are aiming to not anthropomorphise Apps. There is no set of eyeballs behind an app anymore, no company able to take a sneaky peak at your data. This will be a hard idea to shake I think, but the nunaces of language we use will help.

For example, rather than saying “This app would like to access your photos” we might say things like

“Using this app, you’ll be able to access your photos”
“This app needs permission so you can edit this image”.

It’s tricky! And we haven’t got it totally right yet, but hopefully it is something we can be mindful of, and refine as we move forward.

13 Likes

How about:

“Use [app name] to access your photos?” Permit | Deny
“Use [app name] to edit this image?” Permit | Deny

10 Likes

Yeah, that’s a good example. There are many places where this type of language crops up, and there isn’t a one size fits all solution. It’s just something to be aware of, and actively mindful of when writing for UX, as all these small things add up.

It can be tricky as the language has to be short, natural, and easy to digest. And It’s surprisingly easy to slip into the existing mental models, if you’re not on the look out for it.

9 Likes

My thinking there is that the wording implies the user is in control rather than the app, and it shifts the permission part to a button.

Language around permissions is a bit deadening so best to ‘outsource’ it to a control, IMO.

4 Likes

@sergejspomer another area that stood out…

Flat vs Hierarchical Data structures

Another thing I’d like to catch up on, is data structures. I realise that perhaps some of the this is down to the current workings of the Solid stack, but I think it’s well worth discussing, both to get more eyes and suggestions for what we are working on, and also potentially to take some thinking back to the Solid crew too, for I feel there are some real benefits to be had here.

In your work you say:

To give users’ flexibility on how they share their data and enable them to structure their data as they like, all resources are stored in a hierarchical container structure.

With this approach users’ have complete control over where their data is stored and are able to find it more easily if needed. Furthermore, it allows users to how more freedom in how they share their data. They can create different containers for different groups of people they want to share data with. For instance, people can create a container for their family and one for friends and by choosing which social media posts should be stored in which folder, curate which content the different contacts and groups will be able to see.

We started with a purely hierarchical structure to data, in a similar vein, however, there is real benefit to be had in flattening this out, and not binding the access to data to specific locations. I think there is real merit in this, and it may help you with some of the issues you highlight, as well as have the potential to reduce the complexity of the experience over all.

The solution we’ve come up with is also really useful when it comes to reducing risk of more open data permissions, while keeping a much more simplified default permissions setup for apps (as I mentioned in the Data Sharing post above).

Let me try and explain.

On top of a traditional file and folder structure, we have what we call labels. You can think of this like a ‘tag’ on a bit of data or folder.

The first way this becomes really useful, is that every has its own unique label, and any data that is created with that app, automatically has this label applied.

This is super useful when it comes to permissions, as we can apply specific permissions and rules for that label, which in the case of the app label, means a user can have much more permissive controls for data which is created via that app, and tighter controls for other data that exists outside it. That way, I know I can happily install a new app and having it running away doing its thing, with out fear that it is sneaking off in the background and deleting my important files, or stealing my crypto stash. It can only view and have access to data that the user has created via that specific app.

Here’s some screens that hopefully help illustrate some of that:

So above you can see that the o the Typedart app screen there are three rows which each represent a manfest you can click through too. As you’ll see from the wee summary, I can happily use TypeDart to create, edit and share data via the app itself, but it has no access at all to my other data. It’s a mock messaging app, so I’ve decided I don’t want to be able to send anything other that what I’ve typed in the app itself.

It also has access to use some of my Safecoin (which is the currency/token system the Network runs on) to pay for data storage—and creating these messages—but it cannot be used to view my balance, nor send any payments anywhere.

It also allows me to maintain permissions for a given app, but store my files in any structure that makes sense to me. Indeed, that app could be used to create and edit data in any number of locations, and I can move them anywhere I want, yet still maintain control over the apps access to it.

Also along side this is an exception I’ve made for a specific file. TypeDart can be used to View and edit that. But I’ve also made the decision that all new apps I install, will have no access to this file by default. It’s a very important picture of a lion that, so I’ve decided that only Apps I deliberately, manually, opt in can access it. And it doesn’t matter where I move this file, that will remain true.


In addition, labels can serve more traditional purposes too. For example, they can be automatically generated and applied from metadata.

An obvious example use case would be if I wanted to share all my photos with a family member. I don’t have to maintain a folder structure to do this, I’m free to store my photos anywhere, or use any App to edit them, without affecting that linkage.

And users on the other side of the transaction could equally choose too maintain their own structure too, and not worry about breaking anything.

Likewise, I could block users or apps from accessing certain categories of data, and again not have to worry about moving that data having a nasty surprise.

We still have the traditional file/folder/directory structure too, of course, and we can apply all the same types of rules and permissions there, but it works in parallel with labels.

There are areas where a more ridged hierarchy makes complete sense, like a website directory tree for example, yet you get the best of both worlds here, as you can choose flat views of the same information when that is useful, and apply permissions and rules to those as well.

Does that make sense to you? Happy to explain our thinking further if it helps.

13 Likes

Agree that language is really helpful here, and I also think the SAFE App in itself is a huge step towards this problem.

If a user can easily access their files through the SAFE App as well as through the app with which they created them, then that in itself shows they own the files, (as opposed to the 3rd party app,) much in the same way that if a photo is in the photos folder in my OS, then I know by default that I own it, rather than Instagram or whoever. I think the idea of the SAFE App being like an online Operating System is really powerful in subconsciously communicating these ideas.

6 Likes

Thank you @JimCollinson for your extensive reply! A lot of interesting thoughts and concepts here. I’ll try my best to answer you questions and explain my reasoning behind my ideas.


That is indeed a problem which I haven’t given much thought to be honest. My ideas were all based on the idea of access by location. When a person or an app requests access they would say what type of data and what access rights they want. You can see it in my prototype here: https://www.sketch.com/s/0c2f4020-a8aa-412b-a778-3dfa042f7b85/a/z3ooQo/play

That’s where my Idea of data types comes in to play. An app or a person let’s just call them an Agent here, sends a request they specify the data types they would like to access. You can then point them to one or multiple locations if you want. If you have set default locations for this data types they would also be shown here. And of course the level of access.

In this scenario that would mean that you could get a request from every agent at least once. Which still might be a lot. It’s a very interesting problem that I have to think about a lot more.

I did think about it but maybe not quite as much as you did. In my concepts when you connect an app to you pod, you have to give the app permission for the location you want the app to access. you can see it here: https://www.sketch.com/s/0c2f4020-a8aa-412b-a778-3dfa042f7b85/a/4Wqq93/play

When you first connect an app it shows you what data types it wants to access and/or create. Then you select the pod (of you have multiple that is) where you want to data to saved and accessed from and in the last step you can select the locations where this app would have access to. If you have default containers for those data types they would be shown here for easier and faster access. Apps could even provide presets to create new containers for you.

Also, in my approach there is technically no such things as an app that publishes something. Publishing implies, at least to me, that you send it to a server or upload it somehow which you don’t do via SOLID You give access rights for a file or location to agents and then they access it directly from you pod. “Publish” in this sense would mean that my pod would have to notify all agents I just gave access to so that they know they can access it.

What do you mean by an app wants to publish data? Will it be send to a different server or stored somewhere else?


Wholeheartedly agree. I believe this is one of the main problems that data ownership brings with it. The user has to understand that they’re in control of their data, they have to understand which agent has what access rights and they have to deal with a lot of access requests.

In my approach the user would grant access to a location to a agent and that’s all they would have to do. Because there is no “publishing” user would not have to answer request for that. As you can see in my prototype, the user can decide on creation of the data which agents would have access to that data. They could also choose if they wanted to save it in a different location.

The only times, at least what i can think of now, when the user would have answer access request is when a new agents asks for permission ( like a new friend request) or when an app that already has permission creates a new bit of data, saves it i you pod and then wants to give someone else access to it. But I haven’t thought about this case at all.


Setting Rules for Permissions

I think I touched upon some of that briefly but due to the time constraints for my thesis I it was out of the scope. I believe there is the possibility in solid to set duration for permissions but I’m not 100% sure. Definitely something that needs to be explored in more detail!


From Sharing on Platforms to Sharing with Contacts

I totally agree! I tried to do this by shifting away from the concept of apps that create and access certain types of data and more towards the idea of sharing by location. Just like with dropbox or any other cloud storage provider. Like I mentioned apps don’t publish anything by default. So by trying to focus the user on where they store what data instead of “this app does this” like you said. Saying things like

“Using this app, you’ll be able to access your photos”
“This app needs permission so you can edit this image”.

is in my opinion in the right direction and something that is a good candidate for an platform agnostic design principle.


Flat vs Hierarchical Data structures

It’s an really interesting approach.
Because a base assumption or goal in my concepts is to allow the user to switch apps whenever they want without any inconvenience I focused my attention on access based on location so that you can just point a new app to that location and whatever is i there, if the app can handle that type of data that is, is there for the app or the user i granted some permissions to.

My idea behind the hierarchical folder structure and granting permission based on the location was that separate folders would allow more control for what I share with whom.

I also wanted to disconnect the data that is created and the apps that create it. If I created something with one app I want to be able to access it directly with a different one. My idea behind the data types was that it should be more like a universal standard like .json, .pdf or .jpg. So it’s not tied to any specific app. In your example:

While it is true that it would be easier for me to just share all photos with my family because they’re tagged. It would make it harder for me to share specific content with specific groups of people.

Let me give you an example behind my thinking.

One idea I had was that you could have one folder for you social media posts that you share with your friends and family and one with your only work colleagues or professional connections. The folder for you friends and family could contain the folder or container that you share with you professional contacts. In that way, I could just add some data to a specific folder an share it with the people that have access to it. I could also just use different app to create let’s say videos or something and by saving them in the same location I know it shared with my friends.

Because apps or people have only access to specific locations, there should be no possibility for them to snoop on other files or data somewhere else.

I used the analogy of a cloud storage provider like dropbox. You share a specific folder with people or specific files and they can only access them.

Can you provide more detail about your tagging or labelling system and how it works?

In my thesis I mentioned briefly that SOLID has way of handling that problem via redirects. If a user choses to move data, they would be prompted with a message that some agents have access to it and by changing the location that would break. The user can choose to create redirect that would point the agents to the new location of that data if they like to. That redirect can also be set for a certain duration. Due to time constraints this was one of the things I could develop further.

But I definitely see the benefit of having tags for every bit of data. It works great with my idea of data types. Those tags could specify that data in more detail and linked data allows you to do that quite easily.

The problems that come to mind, but also didn’t have much time to think about it, is that when I want to share larger amounts of data with different people. Say I don’t want to share all my photos with my family so I would need to differentiate between them somehow. Maybe with more tags? But then I would have to go through all of them and tag them if I didn’t do it on creation. Maybe I’m not seeing something here, Have you thought about those scenarios?

There are certainly different problems that arise because of the differences of SAFE and SOLID. It’s definitely interesting to see how you approached this topic here and how different it is in certain ways.

I hope it makes sense, happy to explain things in more detail.

9 Likes

Sorry @sergejspomer, I had a rely to this, but totally spaced on hitting send :upside_down_face:

Ah, maybe that’s the part i’ve missed… can you explain what data types are, in the Solid model? It’s perhaps similar to our labels… are they metadata driven?

I’m not sure what ‘Photo Sharing’ is in this context, is this just allowing the Agent to access any photos within the sopecified loactions?


Ah sorry, perhpas I should have explained a bit more about SAFE and the way our different type of datas work.

With the SAFE network, there are no servers really, it’s all just one giant server, but all data on this huge server is encrypted, and access to data is controlled by the owners. I can keep a file private to me only, share access to it with a subset of users, or make it public by publishing it, in which case anyone can access it, and it is perpetually available on the network.


I’ve actually be pondering a bit more on this over the past couple of weeks—and I’d be interested to hear everyones thoughts—but perhaps the term permissions should be reserved for other users/agents, and the term capability could be used for Apps.

So I give an App certain capabilites, like the ability to edit my existing spreadsheets, but I grant permisson to a friend to view them.

Might be worth a test.


I guess much of this is stepping into new territory, and we won’t fully understand in the implications until we can see many more people using these tools, and also see what path developers take too.

My fear is that hinging too much on file location for both data sharing, app utilisation, and user organisation, might end up being too blunt an instrument to satisfy all three sufficiently.

Granted, we have the advantage witn SAFE of not being bound by a file location on a server from the start. It’s a flat file structure by default—really more like a Content Addressable Storage, rather than location based—so each data simply has a random address, metadata, and then keys that enable access to for users and apps.

It’s from this base that we can build the UX, so maybe a slightly different starting point from where you have been working from, so perhaps landing on different solutions.

My assessment was that hierarchical file/folder structure should be there to deal afford users personalised organisational structure, which is highly individualised.

Then when it comes to seemlessly switching apps, but utilising the same data, the user shouldn’t really need to think about the underlying structure or location of that data—which in the first instance, might have been defined by the developer—really their goal here would be something like “I’m getting tired of this FaceGram app, I’m gonna switch over to TwitSpace as it seems much easier”. If I had to understand how things were being structured the scenes on these two apps, before taking the plunge, and those smae structures were also being utilised to manage sharing with other users, I think the task migh become a lot more onerous.

I’m not saying we’ve got the complete solution here yet BTW, we’re just taking baby steps, but starting with a flat file structure, plus metadata, plus labels (both automated and manually applied), plus file/folder structure, an I think we’ve got a pretty flexible base to work from.

I’ll try!

So, you can think of a label like a tag, or a bit of metadata applied to data either in an automated way, or manually be a user. These labels don’t care where the data is stored, they follow it about regardless of where a user moves it (and bearing in mind that more than one user might have access to a file, and choose to ‘store’ it in different ‘places’ on in there own file system views).

The first usecase for this that we are utilising labels for is allowing people to give a new app quite open and permissive access to data that has been created with that app, and yet restrict access to other data. This label would be unique to the app, and automatically applied. Doing this allows me to use the app to store and read data from in location in my chosen file structure, safe in the knowledge that the app cannot be malicious and access existing data without my say so.

Yeah, so the next set of scenarios would be around sharing of data with other users. The thing you have to bear in mind is that I can set permissions based on both labels and file/folder structure. And the other thing to remember is that labels will be predominantly automtically applied, but the can also be manually used too.

So, if I wanted to share all my photos with a family member, but exclude a certain folder, I can do that. Or perhaps I want to share access to only my music files in a large media folder, but I don’t want to have to manually sort things into media/music I can do that too. And also, it doens’t matter if I rearrange things later, it won’t affect the sharing permissions in an unintended way.

Or perhaps I want to share my health related data with a doctor, but only data that has been created with two different apps, and I also want to exclude location data, I can do that too. And those two different apps could have very different file structure for the data the produce, and it won’t matter. Or could organise that data totally according to my own needs and understanding, and my doctor could do the same, and it won’t affect the access to it.

To my mind, it can be a pretty powerful set of tools, and I’m excited for possibilities!

14 Likes

I’m finding this thread very helpful. One thing that reading this is suggesting, is that starting from the right underlying capabilities means that with SAFE we can build anything, well pretty much anything like other systems, on top. Whereas starting from a higher level, in Solid case the Linked Data Platform (LDP) and then adding permissions is limiting.

You can still implement Solid/LDP using different backends (file system, graph store, SAFE Network, AWS etc) but you have to shoehorn them all into Solid/LDP and find ways to do this using the features of your chosen backend, which in some cases is tricky, and has I suspect lead to compromises in the design of the permissions system of Solid.

I haven’t thought about it, but for example, I wonder how feasible it would be to try and implement capabilities for Solid/LDP based on a file system server. It seems likely that if you start with a file system view, you would tend towards a permission based model because that’s already there in roughly the right form. So maybe this has constrained thinking about the permissions design. I believe that the first Solid server implementations were file system based, and think this is still the primary focus, in order to make it easier for people to adopt and deploy Solid servers. So things like this may well have influenced the Solid permissions APIs as well.

SAFE on the other hand is driven from the bottom up. Designed to meet key design goals, then to provide a capable platform, and now to work out exactly what features to offer for developers, how best to express different kinds of use, and how to present this to application users.

Whatever you want to sit on top of this gets the benefits of those first level design goals, and can be implemented at the platform API layer, or a standard protocol layer on top of that (key/value store, RDF, JSON, or Solid LDP and so on). :sunglasses:

9 Likes

Not sure how things would differ under the hood. Are you simply proposing wordage changes or imagining something deeper @jim ?


Aside:
I do hope eventually we get rid of a lot of the differences between an app/user in terms of the ClientHandler layer, and the authenticator becomes an app managing keys. But that (in my mind at least), doesn’t necessarily touch the UI layers at all and is more about simplifying what’s going on in the background (and making the auth and its data structs an ‘app’ in itself… which it sort of is, but sort of isnt as things stand).

Maybe too much bg details for this thread, but just wanted to drop that in in case it impacts thinking from anyone!


Yeh, that’s in line with my thinking. Our goal, IMO is to make sure data that we put up can be easily identified / converted. That will likely be via RDF. But that’s seperate to integration w/ solid etc which is much more a server spec and focussed on clearnet use/integration. So that’s some app layer that you’d put atop SAFE as a storage medium (where ideally, all the data is ready for SOLID consumption) :+1:

6 Likes

Yeah just talking about verbiage, in reference to earlier discussions about not anthropomorphising apps. Apps being just for me to access and do stuff with my own data—and having certain capabilites—whereas users are given permision and a level of autonomy.

6 Likes

Whats the TLDR?
No, not joking.

One thing that would be nice to know is if I can choose to who an app is allowed to share data with.

One problem I have with permissions in todays world when downloading using apps is that I don’t know if the app uses the permissions for functionality, to share data with other users or if the app copies every document/picture/sms and sends it to 10 third party servers, where I no longer have control of the data.

To know if an app uses your data for functionality, share with users or sends the data somewhere else would be nice to know.

Example you could grant permissions for functionality, share with choosen friends or allow the app to send data somewhere else.

1 Like

For the whole thread? :sweat_smile: Well, there’s quite a lot covered here, but it mainly boils down to this…

TLDR; Both Solid and SAFE aim to put users in control over their own data, how it’s used, and who can access it, but they differ in how this is achieved. With Solid, access to data is based on where it is located. Whereas with SAFE, it is based on what the data is.

There are numerous implications to this, and the bulk of the thread is discussing what this will mean for the user experience.

7 Likes

Absolutely. This is the premise of the SAFE Network when it come to apps. Apps are software that I use to manipulate my own data, with no 3rd parties peeping, and I am in control of when that is shared with another entity, or published for everyone to see.

We can acheive this because all data you add to the Network is encrypted, and only you have the keys to it. You can choose to send this data elsewhere, and let other people (or entities) see it by sharing it or publishing it. That is the express purpose of the share and publish permissions/capabilities you’ll grant an app, and the rules and controls we are trying to carefully design.

This is precisely what we are making, you’ll be glad to know. I did a wee video about it a while back, I go into some detail on the overall expeience, but in particular you might want to watch this bit, where I mention give share permissions to an App, and adding a rule for that, and then here where I show the consent screen a user would be presented with each time that app needed to share or publish a specific bit of data.

There are still some risks in terms of malicious, or poorly design apps leaking data (although not clearnet levels of risk of though), and this is one of the reasons we have conceived the data labelling scheme, as a was to ringfence an app’s level of access by default, while still making things usable, and then putting the user in the driving seat when it comes to widening out those permissions.

And there are also other nifty elements, such as account level defaultys and exceptions (also touched on in that video IIRC) which would allow users to wall off certain data entirely, if they choose too.

Yes, this is coming down the pipe too… although I don’t have any screens to show you yet, as this bit of work is slated for the next phase. It’s already begun though, as you can see in the feature tracker. I think we’ve got the bones of the design already with the manifests and controls we already have, but there is fair bit more nuance to it, and it starts to span into other areas such as contacts management etc, so will end being a fairly chunky bit of work.

9 Likes

ChillyClearcutDairycow-size_restricted

5 Likes

5/5

(sorry hat to post multiple times because only one image per post was allowed for me and it messed up the order of the posts. @JimCollinson I added numbers to them so you should ideally read them in order)
Having these data types allows the user to learn what kind of data an app can create and would like to access as well as have an idea where to store those different types of data.

The apps could also leverage this information because it would make it easier to choose the proper visualisation (I explain that in more detail in the paper I wrote)

Also Data Types would allow to create what i called “default containers”. the idea is quite simple. Users can define a container or folder as a default for a specific data type and every time they would be asked where they would like to store that data the system can show them “hey here are your default folder for social media posts, want to save them here?”. That makes the decision easier and faster for the user.

There are a lot more benefits this data types system would bring in my opinion. I tried to show that in my thesis and it was the first try to formulate how this could work. I think if the community could create those standards together, much like we decided collectively on jpegs, txt, json, etc we could extends the same ideas to new types of data structures that would make it easier to move data freely between different apps.

If I need to explain it in more detail please let me know

I think the file systems of our operating system work quite well and people are already used to them so they don’t have to learn something completely new. And we use it already to share data easily (more or less) with other people, to access and modify data with different applications based on their use case.

We don’t care if some created a PDF with word, excel, google drive or acrobat, as long as we know what data it is and where it’s stored we can use it. I think the same would work for different types of data such as social media posts, tasks , projects and so on.

But maybe I’m missing something or didn’t understand you correctly

that’s why the user should decide how their files are structured and not the developers. Like I said before, I think it works well for most people when they use their computers and they are already familiar with the concepts.

So, you can think of a label like a tag, or a bit of metadata applied to data either in an automated way, or manually be a user. These labels don’t care where the data is stored, they follow it about regardless of where a user moves it (and bearing in mind that more than one user might have access to a file, and choose to ‘store’ it in different ‘places’ on in there own file system views).

I agree that a combination of tags, data types and a folder structure would a pretty powerful toolset.
I also strongly believe that we need something like a shared understanding of data be it in the form of my proposed data types or something else. Without that it would be really difficult to enable true data ownership and help people to actually understand what data different apps create and need to access. what apps I can use to modify this specific data and so on.

But I#m also interested to see what other people think here

5/5

4 Likes

Some examples for data types

Those data types here a just an example that I created to test and work with and the general principles have at least worked well for me.

4/5

2 Likes

Or define data types by using the others

3/5

4 Likes