Not sure if this belongs here or into RFC 42, as I’d fix it in the user-facing part of the app, but RFC 41 is currently talking about it specifically, so I want to ask this here. I posted a follow-up there.
In the RFC 41 under Detailed Design it reads:
Currently one of the functionality of
Launcheris 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 withinSAFEDrivewhich 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 exposed 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 storesStructuredDataabcsomewhere in the network. If App-1 uses a directGETforabcthere 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 byCipherOptionbelow. Note that, new nonce shall be generated everytime encryption is used.
I am not sure I understand this second paragraph: get around what limitation. The Limitation of being sandboxed? Or to ensure that one App can’t write (accidentally) as the other on the same key?
Either way, do I understand correctly that then the id is globally unique? Or will it be namespaced for the same user somehow? Because all that reads that if someone (accidentally) wrote the userProfile-id, this would the network-wide globally unique. Which would be terrible as no other app could ever use that name again, or any other that has a potential collision. The only way you could half-way assure you aren’t overwriting other stuff apps would be to namespace (aka prefix) the key yourself and use a super-random (as in crypto-random UUID) key. It would also make collisions more likely the more popular the app gets.