Apps disguising themselves as other apps

[anon40790172]

I didn’t read the whole topic, but here’s something we could do as well:

Use the SAFE Beaker Browser to start local Apps and validate the hash of each App before it’s used. That way people might see that I’m using a certain App so it could also be loaded from the users datamap. So:

• Log in to SAFE using the App Launcher
• The Launcher opens the personal map and checks the hashes of the local App.
• When the SAFE Beaker Browser is used the Launcher only allows local Apps that validated correctly by hash.

[Viv]

@happybeing

we can tighten things up in various ways, but if an app chooses to impersonate another app, and the user ok’s this, knowingly or not, nothing we can or should do to stop this.

That is a lot more accurate than my crappy typing cheers mark.

@happybeing

No, it was SafeEditor that alerted @jm5 to the possibility of any an App impersonating any other App and the user accidentally authorising the fake-app.

Yeh “accidental authorisations” are whats hard to nail down. Thats why further fingerprinting of apps and approaches similar to that

@Viv

(extended fingerprinting, dedicated comms channels, low level api and also general apps using their own sign keys as sub keys of user sign keys, launcher educating user abt importance of app authorisations, …)

are certainly worth thinking abt but what makes them hard is weighing against the general UX to then not become a hindrance where the user results with spam accepting or as you mentioned go into auth fatigue.

@happybeing

And it was to address this that I made my suggestion, that by switching from authorising an app, to authorising access to particularly data buckets, we could make it more apparent to the user what they are granting access, and much harder for them to do something they don’t want,

Maybe I still misunderstand this, but I dont seeing this allowing clear indication to the user cos as you mentioned the impersonation control is with the app and we are relying on the app to play good to not get the user to make accidental mistakes. However with something like:

@Viv

Launcher could fingerprint in a more verbose manner say via token validations. so App asks launcher for approval, user chooses to provide access. Now launcher provides user a token say “ABCD” and asks user to input that back to the app and when the launcher receives that from the app, it trusts its validity.

(Just quoting minimal) now the user needs to go back to the original app to finish the auth process thereby adding another step in the auth process and preventing an accidental accept as if the app pretended to be demo app and the user went to the demo app after accidentally hitting accept, its not got access yet and when the user opens demo app thinking it was what asked access, he now knows it never did and is gonna cancel the auth. This again comes at the cost of UX ofc

This I see not needing to for example rely on the app playing by the book cos even if it doesnt user doesnt make the accidental mistake. AND it provides a way for apps to sandbox their content and keep it private from other apps.

@happybeing

I don’t want to derail this topic, but to note the issue because I think it ties together with any discussion of launcher UX.

Yeh I dont think this would be a offtopic thing here at all. Agree with you that this would be a pain.

[DavidMtl]

@Viv

Maybe I still misunderstand this, but I dont seeing this allowing clear indication to the user cos as you mentioned the impersonation control is with the app and we are relying on the app to play good to not get the user to make accidental mistakes.

On the other hand it makes disguising an app very sketchy, not just something we get used to because that’s what an app needs to do lack of a better option. You could even have read/write/delete type of access. Or even customizable access groups. This approach is much more flexible and collaboration friendly.

Maybe the authentication process is made in steps.

Step one, ask basic authorization to access the app’s data. Green background, warning against fake-app and add the special handshake code. If the app is asking for the low-level api change the background to red and warn users about the risks.

Step two (optional), ask for custom access(read/write/delete): Yellow background, ask the user to accept or decline any/all custom requests. This can be done at any time by the app and these can be individually revoked at any time by the user within the launcher. In the future you could add options like one time use only.

Add an API endpoint to get a list of visible folders. Add an option to hide folders for extra privacy.

I believe that would be a pretty good start.

[Viv]

@DavidMtl

On the other hand it makes disguising an app very sketchy, not just something we get used to because that’s what an app needs to do lack of a better option. You could even have read/write/delete type of access. Or even customizable access groups. This approach is much more flexible and collaboration friendly.

It still is sketchy cos it just relies on the same app “not needing to pretend cos there is nothing hidden to it”. Thus comes at the cost of apps not being able to shield their data from other apps for any usecase.

one thing to note is even currently its not exclusive to a sandbox. We have the “SAFE Drive” bucket which is to allow apps to collaborate. So expanding the buckets is something I dont see as needing to be exclusive. Apps probably need to know the scope too.

@DavidMtl

Step one, ask basic authorization to access the app’s data. Green background, warning against fake-app and add the special handshake code. If the app is asking for the low-level api change the background to red and warn users about the risks.

If apps had their own sign key, there wouldnt need to be this burden given to the user as that by itself would facilitate apps not being able to mutate other apps data even with the low level API. Currently they just cant decrypt it, but they can overwrite it if they manage to figure out the backend DataIdentifiers.

@DavidMtl

Add an API endpoint to get a list of visible folders. Add an option to hide folders for extra privacy.

Thats my key point, cos if there were purely buckets and then one app say demo app chose to hide particular folders which then only is visible to it, now we get back to square one where another app might just say “hey I wanted to see what its storing so I pretended to be it” and the user allowed it.

[DavidMtl]

@Viv

Thus comes at the cost of apps not being able to shield their data from other apps for any usecase.

I’ll argue this is a decision for the user to make, not for the app. The app is welcome to make a case for it though.

@Viv

We have the “SAFE Drive” bucket which is to allow apps to collaborate. So expanding the buckets is something I dont see as needing to be exclusive. Apps probably need to know the scope too.

The SAFE Drive is not a very flexible solution. It’s an on and off switch and doesn’t offer any granularity on what to access and what can be done with the data. if we adopt the other model, we don’t need it anymore.

Also the decision to collaborate is given in the hand of the developer. The example of the SafeEditor with the Demo APP shows perfectly why it’s a good idea to give that choice to the user instead. For some reason the demo app doesn’t use the SAFE Drive, that’s a choice its developers made, but we don’t need to wait for them to change their software to start layering other apps over it like the SafeEditor does.

Again, that is not a decision the developer should be allowed to make. This is what owning your data means at the deepest level. The ability to do what exactly you want with it.

@Viv

Thats my key point, cos if there were purely buckets and then one app say demo app chose to hide particular folders which then only is visible to it, now we get back to square one where another app might just say “hey I wanted to see what its storing so I pretended to be it” and the user allowed it.

The ability to hide a folder would be provided by the launcher and only the user would be able to do it. This is not something an app should be allowed to do, at least not without explicit consent of the user.

EDIT: Extra detail. When an app requires the list of visible app. Never include the current app in the list. This way it will not be possible for the app to act on it and decide to stop working if the user decided to not hide it.

[Viv]

@DavidMtl

I’ll argue this is a decision for the user to make, not for the app. The app is welcome to make a case for it though.

sure the usecase can be your safecoin wallet app or say just some other private data app(pictures,texts,…). Now as a user I certainly would not want every app I got to be able to read this accidentally or via a mistake of priviledges. and then step-2 in mutating it and as far as the network goes, these apps dont have another option.

So question would be as an app dev how would someone protect their apps config/priv-data/any info if the ecosystem is open to all apps from that user.

[DavidMtl]

@Viv

sure the usecase can be your safecoin wallet app or say just some other private data app(pictures,texts,…). Now as a user I certainly would not want every app I got to be able to read this accidentally or via a mistake of priviledges. and then step-2 in mutating it and as far as the network goes, these apps dont have another option.

Other apps would still need to ask for access in order to access it. It’s just the name of the folder that can be seen, not its content. Make it invisible by default if you want. What matters is who makes the decision.

@Viv

So question would be as an app dev how would someone protect their apps config/priv-data/any info if the ecosystem is open to all apps from that user.

You don’t get to. These are not your data. If the user allows it you don’t get a say in the matter. Just like on your PC. You can tinker with any files you feel like and it’s a pretty good thing it’s not the other way around.

[Viv]

@DavidMtl

The SAFE Drive is not a very flexible solution. It’s an on and off switch and doesn’t offer any granularity on what to access and what can be done with the data. if we adopt the other model, we don’t need it anymore.

yeh absolutely, I was just comparing it to the similarity of buckets that apps can request access to. If apps get tiered access then there might not be a need for buckets in terms of collaboration.

@DavidMtl

Also the decision to collaborate is given in the hand of the developer. The example of the SafeEditor with the Demo APP shows perfectly why it’s a good idea to give that choice to the user instead. For some reason the demo app doesn’t use the SAFE Drive, that’s a choice its developers made, but we don’t need to wait for them to change their software to start layering other apps over it like the SafeEditor does.

Again, that is not a decision the developer should be allowed to make. This is what owning your data means at the deepest level. The ability to do what exactly you want with it.

Dont know about this one. Its still not really in the control of the user and I agree with you that this shouldn’t be the choice of devs and instead should be the user. I think we’re say looking at this specific case, but say lets assume the functionality provided by SafeEditor and bit more was provided by Launcher.

So lets imagine a tab in launcher that shows the user his entire storage spec and allows him to move data about from one app sandbox to another. Now I think we would say user does have control over the data and he doesnt need a third party app to do it and third party apps cannot do it thereby introducing the risks of accidental auth.

Now in this case apps arent competing to be each other as the user can migrate content / provide on his choosing. Thats how I see the devs dont get the final say in terms of the access levels they request.

Also another perspective, if an app like demo app say did not expose a feature that another app did expose, the user probably is going to stop using the first app alltogether and the second dev makes his earning via showcasing that feature?

Now in this scenario apps merely just need to request user for “access”, they all can get a sandbox and common location. User still remains in control?

[Viv]

@DavidMtl

Other apps would still need to ask for access in order to access it. It’s just the name of the folder that can be seen, not its content. Make it invisible by default if you want. What matters is who makes the decision.

I think I’m maybe misunderstanding what the API provides here. So this would be hidden folders(lets say content) that apps are asking the user access to. sure that should be fine.

@DavidMtl

You don’t get to. These are not your data. If the user allows it you don’t get a say in the matter. Just like on your PC. You can tinker with any files you feel like and it’s a pretty good thing it’s not the other way around.

Yes thats a good point and certainly like the comparison to offline apps, but when it goes online currently users dont even get access to their meta data so thats way past the scale lol, what if an app say a competitor keeps corrupting a different app’s data just to make it seem like the other app is buggy and get the user to not use it.

I do like the comparison to the offline apps and the hidden folders that apps request access to maybe decent too. the UX of same, not too sure how thats gonna scale tho

[DavidMtl]

@Viv

So lets imagine a tab in launcher that shows the user his entire storage spec and allows him to move data about from one app sandbox to another. Now I think we would say user does have control over the data and he doesnt need a third party app to do it and third party apps cannot do it thereby introducing the risks of accidental auth.

@Viv

User still remains in control?

It’s a very limited control. Only option is to live with it or go somewhere else. But why going somewhere else when all that is missing is a feature that another app provides perfectly. For example this means the SafeEditor would need to become better at what the other app is doing just so the user decides to transfer the files into its folder so they can edit them. That just doesn’t work at all.

One of the power of owning your data like on your computer is the ability to layer features over them with multiple apps.

One is a gallery, the other is a picture editor, the next is an indexer, the other is a search engine, the other is a timeline app that presents the pictures chronologically, etc. Of course dev will need to play nice with each others or the user will simply not use their apps. (Btw we have logs to see what app does what, they just need to be more detailed).

Another example: SafeNote is good at taking note but really not at managing them. SafeEditor fills that gap. I don’t need to duplicate that feature inside SafeNote and I can work on more interesting projects instead.

As a dev that’s the kind of ecosystem I’m trilled to work in. And I can’t wait to see how other dev will overlay their apps over mine.

So yeah, that’s just pretty awesome seriously

[happybeing]

@Viv:

So question would be as an app dev how would someone protect their apps config/priv-data/any info if the ecosystem is open to all apps from that user.

• Why would an a app doing this be a good thing? Examples? It isn’t what I’m used to so I don’t understand the benefits yet.

• Why is that good thing, more important, than the user being able to say “I want to be able to access that data with X”?

Is there a model which works like this? I’m not expert, but AFAIK Android etc Apps store data in the file system, accessible to a all.

An Android App doesn’t have exclusive access does it - except perhaps for certain privileged software? Google Play perhaps (?) - which then has the ability to restrict what the user can do with their data and their device (hence the need to root your phone to install certain stuff).

I am not saying that giving apps that ability is a bad thing, but trying to understand why it might be a good thing.

And, if you want to further elaborate, why it is a bad thing to turn the permissions model the other way up and have the user decide which App can access which data (which is I think what we are used to and expect).

SAFE Demo App

As an example: the decision by some developers to sandbox the the files uploaded by the SAFE Demo App, rather than create them in a sub directory of Drive, was not what I as a user expected or wanted. Letting the user decide which other Apps can access those files would have avoided that wrong expectation on my part, and ensured I could do what I wanted with the files it uploaded. @DavidMtl would also not have implemented his App impersonation feature in SafeEditor!

It would be more intuitive to me to have different top level directories with different levels of security. For example: perhaps I could set each top level directory to one of:

• accessible to any app
• ask before granting first access, but remember this authorisation until I explicitly revoke it
• ask before granting access, and revoke access on certain conditions (system restart, time based expiry etc)

These could be further refined to allow read only, or read write, in each category above.

This mechanism would also have a similar UI/UX for the user when sharing files with individuals - so something learned in one context, easily understood and applied in another.

In fact, maybe Apps could be treated just like other users and the same UI used for file sharing, and control of application data access?

[Viv]

@DavidMtl

For example this means the SafeEditor would need to become better at what the other app is doing just so the user decides to transfer the files into its folder so they can edit them. That just doesn’t work at all.

That is a fair point

I think in terms of offline apps apart from what I had misunderstood before with the proposal of hidden folders(hopefully I’m not wrong now ) I’d say we’d agree on the same things.

@DavidMtl

Another example: SafeNote is good at taking note but really not at managing them. SafeEditor fills that gap. I don’t need to duplicate that feature inside SafeNote and I can work on more interesting projects instead.

As a dev that’s the kind of ecosystem I’m trilled to work in. And I can’t wait to see how other dev will overlay their apps over mine.

So yeah, that’s just pretty awesome seriously

This too. I don’t think anyone would intend on breaking collab options between apps cos that’d fundamentally be what drives the ecosystem of apps.

What I’m trying to think of are cases which require tamper proof and specified hidden folders would provide it, would need to see the UX cost of that too though cos some stuff might not be too obvious. Especially with low level API, data doesnt have to follow the file/folder structure and user control to enforce it would have to be traced via such hidden folders if they get buried inside.

@happybeing

Why would an a app doing this be a good thing? Examples? It isn’t what I’m used to so I don’t understand the benefits yet.

prevent competitors from mucking abt with the other apps data, it kinda falls into the trust apps play good, but on the other side we can also just say the user will not use an app thats intentionally mucking a different apps data, like offline apps so can be a moot point.

@happybeing

Why is that good thing, more important, than the user being able to say “I want to be able to access that data with X”?

Yeh this point similar to the collab notion would be what would make me side with the approach. not bucket based, just open for all with hidden folders or so if the UX can get worked out ofc and doesnt become a cumbersome affair for normal users to manage.

@happybeing

Is there a model which works like this? I’m not expert, but AFAIK Android etc Apps store data in the file system, accessible to a all.

Yeh thats not entirely correct. Apps in Android or iOS are sandboxed to a heavy percentage in terms of their local file system access and stuff. ofc rooting/jailbreaking removes all those barriers. but thats also why we get a lot of bucket access when using such apps. access to photos/location/…

@happybeing

I am not saying that giving apps that ability is a bad thing, but trying to understand why it might be a good thing.

lol I’m in the same boat as you, just trying to scope both sides.

@happybeing

As an example: the decision by some developers to sandbox the the files uploaded by the SAFE Demo App, rather than create them in a sub directory of Drive, was not what I as a user expected or wanted. Letting the user decide which other Apps can access those files would have avoided that wrong expectation on my part, and ensured I could do what I wanted with the files it uploaded. @DavidMtl would also not have implemented his App impersonation feature in SafeEditor!

I think the reasoning at the time of starting with demo app was, if a folder was mapped to a service and it went to safe drive and say a file manager app or some other app renamed the folder, then the service would ofc break and not work cos the service would have not been updated. hence why it was reasoned to store data in its sandbox to prevent accidental rename and not update the corresponding service.

[happybeing]

@Viv @DavidMtl thank you both. It’s a useful and important discussion, and I love this kind of stuff. Enjoying it very much and think I’m getting to grips with it better now

For me this is one of the best parts of making software (or anything new) - imagining the what’s possible, why this or that, how and so on. It feels exciting.

[DavidMtl]

@Viv

I think in terms of offline apps apart from what I had misunderstood before with the proposal of hidden folders(hopefully I’m not wrong now ) I’d say we’d agree on the same things.

To summarize the idea.

• A new API endpoint allows authorized app to get a list of app folders.
• Through the Launcher, the user decides which folders should appear on that list. Maybe there’s a checkbox in the authorize popup that is set to hidden by default.
• The current app never knows if the user is hiding or not its own folder. (optional, but I think it’s a good idea)
• Authorized apps can then request permission to read/write/delete files located in any of the folder in the list.
• Through the launcher those permission can be revoked at any time.

Maybe later on we might need ever greater flexibility to handle sub folders but I think this is a good starting point.

@happybeing

@Viv @DavidMtl thank you both. It’s a useful and important discussion, and I love this kind of stuff. Enjoying it very much and think I’m getting to grips with it better now

For me this is one of the best parts of making software (or anything new) - imagining the what’s possible, why this or that, how and so on. It feels exciting.

Same, glad we went through it.

[digipl]

The freedom that authorized apps can request permission to read/write/delete files in any folder is very laudable but give this power openly to anyone is suicide. Sorry but the average Joe, and not so average, is not capable of properly managing applications attempting to access sensitive data, and, at one time or another, will give permission to an harmful app.

This possibility should come off by default and only be accessible in an extremely complex way.

Murphy’s law also exist in the Safe network.

[happybeing]

This is completely wide open on just about every personal computer in use today - so not as disastrous as you suggest!

We can and will improve on that I’m sure.

[Viv]

@frabrunelle is going to kick me but I think we should be seeing another post abt launcher in terms of app integrations / name of the launcher app lol / bundle options / … to consider soon-ish where it’d be nice to pull this suggestion in and discuss further in terms of the impact of UX and how feasible it is going to be for users to manage this.

I see this suggestion(hidden folders that apps “can request” access to) as a good alternative to the app specific sandbox folder in a logical way. Usability and technical details hopefully can continue getting discussed. There are few other points highlighted in the thread too apart from this in terms of auth fatigue / accidental privileges / app package validations. Would certainly want to not miss those points out as they are going to play a vital role in terms of how users finally end up seeing the full package and these access scopes are likely to impact the same too.

This also still has the low level API access which doesnt fall under the file hierarchy system, however with “offline app like ecosystem”, apps might not even need their own encrypt key for low level API and the entire access is just the scope set by the user as to if its just high-level or low-level too. In that sense maybe hidden folders could almost be seen as an added bonus too while comparing UX impact.

should be an interesting discussion combined with the other key points and hopefully an RFC that can provide an impl that we can work with

[digipl]

@happybeing

This is completely wide open on just about every personal computer in use today - so not as disastrous as you suggest!

I thought we were here trying to create a free and secure new system, not to fall into the same old mistakes. Is useless that data are encrypted and dispersed if any application can access them by a simple click error.

At the end any developer should know to whom it is addressed their product and if we want a Safe network for anyone we must follow two rules, be simple and be safe.

[happybeing]

@digipl

I thought we were here trying to create a free and secure new system, not to fall into the same old mistakes. Is useless that data are encrypted and dispersed if any application can access them by a simple click error.

I agree, and you and I share the same aims in this respect I believe. My comment was a response to the extreme language you used. I think “suicide” is too strong. Something we want to improve on as best we can, certainly.

[lightyear]

@happybeing

So question would be as an app dev how would someone protect their apps config/priv-data/any info if the ecosystem is open to all apps from that user.

• Why would an a app doing this be a good thing? Examples? It isn’t what I’m used to so I don’t understand the benefits yet.
• Why is that good thing, more important, than the user being able to say “I want to be able to access that data with X”?

Is there a model which works like this? I’m not expert, but AFAIK Android etc Apps store data in the file system, accessible to a all.

An Android App doesn’t have exclusive access does it - except perhaps for certain privileged software? Google Play perhaps (?) - which then has the ability to restrict what the user can do with their data and their device (hence the need to root your phone to install certain stuff).

As a developer, I can tell you there is plenty of places an App writes and stores data, that if it wasn’t protected, I’d have to consider my app compromised. Settings/configuration are the obvious starting area, but anything that is “app internal” also falls under that, like, an internal cache, or sqlite database with an index of or data I have downloaded. Those all also exist on mobile and are used heavily. And weren’t those apps sandboxed by the system, this would all fall apart. (Also simply because you can’t access an sqlite database safely from more than once thread at a time.)

I do think there is very reasonable case for giving apps at least a configuration-type of folder to store this kind of information. And from the system protect them from especially accidental access, so that you one app doesn’t f*-up another app by messing with its internal data. That would only work if you can safely distinguish apps and app-disguising can be largely prevented.

Of course all this data is still accessible to the user themselves outside of the sandboxing mechanism (also because you sometimes just need to delete it – ehem). But it shouldn’t be shared between different apps. There is a reason we have different databases for different apps.

---

This is mostly about internal data, like metadata, indexes for performance and alike. And I do agree we need to find a mechanism to allow easy access to the actual content across apps. I like @Viv’s idea of “containers” here. Think of how many modern operating systems organise all Pictures in the “Photos”-Folder (which some then even localise, like Mac) and all Photo-Related Apps “know” about that. In the case of the sandboxed mobile, apps even have to explicitly request permissions to these on a case-to-case-bases.

I’ve argued before (and will here again) that permissions need to be more granular. Giving an app access “to a folder” still means it can delete all files in there without asking – or re-arrange the structure and I can’t find anything anymore (and thus render indexes of other apps incompatible). I think we are limiting ourselves largely by thinking of these in terms of ‘files’ and ‘folders’, when there is no need to. What if we instead think of these as “containers” (as a specific data type) with certain features, sub-items and protections. As an example, the “Photos Container” could have a feature allowing an app to “request picture” – that the user triggers in the email app by saying they want to attach a photo. The user the selects the photo from within the “launcher” (or whatever) and the “Photo Container” delivers the selected photos to the app. The App never had any read/write/whatsoever permissions to the container itself or the data it contains.

This is a very common use case on mobile phones today. MANY of them don’t even expose any file system operations to any apps NOR THE USER ever. That there is a filesystem under it, is more a relict of the history of how to organise hard drives than it is needed or appropriate for the use cases. They want to get rid of these structures and their bounds for a while, why would we bound ourselves into them when we don’t even have them in the first place?