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.
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?”
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.
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.
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.
Yeah that would be great, hmm, if you could just always have your list of trusted, pre-approved apps. Wonder if it’s possible
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 
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 !