Web Apps and access control

Features
21

Yes, you’ve just supported my point ( it’s your other account, not some third party). I didn’t request that the network should make it impossible to transfer data between accounts. Just enforce the requirement that you need to at least be AN owner of the account, if not sole owner, to get write access. (Again, I think this is the way alpha 2 works now right?.) So this means that you could do all the backups you want with no problem, while also writing to an account that you and your kids have shared ownership of if you wanted to. This way there is no way a bad app is going to be able to phone home to some nefarious devs.

Your example of the nefarious image viewer is a good one. We need to think more on that kind of attack vector. Perhaps the encryption code needs to call back to the authenticator in order to double verify that the encryption key being used is the same as the account owner’s key.

1 Like
22

BUT SAFE doesn’t know that. And why would it require you to be a joint owner. The point was that the backup account is independent so that it cannot be linked to other accounts. I don’t want my business account linked to my personal account because both has a common owner. A tiny bit of anonymity would be lost.

What about consulting businesses that create data/files for customers and they need to transfer the datamaps over to their customers? Bit silly for the customer to give the consultancy firm access to their account(s) as a joint owner just because the network would not allow that sending ever.

1 Like
23

Valid point. The extra layer of security knowing that your data cannot be written anywhere other than an account that you actually have ownership of may be worth the tiny bit of anonymity that is lost. I think it is. Under this scenario, you could always keep the accounts unlinked and transfer files between them via your PC that is logged in to both accounts independently, no anonymity lost in that case.

That’s no problem at all. Currently a lot of cloud services (like dropbox) are used to host shared folders where clients and consultants send big files and docs back and forth. A simple use case would be to just self authenticate an account where both parties’ parent accounts are set as owners. Each would have read and write access for direct collaboration. Files could be uploaded directly to this shared “safebox” aka “safe-drive” or transferred from either party’s account.

1 Like
24

But that is just 2 examples and where extra work is then required.

Also really. You want the consultancy firm to do all their work in the joint account, most don’t want to give customers a look into their creative process and see all the intermediary working.

And then how does the consultancy firm get their templates into the joint account in the first place? The consultancy firm doesn’t want them as public files.

And then how do I share my holiday photos with my friends?

And then how to I send anything to others? without the files being public files?

1 Like
25

An account is just data like an MD right? Doesn’t MD have an ownership field already? Alpha 2 already does the check to make sure a client has ownership in order to write data. So I’m really just suggesting that multi-owner accounts be allowed and to keep things as they are now by not implementing the ability to allow writes to accounts not owned… I haven’t scanned the source in a while @happybeing knows more about the details and will hopefully set me straight if I’ve missed something.

No, that’s not what I was saying. The joint account is just a means to share data they want to be able to edit and modify jointly. Like a shared Google doc or a shared Dropbox folder. Each party can pull a copy into their PC hard drive or private parent account and work independently if they want.

You wouldn’t want to give them write access would you? Happy being already described a method of granting read permissions to your friends.

You grant them read access to something you have explicitly written in your own account. They can then make a copy in their own account if they want to make modifications to it and then grant you read access to the revised document.

If you want to collaborate closely on a specific project, then maybe you will choose to setup a shared account to encapsulate the work.

This methodology changes the attack surface because now you can’t have a situation where a malicious app is logging data and sending it somewhere else without your knowledge. Instead, you just need to make sure that an app has not granted read access to a third party without your knowledge.

2 Likes
26

This is not easily done. You’re talking about Bitcoin mining level of computation to get a small enough “scannable” area. On every persons account you want to steal pictures from. That has to be done on their local computer.

Not many pictures/files/documents will be stolen this way at all.

If I remember from the playground there is a way to choose a location for an MD. Does that apply here? I forget the specifics of how that worked and how it was encrypted.

27

So my friend’s accounts have to have me as a joint owner??? Just so I can send them a image? What if its just one image to a non-friend.

Sorry you are stretching the friendship there :wink: (if you get my drift)

So how does the consultancy firm get the data there in the first place? Joint account with the joint account? where does it end? you’ll have joint accounts all over teh place just to share things. And then does that not defeat some of the original purpose?

So then as an APP writer I would make accounts all over the place. Each has added to it as a joint owner one account I wish to steal from. Then your idea is defeated. I don’t need permission to make you a joint owner otherwise if your idea is in place there can never be joint ownership since there would be no permission to do it. Blocked remember.

Thus why have it in the first place making it difficult for anyone to share a file with various friends.

1 Like
28

You said send any of your data to anyone else.

Thus to read my image the datamap has to be sent. Thus impossible unless its a joint account.

Now say I have 50 circles of “friends” then I need joint accounts for all the circles and joint accounts for subsets, and joint accounts for my singular “friends” which maybe 500 to 1000

So

  • Boss → say 1 to 5 accounts depending on how functional management is structured
    • oh and the boss may have 1000s of these because of all the subordinates he/she has had over the years
  • management group → again 1 to 5 accounts
  • old school groups → maybe 10 (footy team, tennis team etc each class etc)
  • secondary school groups → maybe 20 this time
  • University groups → maybe 50 this time
  • work mates → maybe 20 to 50 after having a few jobs/positions
  • social friends → maybe a few 100 with things from sporting clubs to kids groups to close friends to that special holiday friends to health clubs to whatever
  • then all the sub-groups where you want to give a file to just a couple out of any group. → multiple 100’s of groups by 2 to 5
  • and so on.

And all those groups are ones where “write access” may very well be needed so that documents could be made for things like meetups, meetings, etc etc

If you realise its needed for read too so datamaps can be sent then multiply that by some large figure to cover your lifetime on SAFE.

So over 10 years you may accumulate 100’s to thousands of joint accounts all of which can be backtracked through by intelligent scanning of potential acquaintances. And still it allows APPs to steal images by adding you as a joint owner to their made up account for that purpose.

1 Like
29

My first suggestion with regard to file sharing was to manage it just like Linux with user and group permissions and/or access control lists.

But the thought process then transitioned to the elimination of unwanted writing of data by apps to other accounts without the user’s knowledge. Eliminating this attack vector was the motivation behind denying write access to an account unless the writing entity had sole or joint ownership credentials.

“Send” was a poor choice of word. What I meant was that if I have an app running with my account credentials, it should never be allowed to write data chunks anywhere else but my own shared or unshared account storage.

True you could make an account where I am the joint owner. But I would need to know about the shared account you created and I would have to authorize writing to it from apps in my private (unshared) account. If I don’t authorize the shared account, then a bad app you made me install won’t have write permission to it, even if it knows about the account you made earlier. So now the bad app needs to find a way to trick me into authorizing an external account, which I presume will be much much harder to do if these authorizations pass through the authenticator.

P.s. You have a lot of friends. I hope I get an invite down-unda for the block party when maid hits $1000 :wink:

1 Like
30

Yes I would think that allowing an APP certain permissions and that it is changeable would be useful and help a lot. EG group your files into various groups so that its easier to control permissions based on group or individual file.

Since the APP resides in immutable data then the APP cannot change and abuse those permissions because the permissions are for the APP residing at those immutable addresses (OR use datamap rather than each chunk)

Ah I see what you are saying now. I still disagree that a blanket disallow is really the way to go. Definitely the default and if we use the permissions wisely then we can usefully inform the user what permission is being asked

I would assume this would be the user ID the user is running the APP as. Because remember one of the benefits of SAFE is that people can use throwaway IDs when using an APP/site so that anonymity is kept.

But still the idea that the APP writer could create numerous MDs and add other accounts (user IDs) to be joint owner and add 999 accounts (userIDs) as joint since the 1000 field limit. And then they could write anything to a field of that MD the user is a joint owner of. Obviously the APP writer has to have knowledge of the accounts they want to rob. Not hard really

Then how can a shop operate effectively since data has to be written to the shop so that an order can be placed. Or a forum where some form of index/db has to be written by many people so that their post can be seen by others.

The joint ownership is discovered when the APP tries to write to it so no discovery process is needed. Permission is simply asked of the user.

BUT it defeats the idea of a blanket disallowance of writing to another’s account data objects doesn’t it. And so easy to do also.

So why implement it in the first place restricting valid uses of it and then not requiring joint ownership accounts all over the place with shops, forums, blogs, friends, etc etc

Talk about account spamming. For every account that is actually being used then what would be the average number of “joint” accounts needed to be created just so the user can do certain kind of interactions.

Another use that needs potentially 1000’s to millions.

  • database updating E.G. booking flights,
  • Wiki updating
  • and similar.

Those cannot conceivably have joint ownership and most likely have to be owned by the APP writer (or other ID) and append/update privileges are given globally.

1 Like
31

And of course messaging.

The APP could send a message after asking permissions. Then the message could contain all the datamap addresses it can fit in the message.

That APP could be a forum, shop, mail, or a number of other APPs that might normally need to send a message. (eg Shop - send the order details data object address)

This is then the default way to steal data if a blanket ban is done on writing data to objects owned by another ID.

2 Likes
32

I am not convinced that the use cases you mention would absolutely need shared write permissions (except for a wiki). The apps for the store or forum could write to the user storage and then provide read access.

Even if they did use a shared account, I’m not sure if it’s really a problem. If you allow groups to be owners then you can eliminate the 1000 userID limit.

Yes. This is the big issue isn’t it. Probably the default no matter what. A shared ownership approach eliminates some attack vectors, but now relies even more on messaging and read permissions. Is there a net benefit? I suppose not as much as I first thought.

So now we’re back to the beginning of the discussion. Permissions and acls…

Thanks for bearing with me on the shared ownership brainstorming. The discussion has convinced me that hardcoding cross account write restriction would not be effective enough to warrant the limitations it would impose.

Shared accounts would be a nice feature though.

1 Like
33

My impression was that they will be available

The ability to append to MDs by “anyone” will be huge for many applications and the ability to write to fields in a MD by anyone will also be needed for some Database applications. Even if these appends and writes are restricted to the particular APP.

I think my example of data theft by a supposedly useful APP is a very important one to solve and probably a very difficult one to solve. Especially since the theft can be done by writing to a data object created/owned with/by user’s ID or just by sending a message to another.

2 Likes
34

Maybe a mitigating solution could to be have APPs read (or write/append) your files "indirectly". That is they can request to read the file but the client code does not give the APP the datamap or the chunk addresses being read. Actually is this how its done now anyhow?

That way it’d be like unix where you open the file and the APP uses the handle to read (or write/append) the actual data. At no time is the APP given the datamap or the chunk addresses.

For some special APPs they can ask for permissions to get the datamap or chunk addresses. But these APPs could also be obtained from APP stores where some confidence level could be assigned to the APP as to its trustworthiness. The point is it requires special permissions to allow access to that info.

Then for your files the image display APP would then have to be writing whole images to MDs etc and this is more obvious (eventually) and easier to catch since it involves a lot of data writing and bandwidth.

So when the permission is given for an APP to write say preferences to a MD then the default could be permission for 1 MD object. That is the permission to write could have limits for that permission (time/quantity/whatever)

And my apologies if this little discussion on a particular part of access control was too long.

2 Likes
35

Skin read the thread, but we must be cognizant of what we can/can’t easily manage.

Access to SAFENetwork storage is controlled by the SAFENetwork, so we can manage permissions at this level. However, we cannot control what apps are run and how at the OS level. We cannot control what any app does over clear net or with local storage, display, etc.

So, imo, any solution around security must reflect this reality. We must still trust apps to behave well with data they have read. We can’t rule out bugs or remote control of the app also corrupting/deleting content (read: data maps).

I just think we need to be realistic with expectations here.

1 Like
36

That’s really the point of the question I posed - is it possible to restrict data leakage for Web apps?

@neo has posed a challenging attack. You’re too good at this Rob! I thought it would be hard, and maybe it is unrealistic, but the potential win is big, so I think it is worth exploring and seeing if we can find solutions to things such as @neo has described.

Because if we can replace permission to access with permission to send elsewhere, we get a much healthier app ecosystem and a much better UX. And, we blow all competition out of the water.

Just to recap:

5 Likes
37

One mitigating solution is what I mentioned in the post 2 above yours. And I am not sure if that is already done anyhow and just need to make sure access to the datamaps and chunk addresses requires a separate permission to be granted. Most APPs reading your files will not need the datamap or chunk addresses anyhow since the client libraries are handling the reading/writing of the chunks, so it would be abnormal behaviour except for the “utility” class of applications.

Yes this is needed, and I think that adding a quantity restriction in the permission to write would help a lot too. Basically the APP is only able to write what it claims to need to do.

Another limit to permissions I miss a lot is some sort of time limit or number of runs limit. The time can be based on the user’s device clock since the permissions is for the user and only the end time needs to be recorded with the permission.

4 Likes
38

Why not? Apps sending any tcp packets over old net is rather suspicious and bad etiquette IMO. Same goes for reading files on the local machine that haven’t been explicitly requested for self-encryption and upload. Unless the app is safe-drive should it really be reading and writing local hdd files?

39

Storing the preferences in the user’s private container instead of a new random MD could also mitigate, right?

40

I think it is close to this in that apps don’t generally see datamap and chunk information directly, but even though they don’t see it - unless they go to a lower level API (which they could atm) - they do currently have permission to access this information. So an additional layer would be needed that pushes some of what I think currently goes on inside client libs, out to the network. I think that would be a big change.

At least that’s my thought, but not based on a clear understanding.