SafeEditor MVP, edit your safe files directly from your browser

You have to look at your launcher and not just mindlessly click APPROVE always.

This is what SAFE means, by giving control of your data back to the users, instead of large data companies

There’s responsibility with that.

I agree with you both. On one hand it’s important to allow other apps to access any app`s data so your data isn’t tied to a particular app but on the other hand it can also be dangerous if the user isn’t careful.

A simple solution that would go a long way to help users to be careful would be to show a special code to the user within the app that is going to authenticate and then show the same special code inside the launcher so the user knows from which app the request is coming from.

So the auth API would take an extra parameter and the launcher would show that value inside the yes/no confirm box.

Um, yeah, that’s not gonna work, me approving an app is not a violation of me controlling my data, it is me approving an app to give me the ability to edit while online. I approve the app that says it does one thing, then it duplicates another app and steals my data, the only way I would know the app does this is if it happened to someone else and they reported it. It even happening to someone else first is unacceptable.

“So, this new SAFE Network is out, it is awesome, i control my data, but then I downloaded a photo app so I could edit my data while online, it then stole all my data, turns out my data wasnt so safe, some safe network”

If that is the case, it is all up to me, there should be some warning saying, “if you authorise this unverified app you may lose your data”

I still dont understand how an app pretending to be another is even possible, not technically but how is this even allowed. I still dont understand how this isnt a security breach, it is possible for one app to access another apps data just because I stupidly authorised it. Doesnt make sense to me

I was replying to whiteout as you replied. Can you explain why this is important?

The idea is that you own the data. Apps are just windows to manipulate that data. If an app no longer satisfies you, you can easily switch to another app without being stuck trying to migrate your data by hand. Actually, you couldn’t even migrate it by hand if the first app doesn’t offer that feature. So in the end you don’t really own your data, the app you use does and you are stuck with it.

Take the demo app for example. You use it to create a website. But then it’s not very useful to edit the files. So you have SafeEditor that can fill that gap. At some point maybe another app will be better for uploading a website and demo app won’t be used anymore, but the data will still be the same. That’s what it means to really own your data. Apps are just workers that manipulates your data for you.

Of course that comes with security risk. The current security scheme is pretty basic and like other things feels more like a tech demo to get us starting playing with Safe. It’s gonna have to be much more flexible then that when it goes live.

Anyway, that’s how I see it.

5 Likes

Maybe we need to rethink the Launcher UX here, for example…

Instead of seeing the data as “belonging” to an app, which it clearly doesn’t because another app can access it with the user’s permission, perhaps “Authorisation of an app” is what is misleading here. At the moment, an app can ask for authorisation to access App or Drive:

  • App meaning, a bucket of data that is (behind the scenes) referenced using a hash based on the app’s identifying information (name and vendor I think), and
  • Drive meaning a bucket of data that any App can see providing the user “Allows” it.

What’s confusing is that any App can request and be given access to the App data created by another App - but to do so has to “pretend” to be the other App. This is very confusing in the UI, and misrepresents what is really happening.

So instead of keying the “App” data bucket using the name of the application we should see it as named bucket of data, like Drive, and which any App can explicitly request access to. This removes the need for one app to pretend to be another - it can be honest about who it is, and clear about what it is asking to access.

So instead of authorisation in Launcher saying:

Authorise Request:

AppName: SAFE Demo App
Vendor: MaidSafe
Version: 0.6.0

Permissions:
  None

             DENY  ALLOW     

The app would supply a name for the each data bucket it wants to access, and this would appear under Permissions. If an app wants its own bucket, it can have it, but another app could also request access to the same bucket.

So for the SAFE Demo App it might say:

Authorise Request:

AppName: SAFE Demo App
Vendor: MaidSafe
Version: 0.6.0

Permissions:
  SAFE Demo Files

             DENY  ALLOW     

Then, it would be clearer if another App seeks access to that same data, as in SafeEditor:

Authorise Request:

AppName: SafeEditor
Vendor: DavidMtl
Version: 0.1.0

Permissions:
  SAFE Demo Files

             DENY  ALLOW     

I think this can be tidied up further, by hiding details that are not needed unless the user asks for them by clicking on a “more info…” link. So the authorisation message could be much simpler. For example:

SAFE Demo App ([details=more info...]
Vendor: MaidSafe
Version: 0.6.0[/details])

Wants to access: SAFE Demo Files

            ALLOW  DENY

Note: I’ve reversed position of “ALLOW” and “DENY” as I think the default should be first, reading left to right.

SAFE Demo App ([details=more info...]
Vendor: MaidSafe
Version: 0.6.0[/details])

Wants to access: SAFE Demo Files

            ALLOW  DENY
4 Likes

I like that better too. I would still add the secret code so you know for sure which app is making the call.

Also, access control for the lower API needs to be handled in its own way. Through it you have access to everything, so it cannot be just an on and off switch. I’m very curious to know how they plan to do that.

Yeah, the confusing part here is just that safeditor IS REQUIRED TO disguise itself as the official MaidSafe app, just to use the SAFE Drive public / private files.

That’s the only problem here,

That’s what makes things confusing.

Labelling problem.

1 Like

This is the part that bothers me. This to me as a general user is a security breach. Why is an app allowed to disguise itself as another, what is to prevent me to download a photoapp that I approve that installs a photoapp but also replaces my storeapp without me knowing, on my end all looks the same. Perhaps @happybeing 's response would fix that. Things dont seem to be getting user-friendly… by that I mean things seem to be getting complicated. “Read this, approve that, otherwise you could lose everything, did you read the fine print?”

2 Likes

created a new thread here so as not to hijack the thread.

The unique application ID are explain in this RFC. I don´t know if, in this moment, is implemented.

Application ID is generated using a deterministic approach. Every application will provide its own unique key/identifier string along with the vendor name in the authorisation request. The hash of Vendor name and Unique key provided by the application (SHA512(Vendor + AppKey)) will yield the id of the application.

And also, are some change with the new Low level Api. With this API each App will have a separate encryption key.

Currently one of the functionality of Launcher is to provide sandboxing. Apps which pass through the Launcher (which is the recommended approach because it is considered bad to give one’s credentials to every app) have access to data either within specific folder created for them or within SAFEDrive which is where common data is. No app is allowed to access data in a folder reserved for another app. However this guarantee will be broken once the low level API’s are xposed because apps will have freedom to create whatever data they want and wherever they want it on the network.

Under the current implementation this would mean that private data stored by one app can be potentially compromised (accessed by another app). For e.g. say App-0 creates and stores StructuredData abc somewhere in the network. If App-1 uses a direct GET for abc there is no way Launcher knows this should not be allowed. Previously apps were only allowed to travel a directory hierarchy to get data and Launcher could assert it travelled only the permissible ones.

To get around this limitation, Launcher shall enforce a rule of separate secretbox::gen_key() for each app that registers successfully with it. All private data created on the network by the app will use this to encrypt/decrypt data.
These keys will need to be persistent, so Launcher will write the details in its configuration file against the registered app. Which keys will be used will be determined by CipherOption below. Note that, new nonce shall be generated everytime encryption is used.

1 Like

Well that’s taking it too far, because it will have to request access to your Store data and you would have to approve that yourself,

…making it your fault, in my mind

Thanks for posting that @digipl, it’s an interesting read. I wonder where the idea that sandboxing on Safe is a good idea comes from. The deeper we go that route the less control we have over our data. It feels like we are trying to make Safe work like an iphone instead of an open system.

I don’t like where this is going honestly.

1 Like

perhaps but who knows what the UI looks like, maybe the “store data” part was hidden in the background.

“Though the keys are persistent, there is no way for Launcher to know if one app is mimicking another during the authentication process. So Launcher will ask user each time an app starts and tries to register with Launcher, even if Launcher was never killed in the meantime (unlike currently).”

I also don’t like the fact that keys expire between app restarts. This makes it impossible to pre-auth an app by providing it a specific token, which is necessary for server side or embedded apps. It also means more of these auth pop-ups for interactive apps (causing the user to be less vigilant about granting access).

Perhaps the process needs more thought.

2 Likes

Yeah that would be great, hmm, if you could just always have your list of trusted, pre-approved apps. Wonder if it’s possible

1 Like

anyone else having trouble using safeditor on alpha with Beaker Browser?

it’s like the page isn’t even loading at all

safe://safeeditor.davidmtl

It doesn’t work in the Safe browser yet. i need to change the API for the one provided by the browser. i don’t have the time right now to do it so I’m mostly waiting for alpha 2 to make the switch, (secretly hoping it’s gonna take a few more weeks before alpha 2 starts so I can free my schedule a bit more.)

Edit: the page should be loading though.

Hey I forgot, did you ever release the code for this?

Still one of my favorite SAFE apps ever :slight_smile:

Hi @whiteoutmashups, I would have liked too but I haven’t done the changes since the SafeBrowser prevents apps impersonification so it wouldn’t work anyway.

When the new API comes out I’ll be happy to make it work again if the browser allows it.

Thanks for the support :slight_smile:!

4 Likes