SAFE App Launcher - Introduction

Development
1

Heya,

So I’m sure you guys might have seen “SAFE Launcher” (should be SAFE App Launcher) mentioned in a few dev update threads / forum posts / new github submodule. Thought I’ll give a quick update as to what it is and why is it being worked on right now. So lets start :smile:

What is it not

This can be quick. Its not some tool to kick start the SAFE network.

Ok. So why do we need this?

As a user, when we use apps that store their data on the network there have been two issues that have bothered a few (more like everyone) of us a LOT

  • Do I give my network credentials to every app to let this app store data on the network for me? - What if this app steals my credentials → Does that mean I compromised “all” my network data cos I made the mistake of trusting one malicious app?
  • As an App dev how can I ensure my competitor doesn’t end up wiping my data stored for a user if the user also allows the other app to access his data?

Before we get into how we plan on addressing these, let’s state the main difference between an app storing user’s data on the traditional cloud storage / SAFE network. In the SAFE network user’s data (app data relating to the user) is stored under the user’s ownership. In traditional systems it’s saved under the app’s ownership. This is why we have the second question pop up since multiple apps are expected to share the same storage location for a user and this might lead to apps either maliciously or accidentaly modifying/removing another app’s data.

Can we fix this now please?

Yes.

Hold up. Can we fix this while still having no servers and keeping the user’s anonymity respected

Yep, Wouldn’t call this fixed any other way. This is where the SAFE App launcher comes in :smile:

  • Credentials in Every App issue:

For this one, our proposed solution is to use the SAFE App Launcher as the only app (on that system) that takes a user’s credentials (PIN, Keyword, Password). With this app then retrieving the MAID details for the user, allow it to “launch” other apps and pass them the required info to communicate with the network directly representing the user.

  • Restrict App priviledges on a user’s account

We can think of this one as a sandbox environment we are setting up for each App. Each app can perform its network storage/operations in its designated location (under the user’s management) and cannot step outside that sandbox. This way apps don’t have the fear of some other app wrecking their data and giving their app a bad reputation.

Sweet. Now how does this “really” work

Well you asked for it :stuck_out_tongue: and considering you’re reading this bit, I assume you are interested in knowing. So here goes (I’ll try to keep it as simple as I can):

As mentioned in the previous section, The App Launcher is going to be the only suggested app that a user should give their credentials to. Let’s answer the basic questions right here. This is an open-source app that users can compile themselves and validate the code to know their credentials aren’t being misused. Also being open-source it doesn’t stop any other person from creating a similar launcher styled app if they so choose.

With that out of the way, let’s have a look at a graphic for the process in which this app functions:

So explanation time: (App-X - An app that uses the SAFE network for storage)

  • Account Creation

  • User Creates / Logs in to an account with the Launcher.

  • Adding an App

  • User installs App-X however App-X wants it installed. From the launcher they select the binary for App-X. This now creates the app sandbox folder under the user’s MAID credential in the network and also stores the app info in their network-session data.

  • Launching Apps

  • Launcher starts listening on a random TCP port.

  • Launcher starts the app, passing it the port it’s listening on.

  • App starts, creates a new, one-time-use RSA key pair for this session, and establishes a local TCP connection to Launcher. The key pair isn’t something the app needs to be bundled with or stored permanently; it’s just for the duration of this session.

  • App passes the session public key to the Launcher via the TCP channel.

  • Launcher registers this key on the network as a temporary session key associated with the user’s MAID, hence giving the app read/write access to the network for as long as it remains connected in that session.

  • Launcher identifies which folder/container in the NFS is this app’s, and passes that info to the app via the local TCP channel.

  • With this info, the app can now connect to the network and start using the NFS interface. The local connection is now dropped and the app has no further dependency on the Launcher for the remainder of its session.

  • SAFE Drive Data

    • To allow apps to share storage locations (picture roll / music / …) user’s will have a choice to also allow any app access to their SAFE Drive. If an app is given this access, it will receive info for two folders when launched by the launcher (one isolated that only this app gets and another which is a shared location)

Great. So I don’t give my credentials to any other app but the launcher?

Yep.

I see the launcher submodule in github, so is it done? can I use it now? I WANT my cookie

Err soz not yet. We’re still implementing it and at an early stage of the process. You can see the to-be UI getting designed by @Shona Here and implemented by Spandan (@ustulation don’t ask me why he has tht as his tag) Here. @anon86652309 is working on the backend to support this and you can see his progress for the library Here We’re still working out the pruning process in the network as in when the network drops the public keys for an app and rejects future requests from the app (as in if when a client goes offline or some other metric).

We’re hoping to have this ready in Testnet-2 phase and iron out any bugs / missing features with your help :smile:. I’ve skipped some minor details like the ability to manage your apps from the launcher or how to pass additional command line args to a binary if it’s launched by the launcher, but that should become clear when you get to try the app out soon

26 Likes
2

This is a question from a computer imbecile, so for all I know, I might be asking a stupid question.

Is the network capable of holding a database of ‘honest/dishonest’ applications based on (say) peer checking of code and user satisfaction, such that when started, an application is checksum checked (or something :blush:) and flagged if found to be suspicious?

1 Like
3

It’s actually an interesting question. The tricky part here is “what do you check against. what if what you’re using as source is corrupted.”

However these questions are easily answered tbh. If it’s a portable app, you can serve the entire app from a public share on the network. Since data chunks are immutable, you can be assured tweaks cannot be made to those original chunks and you will always retrieve the same chunks (this part is automatic). So as long as you use a trusted public-share to retrieve the portable app there isnt a risk of the app being tampered with.

As for reputation and rating’s, that would make an ideal objective for an App on the network. Such an app could take the above point and wrap with it the user element of rating(UX/otherwise) and save the info back to the network(we could possibly add this to the launcher itself in a future iteration). Such an app serving portable binaries tagged with user reputation can make a user’s life much easier.

There is also a hidden benefit to such portable apps. Which is you could have a huge collection of apps linked to your account and when you switch computers, you’ve essentially got access to all of them. You’ll only be retrieving the apps you will be “using” at that particular time. So keeping your huge collection of apps when you only use a few at any time in sync becomes quite easy since updates made to the original public share will auto reflect in you getting the latest version next time you launch it. Last of all when you log out all those portable app binaries are gone from the system as well(this ofcourse means the apps don’t save anything locally, well they shouldnt be anyways :smile: )

9 Likes
4

I feel some binaries are coming :wink:

5 Likes
5

It’s so awesome this is being done. Great job!

5 Likes
6

@Viv thanks for this - both such a well thought out solution to a tricky but vital issue, and for laying it all out so clearly, and in an enjoyable style :slight_smile:

6 Likes
7

You guys are changing the world :slight_smile:

3 Likes
8

Sounds good. Does this system use OS level permissions for dictating access rights?

9

I would just like to point out that the UI is amazing. It’s rare for a project as huge and technical as this to function well and look good! Great job @Shona on the design!

14 Likes
10

@Viv is going to enjoy the conversation, since he had to suffer some back-and-forth on this topic over Mumble on several occasions. I’m not sure how @Viv and @anon86652309 plan to tackle this issue, but basically this Application can be amazing in *BSD/Linux, and satisfactory in Windows/OSX.

The problem is that securely passing the credentials for a specific safe-folder from the launcher to the authorized-app, so that no other app can impersonate the authorized-app, is only possible if separate local OS accounts are used for each app, OR a Jail/Container is used for each app. The Jail/Container approach is appealing because the launcher can automatically start the application in a limited container. Creating local OS accounts for each app is a little “clunky”; in Linux you need special permissions to create accounts, and in Windows I’m not sure if its possible to launch a process as another account (you can launch threads in other processes virtual memory space, so its probably possible).

This problem is similar to when using a local app with OAUTH to some provider (Google, etc.). The provider will give a token to paste in your app that grants access to it, and any local process running under the same privileges can see that token and impersonate the intended app. For example, Google recommends that you pass the OAUTH key in an environment variable. Environment variables can be read in /proc by applications with the same privileges - the issue is identical. The launcher is arguably better here, because it will automaticaly provide the “best practices” for handling the authorization token.

I do not want to detract from the importance of this application, even with the limited security aspects for Windows/OSX users. Users should not be running any application that might be malicious on their local machine, especially outside of a virtual machine/container/another OS account. For instance, a malicious app could always be a keylogger, which grabs your SAFE password. However, the launcher will (hopefully) undergo much more stringent testing than most apps, so the likelihood of a bug that results in password exposure should be minimal (hopefully zero). Since SAFE apps should never handle the account password, a buggy app can only expose data to the folder it was given access to. Still unfortunate, but signifcantly reduces the damage of a software bug.

The browser extension could be the preferred usage for lots of people - in theory each browser tab should be its own container (meaning apps will be unable to impersonate each other in that environment).

6 Likes
11

Interesting! Thanks for the detailed reply!

So, I suppose as long as everything goes through the launcher, the container solution would work well. I assume that apps which aren’t started by the launcher could potentially read/write the contents of the container though? I assume that is a limitation of not have OS level user access control?

Could/will the allocated container storage itself be encrypted and only readable when the launcher starts a session? At least files could only be deleted, but not read by a malicious app (local or otherwise).

3 Likes
12

Thinking about UX, how do you envisage Launcher and LifeStuff and other apps?

Could Launcher be the main gateway to SAFENetwork, with LifeStuff and other “launcher compatible” apps all accessed through this recommended UI?

Obviously developers can make apps that request credentials and authenticate directly with the network, but would it be a good idea to discourage this except where necessary, and to promote Launcher? It would then be the first and primary UI for the network.

1 Like
13

Yep LifeStuff will be a normal app relying on the launcher just like any other app. Easy way to think of the launcher is as a gateway to the network. One of it’s fundamental purpose being “prevent your credentials being entered in multiple apps”.

Absolutely. Devs should be discouraged from asking network credentials from a user directly unless they build an alt launcher app. While stuff like creating an account/logging in functionality can be achieved directly via the submodules, the API project wouldn’t expose these features anymore. Instead it will provide helper functions such as "CreateAppKeyPair() and “ConnectToLauncher(port, key_pair)” (<- names are not final, just off the top of my head.) which make integrating with the launcher pretty simple for an App dev.

Personally I’d prefer this than handle credentials myself. It’s a very simple comparison to what oAuth provides for traditional web auth. Instead of buiding your own authentication system and handling it properly(keep your stuff secure make sure your UI doesn’t leak credentials to some UI “snoop” apps), you chuck that entire requirement and use another system to do the work for you. Just makes your life a bit easier to not have to deal with it.

5 Likes
14

@Viv, that’s good and I agree, a much better security, dev, and user experience.

So… I’d suggest “App Launcher” while true, doesn’t convey the full scope. I’m thinking it is the SAFE Client, SAFE Gateway… the logical place to provide all genetic network functions - or at least direct access to them (credentials management, wallet, farming configuration, messaging/email, invites) which ATM is a step away in LifeStuff and perhaps other apps.

I’m wondering if renaming Launcher (to SAFE Network Client, or just SAFE Network, or something along those lines) and bringing LifeStuff core features within it might create a good UX?

5 Likes
15

I think if we have a majority we can certainly rename the Launcher. I’d steer clear of “client” to not have it be confused with any other app client and gateway sounds too techy but I’m quite picky myself lol. I’d personally even go for something like “SAFE Authenticator” just to keep it simple(it authenticates you on the SAFE network :smile: and people are used to the word with hardware devices generating pins for bank account logins/ other solutions. We can call the process apps use for authentication as safe-auth lol). It should be a name that’s clear and simple that any user should be able to guess the purpose for.

I see this tool as merely something that handles your auth process for the network. Even in a broader scope, I can only get myself to see it as a sort of an “App Store”(more like an Open-To-All App store that doesn’t arbitrarily regulate entries). Like the points I mentioned in my first reply on this thread, having this tool be a “Showroom” for apps would be quite nice and if ratings/reviews are managed by users directly for apps that can be referenced via portable binaries from the network, makes it that much more better. It shouldn’t become one of the same apps it’s showcasing

I’d prefer LifeStuff being it’s own standalone app for two reasons.

  • To keep this tool precise about it’s responsibility and not have it bloated. Some people might only want to authenticate and use third party apps. They shouldnt feel like some messenger/storage-drive/feature is getting bundled without a choice.
  • Also to maintain an equal system. From this tools POV, LifeStuff exposing a messenger feature is the same as someone else from the community developing a messenger, it shouldn’t turn into some sort of MaidSafe app stage.
  • Ok I lied(maybe I got three points :S). To keep it unobtrusive. When you think of an App Store system, you visit it when you want an app/update it maybe if you don’t have auto-updates. It’s not something you constantly see/hear about on your daily usage. You visit it to know about other stuff. I do like that UX element of being present but not in your face. If I as a user wanted something for features, I’ll get an app that specializes that feature set :smile:
5 Likes
16

I like client myself, but what about Safe Browser. This would be particularly good if it were bundled with the capability to manage data permissions, not just for apps but for any kind of user on the network. I know bloating is an issue, but really, I’m not sure that we should limit this sort of feature to apps in the classic sense.

Just out of curiosity, how much of a difference would there be between what you had planned and a P2P data permissions manager?

17

I like Launcher, sounds catchy already.

18

SAFE Authenticator is quite good! That’s really all you want it to do and you don’t want any other app doing it.

Other names for much the same thing might be:

SAFE Credentials Locker
Credentials Authenticator
SAFE Keys app
SAFE Keys Locker
SAFE Keys Isolator
SAFE Identity Isolator
SAFE Identity Locker

I’m liking SAFE Identity Locker, myself.

[edit to add:]

SAFE Identity Safe
SAFE ID Safe

19

Oh I like Safe Keys App

Or Safe Keychain!

20

Are there any more screenshots of the UI?